Accessible Software Design

1. Accessible Software Design Taken from several sources

2. Users With Disabilities • Sight • Hearing • Mobility • Cognitive • Language impairment • Seizure disorders • Speech impairments

3. Why Worry About It? • Profits • Americans With Disabilities Act • Rehabilitation Act • Legislation elsewhere • It is part of ANSI and ISO standards for usability • Moral High Road

4. Accessibility in the Lifecycle • Plan early to accommodate • Include people with disabilities in feedback process • requirements determination • usability testing • Beta testing • Ensure developers are familiar with accessibility guidelines • Ensure test team can recognize accessibility problems • Ensure technical support and customer service have access to accessible environments

5. How Computers can Become Accessible • New Features in hardware / OS • Accessibility Aids • Specialized applications • Usability features in applications

6. Accessibility Aids • Require cooperation from application program • Screen enlargement utilities • Screen readers • Voice input utilities • On screen keyboards • Keyboard filters

7. Some Basic Principles • Flexibility • Choice of input methods • Choice of output modalities • Compatibility with accessibility aids • Consistency

8. Keyboard Access is Key • Blind people cannot maneuver a mouse • Provide keyboard access to all features • Fully document keyboard interface • Model keyboard interface on known interfaces • Allow users to select text using keyboard • If possible, provide customizable keyboard shortcuts • Make sure dialog boxes define the correct tab order

9. Play Nice for Accessibility Aids • If, for example, an accessibility aid is going to verbalize visual info, they need things to be named and labeled meaningfully • Ensure that every window, object, and graphic is named appropriately • Define correct text labels for all controls • Give every window a user-friendly caption • Expose names or descriptions for all images • Expose your elements to the accessibility software

10. Color • Color is an issue for color blind, and visually impaired • Use only colors that user can customize – in control panel • Use proper foreground / background combinations • No background images behind text • Avoid conveying important info via color alone • Give good contrast of images to background • Allow MS “High Contrast Option”

11. Size • Of importance to visually impaired • Allow the user to select font and font sizes for displayed info • If feasible, provide draft mode, zoom, and wrap to window features • Allow the user to adjust size of non-document elements – such as toolbars • Make sure application is compatible with changes to system font

12. Sound • Good for visually impaired, bad for hearing impaired • Define Sound Schemes • Allow substitution of visual for sound • Allow substitution of sound for visual • Provide a way to turn off sounds

13. Timings • Of importance to visually impaired and cognitively impaired • Allow user to customize any interface timings • Allow the user to avoid having messages time out • Flashing can cause seizures – allow slowing down or disabling any rapid screen updates or flashing

14. Good Layout is Even More Important • Things that help regular users understand what to do are even more important for visually or cognitively impaired people • Text labels immediately to left of or above control • Not ambiguous which of the above • Text labels end with : (text not requiring input, no : ) • Icons identified with text below, to right, or in tool tip • Position related objects near each other

15. Documentation • Provide documentation in accessible format such as ASCII text or HTML • Include descriptions of any illustrations and tables • Do not convey important information via color or graphics alone • Keep high contrast between text and background • Do not use text smaller than 10 pt • If possible, bind printed documentation to lie flat

16. Verifying Accessibility • Test against guidelines discussed here • Test compatibility with extra large appearance schemes • Verify that all features can be used without a mouse • Verify that all keyboard access methods are documented • If MS, test use with accessibility tools/options • Test with commercial accessibility aids • Include people with disabilities and accessibility software vendors in beta tests • Distribute free evaluation copies to individuals with disabilities, disability organizations, and accessibility software vendors • Include people with disabilities in your usability tests • Conduct surveys of your users with disabilities

17. Anything Special About the Web? • Resources – Web Accessibility Initiative (WAI) – http://www.w3.org/WAI • "Web Content Accessibility Guidelines 1.0", G. Vanderheiden, W. Chisholm, and I. Jacobs, eds., 5 May 1999. W3C Recommendation: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505 • “User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs, eds., 28 July 2000. W3C Working Draft:http://www.w3.org/TR/2000/WD-UAAG10-20001023

18. Color blindness • Color blind online shoppers may not pick up sale prices – the red doesn’t stand out • Controlling presentation with style sheets • User override of author style sheets

19. Color Blindness – WWW Barriers • color that is used as a unique marker to emphasize text on a Web site • text that inadequately contrasts with background color or patterns • browsers that do not support user override of authors' style sheets

20. Motor Disabilities • include weakness, limitations of muscular control , limitations of sensation, joint problems, or missing limbs. • To use the Web, people with motor disabilities affecting the hands or arms may use • a specialized mouse; • a keyboard with a layout of keys that matches their range of hand motion; • a pointing device such as a head-mouse, head-pointer or mouth-stick; an eye-gaze system; • voice-recognition software; • They may activate commands by typing single keystrokes in sequence with a head pointer rather than typing simultaneous keystrokes ("chording") to activate commands. • may need more time when filling out interactive forms on Web sites

21. Motor Disabilities – WWW Barriers • time-limited response options on Web pages • browsers and authoring tools that do not support keyboard alternatives for mouse commands • forms that cannot be tabbed through in a logical order (Note: "Tabindex" solution not yet well supported in browsers.)

22. Repetitive Stress – Carpal Tunnel • Voice input allows less use of mouse and typing • Problem: WWW sites with streaming audio conflict with speech recognition • Alternative keyboard • Using access keys for shortcuts • Problem: authoring tool accessibility

23. Hearing Impairment - Deafness • To use the Web, many people who are deaf rely on captions for audio content.

24. Deafness – WWW Barriers • lack of captions or transcripts of audio on the Web • lack of content-related images in pages full of text, which can slow comprehension for people whose first language may be a sign language instead of a written/spoken language • Any requirements for voice input on Web sites

25. Hearing Impaired • Some WWW pages have audio that is important part of the content (e.g. university with online audio lessons) • Making multimedia accessible

26. Visual Impairment - Blindness • To access the Web, many rely on screen readers – • outputs this information to a speech synthesizer and/or • refreshable braille display. • Some use text-based browsers such as Lynx, or voice browsers, • may use rapid navigation strategies such as tabbing through the headings or links on Web pages

27. Blindness - WWW Barriers • images that do not have alt text • complex images (e.g., graphs or charts) that are not adequately described • video that is not described in text or audio • tables that do not make sense when read serially (in a cell-by-cell or "linearized" mode) • frames that do not have "NOFRAME" alternatives, or that do not have meaningful names • forms that cannot be tabbed through in a logical sequence or that are poorly labelled • browsers and authoring tools that lack keyboard support for all commands • browsers and authoring tools that do not use standard applications programmer interfaces for the operating system they are based in • non-standard document formats that may be difficult for their screen reader to interpret

28. HTML Tables • Problem: Tables can be hard to read for screen readers • you should use the HTML TABLE element and its supporting elements and attributes (like TR, TD, TH and CAPTION). • A simple data table created with proper data table mark up, might look like this:

29. HTML Table • <TABLE border=1> • <CAPTION>Example of a simple data table created using HTML markup.</CAPTION> • <TR><TD></TD><TH>Column 1 header</TH> • <TH>Column 2 header</TH></TR> • <TR><TH>Row 1 header</TH> • <TD>Column 1 Row 1</TD> • <TD>Column 2 Row 1</TD></TR> • <TR><TH>Row 2 header</TH> • <TD>Column 1 Row 2</TD> • <TD>Column 2 Row 2</TD></TR> • </TABLE>

30. HTML for Better Reading • HTML 4.0 also allows you to explicitly link header information to columns and rows using the "headers" attribute of the <TD> and <TH> elements, e.g.: • Cups of coffee consumed by each senator • If you use the 'headers' attribute, a browser or screen reader might be able to expose or read the contents of the cells (if the user wishes) like this: • Name: T. Sexton, Cups: 10, Type: Espresso, Sugar: NoName: J. Dinnen, Cups: 5, Type: Decaf, Sugar: Yes • because each datum is explicitly associated with its appropriate header.

31. View the markup code that would generate this example • <TR> • <TH id="t1">Name</TH> • <TH id="t2">Cups</TH> • <TH id="t3" abbr="Type">Type of Coffee</TH> • <TH id="t4">Sugar?</TH> • </TR> • <TR> • <TD headers="t1">T. Sexton</TD> • <TD headers="t2">10</TD> • <TD headers="t3">Espresso</TD> • <TD headers="t4">No</TD> • </TR> • <TR> • <TD headers="t1">J. Dinnen</TD> • <TD headers="t2">5</TD> • <TD headers="t3">Decaf</TD> • <TD headers="t4">Yes</TD> • </TR>

32. More Visual Impairment • Abbreviations in documents make reading them aloud hard for a mere program • Expanding abbreviations and acronyms When in Boston, be sure to visit the <ACRONYM TITLE="Museum of Fine Arts">MFA</ACRONYM>, <ACRONYM TITLE="Massachusetts Institute of Technology">MIT</ACRONYM> and, of course, the <ACRONYM TITLE="World Wide Web Consortium">W3C</ACRONYM>. These destinations are easily reached via <ABBR TITLE="Massachusetts Avenue">Mass. Ave.</ABBR> or <ABBR TITLE="Memorial Drive">Mem. Dr.</ABBR>.

33. More Visual Impairment • The WWW is full of visual info, graphics, multimedia

34. Visual Impairment – Low Vision • There are many types of low vision • To use the Web, some people use extra-large monitors, and • increase the size of system fonts and images. • Others use screen magnifiers • Some use bright contrast • or choose typefaces is legible given their condition

35. Low Vision – WWW Barriers • Web pages with absolute font sizes that do not change (enlarge or reduce) easily • Web pages that, because of inconsistent layout, are difficult to navigate when enlarged, due to loss of surrounding context • Web pages, or images on Web pages, that have poor contrast, and whose contrast cannot be easily changed through user override of author style sheets • imaged text that cannot be re-wrapped • also many of the barriers listed for blindness, above, depending on the type and extent of visual limitation

36. Resources - Corporate • Microsoft • User Oriented - http://www.microsoft.com/enable/ • Developer Oriented - http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28000544 • http://www-3.ibm.com/able/swreferences.html- links from IBM

37. Resources - Organizations • ACM SIGCAPH – Special Interest Group on Computers and the Physically Handicapped - http://www.acm.org/sigcaph/ • www.rit.edu/~easi/access.htm - Equal Access to Software and Information • trace.wisc.edu/world/computer_access – Designing More Usable Computers and Software

38. Resources - WWW • aware.hwg.org/tips - Tips and Techniques for Accessible Web Authoring • nadc.ucla.edu/dawpi.htm - Web Access resource list

39. Resources - Government • www.access-board.gov/sec508/508standards.htm

40. Resources - Evaluation • www.cast.org/bobby - www site which will (partially) evaluate a www page for accessibility

41. End Accessibility