Making IT Accessible

1. Making IT Accessible Iain Murray School of Electrical & Computer Engineering Curtin University of Technology I.Murray@ece.curtin.edu.au

2. What will and won’t be covered • No HTML. • No Java. • No Image Editing. • Animated GIFS, Blinking text etc. • How people with disabilities access technology. • Presentation of content for accessibility. • Why go to the trouble? • Awareness Issues.

3. Areas of Concern • Corporate IT. • Legalities. • Productivity. • Web content accessibility. • Market size is growing. • Greater spending power. • Applications. • Hardware design considerations. • Palm, EFTPOS, Ticketing machines etc.

4. Why? • Legalities. • The Sydney Organizing Committee for the Olympic Games (SOCOG) was successfully sued for $20,000. • This has created a precedent. • Applies to business and Government. • Estimated only 25% of Australian Web sites comply with W3C Guidelines (Innes, 2001). • Australian Disabilities Discrimination Act 1992.

5. Why? • 19% of the Australian population have disabilities or functional limitations, which a major cause is aging (ABS, 1998). • Includes those. • born with disabilities. • whose abilities diminish during their lifetime through disease, accident or ageing. • There is a demographic trend toward a growing elderly population (particularly as the "babyboom" generation ages). • Raises the prospect of a large number of consumers with decreasing abilities.

6. Disability Discrimination Act • DDA is administered by the Human rights and Equal Opportunities Commission (HREOC). • Accepts that some differential treatment is unavoidable. • Commonwealth Departments and Agencies must develop action plans. • Emerging DDA standards on “Electronic Communication”.

7. Economic or Humanitarian? • Should the mainstream design of products include consideration of people who have disabilities or are elderly? • From a humanitarian standpoint. • This must also be considered in terms of effects on personnel, curricula and economic perspectives.

8. Economic or Humanitarian? • It is useful to break this complex question into the following component questions: • Who is included in the category of "disabled and elderly persons"? • How large is the disabled and elderly population? • Can't the needs of disabled or elderly persons be handled separately or as exceptions? • Is it economically and practically feasible to include disabled and elderly persons in the design process for mass market products? • What are the "costs"?

9. Prevalence of Impairment (based on data from National Center for Health Statistics, 1979, as reported in Czajka, 1984)

10. Disabled and Elderly Persons • Can't the Needs of Disabled and Elderly Persons Be Handled Separately or As Exceptions? • Many small groups together represent a large portion of the population. • Is it both economically and practically feasible to include disabled and elderly persons in the design process for mass market products? • Aging wealthier population. • OS&H considerations and employee comfort. • Discrimination suits.

11. Disabled and Elderly Persons • What are the costs? • With web design, negligible. • If implemented early. • Hardware and Application designs becoming cheaper. • MS speech API (free). • Speech recorder chips are relatively cheap. • Voice recognition. • Standards are available. • Trace Research EZ Access system.

12. Access Methods • For low vision users. • Screen enlargement. • Zoomtext, Magic. • Screen review programs. • Jaws, Slimware, Artic. • Two output methods - speech and Braille displays. • Screen review software must rely on text output.

13. Access Methods • Other mobility difficulties. • Quadriplegics. • Morse, Eye tracking, scan boards. • Emphasis on keyboard/mouse replacement issues. • Deaf. • Subtitles, visual alerts, transcription of conferences/video. • Many others.

14. Speech Demonstration Jaws jaws keys and demo.doc Freedom Scientific assistive technology for blind and visually impaired computer users.htm School of Electrical and Computer Engineering Home page.htm

15. W3C Guidelines • Four Parts: • Techniques for Web Content Accessibility. • The gateway to other documents. • Core Techniques for Web Contents Accessibility. • Discusses the accessibility themes and general techniques that apply across technologies (e.g. Validation and testing). • HTML Techniques for Web Content Accessibility. • Provides examples and strategies for authoring accessible HTML content. • CSS Techniques for Web Accessibility. • Helps authors write cascading style sheets as part of accessible content design.

16. Web Content Accessibility • Accessibility issues. • Clients may not be able to see, hear, move or process some types of information easily or at all. • They may have difficulty reading or comprehending text. • They may not be able to use a keyboard or mouse. • They may have a text-only screen, a small screen or a slow Internet connection. • They may be in a situation where their eyes, ears or hands are busy or interfered with (e.g. driving to work, working in a loud environment, etc.). • They may have an early version of a browser, a different browser entirely or a voice browser.

17. Checkpoints • Each checkpoint has a priority level based on the checkpoint’s impact on accessibility. • Priority 1. • A Web content developer must satisfy this checkpoint. If not, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.

18. Checkpoints • Priority 2. • A Web content developer should satisfy this checkpoint. If not, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents. • Priority 3. • A Web content developer may address this checkpoint. If not, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents. • Some checkpoints specify a priority level that may change under certain (indicated) conditions.

19. Conformance • There are three levels of conformance to the W3C document: • Conformance Level "A": • all Priority 1 checkpoints are satisfied. • Conformance Level "Double-A": • all Priority 1 and 2 checkpoints are satisfied. • Conformance Level "Triple-A": • all Priority 1, 2 and 3 checkpoints are satisfied.

20. Web Content Accessibility Guidelines Guideline 1 Provide equivalent alternatives to auditory and visual content. Provide content that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content.

21. Web Content Accessibility Guidelines Guideline 2 Don’t rely on colour alone. Ensure that text and graphics are understandable when viewed without colour.

22. Web Content Accessibility Guidelines Guideline 3 Use markup and style sheets and do so properly. Markup Documents with the proper structural elements. Control presentations with style sheets rather than with presentation elements and attributes.

23. Web Content Accessibility Guidelines Cascading Style Sheets (CSS) is a simple mechanism for adding style (e.g. fonts, colors, spacing) to Web documents. <style type="text/css"> body { color: black; background: white; } </style>

24. Web Content Accessibility Guidelines MathML is intended to facilitate the use and re-use of mathematical and scientific content on the Web, and for other applications such as computer algebra systems, print typesetting, and voice synthesis.

25. Web Content Accessibility Guidelines Guideline 4 Clarify natural language usage. Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text.

26. Web Content Accessibility Guidelines Guideline 5 Create tables that transform gracefully. Ensure that tables have the necessary markup to be transformed by accessible browsers and other user agents.

27. Web Content Accessibility Guidelines Guideline 6 Ensure that pages featuring new technologies transform gracefully. Ensure that pages are accessible even when newer technologies are not supported or are turned off.

28. Web Content Accessibility Guidelines Guideline 7 Ensure user control of time-sensitive content changes. Ensure that moving, blinking, scrolling or auto updating objects or pages may be paused or stopped.

29. Web Content Accessibility Guidelines Guideline 8 Ensure direct accessibility of embedded user interfaces. Ensure that the user interface follows principles of accessible design, namely device-independent access to functionality, keyboard operability, self voicing etc.

30. Web Content Accessibility Guidelines Guideline 9 Design for device independence. Use features that enable activation of page elements via a variety of input devices.

31. Web Content Accessibility Guidelines

32. Web Content Accessibility Guidelines Guideline 10 Use interim solutions. Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly.

33. Web Content Accessibility Guidelines Guideline 11 Use W3C technologies and guidelines. Use W3C technologies (according to specification) and follow accessibility guidelines. Where it is not possible to use a W3C technology, or doing so results in material that does not transform gracefully, provide an alternative version of the content that is accessible.

34. Web Content Accessibility Guidelines Guideline 12 Provide context and orientation information. Provide context and orientation information to help users understand complex pages or elements.

35. Web Content Accessibility Guidelines Guideline 13 Provide clear navigation mechanisms. Provide clear and consistent navigation mechanisms orientation information, navigation bars, a site map, etc., to increase the likelihood that a person will find what they are looking for at a site.

36. Web Content Accessibility Guidelines Guideline 14 Ensure that documents are clear and simple. Ensure that documents are clear and simple so they may be easily understood.

37. Validation • Validate accessibility with automatic tools and human review. • Bobby is a good example. • www.cast.org • Software tools do not address all accessibility issues, such as the meaningfulness of link text, the applicability of a text equivalent etc. • www.abwa.asn.au has links to many automated validation methods. • Use validation methods at the earliest stages of development. • Accessibility issues identified early are easier to correct or avoid.

38. Validation • Bobby Demo • bobby.html • bobby3.2 • bob47867.html

39. Validation • The Murray Method: • 1: Start the screen review software. • 2: Turn off the screen. • 3: Disconnect the mouse. • 4: (Try to) Navigate your site ! • Jaws is available as a free download. • Supports a software synthesizer. • Runs for 40 minutes.

40. Validation Methods • Use an automated accessibility tool and browser validation tool. • Use a text-only browser or emulator. • Use multiple graphic browsers, with: • sounds and graphics loaded, • graphics not loaded, • sounds not loaded, • no mouse, • frames, scripts, style sheets, and applets not loaded • Use several browsers, old and new.

41. Validation Methods • Use a self-voicing browser, a screen reader, magnification software, etc. • Use spell and grammar checkers. • Review the document for clarity and simplicity. • Readability statistics, such as those generated by some word processors may be useful indicators of clarity and simplicity. • Invite people with disabilities to review documents. • They are normally more than happy to help out.

42. Further Information • W3C Techniques for Web Content Accessibility Guidelines. • www.w3c.org/TR/2000/WCAG10-TECHS • Trace Research and Development Centre. • www.trace.wisc.edu • Association for the Blind WA. • www.abwa.asn .au

43. Thank You Any Questions?