This part three of a four-part series explores different accessibility issues that can be solved by using Accessible Rich Internet Applications (ARIA).
On modern websites, interface controls such as show/hide and controls to select personal preferences are very common. However, these types of features are often inaccessible to users who can’t use a mouse or an alternate pointing device — typically screen reader users.
This is where ARIA (Accessible Rich Internet Applications) comes in. ARIA is used to give meaning, or semantics, to interface controls so a screen reader can use them. As we become more familiar with these kinds of interactive controls and start to expect them, these features become crucial for being able to use a website, so it’s extremely important that they are made accessible.
Media Access Australia’s article Introduction to WAI-ARIA: It’s accessibility but not as we know it says that accessibility guidelines like WCAG 2.0 focus on design principles and aim “to be technology-neutral so they could apply to more situations”.
On the other hand, ARIA uses specific commands to tell assistive technology, such as screen readers, what’s going on. For example, if an event happens on a webpage such as an updated sports score, the assistive technology program being used to help a person with a disability will notice the change and provides the user with access to the new content.”
ARIA solves these main areas of accessibility problems with web applications:
Widgets are sections of code that can be added to a webpage to enhance its functionality, including sliders, dropdown and fly-out menus, and drag-and-drop controls. Widgets coded in HTML convey limited information to screen readers about how to interact with them, which makes them inaccessible to blind and vision impaired users.
ARIA adds semantics to widgets through Roles, States and Properties to give screen reader users full functionality of widgets.
Roles describe the type of element the user is encountering, whether it is a slider, menu or some other kind of widget. This is an example of how ARIA roles are added to HTML code:
<li role="menuitem">Open file…</li>
Properties describe the characteristics of a widget, for example, that an element can be dragged, has a pop-up associated with it, or has a required item such as a mandatory field in a form. To indicate that the name field on a form is required the following code may be used:
<label for="name">First Name</label>: <input name="name" id="name" aria-required="true">
States are the mode an element within a widget is currently in. For example, a “notify me of sales and special deals” checkbox in a form can have the state of being “checked” or a button can be in the pressed state:
<span role="button" aria-pressed="true">Push me</span>
Through ARIA Roles, Properties and States, widgets can be programmed so screen readers can properly interact with them and users are not left with completely inaccessible features of webpages.
This is the third article in a four-part series by Richard Corby, web accessibility expert and partner at Webbism. This post was originally published on the Access iQ website as ARIA and accessibility: Widgets.