Subscribe to Newsletter
Tell a Friend
Print this Page
Why Keyboard Accessibility isn't the Same Thing as Screen Reader Accessibility
What are the key considerations that coders have to keep in mind while implementing ARIA? Bryan Garaventa explains
Note: WAI-ARIA (Accessible Rich Internet Applications or ARIA) is a W3C protocol for enhancing and supporting accessibility of scripted and dynamic content. ARIA provides accessible interactive controls (such as tree menus, drag and drop, sliders, sort controls, etc.), content roles for identifying page structure (navigation, search, main content, etc.), areas that can be dynamically updated (called "live regions" in ARIA), better support for keyboard accessibility and interactivity, and much more. For more information, visit the website: http://webaim.org/techniques/aria/
There are 3 critical aspects of accessibility for interactive web technologies:
1) Keyboard Accessibility
2) Screen Reader Accessibility
3) Cognitive Accessibility
The concept is simple, if you cannot Tab to the feature, activate it in an intuitive manner such as pressing Enter on it, use Tab or the Arrow keys to navigate it, or use a simple means to close or invoke it from the keyboard, then the feature is not accessible.
E.G.: The following span tag is styled as a link, and a 'click' event has been added dynamically to make it act like a link when clicked:
So first, this is not keyboard accessible. To make it keyboard accessible you have to add tabindex like so:
Now you can Tab to the span tag as you would with a link. However, you cannot activate it by pressing Enter. This is because in the browser, a span tag is a 'non-actionable' element, unlike a button or A tag, for example, which you can expect to activate by pressing Enter when a 'click' event is attached.
To make this simulated link fully accessible from the keyboard, you have to attach both a 'click' and a 'keyDown' event to the tag in order to cover both mouse and keyboard interaction. So now, it's accessible right? No actually, since screen reader users will have no idea that this element is supposed to be a link. To a screen reader this simply looks like static text in the page, as is every other span and div tag.
This is where ARIA comes in, which provides the right type of feedback for screen reader users. In this case, the ARIA attribute role="link" can be added to make this element accessible for screen readers that support ARIA, like so:
This is just a simple example to illustrate the point. I've recently submitted an issue for the Readium project at
https://github.com/readium/readium/issues/166, which outlines all of these considerations and provides precise coding guidance for implementing simulated radio buttons. All of the above concepts are applied here as well.
This is very important when designing complex component types like sliders, which can be made keyboard accessible, but are useless to screen reader users without the use of ARIA at the same time.
The last one, regarding cognitive accessibility, is making sure that the font-sizing, page format, coloration, and layout, and behaviors are as easy to understand and use as possible for all people. This also covers color contrast and low vision considerations.
So just to summarize, to make an interactive web component fully accessible, it must be fully accessible from the keyboard, it must have proper textual equivalents for screen reader users, and it must be intuitive. If you can only do one or two of these three things, the component is not accessible.
A few last notes about ARIA:
ARIA is awesome! Nevertheless, it doesn't need to be used for everything. For example, if you have an A tag with an href attribute, it is already a link, you don't need to add role="link", etc. The point here is that there are many backwards compatible ways to make standard component types fully accessible without using ARIA. ARIA should be used to bridge the gaps when it's not possible to provide the same level of feedback for screen reader users as is conveyed visually.
Lastly, adding an ARIA role to an attribute doesn't magically change the element type in the browser. This is very important to keep in mind. A span tag for example, remains a span tag regardless whether you add role="button" or role="link" to it, and these attributes have absolutely no benefit to anyone who is not using a screen reader.
Bryan Garaventa was permanently blinded in 1994 from a gunshot wound. After attending the California School for the Blind and graduating from Kennedy High School in Fremont California, Bryan attended Notre Dame de Namur University in Belmont California; majoring in Political Science and Creative Writing. While working for Napster in the early 2000's, Bryan began studying interactive user interface design, and devised a methodology based on mathematics for programming web technologies without sight. In 2009, Bryan started building AccDC as a free accessibility API for developers, which was publically released in 2012. Bryan is currently the founder and developer for WhatSock.com, a member of the Guild of Accessible Web Designers, and a Fellow of the Royal Society of Arts. Visit his website: http://whatsock.com and catch up with him on: http://www.linkedin.com/in/bgaraventaback
• G3ICT PUBLISHES INTERNATIONAL SURVEY OF WEB ACCESSIBILITY POLICIES WHITE PAPER BY THE CENTRE FOR INTERNET AND SOCIETY, BANGALORE, INDIA
• Three Things to make your App stand out when Building for Accessibility
• Nominations Open for U.S. FCC Chairman’s Award for Advancement in Accessibility (AAA)
• UN Secretary-General Ban Ki-moon's Address
• 7th European e-Accessibility Forum: Developing e-Accessibility as a Professional Skill, Paris, France
No records were found.
Post new comment:
Only register users can add comments please Log-in