Archive for the 'accessibility web standards' Category

Apple, the DMA, and malicious compliance

If you’re the kind of gorgeous funbundle who reads my blog, you’ve doubtless heard that Apple will finally allow full versions of Chrome and Firefox to run on the iPhone, but only in the European Union. This geo-fencing is because Apple has been dragged kicking and screaming into ending its browser monopoly by the European Union’s Digital Markets Act.

Of course, Apple isn’t giving in without some petulant whining in its announcement. Whatever. But more important than its sadness that “the new options for developers’ EU apps create new risks to Apple users and their devices” (conveniently forgetting that WebKit consistently has the poorest record of shipping bug fixes to users) are the restrictive terms under which competition is allowed.

Here’s a video explainer, if video explainers are your thing:

Call me “Brucestradamus”, but I predicted legal shenanigans from Apple as it began to wriggle. I don’t know what the EU can do about Apple’s malicious compliance; the Commission asked us to brief them several times to understand the technical ramifications of the WebKit monopoly (before we turned up, there was nothing in the drafts about PWAs or the restrictions on browser engines). Quite rightly, it didn’t ask us to draft legislation or its enforcement procedures. This is as it should be.

Cleverer people than me, who know about law, have said that Apple is taking the European Commission for fools:

my initial reaction to Apple’s announcement (and related documentation) is that Apple is not seriously complying with the DMA. The objectives of the DMA are to bring contestability and fairness in digital markets, and this is not achieved here. Apple shows disdain for both the DMA and app developers. Its approach to DMA implementation appears to do little for users, other than to deprive them from meaningful choice on the need for protection.

We at Open Web Advocacy didn’t only talk to the European Union. We’ve briefed the UK’s Competition and Markets Authority (whose investigation restarted on 24 January after Apple did some more silliness with lawyers), as well as the Japanese and Australian regulators – and another huge regulator which has asked not to be named. You can bet that all of these will be watching Apple’s malicious compliance very closely, and making notes for when they draft their rules.

Apple continues to find innovative ways to stifle competition, deny consumers meaningful choice, and damage the Web. But its days of doing this are numbered.


In the meantime, I am going out in a few hours to celebrate the fact that Stuart Langridge, co-conspirator and friend, did not die in the year since his last birthday. While we carouse until the second cock, it is plausible that we may raise a glass to celebrate how our little ragtag gang of web developers scattered across the globe is forcing the world’s largest company to begin to behave itself.

(Needless to say, this is my take on the situation and I speak for nobody else. Our “official” Open Web Advocacy blogpost is “Apple’s plan to allow browser competition dubbed unworkable“. Read that, too!)

Reading List 313

Reading list 312

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