Issues in information architecture I. Accessibility • Why bother with web accessibility?

1. Issues in information architecture I. Accessibility • Why bother with web accessibility? II. W3C Accessibility guidelines • Web Content Accessibility Guidelines 1.0 • Authoring Tool Accessibility Guidelines 1.0 • User Agent Accessibility Guidelines 1.0 III. Maintenance

2. Issues in information architecture I. Accessibility There are two good reasons we should be concerned with accessibility There is a significant population of people with various disabilities who use the web ~14% of people < 65 have some type of functional disability We are getting older and want to continue to use the web ~50% of people > 65 There are good business reasons as well People with disabilities tend to be loyal customers when they find a responsive business

3. The web is replacing traditional sources of information and interaction Schools, libraries, print materials Some resources are becoming less accessible The web is a critical, but somewhat inaccessible, resource for: News, information, commerce, entertainment Education, distance learning Job searching, and workplace interaction Civic participation -- laws, voting, government services An accessible Web will mean unprecedented access to information for people with disabilities From W3C. (2002). Web Accesibility Initiative http://www.w3.org/Talks/WAI-Intro/slide5-0.html

4. Barriers include Visual disabilities: Unlabeled graphics Lack of description for video Poorly marked-up tables or frames Lack of keyboard support or screen reader compatibility Hearing disabilities: Lack of captioning for audio Proliferation of text without visual signposts

5. Physical disabilities: Lack of keyboard or single-switch support for menu commands Cognitive or neurological disabilities: Lack of consistent navigation structure Overly complex presentation or language Lack of illustrative non-text materials Flickering or strobing designs on pages These disabilities affect the global population of web users

6. The types of disabilities that are relevant are those that impair a person’s ability to use a computer This means having difficulty using input devices Keyboard, mouse (physical impairments) Also output devices Monitors (visual and auditory impairments) This is an estimated 30 million people The challenge: Incorporate into design some basic principles to increase the overall usability of the web for people with disabilities

7. Issues in information architecture I. Accessibility • Why bother with web accessibility? II. W3C Accessibility guidelines • Web Content Accessibility Guidelines 1.0 • Authoring Tool Accessibility Guidelines 1.0 • User Agent Accessibility Guidelines 1.0 III. Maintenance

8. W3C Web accessibility initiative (WAI) Mission: to lead the Web to its full potential by promoting a high degree of usability for people with disabilities Sponsors: US NSF, US Department of Education's National Institute on Disability and Rehabilitation Research European Commission, DG XIII, Telematics Applications Programme for Disabled and Elderly Canadian government, Industry Canada's Assistive Devices Industry Office IBM, Lotus, Microsoft, Bell Atlantic and others http://www.w3.org/WAI/

9. Development is occurring in technology, guidelines, tools, education and outreach, and R&D Technologies supporting for accessibility include HTML 4.0 accessibility features include: Style sheet linkage; alternative representation; navigation; improved table mark-up CSS2 accessibility features include: Layout; fonts; user control; aural CSS SMIL accessibility features include: Synchronization of captioning & audio description Also: Mobile Access, Internationalization (I18N), XML, SVG, DOM, P3P

10. There is a set of guidelines that the W3C has developed to aid web developers Web Content Accessibility Guidelines 1.0 Authoring Tool Accessibility Guidelines 1.0 User Agent Accessibility Guidelines 1.0 WAI has supporting documents and resources for each guideline: Checklists Techniques documents with implementation detail Curricula Logos

11. Using Web Content Accessibility Guidelines 1.0 Graceful transformation Pages that remain accessible despite physical, sensory, and cognitive disabilities users, work constraints, and technological barriers Separate structure from presentation This is what CSS and XML do This is the difference between content, structure, and presentation Provide text, including text equivalents Text can be rendered in ways that will be available to almost all browsing devices and accessible to almost all users

12. Create documents that work even if the user cannot see and/or hear Provide information that serves the same purpose or function as audio or video Use techniques suited to alternate sensory channels Users who are blind can use screen reader technology to render all text information in a page Create documents that do not rely on one type of hardware Pages should be usable by people without mice, with small, low resolution, or black and white screens, no screens,or with only voice or text output, etc

13. Designers should provide understandable mechanisms for navigating within and between pages Providing navigation tools and orientation information in pages maximizes accessibility and usability Some users can’t use of visual cues Problems can be causes by image maps, proportional scroll bars, side-by-side frames, or graphics that guide sighted users of graphical desktop browsers These users can also lose contextual information when they can only view a portion of a page This occurs because they access the page one word at a time (speech synthesis or braille display), or one section at a time (small display, or a magnified display)

14. The web content accessibility guidelines 1. Provide equivalent alternatives to auditory and visual content 2. Don't rely on color alone 3. Use markup and style sheets and do so properly 4. Clarify natural language usage 5. Create tables that transform gracefully 6. Ensure that pages featuring new technologies transform gracefully 7. Ensure user control of time-sensitive content changes 8. Ensure direct accessibility of embedded user interfaces

15. And 9. Design for device-independence 10. Use interim solutions 11. Use W3C technologies and guidelines 12. Provide context and orientation information 13. Provide clear navigation mechanisms 14. Ensure that documents are clear and simple There are three levels of conformance to this document: Level "A": all Priority 1 checkpoints are satisfied Level "Double-A": all Priority 1 and 2 checkpoints are satisfied Level "Triple-A": all Priority 1, 2, and 3 checkpoints are satisfied

16. Authoring Tool Accessibility Guidelines 1.0 The purpose is to assist developers in designing authoring tools that produce accessible Web content They also assist developers in creating an accessible authoring interface It is just as important that all people be able to author content as it is for all people to have access to it The tools used to create this information must therefore be accessible themselves regardless of disability They should produce accessible content by default

17. The guidelines are intended to provide better support for creation of accessible Web content through WYSIWIG editors Conversion tools (word processors, presentation software) Tools that dynamically generate Web pages from databases Image editors, site management tools These guidelines address Creation of valid content Strategies for prompting, alerting, help, validation Accessibility of the user interface

18. User Agent Accessibility Guidelines address: Browsers, multimedia players, and assistive technologies Accessibility of the user interface Rendering of accessibility information Checkpoints, priority levels, and conformance levels Goal is to design user agents that lower barriers to web accessibility for people with disabilities Visual, hearing, physical, cognitive, and neurological These include HTML browsers and other types of software that retrieve and display web content A conforming agent promotes accessibility through its user interface and other internal facilities, including its ability to communicate with other assistive technologies

19. Assistive web technologies include Screen magnifiers, used by people with visual disabilities They enlarge and change colors on the screen to improve the visual readability of rendered text and images Screen readers, used by people who are blind or have reading disabilities They allow people to read textual information using synthesized speech or braille displays. Voice recognition software, used by people with visual or physical disabilities Alternative keyboards, used to simulate the keyboard Alternative pointing devices, used to simulate mouse pointing and button activations

20. The user agent accessibility guidelines 1. Support input and output device-independence 2. Ensure user access to all content 3. Allow configuration not to render some content that may reduce accessibility 4. Ensure user control of rendering 5. Ensure user control of user interface behavior 6. Implement interoperable application programming interfaces 7. Observe operating environment conventions 8. Implement specifications that benefit accessibility

21. And 9. Provide navigation mechanisms 10. Orient the user 11. Allow configuration and customization 12. Provide accessible user agent documentation and help There are priorities to be met Priority 1 (P1) If the user agent does not satisfy this checkpoint, one or more groups of users with disabilities will find it impossible to access the web This checkpoint is a basic requirement for enabling some people to access the web

22. Priority 2 (P2) If the user agent does not satisfy this checkpoint, one or more groups of users with disabilities will find it difficult to access the web Satisfying this checkpoint will remove significant barriers to web access for some Priority 3 (P3) If the user agent satisfies this checkpoint, one or more groups of users with disabilities will find it easier to access the web Icons indicating conformance

23. Shortcut to web accessibility http://www.w3.org/WAI/EO/waicard12snapshot.gif

24. The guidelines for authoring tool accessibility 1. Support accessible authoring practices 2. Generate standard markup 3. Support the creation of accessible content 4. Provide ways of checking and correcting inaccessible content 5. Integrate accessibility solutions into the overall “look and feel” 6. Promote accessibility in help and documentation 7. Ensure that the authoring tool is accessible to authors with disabilities

25. Designing for accessibility has far-reaching benefits Support for access benefits users of devices with small display screens, web-TV, kiosks Increases usability for sites and users With low bandwidth, in noisy environments, or where there is screen-glare Redundant text/audio/video can support Different learning styles Low literacy levels, second-language access CSS can support efficient page transmission and site maintenance Captioning of audio files supports machine indexing of content and faster searching of content

26. Accessibility tool Bobby It is a comprehensive web accessibility software that helps to expose and repair barriers to accessibility It was created at CAST in 1996, a not-for-profit R&D organization working to expand opportunities for people with disabilities Watchfire acquired Bobby in 2002 Pricing Single user: $99.00 Single server: $3000.00 Multiple servers: $2000 for every 5 or more servers http://bobby.watchfire.com/bobby/html/en/index.jsp

27. Accessibility sites WebAccessibility in Mind (WebAIM) http://www.webaim.org/ IBM Web accessibility guideline center http://www-3.ibm.com/able/accessweb.html National Federation for the Blind http://www.nfb.org/tech/webacc.htm Illinois Technology Office Web Accessibility Standards http://www100.state.il.us/tech/technology/accessibility/ MIT Disabilities Resources for Information Technology http://web.mit.edu/atic/www/sw/