SlideShare ist ein Scribd-Unternehmen logo
1 von 52
Accessible Rich Internet
Applications:
Beyond the Basics
Dylan Barrell
Twitter: @dylanbarrell
GitHub: dylanb
http://unobfuscated.blogspot.com/
http://www.deque.com/
8 trillion
$8 trillion
15%
1 billion
P
O
U
R
Perceivable
Operable
Understandable
Robust
Role
Name
State(s)
Value
Keyboard (and gestures) – add graphic of a Braille keyboard
• Accessibility and the DOM
– DOM tree
• Semantic structure
• Styled with CSS
• Mouse and Keyboard behavior implemented by
browser
• Default mapping to the accessibility tree
– Accessibility tree
• Representation of the accessibility information
• Each element has a name, a role, a value and a
state
• Interpreted by Assistive technology
• Used in combination with the Accessibility API
– Composed Tree (web components)
Insert periodic table of ARIA
roles
• ARIA roles:
– Provide the ability to control the transition
between application (forms) mode and
document mode
– Provide more native announcments for
widgets like menus, tabs, sliders etc.
– Provide for the ability to control
announcements when updates occur away
from the focus
– Provide much more control over the structure
of the document and how someone navigates
around it
<div id=”myId" class=”…”>
<button class=”…” id=”…”
role="slider”
aria-labelledby=”sliderLabelID”
aria-valuemin="0" aria-valuemax="100”
aria-valuenow="0" aria-valuetext="0%”>
</button>
</div>
• Adding role:
– Changes the mapping to the accessibility API
– Does not change the behavior
• Focussability
• Keyboard interaction
• Mouse interaction
– Does not change the appearance
<div id=”myId" class=”…”>
<button class=”…” id=”…”
role="slider”
aria-labelledby=”sliderLabelID”
aria-valuemin="0" aria-valuemax="100”
aria-valuenow="0" aria-valuetext="0%”>
</button>
</div>
Insert periodic table of ARIA
attributes
• ARIA attributes:
– Solve the problem of multiple labels and
descriptions through the addition of finer-
grained labeling attributes
– Enhance the ARIA roles through the addition
of standard state, value and role-specifying
attributes
– Add some attributes for better control of what
is spoken by the screen reader versus what is
simply there for presentational purposes
<div id=”myId" class=”…”>
<button class=”…” id=”…”
role="slider”
aria-labelledby=”sliderLabelID”
aria-valuemin="0" aria-valuemax="100”
aria-valuenow="0" aria-valuetext="0%”>
</button>
</div>
<div id=”myId" class=”…”>
<button class=”…” id=”…”
role="slider”
aria-labelledby=”sliderLabelID”
aria-valuemin="0" aria-
valuemax="100”
aria-valuenow="0" aria-
valuetext="0%”>
</button>
</div>
<div id=”myId" class=”…”>
<button class=”…” id=”…”
role="slider”
aria-labelledby=”sliderLabelID”
aria-valuemin="0" aria-
valuemax="100”
aria-valuenow="0" aria-
valuetext="0%”>
</button>
</div>
<div id=”myId" class=”…”>
<button class=”…” id=”…”
role="slider”
aria-labelledby=”sliderLabelID”
aria-valuemin="0" aria-
valuemax="100”
aria-valuenow="0" aria-
valuetext="0%”>
</button>
</div>
<div id=”myId" class=”…”>
<button class=”…” id=”…”
role="slider”
aria-labelledby=”sliderLabelID”
aria-valuemin="0" aria-
valuemax="100”
aria-valuenow="0" aria-
valuetext="0%”>
</button>
</div>
<div id=”myId" class=”…”>
<button class=”…” id=”…”
role="slider”
aria-labelledby=”sliderLabelID”
aria-valuemin="0" aria-
valuemax="100”
aria-valuenow="0" aria-
valuetext="0%”>
</button>
</div>
handled = false,
$this = jQuery(this);
if (e.ctrlKey || e.shiftKey || e.altKey || e.metaKey) {
// not interested
return;
}
/*
* Open a sub-menu and place focus on the first menuitem
within it
*/
function openMenu() {
if($this.hasClass("a11yfy-has-submenu")) {
$this.addClass("open").attr("aria-expanded",
"true").find(">ul>li:visible").first().attr("tabindex", "0").focus();
$this.attr("tabindex", "-1");
}
}
/*
* Move the focus to the menuitem preceding the current
menuitem
*/
function prevInMenu() {
var $context = $this;
$this.attr("tabindex", "-1");
while (true) {
if ($context.prev().is(':visible')) {
$context.prev().attr("tabindex", "0").focus();
return
}
$context = $context.prev();
if (!$context.prev().length) {
$context = $this.parent().find(">li").last();
if ($context.is(':visible')) {
$context.attr("tabindex", "0").focus();
return
}
}
if ($context[0] === $this[0]) {
$this.attr("tabindex", "0")
break;
}
}
}
/*
* Move the focus to the next menuitem after the currently
focussed menuitem
*/
function nextInMenu() {
var $context = $this;
$this.attr("tabindex", "-1");
while (true) {
if ($context.next().is(':visible')) {
$context.next().attr("tabindex", "0").focus(
/*
* This implements the WAI-ARIA-PRACTICES keyboard
functionality where
* pressing the key, corresponding to the first letter of a
VISIBLE element
* will move the focus to the first such element after the
currently focussed
* element
*/
var keyCode = e.charCode || e.which || e.keyCode,
keyString = String.fromCharCode(keyCode).toLowerCase(),
ourIndex = -1,
currentItem = this,
$this = jQuery(this),
$nextItem, $prevItem,
$menuitems = $menu.find("li[role="menuitem"]:visible");
if (keyCode === 9) {
return true;
}
$menuitems.each(function(index, value) {
if (value === currentItem) {
ourIndex = index;
}
if (index > ourIndex && !$nextItem) {
if
(jQuery(value).text().trim().toLowerCase().indexOf(keyString) === 0) {
if (ourIndex !== -1) {
$nextItem = jQuery(value);
} else if (!$prevItem) {
$prevItem = jQuery(value);
}
}
}
});
if (!$nextItem && $prevItem) {
$nextItem = $prevItem;
}
if ($nextItem) {
$nextItem.attr("tabindex", "0").focus();
$this.attr("tabindex", "-1");
if ($nextItem.parent().get(0) !== $this.parent().get(0)) {
$this.parent().parent("li").removeClass("open").attr("aria-
expanded", "false");
}
}
e.stopPropagation();
}).on("keydown", function(e) {
/*
* This implements the WAI-ARIA-PRACTICES keyboard
navigation functionality
*/
var keyCode = e.which || e.keyCode,
} else {
/* If in sub-menu, open sub-sub-menu */
openMenu();
}
break;
case 40: //down
handled = true;
if ($this.parent().hasClass("a11yfy-top-level-menu")) {
/* If in menubar, open sub-menu */
openMenu();
} else {
/* If in sub-menu, move to the next menuitem */
nextInMenu();
}
break;
}
if (handled) {
e.preventDefault();
e.stopPropagation();
}
return true;
);
return
}
$context = $context.next();
if (!$context.next().length) {
$context = $this.parent().find(">li").first();
if ($context.is(':visible')) {
$context.attr("tabindex", "0").focus();
return
}
}
if ($context[0] === $this[0]) {
$this.attr("tabindex", "0")
break;
}
}
}
switch(keyCode) {
case 32: // space
case 13: // enter
handled = true;
if ($this.find(">a").length) {
if ($this.find(">a")[0].click) {
/* If this is a leaf node, activate it*/
$this.find(">a")[0].click();
} else {
// This is a hack for PhantomJS
$this.find(">a").first().trigger("click");
}
} else {
/* If it has a sub-menu, open the sub-menu */
openMenu();
}
break;
case 37: //left
case 27: //esc
handled = true;
if (keyCode === 37 && $this.parent().hasClass("a11yfy-
top-level-menu")) {
/* If in the menubar, then simply move to the previous
menuitem */
prevInMenu();
} else {
if ($this.parent().attr("role") === "menu") {
// this is part of a submenu, set focus on containing li
$this.parent().parent().attr("tabindex", "0").focus()
.removeClass("open").attr("aria-expanded",
"false");
$this.attr("tabindex", "-1");
}
}
break;
case 38: //up
handled = true;
if ($this.parent().hasClass("a11yfy-top-level-menu")) {
/* If in the menubar, then open the sub-menu */
openMenu();
} else {
/* If in sub-menu, move to previous element */
prevInMenu();
}
break;
case 39: //right
handled = true;
if ($this.parent().hasClass("a11yfy-top-level-menu")) {
/* If in menubar, move to next menuitem */
nextInMenu();
First ARIA Best Practice – If there is a
native HTML element that does the
job, use that
Examples
1. Use <button> and <input
type=“submit”> NOT <a
role=“button”>
2. Use <ul>, <ol> and <li> NOT <span
role=“list”> etc.
Compelling ARIA roles
• Landmark Roles
– main, search, navigation, contentinfo, complementary,
banner
– region in combination with aria-label
• Live Region Roles
– log, status, alert
• Some Widget Roles
– tabpanel and tab
– slider
– menu, menubar, menuitem and associated attributes
– dialog – in combination with the document role to get it to
work in NVDA
– tree and treeitem – a bit tricky to get to work reliably
• Some form roles
– button, textbox, checkbox, radio, radiogroup
• presentation role
Second ARIA Best Practice – test it
on all YOUR platforms with the
assistive technology YOU must
support
All platforms have problems, most
have workarounds, iOS is the
most problematic and Android is
not quite ready for prime time yet
ARIA holes
• Tables, tables, tables
– Use the a11yfy library
• Arrow keys on iOS
– Insert dynamic modal content in line
– Use gestures
• Gestures
– Think hard about your mapping to the
portable gestures
– add on screen controls where possible
Accessible Gesture Calendar Example
https://github.com/dylanb/gestura11y
http://dylanb.github.io/datepicker/datepicker.html
• Shows use of tabindex to control focus
• Shows use of role=“application” to force
application mode
• Shows use of aria-live regions to announce the
current date as the user moves around
• Shows use of aria-hidden to hide presentation
markup from the screen reader
• Shows use of keyboard handler and mapping to
gestures
• Shows how to ensure that gestures are consistent
regardless of zoom level
Accessible Gesture Calendar Example
https://github.com/dylanb/gestura11y
Third ARIA Best Practice – Always
attach your event handlers to the
same element that has the role
and the focus
If you stick to this rule, you will avoid
events not being delivered
consistently
Fourth ARIA Best Practice – In
complex widgets like menubars,
tabpanels etc. always make all
interim structures presentational
Fifth ARIA Best Practice – in a
complex widget where you are
managing focus, disable all
naturally focusable elements with
tabindex=“-1”
Example is the a11yfy menu
examples where the anchors are
given tabindex=“-1”
Finally
There is a wealth or resources including
The ARIA specification (recommendation, normative)
http://www.w3.org/TR/wai-aria/
The Authoring Practices (draft)
http://www.w3.org/TR/wai-aria-practices/
Using ARIA in HTML (draft, informative)
http://www.w3.org/TR/aria-in-html/
The WAI Web Site http://www.w3.org/WAI/intro/aria
Mozilla Developer Network
https://developer.mozilla.org/en-
US/docs/Web/Accessibility/ARIA

Weitere ähnliche Inhalte

Ähnlich wie Aria a11ycamp-bay-2015

jQuery Mobile
jQuery MobilejQuery Mobile
jQuery Mobile
mowd8574
 
HTML5 and the dawn of rich mobile web applications pt 2
HTML5 and the dawn of rich mobile web applications pt 2HTML5 and the dawn of rich mobile web applications pt 2
HTML5 and the dawn of rich mobile web applications pt 2
James Pearce
 
aria_with_kissy
aria_with_kissyaria_with_kissy
aria_with_kissy
yiming he
 
The Best (and Worst) of Django
The Best (and Worst) of DjangoThe Best (and Worst) of Django
The Best (and Worst) of Django
Jacob Kaplan-Moss
 

Ähnlich wie Aria a11ycamp-bay-2015 (20)

Dynamic and accessible web content with WAI-ARIA
Dynamic and accessible web content with WAI-ARIADynamic and accessible web content with WAI-ARIA
Dynamic and accessible web content with WAI-ARIA
 
Real JavaScript Ninjas should know how to role with WAI-ARIA
Real JavaScript Ninjas should know how to role with WAI-ARIAReal JavaScript Ninjas should know how to role with WAI-ARIA
Real JavaScript Ninjas should know how to role with WAI-ARIA
 
The Inclusive Web: hands-on with HTML5 and jQuery
The Inclusive Web: hands-on with HTML5 and jQueryThe Inclusive Web: hands-on with HTML5 and jQuery
The Inclusive Web: hands-on with HTML5 and jQuery
 
jQuery Mobile
jQuery MobilejQuery Mobile
jQuery Mobile
 
ARIA Gone Wild
ARIA Gone WildARIA Gone Wild
ARIA Gone Wild
 
HTML5 and the dawn of rich mobile web applications pt 2
HTML5 and the dawn of rich mobile web applications pt 2HTML5 and the dawn of rich mobile web applications pt 2
HTML5 and the dawn of rich mobile web applications pt 2
 
HTML5 Accessibility
HTML5 AccessibilityHTML5 Accessibility
HTML5 Accessibility
 
jQuery UI and Plugins
jQuery UI and PluginsjQuery UI and Plugins
jQuery UI and Plugins
 
Introduction to Web Components
Introduction to Web ComponentsIntroduction to Web Components
Introduction to Web Components
 
FamilySearch Reference Client
FamilySearch Reference ClientFamilySearch Reference Client
FamilySearch Reference Client
 
JQuery Flot
JQuery FlotJQuery Flot
JQuery Flot
 
Jquery 3
Jquery 3Jquery 3
Jquery 3
 
RubyBarCamp “Полезные gems и plugins”
RubyBarCamp “Полезные gems и plugins”RubyBarCamp “Полезные gems и plugins”
RubyBarCamp “Полезные gems и plugins”
 
jQuery in the [Aol.] Enterprise
jQuery in the [Aol.] EnterprisejQuery in the [Aol.] Enterprise
jQuery in the [Aol.] Enterprise
 
London React April- r3t & a11y : This is for everyone , Shaun Dunne.
London React April-  r3t & a11y : This is for everyone , Shaun Dunne.London React April-  r3t & a11y : This is for everyone , Shaun Dunne.
London React April- r3t & a11y : This is for everyone , Shaun Dunne.
 
aria_with_kissy
aria_with_kissyaria_with_kissy
aria_with_kissy
 
Making your jQuery Plugins More Accessible
Making your jQuery Plugins More AccessibleMaking your jQuery Plugins More Accessible
Making your jQuery Plugins More Accessible
 
WAI-ARIA An introduction to Accessible Rich Internet Applications / AccessU 2018
WAI-ARIA An introduction to Accessible Rich Internet Applications / AccessU 2018WAI-ARIA An introduction to Accessible Rich Internet Applications / AccessU 2018
WAI-ARIA An introduction to Accessible Rich Internet Applications / AccessU 2018
 
Modularity and Layered Data Model
Modularity and Layered Data ModelModularity and Layered Data Model
Modularity and Layered Data Model
 
The Best (and Worst) of Django
The Best (and Worst) of DjangoThe Best (and Worst) of Django
The Best (and Worst) of Django
 

Kürzlich hochgeladen

Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Safe Software
 
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
?#DUbAI#??##{{(☎️+971_581248768%)**%*]'#abortion pills for sale in dubai@
 

Kürzlich hochgeladen (20)

Apidays New York 2024 - The value of a flexible API Management solution for O...
Apidays New York 2024 - The value of a flexible API Management solution for O...Apidays New York 2024 - The value of a flexible API Management solution for O...
Apidays New York 2024 - The value of a flexible API Management solution for O...
 
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
 
MS Copilot expands with MS Graph connectors
MS Copilot expands with MS Graph connectorsMS Copilot expands with MS Graph connectors
MS Copilot expands with MS Graph connectors
 
Boost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdfBoost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdf
 
EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER
EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWEREMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER
EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER
 
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
 
Real Time Object Detection Using Open CV
Real Time Object Detection Using Open CVReal Time Object Detection Using Open CV
Real Time Object Detection Using Open CV
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
 
AXA XL - Insurer Innovation Award Americas 2024
AXA XL - Insurer Innovation Award Americas 2024AXA XL - Insurer Innovation Award Americas 2024
AXA XL - Insurer Innovation Award Americas 2024
 
A Year of the Servo Reboot: Where Are We Now?
A Year of the Servo Reboot: Where Are We Now?A Year of the Servo Reboot: Where Are We Now?
A Year of the Servo Reboot: Where Are We Now?
 
TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
TrustArc Webinar - Unlock the Power of AI-Driven Data DiscoveryTrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
 
presentation ICT roal in 21st century education
presentation ICT roal in 21st century educationpresentation ICT roal in 21st century education
presentation ICT roal in 21st century education
 
FWD Group - Insurer Innovation Award 2024
FWD Group - Insurer Innovation Award 2024FWD Group - Insurer Innovation Award 2024
FWD Group - Insurer Innovation Award 2024
 
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemkeProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
 
Emergent Methods: Multi-lingual narrative tracking in the news - real-time ex...
Emergent Methods: Multi-lingual narrative tracking in the news - real-time ex...Emergent Methods: Multi-lingual narrative tracking in the news - real-time ex...
Emergent Methods: Multi-lingual narrative tracking in the news - real-time ex...
 
Apidays Singapore 2024 - Modernizing Securities Finance by Madhu Subbu
Apidays Singapore 2024 - Modernizing Securities Finance by Madhu SubbuApidays Singapore 2024 - Modernizing Securities Finance by Madhu Subbu
Apidays Singapore 2024 - Modernizing Securities Finance by Madhu Subbu
 
2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...
 
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
 
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
 

Aria a11ycamp-bay-2015

  • 2. Dylan Barrell Twitter: @dylanbarrell GitHub: dylanb http://unobfuscated.blogspot.com/ http://www.deque.com/
  • 3.
  • 6. 15%
  • 11. Keyboard (and gestures) – add graphic of a Braille keyboard
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18. • Accessibility and the DOM – DOM tree • Semantic structure • Styled with CSS • Mouse and Keyboard behavior implemented by browser • Default mapping to the accessibility tree – Accessibility tree • Representation of the accessibility information • Each element has a name, a role, a value and a state • Interpreted by Assistive technology • Used in combination with the Accessibility API – Composed Tree (web components)
  • 19.
  • 20.
  • 21. Insert periodic table of ARIA roles
  • 22. • ARIA roles: – Provide the ability to control the transition between application (forms) mode and document mode – Provide more native announcments for widgets like menus, tabs, sliders etc. – Provide for the ability to control announcements when updates occur away from the focus – Provide much more control over the structure of the document and how someone navigates around it
  • 23.
  • 24. <div id=”myId" class=”…”> <button class=”…” id=”…” role="slider” aria-labelledby=”sliderLabelID” aria-valuemin="0" aria-valuemax="100” aria-valuenow="0" aria-valuetext="0%”> </button> </div>
  • 25. • Adding role: – Changes the mapping to the accessibility API – Does not change the behavior • Focussability • Keyboard interaction • Mouse interaction – Does not change the appearance
  • 26. <div id=”myId" class=”…”> <button class=”…” id=”…” role="slider” aria-labelledby=”sliderLabelID” aria-valuemin="0" aria-valuemax="100” aria-valuenow="0" aria-valuetext="0%”> </button> </div>
  • 27. Insert periodic table of ARIA attributes
  • 28. • ARIA attributes: – Solve the problem of multiple labels and descriptions through the addition of finer- grained labeling attributes – Enhance the ARIA roles through the addition of standard state, value and role-specifying attributes – Add some attributes for better control of what is spoken by the screen reader versus what is simply there for presentational purposes
  • 29. <div id=”myId" class=”…”> <button class=”…” id=”…” role="slider” aria-labelledby=”sliderLabelID” aria-valuemin="0" aria-valuemax="100” aria-valuenow="0" aria-valuetext="0%”> </button> </div>
  • 30. <div id=”myId" class=”…”> <button class=”…” id=”…” role="slider” aria-labelledby=”sliderLabelID” aria-valuemin="0" aria- valuemax="100” aria-valuenow="0" aria- valuetext="0%”> </button> </div>
  • 31. <div id=”myId" class=”…”> <button class=”…” id=”…” role="slider” aria-labelledby=”sliderLabelID” aria-valuemin="0" aria- valuemax="100” aria-valuenow="0" aria- valuetext="0%”> </button> </div>
  • 32. <div id=”myId" class=”…”> <button class=”…” id=”…” role="slider” aria-labelledby=”sliderLabelID” aria-valuemin="0" aria- valuemax="100” aria-valuenow="0" aria- valuetext="0%”> </button> </div>
  • 33. <div id=”myId" class=”…”> <button class=”…” id=”…” role="slider” aria-labelledby=”sliderLabelID” aria-valuemin="0" aria- valuemax="100” aria-valuenow="0" aria- valuetext="0%”> </button> </div>
  • 34. <div id=”myId" class=”…”> <button class=”…” id=”…” role="slider” aria-labelledby=”sliderLabelID” aria-valuemin="0" aria- valuemax="100” aria-valuenow="0" aria- valuetext="0%”> </button> </div>
  • 35.
  • 36. handled = false, $this = jQuery(this); if (e.ctrlKey || e.shiftKey || e.altKey || e.metaKey) { // not interested return; } /* * Open a sub-menu and place focus on the first menuitem within it */ function openMenu() { if($this.hasClass("a11yfy-has-submenu")) { $this.addClass("open").attr("aria-expanded", "true").find(">ul>li:visible").first().attr("tabindex", "0").focus(); $this.attr("tabindex", "-1"); } } /* * Move the focus to the menuitem preceding the current menuitem */ function prevInMenu() { var $context = $this; $this.attr("tabindex", "-1"); while (true) { if ($context.prev().is(':visible')) { $context.prev().attr("tabindex", "0").focus(); return } $context = $context.prev(); if (!$context.prev().length) { $context = $this.parent().find(">li").last(); if ($context.is(':visible')) { $context.attr("tabindex", "0").focus(); return } } if ($context[0] === $this[0]) { $this.attr("tabindex", "0") break; } } } /* * Move the focus to the next menuitem after the currently focussed menuitem */ function nextInMenu() { var $context = $this; $this.attr("tabindex", "-1"); while (true) { if ($context.next().is(':visible')) { $context.next().attr("tabindex", "0").focus( /* * This implements the WAI-ARIA-PRACTICES keyboard functionality where * pressing the key, corresponding to the first letter of a VISIBLE element * will move the focus to the first such element after the currently focussed * element */ var keyCode = e.charCode || e.which || e.keyCode, keyString = String.fromCharCode(keyCode).toLowerCase(), ourIndex = -1, currentItem = this, $this = jQuery(this), $nextItem, $prevItem, $menuitems = $menu.find("li[role="menuitem"]:visible"); if (keyCode === 9) { return true; } $menuitems.each(function(index, value) { if (value === currentItem) { ourIndex = index; } if (index > ourIndex && !$nextItem) { if (jQuery(value).text().trim().toLowerCase().indexOf(keyString) === 0) { if (ourIndex !== -1) { $nextItem = jQuery(value); } else if (!$prevItem) { $prevItem = jQuery(value); } } } }); if (!$nextItem && $prevItem) { $nextItem = $prevItem; } if ($nextItem) { $nextItem.attr("tabindex", "0").focus(); $this.attr("tabindex", "-1"); if ($nextItem.parent().get(0) !== $this.parent().get(0)) { $this.parent().parent("li").removeClass("open").attr("aria- expanded", "false"); } } e.stopPropagation(); }).on("keydown", function(e) { /* * This implements the WAI-ARIA-PRACTICES keyboard navigation functionality */ var keyCode = e.which || e.keyCode,
  • 37. } else { /* If in sub-menu, open sub-sub-menu */ openMenu(); } break; case 40: //down handled = true; if ($this.parent().hasClass("a11yfy-top-level-menu")) { /* If in menubar, open sub-menu */ openMenu(); } else { /* If in sub-menu, move to the next menuitem */ nextInMenu(); } break; } if (handled) { e.preventDefault(); e.stopPropagation(); } return true; ); return } $context = $context.next(); if (!$context.next().length) { $context = $this.parent().find(">li").first(); if ($context.is(':visible')) { $context.attr("tabindex", "0").focus(); return } } if ($context[0] === $this[0]) { $this.attr("tabindex", "0") break; } } } switch(keyCode) { case 32: // space case 13: // enter handled = true; if ($this.find(">a").length) { if ($this.find(">a")[0].click) { /* If this is a leaf node, activate it*/ $this.find(">a")[0].click(); } else { // This is a hack for PhantomJS $this.find(">a").first().trigger("click"); } } else { /* If it has a sub-menu, open the sub-menu */ openMenu(); } break; case 37: //left case 27: //esc handled = true; if (keyCode === 37 && $this.parent().hasClass("a11yfy- top-level-menu")) { /* If in the menubar, then simply move to the previous menuitem */ prevInMenu(); } else { if ($this.parent().attr("role") === "menu") { // this is part of a submenu, set focus on containing li $this.parent().parent().attr("tabindex", "0").focus() .removeClass("open").attr("aria-expanded", "false"); $this.attr("tabindex", "-1"); } } break; case 38: //up handled = true; if ($this.parent().hasClass("a11yfy-top-level-menu")) { /* If in the menubar, then open the sub-menu */ openMenu(); } else { /* If in sub-menu, move to previous element */ prevInMenu(); } break; case 39: //right handled = true; if ($this.parent().hasClass("a11yfy-top-level-menu")) { /* If in menubar, move to next menuitem */ nextInMenu();
  • 38.
  • 39.
  • 40. First ARIA Best Practice – If there is a native HTML element that does the job, use that Examples 1. Use <button> and <input type=“submit”> NOT <a role=“button”> 2. Use <ul>, <ol> and <li> NOT <span role=“list”> etc.
  • 41. Compelling ARIA roles • Landmark Roles – main, search, navigation, contentinfo, complementary, banner – region in combination with aria-label • Live Region Roles – log, status, alert • Some Widget Roles – tabpanel and tab – slider – menu, menubar, menuitem and associated attributes – dialog – in combination with the document role to get it to work in NVDA – tree and treeitem – a bit tricky to get to work reliably • Some form roles – button, textbox, checkbox, radio, radiogroup • presentation role
  • 42. Second ARIA Best Practice – test it on all YOUR platforms with the assistive technology YOU must support All platforms have problems, most have workarounds, iOS is the most problematic and Android is not quite ready for prime time yet
  • 43. ARIA holes • Tables, tables, tables – Use the a11yfy library • Arrow keys on iOS – Insert dynamic modal content in line – Use gestures • Gestures – Think hard about your mapping to the portable gestures – add on screen controls where possible
  • 44. Accessible Gesture Calendar Example https://github.com/dylanb/gestura11y http://dylanb.github.io/datepicker/datepicker.html • Shows use of tabindex to control focus • Shows use of role=“application” to force application mode • Shows use of aria-live regions to announce the current date as the user moves around • Shows use of aria-hidden to hide presentation markup from the screen reader • Shows use of keyboard handler and mapping to gestures • Shows how to ensure that gestures are consistent regardless of zoom level
  • 45. Accessible Gesture Calendar Example https://github.com/dylanb/gestura11y
  • 46.
  • 47.
  • 48.
  • 49. Third ARIA Best Practice – Always attach your event handlers to the same element that has the role and the focus If you stick to this rule, you will avoid events not being delivered consistently
  • 50. Fourth ARIA Best Practice – In complex widgets like menubars, tabpanels etc. always make all interim structures presentational
  • 51. Fifth ARIA Best Practice – in a complex widget where you are managing focus, disable all naturally focusable elements with tabindex=“-1” Example is the a11yfy menu examples where the anchors are given tabindex=“-1”
  • 52. Finally There is a wealth or resources including The ARIA specification (recommendation, normative) http://www.w3.org/TR/wai-aria/ The Authoring Practices (draft) http://www.w3.org/TR/wai-aria-practices/ Using ARIA in HTML (draft, informative) http://www.w3.org/TR/aria-in-html/ The WAI Web Site http://www.w3.org/WAI/intro/aria Mozilla Developer Network https://developer.mozilla.org/en- US/docs/Web/Accessibility/ARIA

Hinweis der Redaktion

  1. Vice President of Product Development at Deque Maintain the a11yfy jQuery open source library and the ngA11y accessibility library for Angular.js Maintain the open source gulp-coverage code coverage module for Gulp.js jQuery UI accessibility contributor Interesting facts: Love JavaScript, Love Dancing have a Son studying computer science at Michigan
  2. Deque is a pioneer in the accessibility industry. Since 1999. Our mission is digital equality. We are a software-based services company. Three main products are the FireEyes accessibility plug-in for Firebug, WorldSpace Enterprise accessibility analysis and reporting tool and the 2013 Computer World 21st Century Award Innovation category winning Amaze – a product for making web applications accessible without source code changes.
  3. What does the number 8 Trillion have to do with accessibility?
  4. $8 Trillion dollars is the yearly spending power of people with disabilities and their immediate families according to Gartner
  5. 15% of the population in the World have a disability
  6. That is approximately 1 billion people
  7. Why is accessibility like a Guinness? Because Guinness is all about the POUR and accessibility is all about POUR too.
  8. P.O.U.R. stands for Perceivable, Operable, Understandable and Robust the four principles of accessibility that underpin the WCAG 2 standard. WCAG 2 Guideline 1 deals with issues of perception Guideline 2, with making UI components operable with all sorts of input devices Guideline 3, with making the page, the UI and the content understandable, and Guideline 4, with making it work across all devices and user agents
  9. Name, Role, Value and State is one of the most important concepts related to accessibility. Lets take Michelangelo as an example, his name is michelangelo, his role is “ninja Turtle” his state could be “eating pizza” and his value might be “full” or “famished”, and similar concepts apply for every UI element, A button may be called “submit”, play the role of a button, have a state of disabled. There is not necessarily a value associated with a button. This is important, everything needs a name, after that, it may or may not be appropriate to apply the other attributes depending on the situation.
  10. The third important principle of accessibility is to make everything keyboard accessible and to ensure that that keyboard accessibility works with assistive technology like a screen reader turned on. Focus management is a big part of this and tabindex is your friend when it comes to focus management.
  11. Here is the current list of all the HTML 5 elements grouped into Josh Duck’s groupings of Text-level, Metadata and Scripting, Embedding content, Grouping Content, Forms, Document sections, Tabular data and Interactive elements. Now the forms and tables obviously form a big part of what we see on the web, but the thing that strikes me when I look at this picture is of all 100-something elements, only 4 of them are grouped into the category of “Interactive Elements”. The Web would be a pretty boring place, if that was all that was possible. Also, I have actually never ever seen one of those elements actually used in the wild. Has anyone here ever used or seen one of the elements - menu, command, summary or details used on a web site or application? This gives you an idea of some of the problems that accessibility faces without ARIA. It is not possible to easily communicate to the user the roles of the elements that they are interacting-with. HTML (including HTML 5) was really designed with content (and not applications) in mind but has been enhanced by JavaScript and CSS to implement web applications. The problem with that is that accessibility for dynamic web applications has been made difficult and in some cases impossible to achieve when only using HTML. Let me show you 4 of the most common types of problems that dynamc web applications face with respect to accessibility.
  12. You probably all recognize this GitHub repository creation form. It’s a pretty simple form – right? How many labels/instructional texts does the “repository name” input field have? In my opinion, there are at least 3 associated pieces of information for that field, the account, the text “Repository Name” and the additional information about what makes a great repository name. You could argue that there are 2 other pieces of information associated with that field: the fact that you are creating a public repo and the slash between the account and the name. At any rate, even with just three labels, it is not possible to elegantly solve this problem purely with HTML 5 for a screen reader. You end up being forced to replicate the instructional or labeling information into off-screen text and you do not have fine-grained control as to when the information is read. You could definitely make a case for the additional instructions “Great repository names are short and memorable, Need inspiration? How about ‘tripping avenger’.” To be read only after all other information about the form and also to be interrupted if the user starts to type.
  13. Who recognizes this? This is the “waiting” gif. It and its brethren were introduced because of AJAX. To inform users that the browser was doing something and they should wait. Generally when this disappears, the page is dynamically updated in some way. Sometimes, this guy is not used and the page simply updates itself automatically. Think about Facebook chat or Twitter. With HTML 5 it is not possible to maintain focus on one part of the screen, but tell the screen reader user about an update that occurred on another part of the screen. This makes that sort of dynamic UI very difficult – sometimes impossible – to make accessible.
  14. Take a look at this screen shot of my GitHub profile page. You will notice it has quite a lot of information on it. One of the things it has is a tabbed user interface. This user interface is implemented using? Anyone? Of course, an unordered list. Now going back to our Role, Name, Value State discussion, what is the state of the first tab in the list of three tabs? It is the “Selected” tab. In HTML 5, there is no standard way to communicate that to the screen reader other than adding off-screen text. This is ok, but it needs to be maintained, translated etc. and it results in a different experience for the user every time they encounter tabs on the Web. You will notice that the developer who created this page, put a “selected” class on the anchor inside the list item, which CSS uses to style that tab differently. But the screen reader does not know anything about the semantic of that class as the class name itself could be called anything.
  15. What does this image look like? It looks like a calendar date picker widget. Actually, it is implemented as a table. As a keyboard-only user, like a screen reader user, to navigate and find a date effectively, I would expect to be able to use keys like the UP arrow, DOWN arrow, Page Up, Page Down etc. The problem is, that he screen reader interprets these keys to allow the screen reader user to quickly navigate the page. So arrow down will navigate to the next element in the DOM instead of being delivered to your JavaScript handler. If the user is persistent and knows he/she is in a datepicker, then they could try to switch to application mode using the shortcut key for that, but when they do that, the screen reader may turn off the table announcements, so whereas they gain the ability to send keyboard commands to the JavaScript handlers, they would lose the information about where they are in the table. In pure HTML 5, you are forced to implement this as a standard table with links on each day and allow the user to tab back and forth through the days. The keyboard-only users loses the ability to efficiently navigate to the next month, week etc. with the page or arrow keys. A pretty bad experience for all keyboard users.
  16. HTML 5 logo and a thumbs down image. Now I love HTML 5. But from an accessibility perspective, it still really sucks. Luckily ARIA, which stands for Accessible Rich Internet Applications has come to the rescue.
  17. This screen shot shows an ARIA menu with an expanded sub-menu with the accessibility inspector for OS X showing the accessibility tree and associated properties for the parent element of the expanded sub-menu. You can see that the role of the element is AXMenuItem You can see that the name (accessibilityTitle) of the element is “One” You can see that the value of the element is 0 (the value and the title on OS X are often interchanged and I am not sure of the reasons all the time), and You can see that the state of the element (accessibilityExpanded) is YES (expanded)
  18. Here is another example for the accessibility information for an ARIA slider Note the role of AXSlider Now note that the title is empty but there is an accessibilityLabel property with the setting of “Volume:” There is a series of state settings such as maximum, minimum and orientation And there is a value of 0 with a value description of 0%
  19. When you create a table of elements with the ARIA roles, you can immediately see where HTML 5 has been significantly enhanced by the WAI-ARIA roles. You will notice a significant increase in the number of interactive roles, a significantly larger number of roles allocated to document structure and some new roles related to forms http://dylanb.github.io/periodic-aria-roles.html
  20. What does the role do to the accessibility tree? If you remember back to the ARIA slider example I showed earlier, when you look under the hood at the HTML markup of this slider then you see something completely different from what you might expect…
  21. You will see in this case that the slider is implemented as a <button> element and the mapping to the accessibility API was changed by adding the role of slider to the element. We will come back to the other ARIA attributes later
  22. So the reason that this implementer chose to use a <button> element for the slider is in order to take advantage of the button element’s inherent tab focussability. It would have been equally acceptable to have chose an <a> element or even (in this case, because of the required implementation of the arrow key and mouse behavior) even a <div>
  23. Looking at the ARIA attributes, you see that additional semantics added by the roles, further enhanced and supported through some additional standardized state and value attributes that support interactivity. But also some attributes to help with naming, in particular, the ability to have different types of labels (a describedby and a labelledby) http://dylanb.github.io/periodic-aria-attributes.html
  24. Example of role-specifying attributes are aria-readonly and aria-required – when added to a form field, they further clarify what role those form fields play within the form
  25. So lets look at how this applies to our slider example. In this slider example you will notice the use of five additional attributes – namely aria-labelledby, aria-valuemin, aria-valuemax, aria-valuenow and aria-valuetext.
  26. Aria-labelledby is how the text for the accessibilityLabel is created
  27. Aria-valuemin is how the setting for the accessibilityValueMin is configured
  28. Aria-valuemax is how the accessibilityMaxValue is configured
  29. Aria-valuenow is how the accessibilityValue is configured
  30. And aria-valuetext is how the description for the current value is configured and assigned to the accessibilityValueDescription
  31. Image Alt “STAY CALM! Just one question… Do you happen to know how to fly this thing?” So the question you may ask is “Brilliant, does that mean the browser automatically added all the keyboard and mouse behavior for me?” No! You have to add that yourself. This is the strength and a weakness of ARIA. It means that you can communicate the state and role of complex widgets to the assistive technology with the help of the browser, but you still have to implement them yourself. It is also one of the main reasons you should never try to use a builtin role like “button” rather than using the browser’s built-in <button> element.
  32. This slide and the next show the amount of code you must implement to implement the ARIA authoring guidelines keyboard handlers for an ARIA menu
  33. The rest of the code from the previous slide
  34. So ARIA is perfection right? (image of a Ferrari)
  35. Actually, it is far from perfect, but it is practical. (Image of a shiny new Dodge minivan)
  36. I am now going to tell you about the ARIA attributes that work well, but remember, wherever you can, use the standard HTML elements where those exist already. Here are some examples, but these are but a few. The reason for this is that these built-in components all support all the assistive technologies well. If you simulate them with ARIA, you MUST supply all the behavior yourself and you will not be able to be used with older technology. ARIA is best used when doing things that were not possible with older assistive technology. For a funny parody of the perils of recreating your own native elements, read http://www.heydonworks.com/article/reinventing-the-hyperlink
  37. Some of the roles and attributes do work very reliably and give you functionality that is indispensible for achieving compelling accessible applications The landmark roles are very well supported and every page should use them The live region roles are a little problematic in that they do not simply work as specified everywhere, but by following some simple rules you can get them to work on all platforms. Us ethe a11yfy library if you don’t want to worry about the details yourself Most of the widget roles work across all browsers. In particular, I find the ones listed on the screen very useful The form roles all tend to work well but I would defer to the native HTML elements – the exception is if you need to style radio buttons and check boxes, then these roles come in useful and will allow you to support iOS where some of the hacks with off-screen native elements and presentational <div>s fall down The role=“presentation” is a special role. It can be used to tell the AT to ignore the native semantics of the HTML structure and treat everything as if it was a div or a span. nOt that I would suggest you do this, but if you have layout tables, then adding role=“presentation” to that layout table will make the screen reader treat it like a bunch of divs instead of a table.
  38. Unfortunately, even some very widely spread examples do not work on all platforms, the landscape is changing, so new releases of iOS could fix (or break) things. Apple does not publish its bug fixes or new features, so you just have to test.
  39. There are two practical and one architectural hole in ARIA. The biggest practical problem with accessibility in general today is table support. iOS and OS X have different and bad support for 3D tables. In addition, there are problems with tables from a responsive design perspective. My suggestion is to use the a11yfy library when you want/need tables as it has quite comprehensive support for all the things that are possible including responsive tables. The second practical problem is that currently when VoiceOver is turned on and a keyboard attached to an iOS device, it is not possible to get access to the arrow key events inside a JavaScript event handler. Add to this the difficulties that iOS has with table markup and you have a real recipe for difficulty. The architectural weakness is that ARIA is silent about gestures. In addition, screen readers treat them totally differently. On mobile devices, they all get intercepted and the gestures you use are totally different from when the screen reader is turned off. Some screen readers have ways to allow gestures through and some do not. Then there are undocumented behaviors when ARIA roles are applied to the focused elements. From a practical perspective, the application role is useful in getting gestures to work on iOS, but Android does not have support for gesture pass-through and you can only reliably get access to about 10 gestures on iOS when VO is turned on. A specification called IndieUI is being worked-on that will address some of these issues but for now, you have to use gestures to replace arrow keys on iOS but there is no good solution for Android
  40. You can clone the repository and follow along as I walk through the code. https://github.com/dylanb/gestura11y You can also try out the example at http://dylanb.github.io/datepicker/datepicker.html
  41. Now lets look at the UI. There is a basic calendar month layout with days of the week at the top and the date numbers aligned underneath those. The table is headed by the month and the year. There is a button at the top to go to the previous month and a button to go to the following month. By default, it opens up on the current month. There is a highlight on the currently focused day for keyboard only sighted users. There is also a focus indicator when the widget itself has focus. A keyboard user can use the arrow keys to move left right and up and down. If the user moves off the top or the bottom of the month, then the widget will advance or retreat by a month. Clicking the Previous and Following buttons will also retreat or advance by a month. The keyboard user can use Page up and Page down to also achieve this retreat and advance functionality. Home and End will move to the last and first day of the month respectively. The gestures of drag left, right, up and down do the same as the arrow keys. Swipe left goes to the beginning of the month. Swipe right goes to the end of the month. Swipe up goes to the previous month and swipe down goes to the next month. Tapping, clicking or pressing enter will select the date and the date picker will disappear, replaced by the selected date. When a screen reader is turned on, advancing the current day to any other date, will read out the entire date – for example January 10 2014
  42. Looking at the HTML markup that is generated by the code, you will see firstly an offscreen <div> that has the role of “log” and the attributes aria-live=“assertive” and aria-relevant=“additions”. If you look at this once you have been using the widget, you will also notice a bunch of <p> tags with dates inside them, only one of which is not display:none – the last one. This is aria-live being used to announce updates because the user’s focus is on the table as a whole, this is the technique that is being used to announce the currently “selected” date to the user with a visual disability.
  43. The second thing you will see is that the table has a tabindex=“0” attribute. This is to allow it to receive focus. It needs to receive focus because we need a way to tell the screen reader when to switch into application mode and ensuring that the table receives focus and then adding an application role to the table will do this. We can then attach or delegate event handlers on the table to deal with keyboard and gesture events. You will also notice that the <thead> and <tbody> elements have aria-hidden=“true”. This is so that a screen reader user does not have to traverse past the entire table structure. The entire table looks like a single widget to the screen reader user. The same as it does to a sighted user. The screen reader user only perceives what is announced to him/her via aria-live. The aria-live technique is a very common technique – especially to get around some of the difficulties that you would otherwise have getting the table markup to work well on all platforms. It can also be used to implement other dynamic content like tooltips, chat widgets, busy icons, progress etc. etc. The aria-hidden technique is useful to hide content from a screen reader when it is redundant or presentational. Another example would be walking directions where there are both turn-by-turn instructions and a map. A blind user may want the turn-by-turn but will not be interested in the map itself.
  44. Now lets turn to the code: If you go to hammer.js/index.js on line 1165, you will see a modification I made to allow gestures to be supported regardless of zoom level. The way that JavaScript gestures work, the velocity is calculated as the number of pixels that are swiped in a given time. However if the user has zoomed in (which will happen automatically if the user puts focus into a form field), then the number of pixels swiped for a given screen distance will be lower. Under thee circumstances – particularly if the user is blind and has not noticed the zoom, it becomes difficult to reliably generate the gestures. By calculating the zoom level with: zoomLevel = ev.target.ownerDocument.defaultView.innerWidth / ev.target.ownerDocument.documentElement.clientWidth; And then multiplying (which will actually reduce it) the threshold for a swipe gesture by this fraction, we get much more predictable gestures. Note that the standard Hammer.js library does not have this code.
  45. Which brings us to the 3rd rule of ARIA – always align focus, roles and event handlers.
  46. If you do not do this, you will see strange behavior like for example the counts of items being wrong
  47. This way you can guarantee that using a combination of tab key and arrow keys will work correctly
  48. But remember the second rule of ARIA – test yourself for support.