I'm so happy about what Interop 2022 is doing for web compatibility in general. It made me think: what if we had something similar, but accessibility-specific, focused on compatibility between our code, assistive technologies and browsers? Excitingly, ARIA-AT pretty much has that goal.

Interop 2022 is great

In the Interop 2022 effort, all major browser vendors, browser engineers and other stakeholders agreed “to solve the top browsers compatibility issues identified by web developers” in one year. I danced a little when I saw that. I mean, they align their priorities between them and web developers get a say in what the priorities are. Excellent.

Subgrid, <dialog> and scroll-snap are tremendous features, but consistently cross-browser supported subgrid, <dialog> and scroll snap (and more) are the real deal. Because browser compatibility issues can be quite the nuisance. They make web development harder and more expensive. Web developers end up with a choice between either supporting less browsers or adding hacks and more bloated code. Either option likely trickles down to the experience of end users.

Unrecommendable web platform features

As an accessibility specialist, I spend some of my time giving advice on how to code accessible UI components. From time to time, I want to recommend a thing, but I don't, because of bugs or inconsistencies somewhere between browsers and assistive technologies.

I asked on Twitter what people's top issues were:

If you could fix 3 bugs in assistive tech or browsers, to make building accessible UI components more straightforward, what would they be?

Some responses that came in, all browser focused:

• display properties (still) break default semantics (thanks Adrian Roselli for all his work documenting the issues in detail)
• the HTML video player has keyboard accessibility, focus management and screenreader issues in various browsers (see also: Scott Vinkle's post How accessible is the HTML video player? from 2019)
• aria-controls is not or weirdly supported by screenreaders
• The expanded state of details/summary is not communicated to users of screenreaders in Firefox if the arrow is hidden (as documented by Scott O'Hara in The details and summary elements, again). That's a problem: conveying status to assistive technologies is a core feature of functionality that does visual expanding and collapsing
• aria-owns is not supported in Safari (see also: Diego Haz' demo)
• Default field validation cannot zoom

Having these issues open for so long hurts web accessibility:

• developers who aren't aware may think that by using the platform they get accessibility by default and unknowingly build something inaccessibly
• developers who are aware may end up adding all sorts of hacky code to fix the issue on their end, which could lead to maintainability issues in the long term and makes accessibility unnecessarily hard
• developers generally will have a greater chance of shipping inaccessible interfaces

On Twitter, people also replied with other interesting ways browsers could improve accessibility, like a browser implemention of “skip to <main>” (as Léonie suggested) or even to any landmark (as Curtis said).

And then there are issues around what browsers do, but (some) accessibility specialists disagree with, like that <dialog>'s focus trap can escape to the browser chrome. I've heard from developers whose accessibility consultants recommended them not to use <dialog in the first place and that's an issue.

I believe in personal responsibility when it comes to building a more accessible web. Teams need to test their work and ensure accessibility. But at the same time, change in the primitives (like browsers and CMSes) is needed and can improve a lot of accessibility at once. All of the above issues are most easily solved by browsers, not individual web developers (see also my earlier post, More accessible defaults, please).

ARIA-AT

If we look beyond just browsers and focus on assistive technologies, an interesting project comes to mind. The W3C's ARIA-AT Community Group has the goal to ensure “assistive technologies work with web code in predictable ways”. The group works on interoperability in four ways (taken from their homepage):

• write tests; they help ensure alignment between how assistive technologies behave, and with that, what users can expect
• run tests across different assistive technologies (currently focused on screenreaders, including JAWS, NVDA and VoiceOver)
• build consensus in the industry
• enable scalable automated testing (for which they are writing a standard, see the AT Driver explainer)

The ARIA-AT explainer video explains why this is so important: “there are hundreds of interpretation issues between screenreaders,” and “the way screenreaders and browsers interpret web code changes all the time”.

I am very excited for this project, it will be super cool to see the test results pop up in places like the ARIA Authoring Practices Guide.

Summing up

It would be great for the web to see browsers prioritise accessibility bugs and align between them on the accessibility aspects of current features like <dialog>, <video>, form validation and aria-controls. Either as part of the regular Interop program, or separately. At the same time, returning to the question I started with: yes, more interop between assistive technologies would be very welcome. Improving how assistive technologies interpret our code is a fantastic goal—I'm excited for the impact ARIA-AT will have.

---

Originally posted as Do we need an Interop for assistive technologies? on Hidde's blog.

Reply via email