Recently there was a large case against a national Pizza chain, the issue was with their website and the fact that those with disabilities were unable to use it to place orders. The plaintiff was successful in the suite. If you have heard about this then you are probably already thinking if your website could be next, if not then this should be a wake-up call for you. In today's article, I will go through how to set up Aria on your website to help you become more compliant.
What is ARIA?
ARIA is an acronym for Accessible Rich Internet Applications, a Web accessibility initiative. WAI-ARIA is the technical specification published by the W3C who is responsible for defining international standards.
Who was ARIA created for?
Aria was created to help with screen readers, magnifiers, and text-to-speech applications designed to make websites and applications more accessible to those with disabilities. While it is still new, it is becoming more widely accepted as the go-to standard on how to build things in a way that is fair to everyone.
ARIA and HTML5
When building a website that utilizes HTML5 you will need to verify that the elements you are using are compatible with ARIA or at the very least have a way to gracefully fail so that they don't make the site unusable for those utilizing a screen reader.
- Check which browsers and devices your site will support
- Check those against one or more of these resources
- In cases where HTML5 elements are not supported add both the HTML5 element and the ARIA role in order to cover those gaps in support.
What does ARIA do?
There are a couple of main components that make up ARIA, those are Roles, States, and properties. Understanding what these do is important to the process of making your website accessible.
- Roles are used in defining a type of User interface element (UI) (example: role="ROLE_NAME"). Once a role is set for an element on the page it should not change.
- Abstract Roles are roles that act as the foundation for all of the other roles. Abstract roles can be utilized by browsers and should not be defined in your code. Instead, think of them like Final classes that you extend from.
- Document Structure Roles are used on elements that are typically not interactive but provide descriptions for sections on a page. Commonly used elements are img, document, heading, list, listitem, and toolbar. There is a full list of these available here
- Landmark Roles are created to help with navigation on the page. Each landmark role identifies each section of content on a page. Some common types of these include banner, contentinfo, form, main, navigation, and search.
- States and Properties
Properties and states can be used on elements and are used often together to support ARIA roles existing on a page.- Properties do not typically change once they are set, example: aria-describedby or aria-labelledby
- States can change on their own or with some sort of interaction from the user, for example aria-checked or aria-disabled.
- There are four categories of properties and states
- DnD attributes
- Relationship Attributes
- Widget Attributes - which are different from Widget roles
- Live Region Attributes
Why would you not want to use Aria
There are some guidelines in deciding when and when not to implement aria according to the W3C you can see the full article about it here, below I have it boiled it down to the five general rules.
- The first rule is to use native HTML in all situations unless it is absolutely impossible to make an element accessible otherwise. When in question, make sure to select the correct HTML element that is native.
- Do not alter the native HTML semantics unless you have to. In most cases, native HTML will work just fine. This is because ARIA does not get added into the DOM so any objects that you create in the browser will not automatically become what they are trying to emulate, for example a dynamically created button.
- All interactive ARIA controls must be keyboard accessible. That means you need to add a tabinedex to the element and ensure that all tab indexes are numbered in an appropriate order.
- Never add the presentation role or aria-hidden property to focusable elements. This can cause issues with some users being able to select the focusing element. Which can cause issues with accessibility on the page
- Give all interactive elements an accessible name. This can only happen when the interactive element includes an aria-label property.
There is a lot of information to unpack in this article, in the next article about this topic I plan on diving deeper into things like how to use descriptive labels and alerts for ARIA as well as how to implement these things on a website, and in a way that makes it easy for your Content entry team to remain compliant with ARIA guidelines.