WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications), often referred to as ARIA, is a technical specification that helps to provide semantic definitions to complex HTML elements. Its purpose is to make the internet more accessible for people who use screen readers and other assistive technologies. By defining web elements and content with WAI-ARIA, developers can improve accessibility for dynamic content and user interfaces.
Read More: Introduction to ARIA for Web Accessibility
When used appropriately, ARIA is extraordinarily helpful for users, but misapplication of ARIA can create serious accessibility issues. In most instances, it’s preferable to use standard HTML, as HTML is more universally interpretable and often much easier to troubleshoot. This is especially true when using the WAI-ARIA “application" role.
ARIA’s application role is intended for web apps that simulate desktop applications
We’re focusing on role=’application' because it’s a landmark WAI-ARIA role. Landmarks are types of regions on a page that a user may want to access quickly, and landmark roles send a powerful signal to screen readers and other assistive technologies. When using one, you’re saying “this is essential for navigation, so don’t ignore it.”
Here’s how the World Wide Web Consortium (W3C) describes the WAI-ARIA application role:
When the user navigates an element assigned the role of application, assistive technologies that typically intercept standard keyboard events SHOULD switch to an application browsing mode, and pass keyboard events through to the web application.
The intent is to hint to certain assistive technologies to switch from normal browsing mode into a mode more appropriate for interacting with a web application; some user agents have a browse navigation mode where keys, such as up and down arrows, are used to browse the document, and this native behavior prevents the use of these keys by a web application.
When utilized properly, ARIA-application allows digital content to emulate desktop application interfaces. It is intended for web applications with complex functionality that cannot be easily addressed via standard HTML.
Of course, standard HTML is remarkably flexible and powerful, and assistive technologies can interpret well-written HTML easily. If a web application contains standard HTML elements like forms, buttons, and hyperlinks, the ARIA “application" role is usually unnecessary. Put simply, assistive tech can handle these types of applications, and there’s no reason to declare your application via ARIA if it will work as intended with a screen reader or other device.
When used incorrectly, the ARIA application role creates serious barriers
The application role can create problems because it restricts assistive devices from using traditional HTML interpretation techniques. If used improperly, this could create serious usability issues. For example:
- A screen reader user may be unable to browse a site by using landmarks or headings.
- Assistive technologies may not be able to navigate the application naturally, and default shortcuts will be disabled.
- Users may not understand how to regain control of their browser or assistive technology.
There are some situations in which the ARIA application role is helpful. Accessibility specialist recommends using the role if a page has no resemblance to a classic document in roughly over 90% of its content.
For instance, if an application has its own menus for controlling navigation and other functions, the user may not need to navigate with their assistive technology’s default shortcuts. The “application" role would be warranted in this circumstance — but developers should still exercise extreme caution when making the decision. If another widget interaction pattern could provide semantics for a widget, use that instead; only use role=’application' when no alternative is available.
Exercise caution when using ARIA landmark roles
The key takeaway: If you’re not sure whether the ARIA application role is warranted, you probably shouldn’t use it. It’s almost always better to let the assistive technology handle things.
Remember, WAI-ARIA can be a powerful tool for improving accessibility, but the vast majority of websites can become reasonably accessible by using standard HTML for semantics. HTML syntax may not be appropriate for websites with elements that change over time or with certain types of user interaction, and in those cases, ARIA can address those challenges.
Developers who use ARIA should test their sites carefully for conformance with the Web Content Accessibility Guidelines. If you’re developing a web application, prioritizing accessibility from the earliest stages of development can help you manage costs while preventing serious issues from affecting your audience.
