Transcript WHAT IS ARIA?
ARIA Web Design and Development Patterns
KEITH HAYS
IT Accessibility Specialist CITES / ITaccess [email protected]
• 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.
– is not a container.
• Four types of roles:
1.
2.
Landmark roles
- enhance document navigation.
Structure roles
– enhance document structure.
3.
4.
Widget roles
- define custom UI widgets.
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.
8.
5.
6.
7.
• Eight roles: 1.
2.
3.
4.
banner main navigation search complementary } } Should be used on most websites.
Use when it seems useful to do so.
form contentinfo } application 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
none
none
none
USE
Once per page on an appropriate Label if more than one.
Once per page on main content container May be appropriate to put on other containers.
Attach to used for site search.
role=“search”
> …
role=“banner”
> …
role=“complementary” aria-labelledby
=“hours-label”>
Office Hours
role=“main”
> …
• 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
• 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
8 Composite Widget Roles:
• combobox • grid • menu • menubar • progressbar • radio • scrollbar • slider • spinbutton • status • tab • radiogroup • tablist • tabpanel • textbox • timer • tooltip • treeitem • tree • treegrid • Composite widgets contain other widgets.
• 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/wai aria/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 cannot be – Provide semantic association that 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 • • • • • • • • • • aria-orientation aria-pressed (state) aria-readonly aria-required aria-selected (state) aria-sort aria-valuemax aria-valuemin aria-valuenow aria-valuetext • • • •
4 Live Region Attributes:
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-controls • aria-flowto • • aria-labelledby aria-owns • • aria-posinset 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 aria hidden=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 aria expanded=false.
• Update 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 the focus.
dispatchEvent()
– these do not change • 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 . Note:
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 non commercial, 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.