Screen readers gain access to important information about the objects and events available to the user on your website or in your application through the Accessibility API.
An API (application programming interface) in general is a way for two or more computer programs to communicate with each other. It is some sort of software interface, offering a service to other pieces of software.
So what is the Accessibility API? Every major operating system (macOS, Windows, the browsers themselves) has some kind of accessibility API. And we'll take a closer look at all of them, their similarities and differences.
Ultimately, all APIs have the same goal: to make the operating system and the applications that run on it accessible to everyone, most likely, of course, to people with disabilities.
Let's look together at the Accessibility Tree in different browsers on different operating systems to give you an idea of what we're talking about here.
Microsoft UI Automation
The current Windows API for accessibility is called UI Automation.
It enables assistive technology products, such as screen readers, to provide information about the UI to end users and to manipulate the UI by means other than standard input.
from the official website of Microsoft UI Automation
The accessibility tree in Edge
As an Edge user on a ThinkPad at work, I'll show you how to access the Accessibility Tree in Edge Developer Tools.
Simply open the DevTools panel by pressing the F12
key on your keyboard and select the Accessibility
tab, where you will find information about ARIA attributes and computed properties of the selected element.
You can even display the elements directly in the accessibility tree instead of the DOM tree by clicking the small icon button in the Elements section.
The accessibility tree has a more specialized purpose. Since not every node, like aΒ <div>
Β or aΒ <span>
Β element is semantically meaningful for accessibility there is no need to be shown in the accessibility tree, while semantic elements, such as landmarks, headings and lists are.
MacOS accessibility API
Although I work privately on a MacBook Air, unfortunately there is not enough space to download xCode to present the Accessibility API.
Nevertheless, I would like to show you how the Accessibility Inspector is structured when it is used, divided in hierarchy, attributes and actions.
Note: This particular example shows the usage of the accessibility API directly on the operating system rather than in a browser.
Figure 6-3 The Accessibility Inspector locked on the System Preferences main window - from the official website
More details on this topic can be found directly on their website about OS X Accessibility.
Checking Accessibility in Firefox
I usually use Firefox on my MacBook Air. So I wanted to show how I see the accessibility tree on a regular basis.
The best combination of screen reader and browser
Each screen reader behaves slightly differently depending on which browser it is used with. Meaning, what, how, or even if they pronounce certain objects.
According to Deque University, the best combinations are
Screen Reader | Browser |
---|---|
JAWS | Chrome, Edge, Firefox |
NVDA | Firefox, Chrome, Edge |
Narrator | Edge |
Voice Over | Safari |
For further information check out the screen reader user survey by WebAIM from 2021. It contains very interesting insights from people with disabilities who regularly use screen readers.
Thanks for your reading and time. I really appreciate it!
Top comments (0)