In the first part of this 3-part series, I went over the ARIA standard, highlighting important sections to be aware of, and then reviewed the 5 Rules of ARIA. If you didn’t get a chance to learn those topics, I highly recommend you read up on that before reading part 2.
ARIA Authoring Practices
An important resource that I want to highlight is the official ARIA Authoring practices. This resource is often, incorrectly, referred to as an example of proper ARIA implementation by developers for various widgets. The ARIA authoring practices are available at www.w3.org/TR/wai-aria-practices, and they demonstrate about 27 different widgets and patterns. Some are essentially ARIA recreations of HTML elements like Button or Checkbox, but some of them are interactive widgets that are only available via ARIA, like Tabs.
Unfortunately, the purpose of the ARIA Authoring Practices is almost always misunderstood to be a type of cookbook, or official examples of ARIA widgets to be copy/pasted. It may be extremely shocking for you to find out that these examples are not meant to be used that way. I want to point out some important notices from the Browser and Assistive Technology section:
Testing assistive technology interoperability is essential before using code from this guide in production. Because the purpose of this guide is to illustrate appropriate use of ARIA 1.1 as defined in the ARIA specification, the design patterns, reference examples, and sample code intentionally do not describe and implement coding techniques for working around problems caused by gaps in support for ARIA 1.1 in browsers and assistive technologies. It is thus advisable to test implementations thoroughly with each browser and assistive technology combination that is relevant within a target audience.
It then continues to say:
Except in cases where the ARIA Working Group and other contributors have overlooked an error, examples in this guide that do not function well in a particular browser or with a specific assistive technology are demonstrating browser or assistive technology bugs. Browser and assistive technology developers can thus utilize code in this guide to help assess the quality of their support for ARIA 1.1.
In other words, these examples don’t provide any guidance as to how to work around bugs you may encounter due to varying support. These examples only provide a proposal of how they would like things to be supported by browsers and assistive technology vendors. Essentially, they are just a guide for browsers and assistive technology vendors to standardize on ARIA support.
The truth of the matter is that ARIA is only a spec. There’s no guarantee that browser and assistive technologies are going to support all the roles, states, and properties that are specified, just the same way building codes don’t always guarantee that a building is built properly. Because of this, they advise testing everything before using it.
One thing I want to highlight is the section on Mobile and Touch Support:
“Currently, this guide does not indicate which examples are compatible with mobile browsers or touch interfaces. While some of the examples include specific features that enhance mobile and touch support, some ARIA features are not supported in any mobile browser. In addition, there is not yet a standardized approach for providing touch interactions that work across mobile browsers.”
Essentially, this is an acknowledgment that these patterns and the ARIA used to build them, may not even be supported by mobile browsers. In fact, the design patterns don’t really take mobile and touch into consideration. I often see a lot of component libraries advertise that they’re accessible because they implement the ARIA Authoring Practices, but just be aware that that doesn’t always guarantee accessibility– things still need to be tested.
Conclusion
I’m not telling you that you can’t use these patterns. You can certainly use them as a basis for your widgets, but you shouldn’t use them as is. The point of all this is test, test, test. Hopefully, you’ll test with users with disabilities, you’ll discover some inconsistencies and you’ll be expected to fill in those gaps on your own. That’s why it’s important to know and understand ARIA and not just copy and paste these patterns.
In the next and final blog post of this ARIA series, I’ll put everything I have gone through together to demonstrate creating an Expand/ Collapse control as a practical example of how to use the ARIA spec when creating custom widgets.