Web 2.0 Accessibility

closebunkieΤεχνίτη Νοημοσύνη και Ρομποτική

15 Νοε 2013 (πριν από 3 χρόνια και 10 μήνες)

205 εμφανίσεις

Web 2.0 Accessibility


Better Usability for All Through


WCAG 2.0 and WAI
-
ARIA

Presented by Ann Abbott

IBM Collaboration Solutions Accessibility Lead

IBM Accessibility Architecture Review Board Focal Point

April 11, 2012


© 2012 IBM Corporation

2

Agenda


Web 2.0 Accessibility: The Problems


The Solution: WAI
-
ARIA


WAI
-
ARIA: How to implement


WAI
-
ARIA Roles, States and Properties


Roles: Landmarks


Roles: Custom widgets


Roles: Document structure


Roles: Presentation


States and Properties: Live Regions


States and Properties: aria
-
required and aria
-
invalid


Summary


Resources

3

Web 2.0 Accessibility: The Problems

4

1997 Accessibility Divergence caused Problems for
Web Access


Web (WCAG 1.0)


Rudimentary access


Keyboard access


not usability


Don’t change HTML


Anything not understood: prohibit


No planning for future developer innovation



Rich Desktop platform accessibility


Real issue is interoperability with assistive technology


Development of richer platform accessibility APIs


Leverage usability of desktop applications to manage information


Keyboard accessible and usable



Inability to address Web interoperability caused web accessibility criteria
to hurt accessibility by forcing less usable solutions

5

Problem Analysis shows opportunity for richer
accessibility


HTML Accessibility depends on tag names


mixing content and presentation



JavaScript creates custom widgets using HTML, user input, and CSS
changing their meaning and purpose within a Web application



HTML lacks the accessibility meta data to support accessibility APIs for
repurposed HTML content



Keyboard usability for People with Disabilities (PwDs) is poor


Almost totally dependent on tabbing


Non
-
anchor/non
-
form elements can’t receive focus

(World Wide Web Consortium (W3C) HTML browser implementation oversight)


User needs keyboard navigation and widget behavior like a GUI


User needs consistent navigation landmark semantics to reduce usability
problem

6

Web 2.0 Challenges for ATs, Developers, and Users


ATs need to have region navigation capability


Main content, secondary


Live region


Use of relationships to navigate content (aria:flowto, aria:controls)



ATs and Authors must communicate Document vs Application
sections


role= “application” turns browse mode off and puts into the AT into
“forms mode”


role=“document” tells the AT to convert to static HTML navigation



ATs will need to provide better context information



User will need to know that document and application navigation
switches are occurring



Users/ATs will need to handle Ajax live regions



Authors will need to manage keyboard focus within widgets

7

Web 2.0 Accessibility


The Problem is HTML


JavaScript and CSS are used to create desktop
-
like controls in browser



JavaScript and CSS incorrectly blamed for Web 2.0 accessibility problem



HTML is the problem


Not fully keyboard accessible


No way for web page authors to provide semantics to browser to support
accessibility API

8

The Solution: WAI
-
ARIA

9

The REAL solution


Solution


Add Desktop accessibility capabilities to HTML to assist authors



To Make it Real


Work with existing browsers, markup


Use Open Source Software


Industry
-
wide collaboration and adoption



The REAL solution is WAI
-
ARIA

10

What is WAI
-
ARIA?
[wey ah
´
∙ree∙uh]


WAI
-
ARIA

W
eb
A
ccessibility
I
nitiative
-

A
ccessible
R
ich
I
nternet
A
pplications



A World Wide Web Consortium (W3C) emerging standard



WAI
-
ARIA delivers the “Robust” requirement in WCAG 2.0

11

IAccessible2 API defines a standard contract between
an application component and an assistive technology

Assistive

Technology

Role

States

Actions

Caret

Selection

Text

Hypertext

Value

Name

Description

Children

Changes

Relations

A

C

C

E

S

S

I

B

L

E

UI

Component

Data

UI

12

Tree Widget Usability Comparison

role = “treeitem”

aria
-
expanded=“false”

aria
-
level=“2”

aria
-
checked=“false”

aria
-
posinset=“1”

aria
-
setsize=“4”

Name=“PJ111”

img alt=“folder”

----------

Keyboard like desktop

Tree widget

“Closed Folder PJ111”

“Closed Folder one of four

Depth 2”

“unchecked”

Anchor tells is a link

Name=PJ11

img alt=“folder”

----------

document “tabbing”

“link folder PJ111”

WCAG 1.0/ current 508 Style Accessibility

WCAG 2.0/potential 508 refresh Style
Accessibility with ARIA

13

CSS and Compliance Issues


US Section 508 of the Rehabilitation Act requires Web pages work with
CSS turned off



Web 2.0 relies heavily on CSS, especially positioning, making it difficult
to run with CSS turned off



US Access Board Acknowledges:


Disabling CSS breaks usability of today’s web applications


PwD’s can no longer apply custom style sheets to consistently ensure a
more usable solution


Use of CSS for personalization is best handled by content generators

14

CSS and Compliance Solution


US Access Board allows “Equivalent Facilitation”



Provide low vision support with CSS enabled


Support system colors / high contrast mode


Respond to font resizing
-

no fixed font sizes

15

WAI
-
ARIA: Most important accessibility advance in a
decade



Brings Accessibility/Usability of Desktop to the Web



Allows for full interoperability with assistive technology



Key technology needed to support WCAG 2.0



Benefits ALL users

16

Why implement ARIA?


A vehicle to provide full interoperability with assistive technologies for Rich
Internet Applications through the browser



A way for authors to apply rich accessibility semantics in Web 2.0 content to
support OS platform accessibility



A way to reproduce the keyboard functionality of desktop applications on a
web page



A vehicle to correct static (X)HTML accessibility deficiencies

17

Best WAI
-
ARIA Support


Firefox 3.6.x and higher







JAWS 12 and higher

18

WAI
-
ARIA: How to implement

19

WAI
-
ARIA Roles, States and Properties


Roles


Landmarks: (main, search, navigation, complementary, banner, contentinfo,
form, application, document and region)


Custom widgets: (tree, grid, button, checkbox, menu, dialog, etc.)


Structural: (directory, list, header, etc.)



Typical widget states


aria
-
checked, aria
-
selected, aria
-
disabled, aria
-
currentvalue, aria
-
expanded



Properties


AJAX Live Region properties


aria
-
live (off, polite, assertive)


aria
-
relevant (additions, deletions, text, all)


aria
-
atomic (Assistive technologies will present the entire region as a whole)

20

WAI
-
ARIA Roles, States and Properties
(continued)


Relationships


aria
-
controls, aria
-
owns, aria
-
flowto, aria
-
label, aria
-
labelledby, aria
-
describeby



Drag/Drop


aria
-
grabbed, aria
-
dropeffect



Miscellaneous


aria
-
sort (ascending, descending)


aria
-
setsize, aria
-
posinset, aria
-
level



Tabindex


<div tabindex=“
-
1” role = “menuitem” aria
-
disabled=“true”>

21

Roles: Landmarks


Landmarks should be determined during Design Phase



IBM requires all page content be included in an appropriate ARIA landmark.
NO ORPHANS.



If the same landmark is used multiple times on a page, each instance must
have a unique label



If a collection of items and objects that, as a whole, combine to create a
region not defined by any named landmark (list follows on next slides) is
present, a
region

landmark with a distinct label is required

22

Roles: Landmarks

(continued)


A
main

landmark is always required (no more than one main landmark per
document or application)



If a collection of navigation links is present, a
navigation

landmark is
required



If a search field is present, a
search

landmark is required



If a region that contains mostly site
-
oriented content rather than page
-
specific content is present, a
banner

landmark is required



If a supporting section of the document remains meaningful when separated
from the main content is present, a
complementary

landmark is required

23

Roles: Landmarks

(continued)


If a large perceivable region that contains information about the parent
document is present, a
contentinfo

landmark is required



If a collection of items and objects that, as a whole, combine to create a
form is present, a
form

landmark is required



If a rich Internet widget is present, an
application

landmark is required (if
role=“application” is applied to the main content element, it is not to be
considered a navigational landmark)



If a region containing related information that is declared as document
content, as opposed to a web application, is present, a
document

landmark
is required (document structures are not usually interactive)

24

WAI
-
ARIA landmarks in IBM Connections

25

Verifying landmarks


Use Firebug to show landmarks



Use JAWS key combo Ctrl+Ins+; to launch a dialog with a list of landmarks



Use JAWS quick key (;) to move from landmark to landmark

26

role=“application”, role=“document” and AT browsing mode


Assistive technologies (ATs) such as screen readers normally have at least
two different reading modes



Using <body role=”document”> (default)


Document browsing mode is activated when the content that the user is reading
is primarily non
-
interactive. When in document reading mode, keystrokes are
intercepted by the AT. This is the default mode of a page and is also triggered by
role=“document”.



Using <body role=”application”>


Application mode is a mode where the screen reader passes keystrokes back to
the application and relies on the application author to provide the relevant
navigation handling. This mode is sometimes referred to as “application” or
“forms” mode. Triggered by role=“application”.


It is the responsibility of the application author to implement ALL the keyboard
navigation and manage focus for the entire page


Sections of the page could be marked as role=”document” e.g. an email preview panel.


27

Roles: Custom widgets

A custom widget is a non
-
form or non
-
anchor element with an event
handler (repurposes native HTML).


For these widgets and structures, the
WAI
-
ARIA Authoring Practices

describes the
keyboard interaction and identifies the relevant WAI
-
ARIA roles, states, and properties.


accordion



alert


autocomplete


button



checkbox



combobox


datepicker


dialog_modal


dialog_nonmodal


dialog_tooltip


Draganddrop


grid


landmarks


link


listbox_div


mediaplayer


menu


menubutton


popupmenu


popuphelp


radiobutton


richtext


slider


slidertwothumb


spinbutton


tabpanel


toolbar


tooltip


treegrid


TreeView


windowsplitter


wizard

28

Roles: Custom widgets

(continued)

From WAI
-
ARIA Authoring Practices:



Pick the widget type (role) from the
WAI
-
ARIA Taxonomy



From the role, get the list of supported states and properties



Establish the widget structure in the markup (parent/child)



Repeat steps 1
-
3 for the children of the parent

29

Roles: Custom widgets

(continued)


Establish keyboard navigation of the widget and plan for how it will be
navigated to within the document


Reference and implement the keyboard navigation per
WAI
-
ARIA Authoring
Practices


Follow desktop keyboard navigation if unavailable


Ensure there is a keyboard equivalent for all mouse operations



Apply and manage needed WAI
-
ARIA states in response to user input
events



Establish ARIA relationships between this widget and others


aria
-
labelledby


aria
-
controls


aria
-
describedby


aria
-
flowto


aria
-
owns


aria
-
posinset


aria
-
setsize

30

Roles: Custom widgets

(continued)


Support basic accessibility, such as alternative text on images



Implement ARIA
-
defined keyboard navigation


First tab keystroke enters custom widget


Subsequent keyboard navigation based on arrow keys


Next tab keystroke exits custom widget and focus falls on next focusable
component.



Review widget to ensure that you have not hard coded sizes


use constants or ems


Widgets
-

be careful of hard coding sizes (based on em height)



Test using Firefox with
JAWS

(screen reader)


If possible, test with a screen magnifier AT and people with disabilities

31

Example of custom widget that must be ARIA enabled


OK and Cancel are links but
perform the function of

buttons
-

ARIA
enable as role=“button”













Testers
must
ensure that JAWS announces them as a "button" and not
"link"

32

Custom widgets: Who is responsible for keyboard
navigation and focus control?


The AUTHOR is responsible for keyboard navigation and focus control



The WAI
-
ARIA Authoring Practices provides consistent best practices for
authors to implement to support keyboard navigation



ATs, like screen readers, provide general browsing keyboard navigation to
be able to do things that the sighted user can do with their eyes. such as
"read me the previous line" or “read me the line phonically”, etc. These
functions are specific to ATs

33

Keyboard navigation (managing focus) basics


Tabindex=“
-
1”

Can set focus on an element without adding to tab order
-

Ideal for Widgets



Tabindex=“0”

Place focusable elements in the tab order in document order



Tabindex=“> 0”

Same as today’s tabindex
-

This usage is discouraged as it requires complete Tab
assignments applied to the page



Tabindex changes supported in IE, Opera 9, and FF 1.5 or higher, Safari 4


Supported by all renderable elements



ARIA aria
-
activedescendant=“child id” tells the AT what child is currently
active for the focused widget


Example: a “grid” (spreadsheet) would indicate which “gridcell” has focus


Use when don’t want to manage tabindex for lots of children (spreadsheets,
listbox, menus)

34

Author
-
managed arrow key navigation within widgets


Capture key strokes at the widget managing focus



Move focus to the child using tabindex


Set the tabindex=“
-
1” on the child element to allow it to be focusable


Childelement.focus();


Draw visible focus to the child with focus using styling


Browser will fire a focus change event to the AT



Managing parent indicates which child has focus using active descendant


Set aria
-
activedescendant=“active childID” on the parent (like listbox or menu)


Draw visible focus to the child with focus using styling


Browser fires focus event on behalf of the child

35

Roles: Document structure


Provide a way to navigate complex documents by marking up sections of
the document with their semantic meaning



Document structure roles are not normally interactive



Correctly structuring content in a document or web page is both a usability
concern as well as a WCAG 2.0 requirement

36

Roles: Document structure

(continued)


Common document structure roles (see ARIA spec for full list)


Article


consists of a composition that forms a whole, ideal for discussion
threads


Document


a document vs. application


Group


A container for grouping elements not part of document content, e.g.
toolbar


Heading


A section that is a heading, can provide a level using aria
-
level


List, listitem


A group of items that form a logical list


Presentation


A UI element that is in the DOM only for presentation and should
not expose any accessibility semantics. More on this later.


Region


A generic region on the page, should have a label


Separator
-

A divider that distinguishes sections of content


Toolbar


container for commonly used function buttons

37

Roles: Presentation


The presentation role is used quite commonly throughout many ARIA
enabled applications and deserves some special attention



Some HTML elements like the list (ul, ol, li) or table have implicit
accessibility semantics



The presentation role can be used to remove native semantic meaning from
HTML elements


In the following example, the heading would not be identified as a heading by the
screen reader

<h1 role=”presentation”>Heading 1</h1>



It would be read as if it were

<span>Heading 1</span>



Especially useful for layout tables (tables without tabular data)

38

States and Properties: Live Regions


Live regions are regions that can be dynamically updated on a web
page and that announce their updates to the user through the AT



When a section of content is marked up as a live region, the browser
will inform the AT about any updates to that region, the AT will in
turn announce that to the user



The aria
-
live attribute can take three values:


aria
-
live=”off”
-

self explanatory


aria
-
live=”polite”
-

announcements will not interrupt current announcements


aria
-
live=”assertive”
-

announcements will be immediate

39

States and Properties: Live Regions

(continued)


Updates to the DOM must be made with careful consideration as the DOM
changes may trigger announcements overriding each other or not being
triggered at all



The specification and AT's do not queue announcements, so if one begins
announcing another one can interrupt it



There are a number of specialized live regions in WAI
-
ARIA:


alert: an assertive update announced when the region is updated


status: periodic updates


timer


marquee


log


40

States and Properties: aria
-
invalid and aria
-
required


Until the introduction of WAI
-
ARIA's aria
-
invalid
state

and aria
-
required
property
, only presentational strategies have been available to Web
content authors to indicate that certain form fields and controls are required
or invalid



The WAI
-
ARIA invalid state and required property provide:


A programmatic aria
-
invalid
state

that can be used to indicate which data fields
have incorrect data to an AT so that the user knows they have entered invalid
data. Invalid data is often rendered in red by HTML form developers


A programmatic aria
-
required
property

that can be applied to a form element to
indicate to an AT that it is required to complete the form

41

States and Properties: aria
-
invalid and aria
-
required
(continued)

aria
-
invalid (state)



When the user attempts to submit data involving a field for which aria
-
required is true, use the aria
-
invalid attribute to signal there is an error



If the attribute is not present, or its value is false, or its value is an empty
string, the default value of false applies

42

States and Properties: aria
-
invalid and aria
-
required
(continued)

aria
-
required (property)



Can be used with the following roles:


Combobox


Gridcell


Listbox


Radiogroup


Spinbutton


Textbox


Tree



If the user needs to fill in an field to submit the form, set the field's aria
-
required attribute to true



Set the field’s aria
-
required attribute to false if user input is not necessary to
submit the form

43

Summary


WCAG 2.0 is the basis for all future government accessibility legislation
for the Web for which WAI
-
ARIA is a critical component to meet



WCAG 2.0 removes JavaScript and CSS restrictions



WAI
-
ARIA, an IBM innovation, is now a W3C emerging standard, which
addresses Web Accessibility



WAI
-
ARIA will be part of the W3C HTML5 Standard.



WAI
-
ARIA delivers the “Robust” requirement in WCAG 2.0 to provide
usable desktop accessibility to the Web



Industry uptake is significant (Yahoo, AOL, MS, SAP, Mozilla, SAS,
Google, IBM, Microsoft, Adobe, Opera, Oracle)



First reusable toolkit to implement ARIA: Dojo Toolkit/Dijit directory

44

Resources

***

Critical references for developers



WAI
-
ARIA Overview



WAI
-
ARIA Primer



WAI
-
ARIA Specification



***

WAI
-
ARIA Authoring Practices



***

WAI
-
ARIA Supported States and Properties



WAI
-
ARIA User Agent Implementation Guide



***

WAI
-
ARIA Code examples on Open Ajax Accessibility site



HTML 4.01 plus WAI
-
ARIA DTD


45

Resources
(continued)

Experience a full WAI
-
ARIA implementation in REAL LIFE!



IBM Connections 3.0.1, a social business Web 2.0 application, acclaimed
as the best WAI
-
ARIA implementation in an IBM product and most
extensive WAI
-
ARIA enabled enterprise application, is now available on
Lotus Greenhouse!



Sign up for an
FREE

account on
Lotus Greenhouse



Once you have an account, log in to
IBM Connections



WAI
-
ARIA implementation is easy to see using Firebug

46

Questions and Answers