Thursday, 6 June, 2024 UTC
Summary
Last year, a colleague introduced me to the Interop Accessibility project. I immediately resonated with its charge to “improve the state of accessibility across the entire web, regardless of which platform, browser, or assistive technology.” The project’s mission was compelling but it also represented, from my perspective, a transformative example of shifting accessibility to the level of web platform features.
After digging in further, I learned about Web Platform Tests (WPT), a cross-browser test suite essential to executing Interop Accessibility’s ambitious vision. WPT enables anyone to write a single automated test that runs in all major browser engines (i.e., Chromium, Gecko, and WebKit), thereby ensuring that web technologies such as HTML or ARIA (Accessible Rich Internet Applications) work as expected. It’s never been possible before this to write an accessibility test that runs in all browsers, on any system. Despite some limitations around mobile testing and operating system coverage, WPT holds great promise as a tool for realizing a more accessible and inclusive web!
As an example, the following hypothetical test asserts that the accessibility role of an
<img> element is “image”:<img data-expectedrole="image" ...>
For an inclusive user experience, it’s imperative that roles are accurately computed by the browser and in turn, properly exposed by platform accessibility APIs (HTML Accessibility API Mappings). Roles enable assistive technology users to understand the purpose of user interface elements (e.g.,
button, link, dialog) and with WPT, we can easily verify browser-calculated roles.You may observe that our fictitious
<img> example is missing a text alternative even though it’s required for accessibility. I can add this to test that the <img>’s textual description, supplied via the alt attribute, is properly exposed as its accessibility label:<img alt="stack of fluffy pancakes"
data-expectedlabel="stack of fluffy pancakes"
data-expectedrole="image"
...
>
In terms of the screen reader experience, we expect that this particular UI properly announces as “stack of fluffy pancakes, image”. Another hypothetical example showcasing label calculation for an image button:
<button data-expectedlabel="Order!" ...>
<img alt="Order!" ...>
</button>
Here, the button’s nested content (the
<img>’s alt specifically) provides the accessibility label for the button itself and the resulting announcement would be “Order!, button”. These examples demonstrate the simplicity and power of WPT: with a couple lines of markup, we’re able to quickly ascertain how web browsers expose the accessibility of any DOM element.Note: for those interested in seeing more complex, real WPT examples: resolving ambiguity in label calculation that involves hidden nodes, investigating
display: contents and accessible name calculation for aria-label .Under the hood, when I run the above
<img> test for example, a JavaScript Promise function asserts that the image’s accessibility role and label are calculated correctly by the browser. To this end, WPT uses testharness.js, a JavaScript framework for writing test cases, and WebDriver for obtaining browser-calculated accessibility metadata about DOM elements (at present, either an element’s programmatic label or role). Most WPT accessibility tests are also written with HTML markup and some data-* attributes (e.g., data-testname, data-expectedrole) that provide hooks for WPT test execution and reporting.Tests can be run locally using CLI commands that invoke browser automation. One of the slicker aspects of WPT is its robust continuous integration (CI) infrastructure that runs tests in the WPT repo across latest versions of all major browser engines on a daily basis (and for pull requests)! Test results are stored in the WPT interop dashboard for easy viewing and to help browser engineers improve interoperability. A special thank you is definitely in order to all the people that keep the WPT CI servers running; their hard work provides a well-maintained, reliable, and stable WPT infrastructure.
I hope that the utility of these WPT accessibility tests is abundantly clear: when accessibility semantics (e.g., role) and labels work interoperably across browsers, and in accordance with developer intent, this is a victory for both web developers and users. Thinking more broadly, what if we could regularly test the accessibility behavior of any and all web platform features on the latest browsers in an automated fashion? How much time and effort could this save?
This is why WPT is so compelling: using a powerful, scaleable testing framework, we can produce easy-to-write tests that:
- decrease frustration for code that should “just work”,
- provide a more consistent, accessible experience for the entire web, including your users,
- surface and eliminate cross-browser discrepancies and unexpected accessibility behaviors,
- prevent future regressions of web platform accessibility bugs,
- reduce accessibility QA efforts, and
- allow you more time to focus efforts on other development priorities.
For the reasons above, it’s difficult to overstate the utility of interoperability and the ultimate benefit of WPT: it gets everyone collectively closer to the shared goal and vision of a reliable and inclusive web!
The value of writing WPT accessibility tests isn’t limited to ensuring correct cross-browser behavior or gauging browser conformance to accessibility specifications. WPT tests can also positively influence the very criteria they are written to test. For example, a colleague recently wrote a WPT test for accessible name node traversal and after investigation, we observed that all major browsers failed in an identical manner (which is unusual). We identified multiple specification ambiguities from this work which motivated fixes across browsers. The issue also spawned fruitful discussion on several related topics all in the pursuit of great web accessibility and a best-in-class user experience. Awesome stuff!
In addition to the value of WPT testing for web developers, further benefits include:
- increased coordination between browser vendors
- greater influence on browser vendors to support web technologies in interoperable ways
- reduction of implementation gaps in accessibility standards and specifications
- improved standardization of how code is interpreted by assistive technologies
- concrete evidence of how browsers actually behave thus facilitating fixes, improved behavior and greater browser parity by browser engineers
It’s incredible to see the WPT accessibility testing grow over time with our efforts continually bolstered by more efficient infrastructure, broader testing coverage, and strong partnerships. While Apple has taken a lead role, it’s highly collaborative across partners such as Adobe, Hilton, Mozilla, Google, Igalia, Bocoup, etc. I’m amazed by the degree of diligence, technical knowledge and passion that is demonstrated in all aspects of this project. From both inside and outside of Apple, the deep focus and unwavering commitment towards the mission of web accessibility is infectious. To everyone involved: kudos and keep up the great work!
I’m excited for a future that includes greater WebDriver capabilities in inspecting browser-generated accessibility metadata, in addition to dwindling accessibility gaps across web browsers as a result of productive collaboration. I invite you, dear reader, to contribute to this future of a more interoperable, reliable, and accessible web by writing WPT tests. Please join us!