Bruce Lawson's personal site

Formstack, autocomplete and accessibility

TL;DR: Until Formstack integrates autocomplete, I don’t believe it’s possible to guarantee accessible forms. Formstack’s inadequate accessibility documentation suggests they do not understand their obligations.

If you find filling in forms boring, you won’t believe how boring coding them can be. And then you have to do something with the submissions, decide on how to archive them, their GDPR liabilities etc. No wonder so many organisations go looking for third party solutions.

For web users, browsers can do a lot of work to help filling in forms accurately and quickly. We’re all familiar with browsers remembering your username and password. Also, all browsers let you input credit card details and other personal data (address, name, date of birth etc) and that can be used by the browser to autocomplete forms, if the developer identifies the purpose of the field:

<input autocomplete="given-name" id="fname" type="text">

(There’s a list of possible autocomplete values in the HTML spec. MDN’s autocomplete documentation is, as usual, excellent.)

A client recently asked me to evaluate their site against the new WCAG 2.2 requirements. One of these is 3.3.7 Redundant Entry which states “Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated, or available for the user to select”. This doesn’t require developers to integrate browser’s autocomplete (logic could be developed to populate from back-end systems), but it could certainly help. And, at level AA (which is the minimum you should aspire to), autocomplete is required by Success Criterion 1.3.5: Identify Input Purpose:

The purpose of each input field collecting information about the user can be programmatically determined when: The input field serves a purpose identified in the Input Purposes for user interface components section; and The content is implemented using technologies with support for identifying the expected meaning for form input data.

The client had made the decision to use Formstack to generate their forms. I pored through the Formstack documentation to learn how to set autocomplete attributes on the HTML it generates, but found nothing. Eventually, I emailed support who replied

Unfortunately, we currently do not have support for this feature however, this is an excellent idea and may be something that we can add in a future release. We recommend submitting this as a Feature Request on our feedback page for our Product team to review for implementation.

I filed a Feature Request, feeling like Winston Smith depositing paper into the Memory Hole. The email contained a link which told me they are “substantially 508 Compliant” (‘508’ is a US accessibility law – note, they don’t claim to be ‘fully compliant’). The page invited me to “get more details and information on our 508 Compliance, please click here!”. “Click here” link text is a failure of the most basic level of accessibility, and the link is broken.

Are Formstack Forms 508 Compliant-
We're very happy to say that our Published Forms are substantially 508 Compliant. This means Users with visual or hearing impairments can fill out online Forms created through Formstack. To get more details and information on our 508 Compliance, please click here!

Nitpicking, but Pat Lauke pointed out 508 still references WCAG 2.0, so the “new” 1.3.5 Identify Input Purpose from 2.1 isn’t necessarily covered by being “508 compliant”, although it is necessary for WCAG. Helpfully, Formstack also has a page Is Formstack WCAG Compliant? which doesn’t talk about WCAG at all, conflating it with 508.

Formstack is committed to complying with the government standards for Section 508 compliance, and we strive to meet the needs of all users, regardless of disability status. To help you create Section 508 compliant forms for your websites, blogs, and social media, our form builder warns you if you're attempting to include features that are not supported by assistive technology. For additional information and resources on Formstack and Section 508 compliance, please review our information and security page found here. Voluntary Product Accessibility Template (VPAT) Many large companies voluntarily choose to follow WCAG and Section 508 compliance guidelines. If you are part of a federal-funded industry, an international organization, or if your company has adopted these internal regulations, you must provide equal accessibility to users with disabilities.

This does not give me confidence that Formstack understands the accessibility requirements of the forms it generates.

Formstack claims that it helps you to “Create the frictionless digital experiences that employees and customers expect”, so it’s bizarre that it doesn’t allow you to integrate with autocomplete; when Google first implemented it in Chrome they found that “by correctly using autocomplete attributes on your forms, users complete them up to 30% faster“.

Of course, browsers will try to help out. Here’s Microsoft Edge valiantly trying to autocomplete a Formstack form:

Formstack showing an error because its heuristics were not able to completely guess the fields

Edge (which is based on Chromium) is packed full of heuristics which even employ machine learning to try to match the previously-supplied user data with the fields. Or, Formstack could simply add simple logic to their form builder so that if I choose a ‘name’ entry field, it adds autocomplete="given-name" to the relevant input field. Perhaps Formstack could expose an “advanced mode” in their designer in which you can attach arbitrary attributes and values to a form element. Until then, I don’t believe it’s possible to guarantee accessible forms if you’re using Formstack.

For humans, “don’t make me think” is a good design motto. For machines, it’s “don’t make me guess”.

Reading List 311

Apple’s EU legal shenanigans

Well, I flipping told you to expect EU legal wrangling as Apple tries to avoid the EU’s Digital Markets Act, which comes into force in May 2024.

This week, I’ve had the pleasure to read the post-modernist triumph that is CASES DMA.100013 Apple – online intermediation services – app stores, DMA.100025 Apple – operating systems and DMA.100027 Apple – web browsers (PDF), which details some of Apple’s attempts to avoid being regulated. I call it a “post-modernist triumph” because its prose is almost as incomprehensible as James Joyce’s Finnegans Wake, and it is so full of preposterous lies and contradictions that it can only be sanely read as a metatextual joke like the Illuminatus! Trilogy.

In order to avoid having Safari being deemed a Core Platform Service (and thus falling under the remit of DMA), Apple argues “Look, those Safaris on iOS, iPadOS, MacOS, TvOS, WatchOS are TOTALLY DIFFERENT PRODUCTS and none of them have enough users in the EU for you to even think about regulating us, alright? We’re a tiny start-up! Will nobody think of the children?!?”. (I paraphrase somewhat).

This is despite the DMA stating

An undertaking providing core platform services shall not segment, divide, subdivide, fragment or split those services through contractual, commercial, technical or any other means in order to circumvent the quantitative thresholds laid down in Article 3(2). No such practice of an undertaking shall prevent the Commission from designating it as a gatekeeper pursuant to Article 3(4).

The commission counters this claim (page 25, paragraph 115) rather deliciously. It notes that the argument put forward by the celebrated law partnership of Messrs Wriggle, Squirm and Weasel Esq. contradicts Apple’s own claims in 64px type: “Same Safari. Different device”.

Same Safari.Different device. Safari works seamlessly and syncs your passwords, bookmarks, history, tabs, and more across Mac, iPad, iPhone, and Apple Watch. And when your Mac, iOS, or iPadOS devices are near each other, they can automatically pass what you’re doing in Safari from one device to another using Handoff. You can even copy images, video, or text from Safari on your iPhone or iPad, then paste into another app on your nearby Mac — or vice versa.

Stay tuned for more exciting fun, brought to you by Apple’s billion dollar legal fiction fund.

Apple Browser Ban: expect EU legal wrangling

Whatever Apple’s real reason for requiring all iOS and iPad browsers to use its own WebKit engine (and therefore be little more than a branded whitelabelled Safari), they claim it’s done to protect customer privacy.

Two days ago, news of another serious WebKit vulnerability became public. Ars Technica quote researchers as saying

we demonstrate how Safari allows a malicious webpage to recover secrets from popular high-value targets, such as Gmail inbox content. Finally, we demonstrate the recovery of passwords, in case these are autofilled by credential managers.

and notes

While iLeakage works against Macs only when running Safari, iPhones and iPads can be attacked when running any browser because they’re all based on Apple’s WebKit browser engine.

So if the iOS WebKit monopoly is for your comfort and security™, it isn’t working very well; the iLeakage bug was disclosed to Apple more than a year ago in September 2022. Another effect of this rendering engine monopoly (AKA #appleBrowserBan) is to inhibit the utility of Web Apps on iOS, because WebKit doesn’t implement certain vital APIs, and users can’t use a different engine.

This had led to the EU’s Digital Markets Act requiring that companies it deems “gatekeepers” can no longer do this:

43: In particular, each browser is built on a web browser engine, which is responsible for key browser functionality such as speed, reliability and web compatibility. When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users.

In September, the EU announced Apple is a gatekeeper, and iOS is a Core Platform Service. The law will come into force in March 2024. We can expect Apple to attempt to wriggle out of anything other than malicious compliance via endless legal wrangling. Here’s a fascinating insight into the legal culture inside Apple, from an interview with Apple’s former General Counsel, Bruce Sewell:

At 28m19s, Sewell describes Apple legal:

with 600 people in my department it’s like a mid-sized law firm. But we still would spend, you know my budget was just shy of a billion dollars a year

At 37m22s, Sewell talks of a previous legal case:

If you can figure out how to get closer to a particular risk, but be prepared to manage it if it does go nuclear, then your company, think of it as a sailing metaphor, your company is able to sail closer to the wind than its competitors are. And that’s a real advantage … The reaction from Tim [Cook] was that’s the right choice. You made the best choice that you could with the information that you had. You didn’t know about these other things. Don’t let that scare you. I don’t want you to stop pushing the envelope because that’s why legal is an important function in the company.

Big Tech is already attempting to water down UK legislation. I don’t expect them to roll over in the much larger EU market.

Reading List 310

HTML popover, videos and display:blackhole

At Barnardo’s, we have a very tight performance budget: All web pages on Barnardo’s products should be less than 100 kilobytes. (This is aspirational rather than a hard rule; as Big Al notes, “To serve users at the 75th percentile (P75) of devices and networks, we can now afford ~150KiB of HTML/CSS/fonts and ~300-350KiB of JavaScript (gzipped)”.)

So while I was prototyping a new project, I decided to use HTML popover to make a ‘lightbox’ when a user clicks on an image or video placeholder to make the media bigger and dim the page behind it. This isn’t quite ready for primetime yet, as it’s not implemented on Safari/Mac, and is still behind a flag in Firefox. But I wanted to kick its tyres because doing something declaratively reduces the amount of JavaScript, leaving more budget for actual content – you know, the thing that the user actually came for.

Also, it’s nice to use a new HTML thingie named after one of my favourite Soviet constructivist artists, Lyubov Sergeyevna Popova (Любо́вь Серге́евна Попо́ва).

As you can see from my popover demo page, it works splendidly for images, with no JavaScript required. Voiceover (on Chrome, as Safari/ Mac doesn’t support it yet) tells me the first image is a button (which it is; popover only works as an attribute on buttons) and that it’s collapsed. Hitting space tells me that the button is expanded, and pressing ctrl+alt+right focusses into the popover, which I can then explore. Hitting esc to dismiss it returns me to the ‘thumbnail’ button, which is announced as once again collapsed.

The video popover is more problematic. All works as expected, but if I start the video and hit esc or click outside the popover to dismiss it, the video disappears from view but the audio continues! Why does the Mr Astley audibly continue to reassure me of his undying devotion and, most importantly, why do those no longer-required bytes keep streaming?

The answer is that when a popover is dismissed, it is set to display:none. Whether the popover spec requires this, or whether that’s just the way the engineers decided to implement it, is unclear to me. You can check that this is how display:none behaves (outside the context of a popover) using this video of Mike Taylr’s legendary Don’t Stop, Donkey Punch video.

As I’m a good web standards wonk, I filed a Chrome bug. I accept that we can’t retrospectively change the behaviour of display:none, as that could break the web. And, as a Chrome engineer pointed out, “one can play audio (or video, e.g., to capture to a canvas) with an element that’s not even plugged into the DOM anywhere”.

So my question is really: should a popover dismissal invoke a special new display mode? display: unperceivable, or display: really-really-none or display: blackhole, or similar? I personally can’t think of a situation in which media showing in a popover should continue playing on dismissal. And if you did want that, you can do it with some JS flim-flam, just as we’ve made popovers for the last 250 years.

But if the point of a declarative standard is to reduce or remove the need for scripting for the most common use-cases, dismissing a video overlay/ lightbox/ popover should default to silencing it and stopping the data transfer, so 99.99% of authors don’t need to write that code.

I’m also told that HTML <dialog> shows the same behaviour if dismissed while an embedded video is playing. There’s an open issue on the HTML spec popover: should audio/video in a popover keep playing after popover is dismissed?, on which you are cordially invited to SPEKE YR BRAINS.

Reading List 309

A screen reader user’s weird tricks to make accessible websites. Number four will shock you!

On Friday, Vadim and I published episode 19 of our podcast, The F-word, with Léonie Watson as a special guest. Léonie is a web standards mover and shaker, a business owner, a total grooving cat, and also a screen reader user.

Leonie, Vadim and me on video chat. We're smiling. Although perhaps Vadim is snarling.

Some of her top tips for making sites accessible:

HTML5 introduced a whole bunch of elements nav, main, header, footer, aside and such. And from a screen reader user point of view these were one of the most amazing strides forward I can remember coming across.

So use them! Here’s my article on the practical value of semantic HTML to get you going.

Should you have very terse, or detailed descriptive alternate text for images? Léonie says,

Not everybody wants to listen to that detail, but you don’t have to listen to it. If it’s there, you can skip past it, or you can stop and listen to it. If somebody decides not to put it there, that choice has gone right out of my hands.

On ARIA:

should you be using ARIA at all? Because from experience the answer is almost always probably not. I’ve probably seen more websites brought down by using ARIA than I have made better for it. To be honest that’s probably one of the biggest accessibility problems I come across … you’ve got to use it sparingly and thoughtfully.

(This isn’t to say that ARIA is always bad. The W3C Using ARIA spec’s first rule of ARIA is “If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so“.)

What’s the biggest accessibility bang for the buck a developer can achieve?

start off with just good quality code. That’s by far and away the best thing you could do for accessibility, especially screen reader accessibility. Screen readers are absolutely dependent on plain old semantic HTML. Divs and spans are our absolute worst thing you can do to us because they’re meaningless.

There you are! Use the right HTML elements for the job. There’s loads more nuance and InfoNuggetz™ in the podcast transcript.

Goodbye Molly Holzschlag–a memoriam post

I woke this morning to the news that Molly Holzschlag is dead. I can’t remember how I first met Molly. It feels like I’ve known her since I started working on the Web. She was definitely one of the people who helped me with the CSS for this very site when I made it in 2004 (she emailed me the code to centre the ransom note logo: .header img {margin: 0 auto;}; there was no social media back then).

Here we are at @media conference in London in 2005:

Bruce and Molly

We co-edited a book together. She was perhaps the only person who could persuade me to go on stage with her at a conference dressed as a cowboy. She came to stay at my house, we got riotously drunk and she threw up on my guest bed. We fell out for a while when we both worked at Opera (about the WebKit engine, ridiculously but so typically). I suspect one team wasn’t big enough two Jupiter-sized egos. We made up again, at Future Insights 2014 in Las Vegas, and celebrated by getting so drunk I lost my laptop so we retraced our steps through the bars we could recall visiting, before I remembered I’d left it on my hotel bed.

And that was the last time I saw her. We stayed in touch occasionally after her illness; her last email was some gossip and backstory on persuading Bill Gates that web standards are good idea. She sent it to me after watching a video of me talking about Open Web Advocacy‘s efforts to end the Apple Browser Bans, which she cheered from the sidelines. Perhaps I’ll include some of it if I ever reprise that talk.

As the announcement in the Tucson Sentinel says

She was steadfast in her insistence that the World Wide Web be usable by disabled people, including sites being able to be parsed by screenreader technology for people with impaired vision.

I was about to type “rest in peace”, but Molly was Jewish, and Jewish chums tell me that the phrase “may her memory be a blessing” is more appropriate. But I think she would prefer “may her teachings about an open, inclusive and humane web be passed on”. They will be.

Farewell Babylon Health

On Friday, TechCrunch reported The fall of Babylon: Failed tele-health startup once valued at $2B goes bankrupt, sold for parts:

It’s the end of the road for Babylon Health, the London tele-health startup once valued at nearly $2 billion after being backed by likes of DeepMind and deep-pocketed health insurance companies. After the company’s U.S. shares became worthless and its operation turned insolvent earlier this month, last night, the U.K. subsidiary of the business formally went into administration. At the same time, the administrators sold a large chunk of its assets to eMed Healthcare UK, a new subsidiary of U.S. company eMed.

Before mid-December 2022, I worked for Babylon until the whole accessibility team (and over a hundred other people) suddenly didn’t work for Babylon any more. It was difficult to understand why; the company had a colossal swanky office opposite Harrods, full of exciting and expensive pot plants. It had floated on the New York Stock Exchange. The after-effects of Covid lockdowns, the continuing pandemic and consequent changes in the way people access healthcare seemed favourable to a telehealth business. Yet suddenly, everything started to go horribly wrong.

But why? The product hadn’t got worse.

It appears that the answer lies in capitalist conjuring. The flotation had been done through some magical process called SPAC: a “special purpose acquisition company” which Wikipedia describes as “a shell corporation listed on a stock exchange with the purpose of acquiring (or merging with) a private company, thus making the private company public without going through the initial public offering process, which often carries significant procedural and regulatory burdens”.

I didn’t know what that means, but everyone seemed very pleased. Lavish floral displays were commissioned for the HQ, staff were promised a commemorative baseball cap or beanie hat (mine never arrived) and best of all, the founder/ CEO Ali Parsa appeared via TV screen on top of a remote-controlled trolley to ring the NYSE bell:

Happy Days! But they were fleeting. Just 13 months later, Parsa described his own decision as “an unbelievable, unmitigated disaster”. Shares were re-wiggled (a technical term that means they were magically multiplied in value by a factor of fifteen to prevent delisting on the Sock Exchange). From a high of $250 they went down to 3 cents, then were delisted.

Sick people in the USA opened the app to login for an appointment to be told “Babylon’s clinical services and appointments are no longer available. For details about your health plan benefits and to find a new provider, contact your health plan”. US staff were terminated and Babylon filed for bankruptcy protection for two of its U.S. subsidiaries.

After I left the company, I spent a few months contracting before deciding what to do next; I work in tech where many companies are Trojan Unicorns: superficially attractive but packed full of asset-stripping shocktroops of venture captialism. I eventually accepted an offer from Barnardo’s, the children’s charity. I’m too jaded to work for an organisation whose fate is in the hands of Capitalist Conjurers, and hate seeing good work by talented people flushed away because of the vagaries and whims of Money Magicians.

Try as hard as I can, I’m finding it hard to summon up many tears for investors like Saudi Arabia’s sovereign wealth fund or Palantir, who won’t see their money again. But then I doubt that they spare much thought for 2.8 million Rwandan people whose healthcare is now in doubt after Babylon announced it is “winding down” Babyl Rwanda.

Luckily, work bezzie Stinky Taylar saw my lament on the Alumni chatgroup about my lack of SPACalicious Babylon beanie, so posted hers to me. It arrived the day before it all collapsed.