Accessible Rich Internet Applications-ARIA

Accessible Rich Internet Application (ARIA) is way to ensure that Web Apps and Content is accessible to users with disability in similar or approximately similar way as to users without disability.

Accessible Rich Internet Applications-ARIA


Accessible Rich Internet Application (ARIA) is way to ensure that Web Apps and Content is accessible to users with disability in similar or approximately similar way as to users without disability.

The Accessibility is a huge concern when web apps have complex functionalities built with JavaScript and CSS.

Accessibility is major concern for governments and businesses as well; and the businesses which rely on the web, it becomes a debate.

Now what kind of disabilities are taken into consideration? Disabilities like blindness, partial blindness, color blindness, challenged to work with hardware devices like mouse or touchpad, hearing problems etc. The major categories of disability types are (from https://webaim.org/intro/):

  • Visual: Blindness, low vision, color-blindness
  • Hearing: Deafness and hard-of-hearing
  • Motor: Inability to use a mouse, slow response time, limited fine motor control
  • Cognitive: Learning disabilities, distractibility, inability to remember or focus on large amounts of information

For this the W3C has advised Accessible Rich Internet Applications – ARIA.

There are Laws which make it compulsory to adhere to Accesssibility. Following are the international laws:

Considering the intrnational laws, W3C has prepared Web Content Accessibility Guidelines (WCAG) which provide international set of guidelines to make accessiblw web. WCAG suggests four basic principles:

  • Perceivable: Available to the senses (vision and hearing primarily) either through the browser or through assistive technologies (e.g. screen readers, screen enlargers, etc.)
  • Operable: Users can interact with all controls and interactive elements using either the mouse, keyboard, or an assistive device.
  • Understandable: Content is clear and limits confusion and ambiguity.
  • Robust: A wide range of technologies (including old and new user agents and assistive technologies) can access the content.

The principles or guides to achieve the Accessibility in Web Application are (taken from WebAIM.org):

  • Provide appropriate alternative text: Alternative text provides a textual alternative to non-text content in web pages. It is especially helpful for people who are blind and rely on a screen reader to have the content of the website read to them.

  • Provide appropriate document structure: Headings, lists, and other structural elements provide meaning and structure to web pages. They can also facilitate keyboard navigation within the page.

  • Provide headers for data tables: Tables are used online for layout and to organize data. Tables that are used to organize tabular data should have appropriate table headers (the <th> element). Data cells should be associated with their appropriate headers, making it easier for screen reader users to navigate and understand the data table.

  • Ensure users can complete and submit all forms: Ensure that every form element (text field, checkbox, dropdown list, etc.) has a label and make sure that label is associated to the correct form element using the <label> element. Also make sure the user can submit the form and recover from any errors, such as the failure to fill in all required fields.

  • Ensure links make sense out of context: Every link should make sense if the link text is read by itself. Screen reader users may choose to read only the links on a web page. Certain phrases like "click here" and "more" must be avoided.

  • Caption and/or provide transcripts for media: Videos and live audio must have captions and a transcript. With archived audio, a transcription may be sufficient.

  • Ensure accessibility of non-HTML content, including PDF files, Microsoft Word documents, PowerPoint presentations and Adobe Flash content. In addition to all of the other principles listed here, PDF documents and other non-HTML content must be as accessible as possible. If you cannot make it accessible, consider using HTML instead or, at the very least, provide an accessible alternative. PDF documents should also include a series of tags to make it more accessible. A tagged PDF file looks the same, but it is almost always more accessible to a person using a screen reader.

  • Allow users to skip repetitive elements on the page: You should provide a method that allows users to skip navigation or other elements that repeat on every page. This is usually accomplished by providing a "Skip to Main Content," or "Skip Navigation" link at the top of the page which jumps to the main content of the page.

  • Do not rely on color alone to convey meaning: The use of color can enhance comprehension, but do not use color alone to convey information. That information may not be available to a person who is colorblind and will be unavailable to screen reader users.

  • Make sure content is clearly written and easy to read: There are many ways to make your content easier to understand. Write clearly, use clear fonts, and use headings and lists appropriately.

  • Make JavaScript accessible: Ensure that JavaScript event handlers are device independent (e.g., they do not require the use of a mouse) and make sure that your page does not rely on JavaScript to function.

  • Design to standards: HTML compliant and accessible pages are more robust and provide better search engine optimization. Cascading Style Sheets (CSS) allow you to separate content from presentation. This provides more flexibility and accessibility of your content.


So with ARIA you can tell the markup rendering engine what element is used in what sense or what was the purpose to use that element.

So despite of their usual meaning, you can override their behaviour also in some way. But the ARIA should be only considered with accessibility prospective; not for any other.

For ARIA; there are some attributes that need to added to the element markup. Most important is role. With this attribute, you can tell the browser or the reader or the engine to treat the content as certain control. Roles are categorized as following:

  1. Abstract Roles
  2. Widget Roles
  3. Document Structure Roles
  4. Landmark Roles

Collectively, values can be following (taken from https://www.w3.org/TR/wai-aria/#role_definitions_header:

Role Short Description
alert A message with important, and usually time-sensitive, information. See related alertdialog and status.
alertdialog A type of dialog that contains an alert message, where initial focus goes to an element within the dialog. See related alert and dialog.
application A region declared as a web application, as opposed to a web document.
article A section of a page that consists of a composition that forms an independent part of a document, page, or site.
banner A region that contains mostly site-oriented content, rather than page-specific content.
button An input that allows for user-triggered actions when clicked or pressed. See related link.
checkbox A checkable input that has three possible values: true, false, or mixed.
columnheader A cell containing header information for a column.
combobox A presentation of a select; usually similar to a textbox where users can type ahead to select an option, or type to enter arbitrary text as a new item in the list. See related listbox.
command (abstract role) A form of widget that performs an action but does not receive input data.
complementary A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content.
composite (abstract role) A widget that may contain navigable descendants or owned children.
contentinfo A large perceivable region that contains information about the parent document.
definition A definition of a term or concept.
dialog A dialog is an application window that is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response. See related alertdialog.
directory A list of references to members of a group, such as a static table of contents.
document A region containing related information that is declared as document content, as opposed to a web application.
form A landmark region that contains a collection of items and objects that, as a whole, combine to create a form. See related search.
grid A grid is an interactive control which contains cells of tabular data arranged in rows and columns, like a table.
gridcell A cell in a grid or treegrid.
group A set of user interface objects which are not intended to be included in a page summary or table of contents by assistive technologies.
heading A heading for a section of the page.
img A container for a collection of elements that form an image.
input (abstract role) A generic type of widget that allows user input.
landmark (abstract role) A region of the page intended as a navigational landmark.
link An interactive reference to an internal or external resource that, when activated, causes the user agent to navigate to that resource. See related button.
list A group of non-interactive list items. See related listbox.
listbox A widget that allows the user to select one or more items from a list of choices. See related combobox and list.
listitem A single item in a list or directory.
log A type of live region where new information is added in meaningful order and old information may disappear. See related marquee.
main The main content of a document.
marquee A type of live region where non-essential information changes frequently. See related log.
math Content that represents a mathematical expression.
menu A type of widget that offers a list of choices to the user.
menubar A presentation of menu that usually remains visible and is usually presented horizontally.
menuitem An option in a set of choices contained by a menu or menubar.
menuitemcheckbox A menuitem with a checkable state whose possible values are true, false, or mixed.
menuitemradio A checkable menuitem in a set of elements with role menuitemradio, only one of which can be checked at a time.
navigation A collection of navigational elements (usually links) for navigating the document or related documents.
note A section whose content is parenthetic or ancillary to the main content of the resource.
option A selectable item in a select list.
presentation An element whose implicit native role semantics will not be mapped to the accessibility API.
progressbar An element that displays the progress status for tasks that take a long time.
radio A checkable input in a group of radio roles, only one of which can be checked at a time.
radiogroup A group of radio buttons.
range (abstract role) An input representing a range of values that can be set by the user.
region A large perceivable section of a web page or document, that is important enough to be included in a page summary or table of contents, for example, an area of the page containing live sporting event statistics.
roletype (abstract role) The base role from which all other roles in this taxonomy inherit.
row A row of cells in a grid.
rowgroup A group containing one or more row elements in a grid.
rowheader A cell containing header information for a row in a grid.
scrollbar A graphical object that controls the scrolling of content within a viewing area, regardless of whether the content is fully displayed within the viewing area.
search A landmark region that contains a collection of items and objects that, as a whole, combine to create a search facility. See related form.
section (abstract role) A renderable structural containment unit in a document or application.
sectionhead (abstract role) A structure that labels or summarizes the topic of its related section.
select (abstract role) A form widget that allows the user to make selections from a set of choices.
separator A divider that separates and distinguishes sections of content or groups of menuitems.
slider A user input where the user selects a value from within a given range.
spinbutton A form of range that expects the user to select from among discrete choices.
status A container whose content is advisory information for the user but is not important enough to justify an alert, often but not necessarily presented as a status bar. See related alert.
structure (abstract role) A document structural element.
tab A grouping label providing a mechanism for selecting the tab content that is to be rendered to the user.
tablist A list of tab elements, which are references to tabpanel elements.
tabpanel A container for the resources associated with a tab, where each tab is contained in a tablist.
textbox Input that allows free-form text as its value.
timer A type of live region containing a numerical counter which indicates an amount of elapsed time from a start point, or the time remaining until an end point.
toolbar A collection of commonly used function buttons or controls represented in compact visual form.
tooltip A contextual popup that displays a description for an element.
tree A type of list that may contain sub-level nested groups that can be collapsed and expanded.
treegrid A grid whose rows can be expanded and collapsed in the same manner as for a tree.
treeitem An option item of a tree. This is an element within a tree that may be expanded or collapsed if it contains a sub-level group of treeitem elements.
widget (abstract role) An interactive component of a graphical user interface (GUI).
window (abstract role) A browser or application window.

Those were the roles. Now for ARIA, roles are not enough; there are more attributes which tell the state of the widget or element to the assistive tool. Those are aria-* And every role has different set of aria-* applying to them. For example, on role="button", aria-pressed="true|false|mixed" is used.

And along with aria-* attributes, the focus-order or tab-flow is also needed to be in normal flow. The tab-flow is maintained by the tabindex attribute.

The tabindex can have value 0, number and -1.

Value Usage
-1 Used for setting focus programmaticaly and does not get focus on normal tab keypress
0 Makes element focusable on regular flow of tab keypresses
number Used to set the tab focus flow in particular order (rarely recommended)

Lets see an example:

<div class="tree">
<ul role="tree">
  <li><span role="treeitem" tabindex="0">Parent</span>
    <ul role="treegrid">
      <li><span role="treeitem" tabindex="0">Child</span>
        <ul role="treegrid">
          <li><span role="treeitem" tabindex="0">Grand Child</span>
          </li><li><span role="treeitem" tabindex="0">Grand Child</span>
            <ul role="treegrid">
              <li><span role="treeitem" tabindex="0">Grand Child</span></li>
              <li><span role="treeitem" tabindex="0">Grand Child</span></li>
            </ul>
          </li>
        </ul>
      </li><li><span role="treeitem" tabindex="0">Child</span>
        <ul role="treegrid">
          <li><span role="treeitem" tabindex="0">Grand Child</span>
            <ul role="treegrid">
              <li><span role="treeitem" tabindex="0">Grand Grand Child</span></li>
            </ul>
          </li>
          <li><span role="treeitem" tabindex="0">Grand Child</span></li>
        </ul>
      </li>
    </ul>
  </li>
</ul>
</div>

markup idea taken from codepen by Phillip Khn which looks like following:


In above markup you can see the role and tabindex.

When any element with tabindex="0" is hidden, it will not receive focus.

Few handy aria-* attributes:

  • aria-hidden: used to tell the visibility status of the element.
  • aria-label: the value of this attribute is the ID of the other element which holds the labe; for this element.
  • aria-labelledby: the value of this attribute is the ID of the other element which holds the labe; for this element.
  • aria-describedby: similar to aria-labelledby but in other way. it is used to denote the ID of element which holds the description/explanation of this element.
  • etc.

There are more aria- attribute which can be read in details here: https://www.w3.org/TR/html-aria/ and can be seen on following chart along with their relation to the different roles:

https://www.w3.org/WAI/PF/aria-1.1/rdf_model.png
click on image to see enlarged/open in new tab

Another aspect of Accessibility comes into play when the content in not readable by machines and context is needed to make them accessible. Such case is image. To make images accessible, we must provide alt attribute to images. Few ideas to keep in mind while providing alt attribute are:

  • Alternative text should:
    • present the CONTENT and FUNCTION of the image.
    • be succinct.
  • Alternative text should not:
    • be redundant (be the same as adjacent or body text).
    • use the phrases "image of…" or "graphic of…".
  • Appropriate alternative text depends heavily on the image's context.
  • Alt text of a functional image (e.g., an image within a link) should describe the function as well as the content.
  • Decorative images still need an alt attribute, but it should be null (alt="").

You read more about the alt in relation to accessibility here: https://webaim.org/techniques/alttext/


You can use https://wave.webaim.org/ to test the accessibility of the your web app.

Please share the article with everyone for whom it might be helpful. Let us know about your feedback and challenges in comments.