ARIA Web Design and
Development Patterns
KEITH HAYS
IT Accessibility Specialist
CITES / ITaccess
khays@illinois.edu
• ARIA stands for:
Accessible Rich Internet Applications
• Created by the Web Accessibility Initiative (WAI) of the
World Wide Web Consortium (W3C).
• Will reach final recommendation status early in 2013.
• Allows dynamic web content to be accessible.
• Maps to browser accessibility APIs.
– Adds additional HTML attributes.
• Document structure only goes so far:
– Assistive technologies (AT), such as screen readers, can
not tell certain things from HTML tags alone.
– CSS is invisible to AT.
– Pages with a lot of information can be hard to navigate.
– Dynamic changes to the page can be missed by AT.
• Consider common page elements:
– Data tables, large menus, typical front-page layouts.
– hide/show regions, modal dialogs, tree views, accordion
menus, etc.
• JavaScript manipulates the DOM and invalidates default
accessibility information.
• Custom widgets are not recognized by AT.
• ARIA provides additional information to AT:
– The semantic role of an element or page region.
– The semantic properties of an element or region.
– The current state of an element.
• ARIA is lightweight and does not affect page
performance.
• Roles define the purpose of a page element or region.
• Roles are applied only to container elements.
– <span> is not a container.
• Four types of roles:
1. Landmark roles - enhance document navigation.
2. Structure roles – enhance document structure.
3. Widget roles - define custom UI widgets.
4. Abstract roles – define role taxonomy.
• Do not use abstract roles in your widgets!
• ARIA landmarks provide region-level structure
– ARIA labels can further enhance landmarks by identifying multiple
regions of the same type.
– Headings provide structure within a region.
• Eight roles:
1.
2.
3.
4.
5.
6.
7.
8.
banner
main
navigation
search
complementary
form
contentinfo
application
}
}
Should be used on most websites.
Use when it seems useful to do so.
} Use only when necessary.
• Screen reader users can navigate by landmark using:
– NVDA (2011.2)
– Jaws (Version 10+)
– VoiceOver (OS X 10.7 Lion)
– VoiceOver (iPhone and iPad iOS 4+)
• Window Eyes (V7.5) does not support landmark roles.
LANDMARK
Banner
Navigation
Main
Complementary
Search
HTML5
USE
none
Once per page on an
appropriate <header>
<nav>
Label if more than one.
none
Once per page on main
content container
<aside>
May be appropriate to
put on other containers.
none
Attach to <form> used for
site search.
<nav id=“topnav” role=“navigation” aria-labelledby=“topnav-label”>
<h2 id=“topnav-label” class=“offscreen”>Site Menu</h2>
<ul id=“topmenu”> … </ul>
</nav>
<div id=“rgn-search” role=“search”> … <div>
<header role=“banner”> … </header>
<div id=“rgn-content”>
<div id=“left-col”>
<nav id=“primnav” role=“navigation” aria-labelledy=“primnav-label”>
<h2 id=“primnav-label” class=“offscreen”>Primary Menu</h2>
<ul id=“primmenu”> … </ul>
</nav>
<nav id=“secnav” role=“navigation” aria-labelledy=“secnav-label”>
<h2 id=“secnav-label” class=“offscreen”>Secondary Menu</h2>
<ul id=“secmenu”> … </ul>
</nav>
<div id=“hours” role=“complementary” aria-labelledby=“hours-label”>
<h2 id=“hours-label”>Office Hours</h2>
</div>
</div>
<div id=“main” role=“main”> … </div>
<div id=“right-col”> … </div>
• The application role should only be used when necessary.
• Changes the navigation mode of screen readers:
– Application mode causes some screen readers not to virtualize the
HTML structure.
– AT expects application to handle all semantic associations and
manage focus.
• Do not use role=application on menus intended for navigating
to another page.
– Users will be stuck in application mode.
• Rule of thumb: Never define a custom widget when a
standard HTML control will do.
18 Document Structure Roles:
•
•
•
•
•
•
article
columnheader
definition
directory
document
group
•
•
•
•
•
•
heading
img
list
listitem
math
note
•
•
•
•
•
•
presentation
region
row
rowheader
separator
toolbar
• Structure roles are usually not interactive.
• Do not use structure to override built-in roles.
– Exception: HTML5 <article> tag.
• Presentation indicates that a page element is ornamental.
– Items with a presentation role are not announced by AT.
• Images that do not convey meaning should have the
presentation role (and alt=“”).
– All spacer images are presentational.
• Layout tables can be given a presentation role.
– Table markup will not be announced.
– AT will not switch into table mode.
– Reading order will still be left to right, top to bottom.
– Avoid using tables for layout.
• Widget roles define interactive elements.
– Only define ARIA widgets when standard html control behavior is
insufficient or undesirable.
• Widget roles cause some AT to switch to application
mode.
– Normal HTML associations are overridden.
– User cannot navigate page unless application handles
keystrokes.
• Widget authors must manage focus.
26 Widget Roles:
•
•
•
•
•
•
•
alert
alertdialog
button
checkbox
dialog
gridcell
link
•
•
•
•
•
listbox
log
marquee
menuitem
menuitemcheckbo
x
• menuitemradio
• option
•
•
•
•
•
•
•
progressbar
radio
scrollbar
slider
spinbutton
status
tab
•
•
•
•
•
tabpanel
textbox
timer
tooltip
treeitem
8 Composite Widget Roles:
• combobox
• grid
• menu
• menubar
• radiogroup
• tablist
• Composite widgets contain other widgets.
• tree
• treegrid
• Provide information about an object.
• Are assigned values:
– True/false (default is “false”)
– Tristate - true/false/mixed (default is “false”)
– True/false/undefined (undefined indicates that state is or property is not
relevant)
– ID reference (ID references other element which must exist in page)
– ID reference list (IDs must exist in page)
– Integer
– Number
– String
– Token
– Token list
• The value of an ARIA state is likely to change; properties rarely
change.
• Some properties and states are inherited
– Check the ARIA documentation (www.w3.org/TR/waiaria/complete) to see what you must define.
• States and properties are organized into four categories:
1. Widget Attributes
– support widget roles
2. Live Region Attributes
without
element having focus.
– indicate that content may change
3. Drag-and-Drop Attributes
– Define draggable elements and drop
targets.
4. Relationship Attributes
– Provide semantic association that
cannot be
determined from document structure.
21 Widget Attributes:
•
•
•
•
•
•
•
•
•
•
•
aria-autocomplete
aria-checked (state)
aria-disabled (state)
aria-expanded (state)
aria-haspopup
aria-hidden (state)
aria-invalid (state)
aria-label
aria-level
aria-multiline
aria-multiselectable
•
•
•
•
•
•
•
•
•
•
4 Live Region Attributes:
•
•
•
•
aria-orientation
aria-pressed (state)
aria-readonly
aria-required
aria-selected (state)
aria-sort
aria-valuemax
aria-valuemin
aria-valuenow
aria-valuetext
aria-atomic
aria-busy (state)
aria-live
aria-relevant
2 Drag-and-Drop
Attributes:
•
•
aria-dropeffect
aria-grabbed (state)
8 Relationship Attributes:
•
aria-activedescendant
•
aria-describedby
•
aria-labelledby
•
aria-posinset
•
aria-controls
•
aria-flowto
•
aria-owns
•
aria-setsize
1. aria-describedby
-
Identifies an element which describes the object.
Useful for associating tool tips with form controls or for help text.
Use to associate long descriptions with images.
Element must be visible.
2. aria-label
-
A string used to label the element.
Useful in forms when a visible label is not desired.
3. aria-labelledby
-
Identifies an element containing text used for a label.
Element must be visible.
Note the spelling with 2 l’s.
4. aria-required
-
Indicate to AT that a form field is required.
Allows for better form validation than HTML5 required keyword.
1. Determine appropriate widget role.
– Widget implementation notes are provided in the ARIA documentation
(www.w3.org/TR/wai-aria/complete).
2. Get list of supported properties and states:
– Set applicable states and properties to initial values.
• All inherited states and properties will have there default values
unless overridden.
3. Establish the widget structure in the markup (parent/child).
– You must include any required owned elements (and declare their roles).
– Repeat for all children of the parent.
4. Plan keyboard navigation pattern and implement handlers.
–
–
–
–
–
Ensure that mouse and keyboard interaction is equivalent.
You must show visual focus for each element that has focus.
Follow standard interaction patterns (DHTML Style Guide).
Provide instructions for how to use non-standard widgets.
Avoid defining keyboard shortcuts.
5. Apply and manage ARIA states in response to user input.
6. Synchronize the visual UI state with accessibility states for
supported AT.
– Using JavaScript to apply and remove CSS classes is a useful
approach.
– Consider using CSS attribute selectors to remove need to manage
classes.
• Firebug for Firefox is very useful for debugging ARIA widgets.
• If you hide an element or region, you must also set ariahidden=true.
– Elements hidden with visibility: hidden are still announced by some
screen readers.
– If the hidden element or region is part of a hide/show or tree, set ariaexpanded=false.
• Update <img> alt text as appropriate.
– Example: Text for a graphic to indicate the collapse state of a hide/show
region.
• Use common sense.
– If an ARIA state should logically have a certain value, set it to that value.
• When navigation in a widget is reliant on the tab index to
determine focus:
– Set tabindex=“0” for the currently focusable item in a widget.
– Set tabindex=“-1” for all other focusable items.
• For composite widgets (use aria-activedescendant), set
tabindex=“0” on the container for the widget.
– Update the id referenced by aria-activedescendant to be the current
item.
– Example: combobox widget.
• Use this pattern so a user can tab into and out of a widget
predictably.
• Use keydown instead of keypress event handlers.
• Use focus and blur event handlers to track focus and update
UI status.
• Use keydown handler to determine next element and call that
element’s focus() method.
• When setting focus, use element.focus().
– Do not use createEvent(), initEvent() or dispatchEvent() – these do not change
the focus.
• When handling a tab key event, allow the event to propagate
or the browser will not change focus.
• Disabled controls should not be in the tab order.
– Set tabindex=“-1”.
• Hide/Show Region
– Set aria-expanded to reflect region state.
– Update alt text on <img>. Note: <img> can be considered presentational.
– Use aria-controls when region does not follow control.
•
Menu
– Do not use ARIA menu role navigation menus.
– Implement arrow-key support.
– Consider managing tabindex for large menus.
•
Modal Dialog
–
–
–
–
•
Dialog must take focus when it appears.
Can set focus on dialog or on first focusable element.
Trap focus within dialog
Prevent user from interacting with page outside of dialog.
Tooltip
– Use aria-describedby to associate tooltip with element.
For more information:
•
Accessible Rich Internet Applications (WAI-ARIA) 1.0
www.w3.org/TR/wai-aria/complete
•
WAI-ARIA 1.0 Authoring Practices
www.w3.org/TR/wai-aria-practices
•
University of Illinois Web Best Practices (iCita)
http://html.cita.illinois.edu
•
Open Ajax Accessibility Alliance
www.oaa-accessibility.org
Copyright © 2012 Keith Hays. This work is the intellectual property of the author. Permission is granted for this material to be shared for noncommercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is
by permission of the author. To disseminate otherwise or to republish requires written permission from the author.