ARIA (Accessible Rich Internet Applications) allows web developers to make their complex web applications accessible. This presentation will introduce ARIA attributes and how they establish landmarks, states, and roles. Learn how to use the basic elements that belong on every application. This presentation will also show more advanced topics, such as invalid form inputs, live regions, and fixing divitis.
The HTML specifications for forms suggests using a
<legend> to define similar items within a form. Normally this is used to combine the forms into large chunks, for instance the billing address, credit card information, and personal information. It’s also useful for combining radio and checkbox sets.
Typically, we associate a form input with a label. The label is announced as the screen reader places focus on the input. This works very well for letting the user know what the checkbox or radio button represents, but it doesn’t give the user context for how it is applied. For instance, the following radio button would be announced as “radio button Yes”. But what is the user saying yes to?
Continue Reading Fieldset legend, aria-describedby, and radiogroup role
Ten years ago, web developers were introduced to a light-weight dropdown menu system that seemed like a perfect solution for complex, nested navigation. Suckerfish Dropdowns used the :hover state to show/hide children of the top nav element. It didn’t take long for people to realize :hover didn’t work without a mouse, meaning a large portion of a web site’s users could not activate: the submenus.
Patrick Griffiths and Dan Web introduced Son of Suckerfish, which fixed the :hover issue by placing a class on the top navigation item when it received focus or hover. This allowed it to be used by mouse and keyboard users.
Fast forward to 2013 and dropdown menu options haven’t changed much. Unfortunately, there’s also been a resurgence of :hover based navigation, thanks to the popularity of some inaccessible jQuery plugins and coding examples.
There are plenty of options for making your dropdown menus accessible. Terrill Thompson researched the options extensively for her presentation and article Accessible DropDown Menus.
Dropdown and flyout menus on websites are great for reducing clutter, simplifying page content, and providing a consistent navigation structure that (if done well) makes it easy to find content from anywhere on the site. Unfortunately, very few of the dynamic menus in use today are fully accessible:
- Most dynamic menus depend on users being able to use a mouse. Mousers hover over menu items, which makes dropdown menus appear. If non-mousers tab to those same top-level menu items, they typically can’t make the dropdown menus appear.
Accessible DropDown Menus – Terrill Thompson
Thompson introduces the importance of keyboard accessibility, allowing users to escape menus, the use of arrow keys, and adding ARIA attributes. The suggested pattern that comes the closest to most jQuery sites is the DropDown Menu from Simply Accessible. Another great option is the menu component from the Yahoo! User Interface Library. YUI components have accessibility baked in, so developers don’t have to worry about keyboard control or ARIA.
If you are looking for something more complex than a dropdown menu, look at the recently released Mega Menu from Adobe. They’ve just released their code as open source. It incorporates full keyboard accessibility and ARIA support. It allows you to include nested navigation within your topnav hierarchy.
Testing Your Menu
How does your site navigation measure up? It’s easy to test. Just push your mouse to the side and try tabbing through your web page. Are you able to navigate the submenus? What happens when you focus on a top level menu item and hit the enter key? What happens when you use the arrow keys? The escape key?
If your answer is nothing, you will need to update to an accessible drop down menu.
ARIA landmarks allow developers to associate structural significance to web page elements. Common landmarks define navigation, header, the main content, and the page’s footer. It’s also possible to define more specific subelements, such as a search form. This page will test the use of
role="form" to define multiple forms on a single page. While this may seem uncommon, it could be seen on a page that has a search, sign up, and login form.
The role attribute is placed on the form tag. In general, you do not want to put a landmark above a similar semantic object, so
<form role="form">, <nav role="navigation">. Add
aria-label to let the user know what the form will include. This is especially helpful when navigating by landmarks.
Continue Reading Using the ARIA Form Landmark
There are times when we want the screen reader to announce individual letters in a string. This is sometimes up to the interpretation of the screen reader with an acronym, such as NASA. There are other times when we need to force the digits, for instance in a confirmation code IXbib. This page will test options for making a screen reader announce this confirmation code: IXbib
Continue Reading Force the screen reader to announce digits