Bruce Lawson's personal site

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.

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.

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:

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”.

• Link of the Week: Navigation API: Accessibility technology announcements – a great discussion of accessibility features in the new Navigation API (that replaces the History API). This should ameliorate many of the woes that Single Page Apps cause screen reader users. Also, a great place to start if you don’t know why SPAs can be very hard for disabled users of Assistive Tech, if coded thoughtlessly and untested. Contains a useful Guide for migrating from the existing history API.
• Who can you trust with your online business? asks Jason Grigsby. I’ve worked in many places with a hugely over-engineered tech stack recommended by Consultants that I suspect were secretly working for the clients’ competitors.
• Autocomplete accessibility bookmarklet – “bookmarklet for testing WCAG success criterion 1.3.5 Identify Input Purpose (AA) which requires that if an input field requests personal information about the user, we must apply the appropriate autocomplete value to the field.”
• Blinded By the Light DOM – Eric Meyer on web components and Shadow DOM
• An Interactive Guide to Flexbox by Josh W Comeau
• Generic font families – “groups font faces into categories which could be considered as an initial set of new generics in CSS. The idea is that if you specify a generic font setting and there is a font on your system that belongs to that category, you would not want the fallback replacement font chosen by the browser to be from a different category”. By Richard Ishida
• CSS Blend Modes an interactive tutorial
• Why You Should Use px Units for margin, padding, & Other Spacing Techniques
• A bold new look for the GOV.UK homepage – Some of the most impactful UX/ web design work isn’t done with whizzy animations, or incredibly smooth SPAs. It’s done by better spacing boring old links and boxes. Thanks, gov.uk
• The DMCC Bill: an appeal to common sense – Tom Fish, previously from the UK CMA, on how the GAMMA firms (Google-Apple-Meta-Microsoft-Amazon) are lobbying to hamstring the Regulator by introducing a procedural quagmire.
• Google’s 21-year deal with Apple is the “heart” of monopoly case, judge says
• This new data poisoning tool lets artists fight back against generative AI – “The tool, called Nightshade, messes up training data in ways that could cause serious damage to image-generating AI models.”
• The big idea: has the digital economy killed capitalism? – “Rather than turbo-charging the free market, Amazon et al have brought back a kind of feudalism” by Yanis Varoufakis

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”.

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