Reading Some of the ARIA Authoring Practices Guide (APG)
Wanted to read the ARIA Authoring Practices Guide to learn more about accessibility. I probably need to return to the guide when looking over the design system to make sure that it is accessible.
References
This guide describes how to apply accessibility semantics to common design patterns and widgets. It provides design patterns and functional examples complemented by in-depth guidance for fundamental practices.
ARIA Patterns
The ARIA guide provides examples of each of the components below and provides some recommendations for aria attributes and JavaScript behavior that should be implemented.
- Accordion
- Alert
- Alert and Message Dialogs
- Breadcrumb
- Button
- Carousel (Slide Show or Image Rotator)
- Checkbox
- Combobox
- Dialog
- Disclosure (Show/Hide)
- Feed
- Grid (Interactive Tabular Data and Layout Containers)
- Landmarks
- Link
- Listbox
- Menu and Menubar
- Menu Button
- Meter
- Radio Group
- Slider
- Slider (Multi-Thumb)
- Spinbutton
- Switch
- Table
- Tabs
- Toolbar
- Tooltip
- Tree View
- Treegrid
- Window Splitter
ARIA Practices
No ARIA is better than Bad ARIA. Read this to understand why.
Functionally, ARIA roles, states, and properties are analogous to a CSS for assistive technologies. For screen reader users, ARIA controls the rendering of their non-visual experience. Incorrect ARIA misrepresents visual experiences, with potentially devastating effects on their corresponding non-visual experiences. The two essential purposes of ARIA:
- A role is a promise
<div role="button">Place Order</div>The code above is a promise that the author of the \<div\> has also incorporated JavaScript that provides the keyboard interactions expected for a button.
- ARIA Can Both Cloak and Enhance, Creating Both Power and Danger
The information assistive technologies need about the meaning and purpose of user interface elements is called accessibility semantics. ARIA gives authors the ability to dress up HTML and SVG elements with critical accessibility semantics that the assistive technologies would not otherwise be able to reliably derive. Some of ARIA is like a cloak; it covers up, or overrides, the original semantics or content. On the other hand, some uses of ARIA are more like suspenders or belts, they add meaning that provides essential support to the original content. This is the power of ARIA. It enables authors to describe nearly any user interface component in ways that assistive technologies can reliably interpret, thus making components accessible to assistive technology users.
Testing assistive technology interoperability is essential before using code from this guide in production.
Landmark Regions
ARIA landmark roles provide a way to identify the organization and structure of a web page. By classifying and labelling sections of a page, they enable structural information that is conveyed visually through layout to be represented programmatically. Screen readers exploit landmark roles to provide keyboard navigation to important sections of a page.
Default Landmark Roles for HTML Sectioning Elements:
| HTML Element | Default Landmark Role |
|---|---|
| aside | complementary |
| footer | contentinfo when in context of the body element |
| header | banner when in context of the body element |
| main | main |
| nav | navigation |
| section | region when it has an accessible name using aria-labelledby or aria-label |
Including all perceivable content on a page in one of its landmark regions and giving each landmark region a semantically meaningful role is one of the most effective ways of ensuring assistive technology users will not overlook information that is relevant to their needs.
- Identify the logical structure
- Assign Landmark Roles to Each Area
- Label Areas
Landmark Roles:
- banner: identifies site-oriented content at the beginning of each page within a website. Site-oriented content typically includes things such as the logo or identity of the site sponsor, and site-specific search tool
- complementary: 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.
- contentinfo: a way to identify common information at the bottom of each page within a website, typically called the "footer" of the page, including information such as copyrights and links to privacy and accessibility statements.
- form: identifies a region that contains a collection of items and objects that, as a whole, combine to create a form when no other named landmark is appropriate
- main: identifies the primary content of the page
- navigation: provides a way to identify groups of links that are intended to be used for website or page navigation
- region: perceivable section of the page containing content that is sufficiently important for users to be able to navigate to the section
- search: contains a collection of items that, as a whole, combine to create search functionality
Providing Accessible Names and Descriptions
Providing elements with accessible names, and where appropriate, accessible descriptions, is one of the most important responsibilities authors have when developing accessible web experiences.
- Naming
- naming with child element/content
- naming with string attribute via aria-label
- naming by referencing content with aria-labelledby
- naming form controls with the label element
- naming fieldsets with the legend element
- Naming tables and figures with captions
- Fallback names derived form titles and placeholders
- Describing
- Describing by referencing content with aria-describedby
- Describing tables and figures with captions
- Descriptions derived from titles
An accessible name is a short string, typically 1 to 3 words, that authors associate with an element to provide users of assistive technologies with a label for the element. It serves two purposes:
- Convey the purpose of the element
- Distinguish the element from other elements on the page
Focusable, interactive elements should have a name. In addition, dialogs, tables, and figures should have a name. The Accessible Name Guidance by Role section lists naming requirements and guidelines for every ARIA role.
Developing a Keyboard Interface
This section describes the principles and methods for making the functionality of web page that includes ARIA widgets, such as menus and grids, as well as interactive components, such as toolbars and dialogs, operable with a keyboard. For a web page to be accessible, all interactive elements must be operable via the keyboard.
A primary keyboard navigation convention common across all platforms is that the tab and shift + tab keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include multiple focusable elements. The path that the focus follows when pressing the tab key is known as the tab sequence or tab ring.
The process of controlling focus inside a composite is called managing focus. The HTML tabindex attribute can be used to add or remove elements from teh tab sequence.
Grid and Table Properties
To fully present and describe a grid or table, in addition to parsing the headers, rows, and cells using the roles described in the grid pattern or table pattern, assistive technologies need to be able to determine other structural and presentation characteristics, such as the number and visibility of rows and columns. There are situations in which the full table or grid may not be rendered dur to the table being too large to render. In these cases, you should include the properties below:
| Property | Definition |
|---|---|
| aria-colcount | Defines the total number of columns |
| aria-rowcount | Defines the total number of rows |
| aria-colindex | Defines a cell's position with respect to the total number of columns |
| aria-rowindex | Defines a cell's position with respect to the total number of rows |
| aria-colspan | Defines the number of columns spanned by a cell or gridcell |
| aria-rowspan | Defines the number of rows spanned by a cell or gridcell |
| aria-sort | Indicates if items in a row or column are sorted in ascending or descending order |
Structural Roles
ARIA provides a set of roles that convey the accessibility semantics of structures on a page. These oles express the meaning that is conveyed by the layout and appearance of elements that organize and structure content, such as headings, lists, and tables. When developing HTML, it is important to use native HTML elements wherever possible. When to use ARIA roles:
- When the HTML element cannot be styles in a way that meets visual design requirements
- When testing reveals that browsers or assistive technologies provide better support for the ARIA equivalent
- When remediating or retrofitting legacy content and altering the underlying DOM to use the HTML would be cost prohibitive
- When building a web component to compose a custom element and the element being extended does not convey the appropriate accessability semantics.
| ARIA Role | HTML Equivalent |
|---|---|
| application | No equivalent element |
| article | article |
| blockquote | blockquote |
| caption | caption |
| cell | td |
| code | code |
| columnheader | th |
| definition | dd |
| deletion | del |
| directory | No equivalent element |
| document | No equivalent element |
| emphasis | em |
| feed | No equivalent element |
| figure | figure |
| generic | div, span |
| group | No equivalent element |
| heading with aria-level="N" where N is 1, 2, 3, 4, 5, or 6 | h1, h2, h3, h4, h5, h6 |
| insertion | ins |
| img | img |
| list | ul, ol |
| listitem | li |
| mark | mark |
| math | No equivalent element |
| none | No equivalent element |
| note | No equivalent element |
| presentation | No equivalent element |
| paragraph | p |
| row | tr |
| rowgroup | tbody, thead, tfoot |
| rowheader | th |
| separator (when not focusable) | hr |
| strong | strong |
| subscript | sub |
| superscript | sup |
| table | table |
| term | dfn |
| time | time |
| toolbar | No equivalent element |
| tooltip | No equivalent element |
Hiding Semantics with the presentation Role
There are some situations where hiding an element's semantics from assistive technologies is helpful. This is done with the presentation role, which declares an element is being used only for presentation and therefore does not have any accessability semantics. Three common uses of role presentation are:
- Hiding a decorative image; it is equivalent to giving the image null alt text
- Suppressing table semantics of tables for layout in circumstances where the table semantics do not convey meaningful relationships.\
- Eliminating semantics by intervening orphan elements in the structure of a composite widget, which as a tablist, menu, or tree.