Another IBM presentation: “How to go beyond adding WAI-ARIA landmark regions to radically improve the accessibility of ordinary web pages by thinking of them as rich internet applications”
Presenters
- Matthew King
- Mary Jo Mueller
- Bill Curtis-Davidson
HTML is good for documents and static forms, but not good for modern rich web sites.
1 – GET LANDMARKS RIGHT
Landmarks indicate what’s on the page and how it’s organized. Only put inside of a region those things that belong in a region. WAI-ARIA landmark roles are:
- Banner (header)
- Search (search tool)
- Navigation (links)
- Main (main content of page)
- Form (collection of form elements)
- Complementary (info related to main content)
- Contentinfo (footnotes, copyrights, privacy statements, etc)
- Region (content where no other role is applicable)
- Application (software unit embedded on the page – not recommended)
Main region is the most important and needs to be created for every page (before and after screen shots of a page were shown)
Don’t create orphaned content – content that’s not included in any region, or relationship to other elements on the page are lost.
2 – DESIGN THE KEYBOARD EXPERIENCE
- “Make keyboard navigation more like a desktop application experience”
- Study the visual layout and group
- With effective grouping, the tab ring of the page collapses dramatically
- Support up and down arrows in vertical groups (showed a megamenu with categories of links within the menu – sort of like the CSUN home page)
- QUESTION: can you put other elements into a megamenu besides navigation elements? Yes, you could put (for example) a search field in it.
- Support left and right arrows in horizontal groups (i.e. – tabs, toolbars)
- Blocks of elements that appear tabular may support all arrows
- Don’t forget the visual focus indicator
- Skip the “skip link” it just eats up one more tab stop; designs a “tab ring” so short that skip links do not add value. The method for skipping large block of becomes tab itself. Showed a slide with a horizontal group of tabs: without horizontal grouping you have 9 tab stops, with horizontal grouping you have 3 tab stops.
3 – MAP THE KEYBOARD EXPERIENCE TO WIDGETS
- Learn standard keyboard patterns for: menubar with submenus, menu and menu button, tree, toolbar, grid, dialogs containing menus and other widgets
- With appropriate widget choice: perfectly map virtually any navigation scheme, equally efficient for all (keyboard or mouse, visual or non-visual)
QUOTABLE QUOTE: “This is a designer’s job…interaction design is the magic”
Menubars with pulldown menus should work just like they do on the desktop. A good example is www.FreedomScientific.com. This was a powerful demonstration of how much WAI-ARIA affects navigation within a page.
Since JAWS 12, opening a dialog allows you to easily navigate confined tab rings.
Even though they look like tabs, in most cases it is better not to use WAI-ARIA tablist and tab roles. Site nav links that are styled to look like tabs usually don’t work like tabs
4 – LABELING AND DESCRIBING
After identifying elements with correct landmark or widget roles, ALL, with few exceptions, should be labeled and related to any describing elements.
- Use aria-labelledby whenever possible
- Re-use of strings simplifies maintenance, translation, etc
- Brevity is key: aim for 1 or 2 short words, 3 tops; do not use role names in labels i.e. “site navigation” for a navigation region; do not put instructions in labels “press enter to…”
A slide was shown with examples of labeling and describing elements, good and bad
Use labels on multiple regions of the same type; some powerful examples:
- Composite labels
- aria-labelledby multiple IDs
- May self-reference by including ID of element being labeled
- May have both aria-label and area-labelledby on same element
- browser automatically concatenates in specified order
5 – COMPLETING THE DESIGN
Success is in the minutia; implement design patterns thoroughly
Implement WAI-ARIA prperties per design patterns:
COMMON MISTAKES
Lost visual focus = lost user
- Is the new focus location logically what user would expect?
- Telling non-visual user useful information?
- Making the task efficient?
Pay attention to where focus moves
- Elements need to be able to receive focus (menuitem, treeitem, button)
- If a parent or child element has focus instead, it may not work correctly
Best practice is to have one role per element
“Code to the spec, not to the test tool or assistive technology” GREAT ADVICE
- WAI-ARIA spec clearly states intended use for each role
- Purpose is to communicate the intent of UI element to assistive technology
- Use role only to communicate WAI-ARIA specified intent
- Do not re-purpose roles to “fix the issue” or manipulate AT behavior
- If AT does not behave as desired or expected: may be incorrect design or bug in your code, may be incorrect expectations, may be bug in browser, may be bug in AT
SUMMARY AND BENEFITS
WAI-ARIA can dramatically boost accessibility and be as desired by PwD as anyone else