HTML5 & WAI-ARIA Forms with jQuery Validation Paul J. Adam Accessibility Evangelist @pauljadam.
Using WAI-ARIA to Make Typical Pages Fabulous #CSUN13
-
Upload
bill-curtis-davidson -
Category
Technology
-
view
106 -
download
0
description
Transcript of 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.”
3© 2013 IBM Corporation
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
© 2013 IBM Corporation
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
5© 2013 IBM Corporation
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)
6© 2013 IBM Corporation
Step 1 – Landmarks: Keep Main Content Simple
Before
After
7© 2013 IBM Corporation
Step 1 – Landmarks: No orphaned content
Content difficult for users to find Relationship to other elements on page lost
Before
After
© 2013 IBM Corporation
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
9© 2013 IBM Corporation
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
10© 2013 IBM Corporation
TabTab Tab
Tab
Support up and down arrows in vertical groups
Step 2 – Keyboard interaction: Vertical Groups
11© 2013 IBM Corporation
Step 2 – Keyboard Experience: Horizontal Groups
Support left and right arrows in horizontal groups
12© 2013 IBM Corporation
Step 2 – Keyboard Interaction: Tabular groups
Blocks of elements that appear tabular may support all 4 arrow keys
13© 2013 IBM Corporation
Step 2 - Keyboard Experience: Visual Focus
Don’t forget the visual focus indicator
14© 2013 IBM Corporation
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
© 2013 IBM Corporation
1. Map visual layout to regions2. Design keyboard experience
Step 3: Map the Keyboard Experience to Widgets
4. Draw labeling and describing relationships
5. Complete widget states and properties
16© 2013 IBM Corporation
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/
17© 2013 IBM Corporation
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
18© 2013 IBM Corporation
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
19© 2013 IBM Corporation
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
20© 2013 IBM Corporation
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
21© 2013 IBM Corporation
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
© 2013 IBM Corporation
1. Map visual layout to regions2. Design keyboard experience 3. Map the keyboard
experience to WAI-ARIA widget roles
Step 4: Labeling and Describing
5. Complete widget states and properties
23© 2013 IBM Corporation
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 …”
24© 2013 IBM Corporation
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”
25© 2013 IBM Corporation
Step 4 – Landmark labeling
“Use labels on multiple regions of the same type.”
JAWS user can’t determine which region to navigate to
26© 2013 IBM Corporation
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>
<!-- Visual label is ‘Actions’. Screen reader label is ‘Actions for Wiki Portlet’ -->
27© 2013 IBM Corporation
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>
<!-- Visual label is ‘Actions’. Screen reader label is ‘Actions for Wiki Portlet’ -->
role=“button”aria-label=“Actions for:” aria-labelledby=“button1 title1”
© 2013 IBM Corporation
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
29© 2013 IBM Corporation
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
© 2013 IBM Corporation
Avoiding Common Mistakes
31© 2013 IBM Corporation
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
32© 2013 IBM Corporation
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”> <!-- button should get focus but does not -->
<!—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>
33© 2013 IBM Corporation
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
<!-- screen reader will not read label for this menu; it is not labeled -->
<div role=”menu”>
<ul aria-label=”Menu label on wrong element”>
<!-- To label the menu, aria-label should be on the DIV, not on the UL -->
<li><A role=”menuitem”>Item 1</a></li>
<li><A role=”menuitem”>Item 2</a></li>
</ul>
</div>
<!-- screen reader will not read label for this menu; it is not labeled -->
<div role=”menu” aria-label=”Menu label on right element”>
<ul>
<!-- To label the menu, aria-label should be on the DIV, not on the UL -->
<li><A role=”menuitem”>Item 1</a></li>
<li><A role=”menuitem”>Item 2</a></li>
</ul>
</div>
34© 2013 IBM Corporation
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”> <!-- Screen reader will see navigation region but not menubar -->
<ul role=”menu> … </ul>
<ul role=”menu”> … </ul>
</ul>
Good: put landmark region role on its own div
<div role=”navigation”> <!-- add div for the navigation region -->
<ul role=”menubar”> <!-- screen reader will recognize this menubar -->
<ul role=”menu> … </ul>
<ul role=”menu”> … </ul>
</ul>
</div>
35© 2013 IBM Corporation
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
36© 2013 IBM Corporation
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
© 2013 IBM Corporation
Summary & Benefits
38© 2013 IBM Corporation
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
© 2013 IBM Corporation
IBM Service Offerings
40© 2013 IBM Corporation
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
41© 2013 IBM Corporation
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
42© 2013 IBM Corporation
Matthew KingIBM I/T Chief Accessibility Strategist
Mary Jo MuellerIBM Human Ability and Accessibility Center
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