This document provides an agenda for a two-day training on web accessibility standards and best practices. Day 1 will cover an introduction to Section 508 and WCAG guidelines, how to validate code for accessibility, and how screen readers work. Day 2 will include demonstrations of popular screen readers like JAWS and VoiceOver as well as case studies evaluating the accessibility of different types of library web resources.

1. Accessibility Update: Section 508 and WCAG in a Library 2.0 World Nina McHale Assistant Professor, Web Librarian University of Colorado Denver LITA National Forum October 1-2, 2009

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

3. Today’s Agenda Accessibility and usability defined Introduction to web standards Section 508 WCAG 2.0 Code validation (X)HTML, CSS Validating for accessibility

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

5. 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?

6. Accessibility “the ‘ability to access’ the functionality, and possible benefit, of some system or entity.” -Wikipedia, “Accessibility”

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

8. Accessibility Fail

9. Usability Fail

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

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

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

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

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

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

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

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

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

20. Principle 1, Guideline 1.2 Time-based media Provide alternatives for time-based media.

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

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

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

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

25. Principle 1, Guideline 1.3 Adaptable Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

26. 1.3.1: Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

27. 1.3.2: Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

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

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

30. Principle 1, Guideline 1.4 Distinguishable Make it easier for users to see and hear content including separating foreground from background.

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

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

33. 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!

34. Principle 2, Guideline 2.1 Keyboard Accessible Make all functionality available from a keyboard.

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

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

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

38. Principle 2, Guideline 2.2 Enough Time Provide users enough time to read and use content

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

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

41. 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?

42. Principle 2, Guideline 2.3 Seizures Do not design content in a way that is known to cause seizures.

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

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

45. Principle 2, Guideline 2.4 Navigable Provide ways to help users navigate, find content, and determine where they are.

46. 2.4.1: Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

47. 2.4.2: Page Titled: Web pages have titles that describe topic or purpose.

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

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

50. 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…”

51. Principle 3, Guideline 3.1 Readable Make text content readable and understandable.

52. 3.1.1: Language of Page: The default human language of each Web page can be programmatically determined.

53. Example, 3.1.1 Use the (X)HTML “lang” attribute wisely Screen readers and text-to-speech software can specify language

54. Principle 3, Guideline 3.2 Predictable Make Web pages appear and operate in predictable ways.

55. 3.2.1: On Focus: When any component receives focus, it does not initiate a change of context

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

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

58. Principle 3, Guideline 3.3 Input Assistance Help users avoid and correct mistakes.

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

60. 3.3.2: Labels or Instructions: Labels or instructions are provided when content requires user input

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

62. Principle 4, Guideline 4.1 Compatible Maximize compatibility with current and future user agents, including assistive technologies.

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

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

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

66. Validating Code Why validate? Validating code against web standards Validating web sites for accessibility

67. Validating for Web Standards W3C tools: HTML: validator.w3.org CSS: jigsaw.w3.org/css-validator Validate live sites or by file upload

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

69. 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?

70. Day 2 Agenda Screen reader software Video: “How I use a Screen Reader” JAWS for Windows Window Eyes VoiceOverfor Mac JAWS Demo Case Studies Small group work Report one case back to all

71. Using a Computer as a Blind Person – JAWS Screen Reader http://www.youtube.com/watchv=a1uYlgLSKMk

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

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

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

75. 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/

76. 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…

77. Demo Links Less accessible page: library.auraria.edu/~nmchale/presentations/lita2009/lessaccessible.html More accessible page: library.auraria.edu/~nmchale/presentations/lita2009/moreaccessible.html

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

79. WAVE wave.webaim.org/ Provides a visual report:

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

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

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

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

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

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

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

87. When I Get Back to My Library…

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

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

90. Questions? Comments? Nina McHale nina.mchale@ucdenver.edu library.auraria.edu/~nmchale Facebook and Twitter: ninermac