Steve Faulkner amp Hans Hillen Diving in to some HTML5 Detailssummary Dialog Spin button slider ARIA rules HTMLARIA validation Tools HTML5 Getting simple HTM5 demo detailssummary ID: 459257
Download Presentation The PPT/PDF document "ARIA + HTML5" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
ARIA + HTML5
Steve Faulkner & Hans HillenSlide2
Diving in to some HTML5
Details/summary
Dialog
Spin button
slider
ARIA rules
HTML/ARIA validation
ToolsSlide3
HTML5
Getting simpleSlide4
HTM5 demo – details/summary
<details>
<summary> label </summary>
Some content
</details>
simpleSlide5
HTM5 demo – details/summary
Supports!Slide6
HTM5 demo – details/summary
What
we get
<summary>Slide7
HTM5 demo – details/summary
What we get
<details>Slide8
HTML5 demo – details/summary
Filling GapsSlide9
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>Slide10
HTM5 demo – details/summarySlide11
HTM5 demo – dialog
Creating a
modal dialog
that works with keyboard and prevents users from accessing ‘disabled’ content is the holy grail….Slide12
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=dialogSlide13
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 scriptingSlide14
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 dialogSlide15
HTM5 demo – input type=number
What we get
Correct role and value information
Keyboard operable
<input
step=
"
2
"
type
=
"
number
"
>Slide16
HTM5 demo – input
type=range
<input
type=range value=10 min=1 max=11>Slide17
HTM5 demo – input type=range
What we get for free
EVERYTHING
\o/Slide18
ARIA
There are conformance rules:
ARIA in HTMLSlide19
HTML
5
specificationSlide20
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>Slide21
http
://validator.w3.org/nu/Slide22
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
.Slide23
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.Slide24
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
)Slide25
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.Slide26
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 PracticesSlide27
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>
Slide28
Firefox
Internet Explorer
Safari
Chrome
Windows, Linux
Windows
OSX + IOS
Android + IOS + Chrome
OS
Zoom
Keyboard
CSS
Zoom
Keyboard
CSSZoomKeyboardTouchZoomKeyboard
Touch
Accessibility testing toolsBrowsers + KeyboardSlide29
Firefox
Internet Explorer
Safari
Chrome
Windows
Windows
OSX + IOS
Android + IOS + Chrome
OS
shift+alt+print
screen
shift+alt+print
screen
Universal Access
IOSOSXContrast ExtensionAccessibility testing toolsBrowsers + High Contrast ModeSlide30
Firefox
Internet Explorer
Safari
Chrome
Windows, Linux
Windows
OSX + IOS
Android + IOS + Chrome
OS
Web Developer
DOM
inspector
Firebug
Developer
tools (F12)Developer tools (OSX)Developer tools (OSX + Chrome OS)
Accessibility testing tools
Developer toolsSlide31
Accessibility testing tools
Firefox –
DOM InspectorSlide32
Accessibility testing tools
Internet Explorer –
Web Accessibility Toolbar Slide33
Accessibility testing tools
aViewerSlide34
Accessibility testing tools
NVDA
– A free open source screen reader for Windows
NVDA Screen Reader
command key quick referenceSlide35
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)Slide36
If you only leave with one take awaySlide37
thank you
www.twitter.com/stevefaulkner
www.paciellogroup.com/blog
www.html5accessibility.com
sfaulkner@paciellogroup.com