Upload
nina-mchale
View
1.420
Download
0
Embed Size (px)
DESCRIPTION
Preconference session from the 2009 LITA National Forum, Salt Lake City. Accompanying case studies also available on Slideshare.
Citation preview
Accessibility Update: Section 508 and WCAG in a Library 2.0 World
Nina McHaleAssistant Professor, Web Librarian
University of Colorado DenverLITA National Forum
October 1-2, 2009
Our Goals: You Will…
• …achieve an understanding of the history and purpose of accessibility standards
• …know how to validate code for web standards and accessibility standards
• …become familiar with screen reader software and how it works
• …be able to evaluate for accessibility many types of web resources commonly used by libraries
Today’s Agenda
• Accessibility and usability defined• Introduction to web standards
– Section 508– WCAG 2.0
• Code validation– (X)HTML, CSS– Validating for accessibility
Tomorrow’s Agenda
• Screen readers in action– Video: How I Use a Screenreader– JAWS, Window Eyes, and VoiceOver– Demo
• Case Studies– Library web pages– Library catalogs and CMSs– Vendor databases– Web 2.0 tools
Getting to Know You…
• Who are you?– Name, job title, organization– Your experience to date with web
design/development/content management and accessibility
• Why are you here?• What to you hope to gain from this
session?
Accessibility
“the ‘ability to access’ the functionality, and possible benefit, of some system or entity.”
-Wikipedia, “Accessibility”
Usability
“…the extent to which a product (e.g., device, service, environment) can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”
-Wikipedia, “Accessibility”
Accessibility Fail
Usability Fail
Why is Accessibility an Issue?
• Because the increasingly graphic nature of the Web has made using it more difficult for people with visual disabilities to use
• Because Web browsers are too forgiving of bad code– (X)HTML doesn’t have to be perfect to display
correctly to a sighted person
• Because library Web pages tend to be home-grown
Accessibility: Why Does It Matter?
• The American Foundation for the Blind estimates that:– 10 million people in the US are blind or visually
impaired– 1.3 million people are legally blind
• People with learning and physical disabilities use screen readers as well
• Legal implications: AFB vs. Target• Universal Design: writing good code is
good practice, and makes it more accessible to all
Excuses, Excuses…
• “We’re not legally obligated to be accessible.”
• “It’s too hard to create accessible sites.”• “We don’t have (m)any users with
disabilities.”• “Our vendors don’t; why should we?”• “Screen reader technology will catch up.”
History of Accessibility Standards
• World Wide Web Consortium (W3C)– Web Content Access Guidelines (WCAG)
• WCAG 1.0: published May 1999 • WCAG 2.0: published December 2008
• Federal Government– Section 508
• First published in December 2000 as part of an amendment to to Rehabilitation Act
• Enforced June 2001• Recommendations for update submitted
April 2008
WCAG 2.0 and 508: What’s the Difference?
• WCAG 2.0– 4 principles, 12 guidelines– Has 3 levels of conformance,
A-AAA (formerly Priorities 1-3)– Compliance is voluntary
• Section 508, Subpart B, §11.94.22 a-p– A list of 16 checkpoints– A subset of a much larger document, The
Rehabilitation Act– Compliance is mandatory for some
WCAG 2.0: What’s New?
• List of 14 guidelines restructured into an outline of 4 principles
• Not as specific as “checkpoint” format of WCAG 1.0
• Priorities 1-3 replaced with conformance levels A-AAA – Note: we’ll be reviewing Level A only
• Met with criticism from developers
WCAG 2.0 Principles 1-2
• Principle 1: Perceivable– Information and user interface components
must be presentable to users in ways they can perceive.
• Principle 2: Operable– User interface components and navigation
must be operable.
WCAG 2.0 Principles 3-4
• Principle 3: Understandable– Information and the operation of user
interface must be understandable.
• Principle 4: Robust– Content must be robust enough that it can be
interpreted reliably by a wide variety of user agents, including assistive technologies.
Principle 1, Guideline 1.1
• Text alternatives– Provide text alternatives for any non-text
content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
1.1.1: Non-text Content
• All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.
Examples, 1.1.1
• Use <alt> tags for images and photos• Use <longdesc> for charts, graphs, or
other visual content to convey the material in them
• Provide text transcripts of audio and video recordings (see Guideline 1.2)
• Image maps• CAPTCHAs (for blog comments, etc.)
Principle 1, Guideline 1.2
• Time-based media– Provide alternatives for time-based media.
1.2.1: Audio-only and Video-only (Prerecorded):
• For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such:– Prerecorded Audio-only: An alternative for time-
based media is provided that presents equivalent information for prerecorded audio-only content.
– Prerecorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.
1.2.2: Captions (Prerecorded):
• Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.
1.2.3:: Audio Description or Media Alternative (Prerecorded):
• An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.
Examples, 1.2.1-1.2.3
• Provide transcripts or captions as appropriate for library podcasts, tutorials, videos, etc.
• Remember that your audience may include deaf/hard of hearing persons
• Tip: some tutorial software, including Camtasia and Captivate, can add captions
Principle 1, Guideline 1.3
• Adaptable– Create content that can be presented in
different ways (for example simpler layout) without losing information or structure.
1.3.1: Info and Relationships:
– Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
1.3.2: Meaningful Sequence:
• When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.
1.3.3: Sensory Characteristics:
• When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.
• Note: Guideline 1.4 will provide specific guidance on color
Examples 1.3.1-1.3.3
• Forms– Remember, search boxes are forms!
• Tables– Ensure that table data is read/presented in the
order in which a sighted person would see it
• CSS and document structure– Scanning content with a screen reader should
be just as easy as for a sighted person
• Use of color– “Click the green button to continue.”
Principle 1, Guideline 1.4
• Distinguishable– Make it easier for users to see and hear
content including separating foreground from background.
1.4.1: Use of Color:
• Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element
1.4.2: Audio Control:
• If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.
Examples for 1.4.1-1.4.2
• Forms and color– Not accessible: “Required fields are in red.”– Accessible: “Required fields are marked by an
asterisk.”
• Audio control– Music that plays automatically with no means
to stop it drowns out the screen reader– All users should control their experience– Don’t be MySpace!
Principle 2, Guideline 2.1
• Keyboard Accessible– Make all functionality available from a
keyboard.
2.1.1: Keyboard:
• All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
2.1.2: No Keyboard Trap:
• If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
Examples, 2.1.1-2.1.2
• Users should be able to operate everything and achieve full functionality with a keyboard—without a mouse.
• Try using your Library’s website without a mouse.
Principle 2, Guideline 2.2
• Enough Time– Provide users enough time to read and use
content
2.2.1: Timing Adjustable:
• (Summary) The user can:– turn off the time limit;– adjust the length of the limit (up to 10X); – receive warning of the limit and have 20
seconds to respond.
2.2.2: Pause, Stop, Hide:
• Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential;
• Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
Examples, 2.2.1-2.2.2
• Does your catalog reset automatically using a meta refresh or other programming trick?
• Do your interactive tutorials, quizzes, etc., provide a non-visual means to pause and resume?
Principle 2, Guideline 2.3
• Seizures– Do not design content in a way that is known
to cause seizures.
2.3.1: Three Flashes or Below Threshold:
• Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.
Examples, 2.3.1
• C’mon, it’s not 1997 and <blink> has been deprecated for years!
• But seriously: does any video content contain flashing lights, such as gunfire or lightning?
• Blinking and flashing can be distracting for people with low vision or learning disabilities
Principle 2, Guideline 2.4
• Navigable – Provide ways to help users navigate, find
content, and determine where they are.
2.4.1: Bypass Blocks:
• A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.
2.4.2: Page Titled:
• Web pages have titles that describe topic or purpose.
2.4.3: Focus Order:
• If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
2.4.4: Link Purpose (In Context):
• The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.
Examples, 2.4.1-2.4.4
• Skip navigation techniques (article links)• How do your templates or web
editing/authoring software handle creating <title> content? How does it handle dynamic content?
• Document structure and use of headings• Link labels:
– Not accessible: “Click here!”– Accessible: “Click here for info about…”
Principle 3, Guideline 3.1
• Readable– Make text content readable and
understandable.
3.1.1: Language of Page:
• The default human language of each Web page can be programmatically determined.
Example, 3.1.1
• Use the (X)HTML “lang” attribute wisely• Screen readers and text-to-speech
software can specify language
Principle 3, Guideline 3.2
• Predictable– Make Web pages appear and operate in
predictable ways.
3.2.1: On Focus:
• When any component receives focus, it does not initiate a change of context
3.2.2: On Input:
• Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
Examples, 3.2.1-3.2.2
• When tabbing through navigation or other lists of choices, ensure that selecting an item doesn’t activate it
• Phone number fields in a form: if there are three separate fields to capture phone number data (area code, exchange, number) users should be alerted that focus will change after they enter area code, etc.
Principle 3, Guideline 3.3
• Input Assistance– Help users avoid and correct mistakes.
3.3.1: Error Identification:
• If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
3.3.2: Labels or Instructions:
• Labels or instructions are provided when content requires user input
Examples, 3.3.1-3.3.2
• Form errors/omissions: make sure that they are described by text
• Where do you have forms in your web presence?
• Coding forms for accessibility:– Jim Thatcher, “Accessible Forms”– WebAIM, “Creating Accessible Forms”– NCSU, “Creating Accessible Forms”
Principle 4, Guideline 4.1
• Compatible– Maximize compatibility with current and future
user agents, including assistive technologies.
4.1.1: Parsing:
• In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.
4.1.2: Name, Role, Value:
• For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
Examples, 4.1.1-4.2.2
• Write good code and validate it—more on that shortly
• Applets and other content of that type should conform to accessibility of the language (i.e., Java)
Validating Code
• Why validate?• Validating code against web standards• Validating web sites for accessibility
Validating for Web Standards
• W3C tools:– HTML: validator.w3.org– CSS: jigsaw.w3.org/css-validator
• Validate live sites or by file upload
Validating for Web Accessibility
• Bobby/WebXACT: no longer available• Cynthia Says
– Generates thorough reports in 508 and WCAG Priorities 1, 2, and 3
– Not updated to reflect WCAG 2.0
• Web Accessibility Evaluation (WAVE) Tool– Visual report interface– Blog/community support
Day 1 Review and Wrap Up
• What’s the difference between accessibility and usability?
• Why do Section 508 and WCAG exist?• Why is most of the web not accessible?• Describe the concept of “skip navigation.”• Why is document structure important?• Why should you validate your code?• Questions? Comments?
Day 2 Agenda
• Screen reader software– Video: “How I use a Screen Reader”– JAWS for Windows– Window Eyes– VoiceOver for Mac– JAWS Demo
• Case Studies– Small group work– Report one case back to all
Using a Computer as a Blind Person – JAWS Screen Reader
• http://www.youtube.com/watchv=a1uYlgLSKMk
Screen Reader Software
• Market leaders: JAWS and Window-Eyes– enjoy a PC/Mac-like rivalry
• Common features: – braille output– integration with popular services, i.e., iTunes– voices in different genders, languages, etc.
JAWS: “Job Access with Speech”
• Vendor: Freedom Scientific• Current version: 10• For Windows• Pricing: $1095 professional; $895
standard• Per the end-user license agreement,
using the free download demo for testing purposes is not permitted.
Window Eyes
• Vendor: GW Micro• Current version: 7.1• For Windows• Pricing:
– Full version: $895– SMA: $299.00
• No end user restrictions for testing purposes
VoiceOver for Mac
• Integrated with OS X since 10.4• Also works with iPod Shuffle, Nano,
Touch, and iPhone 3GS• Different voices and options/features• www.apple.com/accessibility/voiceover/
JAWS Demo: What You’ll Hear
• The percentage of the page loaded announced
• The number of frames, links, headings, and forms on the web page being read announced
• The word “edit” when JAWS encounters a form/search box
• Now close your eyes…
Demo Links
• Less accessible page:
library.auraria.edu/~nmchale/presentations/lita2009/lessaccessible.html
• More accessible page:
library.auraria.edu/~nmchale/presentations/lita2009/moreaccessible.html
Drawbacks to using Screen Readers for Testing Your Sites
• They have a difficult learning curve• They’re expensive• Enter Fangs and WAVE!
– Accessibility evaluation tools– Freely available– Fangs: a FireFox add-on– WAVE: a site where one can enter a URL or
upload a file for evaluation
WAVE
• wave.webaim.org/• Provides a visual report:
Fangs Screen Reader Emulator
• Produces a print transcript similar to the voice output of screen readers
• Download:
sourceforge.net/projects/fangs• To create a transcript for a web page:
– Download Fangs– Open Firefox– Browse to the Web site you wish to test– Tools => Fangs
Fangs Demo
• What you get from Fangs:– Output screen: a screen reader transcript of
the current page– Headings list: lists all h1-h6 items in the
current page– Links list: lists all links in the current page
Case Studies
• What you’ll get for each resource:– Screen shot– Fangs output screens– Some hints
• What you’ll do:– Review these materials for each case– Evaluate the samples against WCAG 2.0– Provide recommendations to improve accessibility– Select the most interesting one to present to
the group
What are we going to evaluate?
• Item 1: a home-grown web page/resource• Item 2: a library-specific product that
allows for varying levels of customization (i.e., catalogs)
• Item 3: a library tool that is not customizable (i.e., databases)
• Item 4: a Web 2.0 tool frequently used by libraries
What to Bring Back to the Group
• A rating for each resource– 1=resource unusable for screen readers– 2=usable, but difficult– 3=usable– 4=screen-reader friendly– 5=screen reader experience as identical as
possible to sighted experience
• List of WCAG 2.0 guidelines followed• List of WCAG 2.0 guidelines NOT followed• Recommendations for improvement
Take a Deep Breath…
• Even sites that are meet Level AAA conformance are not accessible to all users with disabilities
• Partner with existing resources in your community to address accessibility issues
• Reach out to users with disabilities, including inviting them to participate in usability studies
Accessibility “Help” Pages
• LexisNexis• Facebook• Suggestions for Library Disability Help Pages
– Contact information for disability support– List of disability services offered– Building access info– List of assistive technology offered
-Rebecca Power and Chris LeBeau, “How Well Do Academic Library Web Sites Address the Needs of Database Users with Visual Disabilities?” The Reference Librarian, Volume 50, Issue 1, January 2009, pages 55-72
When I Get Back to My Library…
Wrapping Up
• What worked well for you? What not so much?
• How will you put what you’ve learned to use when you get back?
• What do you want to know more about?• All links from this session:
delicious.com/ninermac/lita2009accessibility
A Final Thought
“Sometimes I think sighted people have handicaps of their own. Vision can be very deceptive.”
-Pat Laing, computer programmer and JAWS user
Questions? Comments?
Nina McHale
library.auraria.edu/~nmchale
Facebook and Twitter: ninermac