Application and Presentation Roles

The application and presentation roles in WAI-ARIA change the way assistive technologies interact with web content. Both have “use with caution” warnings. Their use and where and when to use them are described here.

Application Role

The application role is used when there is not a corresponding widget interaction pattern available to provide semantics for a custom widget.

Imagine, for instance, a file manager application embedded in a web page, which does not have widget roles specifically defined. It may have many of the functions a typical file manager might have on a Windows, Mac, or Linux system. It might have the typical File, Edit, and View menus that most applications have, including browsers. Those menus in the file manager should function like these same menus in other applications. When the application role is used in a container containing the embedded file manager, keystrokes are intercepted and repurposed to operate the file manager, instead of the browser and the assistive technology.

When in the file manager application, this behaviour may be desirable. But, defined with the application role, all of the standard screen reader shortcut keys are also disabled, so the user is no longer able to navigate the pages by headings, or landmarks, for instance, while inside the application. This may be fine in such a case because the screen reader user will likely temporarily want shortcut keys to file manager functions, and not those of the browser or screen reader.

If, however, the application role is used to contain a carousel widget, for example, then browser and assistive technology functionality may be unnecessarily disabled, potentially creating barriers. A carousel widget typically has limited functionality. For example, carousels may contain scripted Arrow keys to move back and forth between slides, between headings within each slide for added structure, or link to another section of the site presented in a slide. In such cases, screen reader users would be unable to navigate through the slides by listing headings or links, using their screen reader’s default heading and link list functionality. By removing the application role, the scripted next/previous link, as well as the heading and the links could be used to navigate the carousel.

The bottom line is to use the application role carefully. Be sure it is not creating more barriers than it is intended to prevent.

Presentation Role

Much like the application role disables default keyboard functionality, the presentation role (and its synonym role="none"), theoretically, removes the default semantics from children of the element it applies to.

So, for instance, if you have a list with role="presentation", it should not announce as a list, and its list items should not announce as list items. However, nested lists within those suppressed list items will announce as usual.

There are a couple of intended exceptions where the presentation role will not remove default semantics:

• When role="presentation" is not applied to elements that have tab focus, such as links, form elements, and elements that have tabindex defined, or
• Where an element has been modified with any of the 21 global states or properties

Where role="presentation" is applied to a parent element, all of its child elements should inherit that role, but not all of its grandchildren. For example, if <ul role="presentation"> is used then the semantics for each of its <li> elements will be ignored. But, if an <li> contains a sublist, that list would be announced as usual.

It should be noted that current support for the presentation role is spotty across browsers and assistive technologies, and you are likely to find it not all that useful if you’re trying to develop with cross browser compatibility. Typically, tables, images, and headings are affected by the presentation role, while other elements like lists, forms, and links are not, or only partially affected. If you are trying to hide elements completely from screen readers, you might consider using either aria-hidden or CSS display:none.

Three common uses for role="presentation" include:

Source: ARIA Authoring Practices Guide

There are also a number of WAI-ARIA roles that act like the presentation role, and these suppress the default semantics for the elements to which they are applied. For instance, if a tablist is created from a <ul>, and role="tab" is applied to each of the list items within that <ul>, their default listitem role will be replaced with the tab role, without the need to set them as presentational.

The following JSFiddle examples have been created for cross browser testing of the presentation role. Navigate through each example with ChromeVox + Chrome. If you have them available, also navigate them with JAWS + IE and NVDA + FF to understand the varied support for the presentation role. Below, the fiddle is a listing of support for current versions of these screen readers.

Skip JSFiddle

Screen Reader Output from the Above Demo

NVDA (2018.1.1) + Edge (41.16299.248.0)

By keyboard, only the link is announced. Mouseover, though, and all elements are announced.

• Link: not announced
• List: not announced or keyboard focusable
• Headings: not announced or keyboard focusable
• Table: not announced or keyboard focusable
• Image: not announced or keyboard focusable
• Form: “Combo box opt three collapsed”

NVDA (2018.1.1) + FireFox (59.0.2)

• Link: announces as usual
• List: values announced but not bullets or the list itself
• Headings: announce as usual
• Table: not announced.
• Image: not announced
• Form: announces opts but not the combobox

JAWS (18) + Edge (41.16299.248.0)

• Link: focusable, but not announced
• List: not focusable, not announced
• Headings: does not announce first heading, but does announce second heading
• Table: not announced
• Image: not announced
• Form: not focusable, not announced

ChromeVox (53.0.2784.5)

• Link: focusable, but not read (using Tab key) Announces as usual when using CVOX + Arrows
• List: Skips over list (using Arrow key) except when link receives focus first, then Arrow key announces the numbers in the list. Announces numbers but not as a list when using CVOX + Arrows
• Headings: Does not announce the first heading, but does announce the second (Arrows and CVOX+Arrows)
• Table: not announced.
• Image: reads alt text “Ryerson Chang School” both Arrow and CVOX + Arrow
• Form: focusable, not announced (using Tab key), Arrow keys announces “Combobox. Opt 3, 3 of 3.”