lit 20170306
Post on 19-Mar-2017
67 Views
Preview:
TRANSCRIPT
Accessible Web Scott WilliamsOffice for Institutional Equityswims@umich.edu@swimsyumich.edu/webaccess/
Goals
Learn the 4 principles of accessible interface design
Learn how to create accessible web content Learn how to evaluate a web interface for
accessibility
What is web accessibility?
Making the web accessible for the widest possible audience
This audience includes temporarily “able-bodied” users
Currently, online infrastructure is hostile to those with disabilities
Inseparable from usability, mobile, SEO: improve one and you improve the others
Best way to accomplish accessibility? Adherence to standards.
W3C WCAG 2.0 De facto standard world-wide. Cited in U.S case law.
Adopted by EU. ISO standard 40500:2012. W3C Web Content Accessibility Guidelines are
principle-, not technology-based The four principles (POUR):
Perceivable Operable Understandable Robust
Contain Guidelines (normative) and Success Criteria (advisory) for each principle
Perceivable
Provide text alternatives for images and form elements
Provide captions and transcripts for video and audio
Use correct semantic markup so content can be presented in different ways
Make it easier for users to see content by using good color contrast
Avoid noise, movement, and distractions on page
Operable
All functionality is available from the keyboard!
Users have control over timing and limits Do not cause seizures (don’t flash content) Provide ways to help users navigate, find
content, and determine where they are
Understandable
Economical and plain use of language Text supplemented with illustrations, videos,
and other formats where appropriate (i.e., use good Universal Design)
Navigation, information structure are discernable and consistent
Make pages operate in predictable ways Help users avoid and correct mistakes
Robust
Functional across various technologies Syntax errors that don’t affect visual
presentation may hamper assistive technology and accessibility evaluation tools
Adhering to W3C standards ensures future compatibility
Validate your code at validator.w3c.org
Questions?
Best Practices
1. Navigation
Navigation
Navigation is a critical aspect of accessibility Information being apparent isn’t enough Sighted users have tried and true visual cues to
orient them on a page Banner Search box Main navigation box Content well
Blind and low-vision users rely on proper coding of page for orientation
What if you can’t see?
Title of page lets you know what page you’re on when page loads
Proper heading placement and hierarchy conveys organization of page and allows SR users to skip navigation and blocks of unwanted information
Link descriptions convey content of page and organization of site
ARIA document landmark roles highlight geographic regions of webpage
Browser “find” function used as last resort
Skip-to-content links
Not favored by screen reader users (!) Allows visual users who cannot use a mouse
to avoid tabbing through entire menu and sidebar
Place at top of document Jump to <h1> tag Must be visible on keyboard focus so
sighted keyboard users will know it’s there
Proper <h1> heading
Screen readers can find and list headings <h1> heading should uniquely identify the
page in the website The <h1> heading should also match at least
a subset of the the page <title> Should be placed directly in front of the main
content of the page, not in banner or footer
Proper heading hierarchy
Headings need to be properly nested to convey organization of the page
<h2> tags follow the <h1> tag, the <h3> tags follow the <h2> tags, etc.
Off-page headings
Useful when you want to give SR users a navigational aid without cluttering presentation for sighted users
Examples: Main and local navigation, search, etc.
Use CSS to position headings off-page
.offpage {position: absolute; left: -1000px;} Don’t use {display:none} or {visibility: hidden}
Meaningful link text
Screen readers can find and list links Descriptions for the links must be meaningful
out of context, via tabbing or presented in a list
Don’t use “here”, “click here”, “read this”, and “more”
Don’t use URL as a link description—will sound like gibberish, unless very short and intuitive
Accessible menus
Main navigation needs to be operable using the keyboard only
Subcategories should not be displayed when main item has focus (and exposed for hover)
Main menu items link to index pages that list subcategories
Complex menus with multiple columns and headings have negative effects on those with cognitive impairments, low vision, and motor impairments
Document landmark roles They do what good visual layout does for sighted
users Call out main geographic areas of web page:
Banner Navigation Search Main content Auxiliary content Posted content Footer information
<div id="maincontent" role="main"></div>
2. Text equivalents
All informative non-text elements must be accompanied by text equivalents Informative images graphical representations of text (including drop
caps, equations, and symbols) form controls and text fields graphical buttons and links audio files and podcasts Videos
<img src="mlogo.gif" alt="University of Michigan Block M logo">
<img src=“wall_sm.jpg” alt=“young man on a climbing wall reaching for a hold, which symbolizes a navigation element available to assistive technology” />
Example alt text
More guidelines
Images that are links must have alt text that describes the target
Keep text to “tweet length”, 140 characters or less
If the image needs further explanation, describe it in the inline text or a link to a separate page
3. Forms
Use <label> tag to describe form fields and controls to screen reader users (is a type of alternative text)
Use <fieldset> and <legend> tags when necessary to group form elements together (not for layout only)
Keep form labels close to their associated controls
Make sure the form is operable using just the keyboard
Form example
Label attribute matches input id — not name Can insert “off-page” label if it would hinder
sighted users
Keyboard accessibility
Make sure that forms can be operated using the keyboard only
Make sure reading order and tab order are logical and intuitive
Source order = tab order Use source order, not tabindex attribute, to
program tab order
Form example 2
4. Tables
Provide a table summary—what are you trying to prove, anyway?
Use table headings Use the scope attribute to define row and
column headings
Table summary
The summary conveys the context or conclusion of the table data (what is the table demonstrating?) to assistive tech users
This is accomplished by adding a summary attribute to the table tag:
<table summary="Tensile strength of structural materials showing the superiority of multiwalled carbon nanotubes” >
Table headings and scope attributes
Use the <th> tag to designate the table headings
The scope attribute is used to further define the row and column headings for your data table
These attributes can be read along with the individual data cell by a screen reader
Keep it simple
Table readability on the web is difficult for everyone
Avoid rowspans, colspans, horizontal and vertical scrolling, and nesting tables
5. Scripting
Using javascript does not make your site inaccessible
Most screen readers can interact with javascript as long as: Widgets can be operated using the keyboard only Content is announced Focus is managed properly Context is conveyed
Native html elements have built-in a11y—which you must supply if you code a JS alternative!
Mouse-dependent Event Handlers
onClick onMouseOver and onMouseOut OnMouseDown onChange used with onSelect onHover
onClick
If you use onClick with an anchor tag or form control, most browsers and assistive technologies will be able to to trigger the event with the Enter/Return key
Scripted elements must contain an Enter/Return event handler. Keyboard testing will expose this common error.
Scripted elements must be inserted in tab order with “tabindex=0” so they can receive tab focus
onMouseOver and onMouseOut
onMouseOver should be accompanied by onFocus
onMouseOut should be accompanied by onblur
OnMouseDown
If the onMouseDown, onMouseUp and onMouseMove event handlers are used, equivalent functionality also needs to be implemented through the keyboard as well
Provide an alternate means of interacting with the web page
onChange used with onSelect
The combination of the onChange and onSelect event handlers can cause problems for keyboard-only users
Although they are device-independent, they need to be tested with the keyboard to ensure that they are accessible
onHover
It is inaccessible to everything but a mouse This fact can be taken advantage of , e.g.,
triggering submenus for mouse users but not screen reader and keyboard-only users
AJAX and ARIA Spec ARIA = Accessible Rich Internet Applications The use of AJAX introduces new challenges in
accessibility Updating information on a page without a page
refresh can disorient assistive tech users or leave them unable to view the updated content
ARIA roles, states, and properties are a means of making AJAX widgets accessible and info apparent
The scope of ARIA role and property code is limited to assistive technologies
ARIA resources
W3C’s WAI-ARIA Overview(http://www.w3.org/WAI/intro/aria)
WAI-ARIA Authoring Practices 1.1https://www.w3.org/TR/wai-aria-practices-1.1/
Hans Hillen’s examples(http://hanshillen.github.io/jqtest/#goto_slider)
Open Ajax Alliance examples (http://oaa-accessibility.org/examples/)
6. Color
An often overlooked aspect of web accessibility Many more people are visually impaired or
color blind than are legally blind There are tools that quantify the contrast
between text and its background Check your web templates’ color contrast
during design phase
What is color contrast?
You intuitively know when something has poor contrast
There is an algorithm for determining a numerical value
Ratio of foreground luminance to background luminance
Big is good: 4.5:1 or greater for WCAG 2.0 Level AA
Don’t use color alone to convey meaning
Test in gray scale …
7. Captioning
Good for those who are: Hearing impaired Do not have access to audio In a quiet and/or public setting Not fluent in the native language of the audio or video Cognitively disabled
Subtitles increase the amount of time that a user spends watching a video by almost 40 percent
Where subtitles appear, 80 percent more people watch the entire video to its completion
8. Accessible word & pdf
As in the web environment, navigation and orientation are key tasks a screen reader user must perform
Word and pdf docs need a11y hooks too
Create structured MS Word docs
Use heading styles for headings Use the table-of-contents utility Provide alternative text for images Use the table utility to create tables Use styles for formatting text We want to ensure that assistive tech
metadata is transferred to PDF
Publishing PDF
WebAIM Acrobat resource page:http://webaim.org/techniques/acrobat/
Office Accessibility Center:https://goo.gl/Qnbi6l
9. Web standards
Many webmasters avoid validating their HTML and CSS code because they view it as limiting and a time sink
However, adhering to standards helps to ensure that everyone has access to the information on web pages
Assistive technologies depend on syntactically correct HTML
Validate your code: http://validator.w3.org/
W3C Validator
Questions?
Website Evaluation
The design phase
Page designs must have sufficient color contrast
The default text size should be large enough for older people and folks with visual impairments to read
The navigation should be simple and the visual layout clean
Features that involve motion should be opt-in
Building the templates Validate your code. Use CSS for layout. Set up your skip navigation links. Implement document landmark roles. Define a unique <title> for each page. Place the <h1> heading directly before the main content,
and make sure it matches at least part of the <title>. Specify a DOCTYPE and language definition for each page.
Populating the website
Use a proper heading hierarchy to organize your page.
Use correct markup for your data tables. Make sure your form controls and data entry
fields are labeled. Give your images meaningful alt text. Caption and make transcripts for your video,
and make transcripts for your audio.
Launch and maintenance
Include a contact for web accessibility complaints.
You should also post an accessibility statement page that includes contact information. Put it after your “skip nav” link.
Evaluation tools
Keyboard — using your tab, arrow, and enter keys
WAVE — Chrome browser extension aXe—Chrome browser extension Mac VoiceOver Universal Access — Mac native
screen reader
The keyboard
Keyboard accessibility is one of the cornerstones of web accessibility.
Screen reader users and those with motor impairments cannot use a mouse.
You should be able to easily navigate to any part of your web pages or website and perform all functionality using just the keyboard.
Testing keyboard accessibility
Unplug your mouse Employ the tab, arrow, return, and spacebar
keys Tab through the entire page. Note sequence.
Can you see keyboard focus? Operate menus Submit forms
Demo: testing with the keyboard
Exercise: keyboard testing
WAVE Accessibility Toolbar
WAVE uses a distinctive icon approach in displaying accessibility information.
Displays: missing alternative text for images missing form labels table structure script elements and event handlers document structure and reading order and many more …
Icon key explains icons
WAVE screen shot
Demo WAVE toolbar
Exercise: Testing with WAVE
U-M resources
http://umich.edu/webaccess/ Evaluation tools and procedures:
http://umich.edu/webaccess/eval/ swims@umich.edu
Accessibility Resources
U-M: http://umich.edu/webaccess/ WebAIM: http://webaim.org Online accessibility checkers:
http://tenon.io/ http://wave.webaim.org/
Plug-ins: aXe: https://goo.gl/CpgsZd WAVE: https://goo.gl/LptVVT
top related