Use of ARIA with assistive technologies

What is ARIA?

ARIA is an acronym that stands for Accessible Rich Internet Applications. Developed as part of the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) and first published in 2014, the main purpose of ARIA is to provide a way to make interactive internet applications (i.e. web apps) accessible to people with disabilities, particularly screen reader users.

Before ARIA, it was very difficult, and at times even impossible, for screen reader users to understand what was happening in dynamic web applications. Without Live announcements a screen reader user may not have had an ability to hear chat messages or live sports score updates; the user would not be informed about even the slightest change in content and therefore could not react to these changes. While webpages may be written in HTML, its disadvantage against ARIA is that it allows a screen reader user to recognise only a few kinds of elements, and it is currently not able to identify some essential user interface components such as menus, tabbed applications, tabbed panels, progress bars, sliders and volume control buttons.

Furthermore, with the implementation of ARIA it has become much easier to handle errors and to interpret the type of an element when the focus moves to an unfamiliar object, since it provides additional semantics to describe the role, state and properties of many familiar user interface components. ARIA has also drastically changed the structure of a webpage by introducing a number of new keyboard shortcuts that allow screen reader users the ability to navigate by headings, landmarks, tables, lists and to access all aspects of the text, including misspelled words.

The role of ARIA in the structure of the web

Despite obvious advantages of ARIA, it is worth noting that it is not a programming language that has a solution for every accessibility issue reported by customers, but just an API for communicating information to assistive technology users. Therefore ARIA should not be seen as a replacement for well-known methods of marking web content. For example: to create a tree menu, a tab panel, or any other interactive widget, JavaScript is used in order for it to function correctly on the webpage, and using ARIA may be inappropriate or duplicate information to the user. Furthermore, ARIA is not the only way to add names or labels to HTML elements; many of them can be easily marked by non-ARIA tags or attributes. For example:

  • <label> tag┬ádenotes the label for a form <input>
  • <legend> and <fieldset> are native HTML tags that are used to group form elements
  • The alt attribute serves as the name, or text replacement, for an image.

These are just a few examples that prove the existence of traditional methods that usually have the best support, especially in old versions of desktop applications as blind and partially sighted people may be reluctant to change to newer technologies that may be more complicated to learn and operate via a keyboard.

Current assistive technology ARIA support

Before applying certain ARIA rolls to form controls or widgets, it is worth investigating best practices for their support for the most popular assistive technology software among blind and partially sighted people. For best results the following screen reader and browser combinations should be used, as recommended by

  • JAWS with Edge or Chrome
  • Narrator with Edge
  • NVDA with Firefox
  • Voiceover with Safari in iOS and MacOS
  • Talkback with mobile version of Chrome.

The main causes for ARIA accessibility issues

In my experience, inappropriate implementation of ARIA may often lead to the following accessibility complications:

  • an inability to identify well-known elements, such as links, headings or buttons that may lack semantic meaning or keyboard focus.
  • misuse of ARIA may affect the individual capacity of locating new content, since it may become difficult to mentally divide the main menu from other important sections of the web page.
  • in some cases, adding redundant roles or empty attributes may create issues related to extra information. For example, in required fields assistive technology users to hear the content in adjacent inputs or form controls.

From these examples and others that could be mentioned, it shows the need for proper use of native HTML or CSS tags instead of ARIA. Doing so will help avoid unforeseen errors that may have an impact on the efficiency of task completion.


ARIA is a set of attributes that help screen reader users to understand the content of webpages and be informed of changes on the page as they occur. ARIA has many benefits that greatly improve the browsing experience for assistive technology users, including collaborative working, error handling techniques, reading live scores and status information. Moreover, with the introduction of ARIA it has become possible to operate interactive user interfaces and have an equal access to social media platforms.

However, ARIA is not always the appropriate choice and it is therefore important that at every stage of the development each resource is tested and research is conducted for the most supported techniques that are available. Doing so may take less time to develop a correct solution from the start than to fix an issue in the later stages of production. ARIA should therefore be used as a resource where there are no traditional solutions available and not as the only means to mark the content or to quickly cover the gaps in accessibility.