aria + html5 steve faulkner & hans hillen. diving in to some html5 details/summary dialog spin...
TRANSCRIPT
ARIA + HTML5
Steve Faulkner & Hans Hillen
DIVING IN TO SOME HTML5
• Details/summary• Dialog• Spin button• slider• ARIA rules• HTML/ARIA validation• Tools
HTML5
Getting simple
HTM5 DEMO – DETAILS/SUMMARY
<details><summary> label </summary>Some content </details>
simple
HTM5 DEMO – DETAILS/SUMMARY
Supports!
HTM5 DEMO – DETAILS/SUMMARY
What we get
<summary>
HTM5 DEMO – DETAILS/SUMMARY
What we get<details>
HTML5 DEMO – DETAILS/SUMMARY
Filling Gaps
HTM5 DEMO – DETAILS/SUMMARY
<details role="group" id="d1"><summary tabindex="0" role="button" aria-controls="d1" aria-expanded="true|false"> label </summary>Some content </details>
HTM5 DEMO – DIALOG
Creating a modal dialog that works with keyboard and prevents users from accessing ‘disabled’ content is the holy grail….
HTM5 DEMO – DIALOG
• What we get for free• Focus moves to modal dialog when it
is displayed• Focus stays in modal dialog until it is
dismissed• Content not in the modal dialog is really disabled
• ESC key dismisses the dialog• <dialog> = role=dialog
HTM5 DEMO – DIALOG
• What we need to add• Accessible name to dialog
• <dialog aria-label="text">• Currently when the dialog is
dismissed focus moves to the <body> when it needs to move to control that triggered dialog display• Can be polyfilled using scripting
HTM5 DEMO – DIALOG
• The good oil on implementing custom dialogs• Juicy Studio - Custom-Built
Dialogs• The Incredible Accessible Modal
Dialog• WAI-ARIA design pattern – modal
dialog
HTM5 DEMO – INPUT TYPE=NUMBER
• What we get• Correct role and value
information• Keyboard operable
<input step="2" type="number">
HTM5 DEMO – INPUT TYPE=RANGE
<input type=range value=10 min=1 max=11>
HTM5 DEMO – INPUT TYPE=RANGE
• What we get for free
EVERYTHING \o/
ARIA
• There are conformance rules:
ARIA in HTML
HTML 5 SPECIFICATION
ARIA VALIDATION
• Use of ARIA in HTML<5 is non conforming and probably always will be.
• It doesn’t make any difference, it still works
• The easiest method is to use the
HTML5 DOCTYPE with ARIA markup and
validate using the W3C Nu Markup Checker.
<!DOCTYPE html>
1ST RULE OF ARIA USE
If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
1ST RULE OF ARIA USE
Under what circumstances may this not be possible?
• If the visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.
• If the feature is not currently available in HTML.
• If the feature is available in HTML but it is not implemented or it is implemented, but accessibility support is not.
CUSTOM CONTROL ACCESSIBLE DEVELOPMENT CHECKLIST:
Custom Control Design Considerations
design consideration description Yes/No
focusable Can you get to the control via the keyboard? Refer to Providing Keyboard Focus
operable Can you use the control with the keyboard? Refer to Keyboard Navigation
expected operation Can you use the standard keys for the control type to operate it. Refer to ARIA Widget Design Patterns
clear indication of focus Can you easily see it when the control has focus? Refer to Visible Focus (WCAG2)
label The control has a text label that is exposed as an accessible name in accessibility APIs
role The control has an appropriate role exposed in accessibility APIs
states and properties The control has any UI states and properties that it has exposed in accessibility APIs
color contrast The control label/description/icon is perceivable/usable for low vision users (Use a color contrast checker.)
high contrast mode The control is perceivable/usable when High Contrast Mode is enabled (e.g. Windows HC mode)
2ND RULE OF ARIA USE
Do not change native semantics, unless you really have to.
For example: Developer wants to build a heading that's a button.
Do not do this:<h1 role=button>heading button</h1>
Do this:<h1><span role=button>heading button</span></h1>
Or better, do this:<h1><button>heading button</button></h1>
Note: it is OK to use native HTML elements, that have similar semantics to ARIA roles used, for fallback. For example using HTML list elements for the skeleton of an ARIA enabled, scripted tree widget.
3RD RULE OF ARIA USE
All interactive ARIA controls must be usable with the keyboard. If you create a widget that a user can click or tap or drag or drop or slide or scroll a user must also be able navigate to the widget and perform an equivalent action using the keyboard.All interactive widgets must be scripted to respond to standard key strokes or key stroke combinations where applicable.For example if using role=button the element must be able to recieve focus and a user just be able to activate the action associated with the element using both the enter and the space key.Refer to the keyboard and structural navigation and
design patterns sections of the WAI-ARIA 1.0 Authoring Practices
4TH RULE OF ARIA USE
Do not use role="presentation" or aria-hidden="true" on a focusable element. Using either of these on a focusable element will result in some users focusing on 'nothing'.
Do not do this:<button role=presentation>press me</button>
Do not do this:<button aria-hidden=true>press me</button>
Firefox Internet Explorer Safari Chrome
Windows, Linux Windows OSX + IOS Android + IOS + Chrome OS
ZoomKeyboardCSS
ZoomKeyboardCSS
ZoomKeyboardTouch
ZoomKeyboardTouch
ACCESSIBILITY TESTING TOOLS
Browsers + Keyboard
Firefox Internet Explorer Safari Chrome
Windows Windows OSX + IOS Android + IOS + Chrome OS
shift+alt+print screen
shift+alt+print screen
Universal AccessIOSOSX
Contrast Extension
ACCESSIBILITY TESTING TOOLS
Browsers + High Contrast Mode
Firefox Internet Explorer Safari Chrome
Windows, Linux Windows OSX + IOS Android + IOS + Chrome OS
Web DeveloperDOM inspectorFirebug
Developer tools (F12)
Developer tools (OSX)
Developer tools (OSX + Chrome OS)
ACCESSIBILITY TESTING TOOLS
Developer tools
ACCESSIBILITY TESTING TOOLS
Firefox – DOM Inspector
ACCESSIBILITY TESTING TOOLS
Internet Explorer – Web Accessibility Toolbar
ACCESSIBILITY TESTING TOOLS
NVDA – A free open source screen reader for Windows
NVDA Screen Reader command key quick reference
TOOLS
• Aviewer (free desktop application for windows ) • Dom Inspector (free Firefox extension) • Inspect.exe (free desktop application for
windows available as part of the Windows SDK) • Accprobe (free open source cross platform app) • Accessibility Inspector (free Mac app) • Java ferret (free cross platform app)• Accerciser (free gnome desktop app)
IF YOU ONLY LEAVE WITH ONE TAKE AWAY