using wai-aria to make typical pages fabulous #csun13

© 2013 IBM Corporation

Using WAI-ARIA to Make Typical Pages Fabulous

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.

By:

Matthew King

Mary Jo Mueller

Bill Curtis-Davidson

2© 2013 IBM Corporation

Why use WAI-ARIA on an ordinary page?

• HTML – good for documents and simple forms

• NO one wants a document for a home page! Modern sites are rich! Interactively guide expanding, floating, dynamic menus Engage sidebars features dynamic feeds and services Anticipate intelligent, dynamic search

• Rich sites require either ARIA or building an alternative experience Less rich, less satisfying Adds cost

“With WAI-ARIA, flashy, modern design can be MORE, not less, accessible than old-school sites. Like non-PwD, PwD will prefer it.”


Step by step…

1. Map visual layout to regions

2. Design keyboard experience

3. Map the keyboard experience to

WAI-ARIA widget roles

4. Draw labeling and describing

relationships

5. Complete widget states and

properties


Step 1: Get Landmarks Right

2. Design keyboard experience3. Map the keyboard experience to WAI-ARIA widget

roles4. Draw labeling and describing relationships5. Complete widget states and properties


Step 1 – Get Landmarks Right

“Stay true to the role – the contents of a region should match its role e.g. Don’t put search inside navigation”

• Use landmark regions to indicate what is on a page and how it is organized.• Only put inside of a region what belongs in a region

The WAI-ARIA landmark roles are: Banner - the header region Search - contains the search tool Navigation - contains links or other navigational elements Main - main content of the page Form - contains a collection of form elements Complementary - has information that closely relates to the main content Contentinfo - contains footnotes, copyrights, privacy statements, etc. Region - a collection of content where no other role is applicable Application - a software unit embedded on the page (not recommended)


Step 1 – Landmarks: Keep Main Content Simple

Before

After


Step 1 – Landmarks: No orphaned content

Content difficult for users to find Relationship to other elements on page lost

Before

After


1. Get landmarks right

Step 2: Design the Keyboard Experience

3. Map the keyboard experience to WAI-ARIA widget roles

4. Draw labeling and describing relationships

5. Complete widget states and properties


Step 2 - Design the Keyboard Experience

“Make keyboard navigation more like a desktop application experience.”

Study the visual layout and group, group, group… With effective grouping, the tab ring of the page collapses dramatically


TabTab Tab

Tab

Support up and down arrows in vertical groups

Step 2 – Keyboard interaction: Vertical Groups


Step 2 – Keyboard Experience: Horizontal Groups

Support left and right arrows in horizontal groups


Step 2 – Keyboard Interaction: Tabular groups

Blocks of elements that appear tabular may support all 4 arrow keys


Step 2 - Keyboard Experience: Visual Focus

Don’t forget the visual focus indicator


Step 2 - Keyboard Experience: No More Skip Link

• You can “skip” the “skip link” The skip link just eats up one

more tab The tab ring becomes so short

the skip doesn’t add value

• The “method for skipping large block of …” becomes tab itself

Without WAI-ARIA: Multiple skip links 100+ tab stops


1. Map visual layout to regions2. Design keyboard experience

Step 3: Map the Keyboard Experience to Widgets

4. Draw labeling and describing relationships



Step 3 – Map Keyboard Experience to Widgets

“99% of all flashy, modern page navigation designs can be made fabulously accessible with about 1% or WAI-ARIA.”

Learn standard keyboard patterns for:

• Menubar/menu

• Tree

• Toolbar

• Dialog

• Menu and menu button

• Grid

With appropriate widget choice:

• Perfectly map virtually any navigation scheme

• Equally efficient for all (keyboard or mouse, visual or non-visual)

For design patterns, see the WAI-ARIA Authoring Practices Guide, section 11.

http://www.w3.org/WAI/PF/aria-practices/


Step 3 – Choosing a widget

“This is a designers’ job… interaction design is the magic.”

Important questions:

Are there fly-outs, pop-ups, or overlays? Understand distinguishing features of menus, button menus, and dialogs.

Is there visual indication of the currently active page?

Understand patterns that can exploit aria-pressed, aria-selected, or aria-checked: Navigation tree Toolbar with toggle buttons


Step 3 – Learn by example - menubar

“Menubars with pulldown menus should work just like they do on desktops. A good example is www.FreedomScientific.com”

Good choice when:

• Fly-out menus are simple lists

• The keyboard interaction can match menubar/menu pattern


Step 3 – Learn by Example: Mega Menu

Mega menu fly-outs or overlays:

• Have several groups of categorized links

• May have search

• May include other widgets

So require dialog pattern:

• Make modal from keyboard perspective (trap focus)

• Include focusable close icon and support escape

What widget should contain mega menu parent links?

• Menu bar menu items may open menus, not dialogs.

• Dialogs should open with buttons

• So links that open mega menus belong in toolbar of buttons


Step 3 – Learn by Example: Navigation Tree

“For the navigation tree, think of the folder tree in Windows Explorer.”

Good when:

• Have hierarchical navigation structure

• Keyboard interaction can match tree pattern


Step 3 - Learn by example: Tabbed Navigation

“Even though they look like tabs, in most cases it is better not to use WAI-ARIA tablist and tab roles.”

Site navigation links that are styled to look like tabs usually don’t work like tabs: Usually are links that cause a page load or data fetch Usually activated with enter or space Usually can not maintain focus if activated

WAI-ARIA roles that match this behavior: Make each link a button: communicates enter or space to activate Give each button aria-pressed true or false: true indicates activated/displayed Put buttons in toolbar: communicates left/right arrow navigation


1. Map visual layout to regions2. Design keyboard experience 3. Map the keyboard

experience to WAI-ARIA widget roles

Step 4: Labeling and Describing



Step 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

e.g., “Site Navigation” for a navigation region Do not put instructions in labels

e.g., “Press enter to …”


Step 4 – Labeling and Describing: Examples

Element Good Bad

Site navigation region “Site”, “IBM” “Main site navigation”

Primary navigation menubar

“Site map” “Navigation menu”

Left-hand nav tree “Site”, “Wiki” “Site navigator – Use up or down arrow to select a link and press enter”

Search region for product search

“Products” “Find a product”

“Search for a product”


Step 4 – Landmark labeling

“Use labels on multiple regions of the same type.”

JAWS user can’t determine which region to navigate to

Step 4 – Composite Labels

• Powerful WAI-ARIA labeling feature

• Build composite label from multiple elements

– Give aria-labelledby multiple IDs

– May self-reference by including ID of element being labeled

– May have both aria-label and aria-labelledby on same element

– Browser automatically concatenates in specified order

• Very useful when multiple elements have same visual label

– Their context provides distinction for sighted users

– Composite label dynamically adds context for screen reader users

• Example: 5 action buttons on a page

– aria-label labels each button

– aria-labelledby concatenates button label with context label to give complete label

<h2 id=”title1”>Wiki portlet</h2><a id=”button1” role=”button” aria-label=”Actions for” aria-labelledby=”button1

title1” href=”…”>Actions</a>

Step 4 – Composite Labels Example

• Example: 5 action buttons on a page

– aria-label labels each button

– aria-labelledby concatenates button label with context label to give complete label

<h2 id=”title1”>Wiki portlet</h2><a id=”button1” role=”button” aria-label=”Actions for:” aria-labelledby=”button1

title1” href=”…”>Actions</a>



role=“button”aria-label=“Actions for:” aria-labelledby=“button1 title1”


1. Map visual layout to regions2. Design keyboard experience 3. Map the keyboard experience

to WAI-ARIA widget roles4. Draw labeling and describing

relationships

Step 5: Completing the Design


Step 5 – Completing the design

“Success is in the minutia; implement design patterns thoroughly.”

In addition to keyboard behavior, widget role, label, and description:

• Implement WAI-ARIA properties per design patterns:

– Represent visual indicators of active page with WAI-ARIA properties

– Communicate presence of pop-up menus and submenus with aria-haspopup

• Provide clear visual indication of keyboard focus


Avoiding Common Mistakes


Avoiding Mistakes – Properly Manage Focus

“Lost visual focus = lost user”

Ask yourself, 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 when

• Dialogs close – usually return it to button that opened dialog

• Menus close – usually return it to button that opened menu

• Actions are cancelled – should usually return to point where action was initiated

• Actions complete, for example:

– Item deleted from a list – focus on next or prior item

– Object moved – maintain focus on object

Avoiding Mistakes – Correctly Align Role & Focus

• Elements with focusable widget roles need to be able to receive focus, e.g., menuitem, treeitem, button

• If a parent or child element has focus instead, it may not work correctly.

Bad: <li> element recast as button does not get focus

<ul role=”toolbar” aria-label=”Not so good focus example”>

<li role=”button”>

<a tabindex=-1 href=”…”>Button1Label</a>

</li>

<li role=”button”> 

<!—The anchor gets focus, not the LI -->

<a tabindex=0 href=”…”>Button2Label</a>

</li>

</ul>

Good: anchor recast as button gets the focus

<ul role=”toolbar” aria-label=”good focus example”>

<li role=presentation”>

<a tabindex=-1 role=”button” href=”…”>Button1Label</a>

</li>

<li role=”presentation”

<a tabindex=0 role=”button” href=”…”>Button2Label-2</a>

</li>

</ul>

Avoiding Mistakes – Correctly Align Role & Properties

To give a widget a label, state, or property:

• Put the WAI-ARIA attribute on the element that has the widget role

• Do not put the attribute on a parent or child element



<div role=”menu”>

<ul aria-label=”Menu label on wrong element”>



<li><A role=”menuitem”>Item 1</a></li>


</ul>

</div>



<div role=”menu” aria-label=”Menu label on right element”>

<ul>





</ul>

</div>

Avoiding Mistakes – Use One Role Per Element

• WAI-ARIA allows multiple roles on one element

• But, browsers and assistive technologies do not support it

• Best practice: 1 role per element

Bad: widget and landmark region roles on same element

<ul role=”navigation menubar”> 

<ul role=”menu> … </ul>

<ul role=”menu”> … </ul>

</ul>

Good: put landmark region role on its own div

<div role=”navigation”> 

<ul role=”menubar”> 

<ul role=”menu> … </ul>

<ul role=”menu”> … </ul>

</ul>

</div>


Avoiding Mistakes – Use, Don’t Abuse Roles

“Code to the spec, not to the test tool or assistive technology.”

• WAI-ARIA spec clearly states intended use for each role

• Purpose: communicate intent of UI element to assistive technology

• Use role only to communicate WAI-ARIA-specified intent

• If assistive technology 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 assistive technology

• Do not re-purpose roles to “fix the issue” or manipulate AT behavior


Avoiding Mistakes – Common Abuses of Roles

• Live regions on widgets to force speaking of changes:

Not good: e.g., make a whole grid live to create awareness of filtering

Use aria-live sparingly; only for specified purpose

• Application role used to force forms mode:

AT designers choose when forms mode is best for their users

Most AT activate forms mode automatically as appropriate; it’s their job

Reality: valid uses are rare or non-existent … still searching for one


Summary & Benefits


Summary and Benefits

To make a site fabulous:

• Use WAI-ARIA landmarks to summarize ALL content and its organization

• Design efficient keyboard experience with WAI-ARIA widgets in mind

• Judiciously apply WAI-ARIA roles, states, and properties

Visually appealing, efficient, dynamic, modern sites:

• No longer demand “separate but equal” alternative experiences

• No longer need be the bane of PwD

• Can dramatically boost accessibility and be as desired by PwD as anyone else


IBM Service Offerings


Summary of IBM Accessibility Services

• Strategic Accessibility Services

– Discovery Workshop

– Strategy and Roadmap Planning

– Governance and Policy Formation

– Core Design and/or Development Framework Accessibility Assessment

• Accessibility Integration Services

– Accessibility Assessments

– Accessible Web and Application Design

– I/T Accessibility Development & Test Integration

– I/T Accessibility Operational Model & Plan

– Accessibility Training Modules & Services

– I/T Accessibility Marketing & Communications

– Rich Digital Media Captioning Services

• Accessibility Compliance Management Services

– Compliance Monitoring and Tracking Services

– I.T. Accessibility Outsourced Staffing Services


Example Client Scenario – Web Accessibility

IBM offers its deep expertise with topics like WAI-ARIA to help clients: adopt best practices, reduce the risks related to non-compliance with regulations, and achieve innovation in their products and services.

• Strategic Accessibility Services– Strategy and Roadmap Planning – I/T accessibility strategy

includes adoption of standards and best practice accessibility development and test practices.

– Core Design and/or Development Framework Accessibility Assessment – Assessment of a client’s core web design standard/style guide and/or common templates or code components, with expert recommendations for improving the design/framework.

• Accessibility Integration Services– Accessibility Assessments – Assessment of how individual applications

conform to web accessibility standards, and evaluation for usable access with A/T, with recommendations for resolving accessibility issues.

– Accessible Web and Application Design – Design and development of accessible web applications.

– I/T Accessibility Development & Test Integration – Implementing accessibility processes, checklists, standard work products to help teams consistently integrate accessibility into their methodologies.

– Accessibility Training Modules & Services – Developing and helping deliver training (online self-paced, webinars, lectures, detailed learning labs) to


Matthew KingIBM I/T Chief Accessibility Strategist

[email protected]

Mary Jo MuellerIBM Human Ability and Accessibility Center

[email protected]

Featuring the Enterprise Accessibility Risk Management servicesTo learn more, please contact:

Bill Curtis-Davidson – [email protected] Jenkins – [email protected] (Jack) Jaccino – [email protected]

Or visit our web site: www.ibm.com/able

IBM Accessibility

IBMAccess

IBM Accessibility

Bill Curtis-Davidson

Phill Jenkins

Henry (Jack) Jacchino

using wai-aria to make typical pages fabulous #csun13

Technology

ibm corporation step

map keyboard experience

keyboard navigation

keyboard interaction

waiaria widget roles

use waiaria

landmarks right step

waiaria landmark roles