When I perform a website accessibility review I can usually tell within the first couple of minutes of my process whether or not an effort has been made to make the website accessible. What usually provides the first hint is if ARIA has been used. In case you’re not aware of what ARIA is, it stands for Accessible Rich Internet Applications. It is not a programming language, but rather a series of attributes and properties that developers can add to their program code to bridge the gap between semantically neutral elements and the Accessibility API. ARIA is what turns a widget into an element that has its name, role, state and other properties defined. This allows users of Assistive Technology to understand what the element is, how to interact with it, and what its current state is. Without ARIA, a widget is as useless to someone who uses assistive technology as the “g” is in “lasagna”.
Native HTML elements such as buttons, links, checkboxes, etc. have the necessary attributes built in and made available to the Accessibility API by default. However, there are times when a native element cannot be used for various reasons, so widgets must be created out of semantically neutral elements such as span or div. When this approach is used, ARIA must be used so everything the Accessibility API needs to know about an element is available to it.
THE PROCESS
When performing a website review, I like to provide as many code examples as I can to demonstrate how ARIA bridges the accessibility gap. At Interactive Accessibility, we try to provide as much information as possible to anyone reading our accessibility reviews, whether that person is in management or is a product owner, a member of the marketing staff, a project manager, designer or developer. Being a former developer, I strive to provide real-world coding solutions that developers can actually understand and implement easily.
The process often continues with developer training, which includes ARIA. The client, having just completed our developer/designer accessibility training, heads into a departmental pow-wow to formulate their accessibility strategy. There is a lot to consider when integrating accessibility into your software development lifecycle (SDLC). But when it comes to using ARIA, the developers and QA staff are at the forefront. The developers have to modify their code and the QA staff have to test it. Pure and simple.
A few scrum iterations go by, a few QA rounds and a few releases pass. The client contacts us and requests a QA review, which is done to verify that they have fixed the accessibility barriers discovered in the first review. I ready and steady myself, then with an optimistic mouse click, I open the first review document and I just hope that I can status everything in that first review as being fixed.
And then I think back to the developer training I did with the client a few months back, when I cautioned the developers about using ARIA. I wanted them to understand that with great power comes great responsibility. I prefaced the entire ARIA portion of the training by heartedly speaking this sentence based on my years of experience, and I believe this statement to be true way down to my inner core:
“There is nothing more dangerous than a developer who thinks he or she knows how to use ARIA based on an hour or two of research.”
DISCOVERY
And now, the QA review has begun. OK, they’ve fixed the heading on the homepage, “Yay!”. Oh, look, they’re removed the unneeded definition list markup from the navigation links, “Wahoo!” I’m rolling now, on my way to the mega menu and, “Awwwwwe NO say it isn’t so!!!!!”…
<h2 id=”filter-head”>Product Filter</h2>
<a href=”javascript:” class=”primary” aria-labelledby=”filter-head”>
<span data-node-index=”$nid_78214532″>Product Categories</span>
<div aria-expanded=”true” style=”width: 194px; left: 50%; opacity: 1; position: absolute; right: 17px; margin-left: -97px; display: block;” class=”sub-menu right”>
…[submenu links]
I head into the code and I see they have set aria-expanded=”true” on the expanded submenu instead of setting it on the link that expands the menu. And look, there is aria-labelledby used on the parent-level menu link that references a heading when there is already sufficient link text provided. Now the name of the menu is incorrect and I don’t even know it’s a menu because my screen reader doesn’t tell me so.
I peruse a bit further to find a properly defined ARIA tab interface (always a bonus)! I remain hopeful as I traverse the rest of the homepage and exit with some easy fixes that still need to be made, but the client’s progress is obvious and I remain hopeful. On to the Product Detail page where I run smack into a “You-Might-Also-Like” product carousel. The pagination elements that control the carousel are div elements with no label or role defined. One screen reader I test with announces the element as “blank.” Another screen reader announces absolutely nothing when the control receives keyboard focus. At least the elements can receive keyboard focus, but screen reader users won’t know what these elements are or how to use them.
THE IMPORTANCE OF ARIA IMPLEMENTATION TESTING
I’ve been doing accessibility testing long enough to know when something isn’t defined properly simply by how the element is (or is not) announced by a screen reader. When that red flag pops up, my first reaction is to dive in for some manual code inspection to pinpoint the issue.
One of the most important things about using ARIA is to test its implementation. After the coding has been done, if ARIA is not tested with assistive technology, you won’t know for certain if it’s been implemented properly because ARIA doesn’t affect anything you see on the screen. One simple copy and paste mistake or a letter left out of an ARIA attribute can kill any accessibility hopes for an element. It’s that simple. If an element has been defined with an ARIA role but an incorrect attribute is assigned to that element that is not meant to be used with that role, something’s going to be amiss and in the end, there will be users who don’t know what the element is or how to use it.
THE BAKED-IN SOLUTION
Make sure you incorporate screen reader testing into your QA process. Yes, in the beginning, using a screen reader can be a challenge and it’s likely some things will be missed when you’re first getting started. But as time goes by, the QA staff will become much more proficient at using a screen reader. They will catch the ARIA mistakes, they will be corrected and the code will be pushed out the door in a much better state than if it weren’t tested with a screen reader. And when you feel you’re comfortable testing with a screen reader, go ahead and install speech recognition software and give that a shot. The time it takes to learn a new assistive technology can more than pay for itself for improving accessibility. Developers can use a screen reader to unit test their work also. This in turn will make the QA process go a bit faster.
The bottom line is if ARIA is going to be used to provide that bridge for your accessibility gap, don’t build the bridge with rope and old wood planks. Build that bridge with steel on top of a solid foundation so you can cross it with the confidence of knowing you have an accessible product that can be used by all, regardless of ability.