accessibility update: section 508 and wcag in a library 2.0 world

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.)


• 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


• 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.”


• 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!


• 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.


• 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?


• 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


• 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…”


• 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


• 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.


• 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”


• 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

[email protected]

library.auraria.edu/~nmchale

Facebook and Twitter: ninermac

accessibility update: section 508 and wcag in a library 2.0 world

Documents