Introduction
About W3C / WAI
World Wide Web Consortium (W3C)
- Mission is to lead the Web to its full potential
- Consortium of industry members who use a consensus process to create interoperable
standards
- Royalty-free standards mean anyone can implement
Web Accessibility Initiative (WAI)
- Activities: Guidelines, technology review, education and outreach, research
and development
- Guidelines are widely referenced in corporate and national policies
- Authorized Translations facilitate worldwide adoption
WAI Guidelines
Rich Internet Application Accessibility
Designing for accessibility
- Accessibility is both a design and technology issue
- Some issues are principally design (e.g. color scheme, page layout)
- Some issues involve good use of the technology (e.g. proper encoding
of features like headings, regions, lists, etc.)
- A good design reduces need for technological accessibility features,
and makes it much easier to implement them when needed
- Universal Design: designing for all users makes a better experience even
for those without identified special needs
Demo comparison of accessible and inaccessible
site
The rich Web application challenge
- HTML 4 does not provide all the features developers want to use
- Developers create widgets using style and script
- More complex user interaction models
- Need to manage focus and selection
Basic steps to make application accessible
- Explicitly hide decorative elements of the application design from AT (SC 1.1.1)
- Define relationships amongst elements (SC 1.3.1)
- Define meaningful reading sequence (SC 1.3.2) and navigation sequence (SC 2.4.3)
- Provide ways to pause audio (SC 1.4.2) and movement (SC 2.2.2)
- Make application keyboard accessible (SC 2.1.1)
and don't trap keyboard (SC 2.1.2)
- Ensure focus is visible (SC 2.4.7)
- Don't change context unexpectedly when control receives focus (SC 3.2.1) or changes value (SC 3.2.2)
- Give user interface components programatically determined name, role, states, properties, value (SC 4.1.2)
Role of WAI-ARIA
Enhance semantics
- Many of the steps to make rich applications accessible are basic design
and implementation questions
- WAI-ARIA extends HTML to address the rich application challenge
- In particular WAI-ARIA allows to:
- Define more precise relationships
- Provide information about role, states, and properties
- Define accessible name
ARIA materials
- Background information
- Developer documents
- Authoring guidance
ARIA concepts
- Roles
role
attribute
- Value is name of role
- States and properties
aria-{propertyname}
attributes
- Value defined by each type
- Some global, some apply to specific roles
ARIA taxonomy
Example: ARIA button
|
HTML Button |
Styled "Button" |
ARIA Button |
Example |
|
Styled |
ARIA |
Code |
<button
onclick="updateButton
('HTML Button')>
HTML
</button> |
<span class="mybutton"
onclick="updateButton
('HTML "Button"')">
Styled
</span> |
<span class="mybutton"
onclick="updateButton
('HTML "Button"')"
role="button">
ARIA
</span> |
Screen reader |
"Button HTML" |
"Styled" |
"Button ARIA" |
Notes about these examples:
- Generally, shouldn't use a
span
to do buttons since button
s can be styled
- Author must provide all style and functionality
- Not shown is the code to make it focusable and responsive to keyboard as well as mouse
Example: Toggle button
Example | Code |
|
<button onclick="exToggleCheckboxes()"
role="button"
aria-pressed="false">
Check all
</button>
function exToggleCheckboxes() {
var curState = button.getAttribute("aria-pressed");
//for each checkbox
if (curState == "false" || curState == "mixed")
element.checked = true;
else element.checked = false;
} |
Notes about this example:
- ARIA extends the
button
element, making it a toggle button
- Using the native button rather than a styled
span
, but must override default behaviour by returning false from action
- State of button (pressed, not pressed, or mixed) exposed to assistive technology
- Visual display is keyed off changes in the
aria-pressed
state, ensuring everything kept in sync
- Needed
role="button"
, even though this is already a button, to activate processing of the ARIA states
Roles
- Abstract roles—part of taxonony, not to be used
- Widgets, e.g., checkbox, menu, progressbar, tabpanel, treegrid…
- Document structure, e.g., heading, img, list, math, presentation…
- Landmark roles, e.g., main, navigation, search…
Complex widgets
- Many more widget types supported
- Some have more complex interaction models than standard HTML controls
- A variety of states and properties support these widgets in different ways
Drag and drop
aria-grabbed
—whether object is selected for drag and drop, or is unselectable
aria-dropeffect
—possible effects (e.g., move, copy, etc.) when an object dropped in
aria-dropeffect
usually only set after something has been grabbed
Relationships
aria-labelledby
and aria-describedby
—reference to alternative content elsewhere on the page
aria-activedescendant
—indicates the subcomponent that has the focus
aria-owns
and aria-controls
—non-descendant elements that are part of or controlled by the object
aria-posinset
—position of an element in a set (when part of the set is elided)
Live regions
0
<div aria-live="polite" aria-relevant="text">0</div>
Live regions have content that updates without user intervention, e.g., stock tickers, chat programs
aria-live
- element has auto-updating content
- "politeness" indicates how important to interrupt other tasks
aria-relevant
—what kind of update occurred
aria-atomic
—change to any part of element triggers update of entire element
WAI-ARIA is a Candidate Recommendation
Applying WAI-ARIA
Growth of WAI-ARIA
- WAI-ARIA is being formally integrated into HTML 5
- WAI-ARIA may need expansion to meet all HTML needs
- Expansion of taxonomy will make WAI-ARIA useful in other host languages
- SVG may use WAI-ARIA as a primary accessibility model
- Considering other host languages for future versions
Support for WAI-ARIA
- The mainstream desktop browsers provide substantial support
- Many assistive technologies support via platform Accessibility API
- WAI-ARIA is being incorporated into HTML 5
- Although WAI-ARIA is not a formal part of HTML 4 (validators will complain),
it is recognized by user agents
Policy implementation of WAI-ARIA
- WAI-ARIA is a technology—in general, policies shouldn't require specific
technologies
- Policies should reference WCAG 2.0
- WAI-ARIA is a "technique" to conform to WCAG 2.0
- WCAG allows any "sufficient" technique
- Different techniques may exist, choose one most appropriate to
situation
- Specific to technology; WAI-ARIA is one (recommended) technology
to use
Beyond WAI-ARIA
WAI-ARIA doesn't address all aspects of rich internet applications, in
particular, developer also needs to:
- Make elements focusable
tabindex
attribute extended to all elements, not just links and form controls
tabindex={positive integer}
defines tab position of element
tabindex=0
puts element in focus order, in default order
tabindex=-1
makes element script-focusable, but not in focus order
- Provide focus highlighting
- Normally user agent highlights focus on links and form controls
- If you have made other elements focusable, you need to show focus yourself
:focus
pseudo-class often covers this
- Sometimes necessary to use script
New Work on Enhancing Accessibility
Mapping language features to accessibility APIs
- Accessibility APIs allow Assistive Technologies to interact with elements
in a common way
- WAI-ARIA allows authors to provide features that will map to accessibility
APIs, when host language support doesn't exist
- For the first time a formal mapping of HTML
5 elements to Accessibility API features is being prepared
- Allows the various user agents to provide a common approach
- The mapping of HTML elements works alongside the mapping of WAI-ARIA
features to provide a complete model
Recognizing user intent
- Proliferation of devices that interact with Web content
- Desktop and laptop computers
- Smartphones
- Tablets
- New modes of input drive these devices, particularly touch
- Touch gestures vary amongst devices, and aren't accessible to all
- Web content can't respond properly to all the potential gestures used
to accomplish a particular action
- Need a way to respond to user intent, e.g., drag, scroll, zoom, next
page, etc.
- Assistive technologies can send such events more effectively than mimicing
device-specific touch events