A staggering 16 percent of the global population, or one in six people, experience significant disability according to the World Health Organization. Even in developed nations, the numbers are high.
In 2019, 394 million people in the WHO European Region had a health condition amenable to rehabilitation services, which includes sensory impairments. This represents two in five people in the region.
In the face of this immense impact, UX professionals should prioritize accessibility in digital products. This ensures we design inclusive experiences that cater to everyone. We’ll discuss how to do so using modern accessibility APIs in this tutorial.
Modern accessibility APIs make the task of making digital products accessible quite easy for UX professionals and developers. These APIs have come a long way, and their implementation ensures less grunt work on the part of UX professionals and developers compared to before.
You can represent the user interface in terms of a tree-like structure. For instance, an application would have a menu containing menu items, which would then have child items. Modern accessibility APIs understand each of these items in hierarchical terms to decipher their relationship to each other.
The same logic applies to other elements of the user interface. For instance, a radio button would be understood as belonging to a set of radio buttons in a group. The following is an example of an accessibility tree of a simple web page:
There are two main APIs for accessibility — one for the Windows platform and one for the Mac platform. The Windows accessibility API is called the Microsoft UI Automation (UIA), an upgraded replacement for the previous Microsoft Active Accessibility API, or MSAA.
In order to understand Microsoft’s UIA, we have to understand its three main aspects:
Apple’s accessibility API is simply known as the Accessibility API. It’s part of the Cocoa framework for macOS and the UIKit framework for iOS.
Both the Apple Accessibility API and Microsoft’s UIA serve the same purpose: to make the interface elements understandable to assistive technologies. The key difference between Apple’s approach and Microsoft’s is how their APIs are implemented.
Apple’s Accessibility API has a more guided approach to allow for a more developer-friendly experience. The API is also deeply integrated with their assistive technologies, such as Voice Over, Switch Control and Live Listen.
This deep integration allows Apple to provide clear guidelines and documentation on how to implement accessibility, including protocols and methods to expose accessibility information. This makes the process of implementing Apple’s Accessibility API fairly straightforward for developers.
In comparison, Microsoft’s UIA requires developers to utilize an extensive set of control patterns and properties. This makes it more complex and requires more manual effort because developers need to create custom automations to expose their interface elements to the accessibility API.
UIA also needs to work across different UI frameworks on Windows devices, which adds to the implementation complexity. However, there is a bright side to this complexity — UIA is designed to work with third-party assistive technologies on Windows.
To understand the difference in complexity, let’s compare the difference in implementation of accessibility for a button:
accessibilityLabel defined. There are other properties such as accessibilityValue, accessibilityHint, and accessibilityTraits that are optional on an as-needed basisSince Microsoft’s UIA requires more properties defined, you need to have a deep understanding of the boilerplate code. This makes the implementation process more complex to achieve the same result as on Apple’s platform.
Apple’s API handles role and trait mapping automatically based on the nature of the element, whereas Microsoft’s UIA requires more explicit handling of events and controls. Microsoft’s UIA has what’s known as a Provider API to pass on the accessibility information to a Client API for consumption, thus facilitating third-party integrations.
Even though Windows might be the more complex platform, it is better suited for niche use cases where the needs cannot be addressed with readily available assistive technologies. This information will help UX designers make informed decisions on what solutions to implement, knowing the limitations of the two platforms.
Implementing accessibility on web applications is far easier than implementing on native applications. Both Windows and Mac have assistive technologies integrated with their browsers that use the HTML and ARIA attributes in web applications to make them accessible to all users with disability.
The assistive technologies themselves don’t understand HTML. Behind the scenes, the browser builds an accessibility tree using HTML and CSS to be consumed by the accessibility tools built into the browser:
Therefore, to effectively leverage assistive technologies on browsers, UX designers need to advocate for the proper and meticulous use of proper HTML and ARIA attributes. The process is not complex, but it definitely takes proactive effort to include aspects such as alt text in images and ARIA labels, which are typically not needed by users without disability.
The following image demonstrates the difference between non-semantic and semantic HTML. By simply using semantic HTML, we can ensure that our web application is accessible to assistive technologies in the browser:
Most users are familiar with HTML, so let’s take a closer look at ARIA, which is also HTML but its primary purpose is to make websites more accessible by defining different parts of the website in code using labels.
As per Webflow, ARIA was initially introduced to address missing attributes in HTML4. However, HTML5 has addressed those gaps, so it’s always advised to use HTML5 instead of ARIA where applicable.
To create a plan for implementing accessibility, we can start by recognizing that there are four main types of disability: visual, physical, auditory and cognitive. We can then plan to solve for accessibility issues based on these four categories.
For visual disabilities:
Learn more →aria-label that describes what they do to inform visually impaired users of the action they are about to takeFor physical disabilities:
For auditory disabilities:
For cognitive disabilities:
Now, let’s look at the different ARIA attributes to better understand their implementations.
The role attribute is used to define function, which is used by screen readers to understand their function. For instance, the role can be set to banner, navigation, main, search, and so on. These are fairly self-descriptive, but there are a large number of them to choose from, including ones like alert, article, timer, toolbar, tooltip, tab, and more.
The roles can be categorized into the following.
Other than ARIA roles, the other important category of ARIA attributes are states and properties. They define the current condition and characteristics of elements within a page.
For instance, aria-expanded informs screen readers whether a dropdown is collapsed or expanded. Similarly, aria-checked informs screen readers whether a checkbox is checked or not.
The aria-label attribute can be used to describe a button that might not have any text at all. Other examples of ARIA states and properties include:
aria-activearia-currentaria-disabledaria-grabbedaria-hiddenaria-relevantThe examples mentioned above are mostly ARIA state attributes, but there are others for ARIA properties, as well.
While discussing the extensive nature of ARIA attributes, it’s important to mention the need to be cautious about the overuse of ARIA. Overusing ARIA attributes can have the opposite effect of making the webpage more confusing for screen readers. Make sure you conduct exhaustive user testing with real users to ensure the end result is effective and not overwhelming.
Before concluding this article, one last point to keep in mind is that accessibility APIs might struggle to interpret complex user interfaces, or non-standard UI elements.
For such scenarios, aria-label can be an easy solution for web applications, but for native applications with complex patterns, Windows has the properties to address complex changes in UI. Developers will have to be more cautious or consider alternate solutions for the Apple equivalent of the action.
It’s generally agreed upon and understood that designing for accessibility improves brand reputation and trustworthiness. Unfortunately, accessibility efforts are often reactive, tending to arise from avoiding lawsuits. That kind of approach results in delivering the absolute minimum.
Putting in the effort to make the product accessible as part of your core plan makes it more cost effective to implement in the long run. This approach usually also results in a superior end result due to meticulous planning and consideration.
Therefore, UX designers should champion accessibility as both a noble cause and a business decision that leads to better outcomes.
LogRocket's Galileo AI watches sessions and understands user feedback for you, automating the most time-intensive parts of your job and giving you more time to focus on great design.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
We’ve all made silly mistakes in apps — clicked the wrong thing, deleted a file too soon. This guide walks through 12 real UX examples that help users avoid those moments entirely.
Users rarely welcome change, even when it improves their experience. Learn how to communicate updates, handle pushback, and keep users from jumping ship.
Documentation may not be your favorite part of the UX design process, but it’s crucial to the success of any design project.
I’ve spent enough time designing with WCAG 2.2 to know it’s not enough. Here’s why I’m skeptical and cautiously hopeful about WCAG 3.0.
