What is WAI-ARIA?
- Accessible Rich Internet Applications (ARIA)
- Defines way to make web content/apps more accessible to people with disabilities.
- Maps custom web controls to an equivalent control in the Accessibility API in browser
- E.g., menus, tab structures, tree structures, etc.
- Communicates name, role, and state of custom widget to assistive technologies
- Example: custom div that looks like a checkbox would need role=”checkbox” to communicate what that custom element “is”
Rules for Using ARIA
- Use native elements when possible; avoid creating custom elements when native element already exists.
- Don’t override native elements unless necessary
- Make controls keyboard accessible - custom controls will need additional scripting vs. native HTML elements.
- Do not use role=”presentation” as that removes semantic information from Accessibility API
- Do not use aria-hidden=”true” on focusable elements as that hides that element from the screen-reader - person can still “tab” to the element, but nothing is communicated.
- Interactive elements must have an accessible name.
Bad ARIA can degrade accessibility of interface - better to not use if you are not following the specification.
ARIA does not impact how an element is visually rendered in the browser or the browser’s behavior. It is for the Accessibility API and what is communicated to assistive technology.
ARIA can be used on regular websites, but some ARIA elements should be reserved for more “application-style” interfaces that are more complex or are trying to duplicate desktop applications.
Common Mistakes
- Using role=”menu” for general navigation on websites
- Usually partially implemented and missing subsequent attributes
- Using redundant ARIA roles/attributes for native HTML content
- Not including the initial state or updating
- Example: need to include aria-expanded attribute at the beginning, not after it is triggered. Can update the attribute, but needs to exist when page loads.
- Using invalid roles
- Using inappropriate/incorrect widget structures on elements
- Example: Adding listbox role/attributes for slider UI; not a correct implementation
Recommendation is to use the specification to review if ARIA role, attribute is valid as well as intended functionality. Example: Provides requirements for keyboard support for a given user interface design
Example of ARIA Role Training Matrices - http://whatsock.com/training/matrices/
- Provides information about what actually works with assistive technologies.
- Recommended if following ARIA 1.1 Authoring Practices
Review of various URLs for more information:
- Accessible Rich Internet Applications (WAI-ARIA) 1.1 - https://www.w3.org/TR/wai-aria-1.1/
- WAI-ARIA Authoring Practices 1.1 - https://www.w3.org/TR/wai-aria-practices-1.1/
- ARIA in HTML - https://www.w3.org/TR/html-aria/
- Helpful to check to see how the current HTML and ARIA elements correspond
- Using ARIA - https://www.w3.org/TR/using-aria/
- The Accessibility Tree and Accessibility API - http://whatsock.com/training/
Any ARIA questions you have?
