1. © Simeon Keates 2008 Usability with Project Lecture 7 – 30/09/09 Dr. Simeon Keates

2. © Simeon Keates 2008 And now for something (not quite) completely different  Guest lecturer: Peter Olaf Looms Page 2

3. © Simeon Keates 2008 Exercise – part 1  Each group will be assigned a type of website Group 1 – car rental sites (e.g. Avis, hertz, alamo, budget) Group 2 – airline flight booking sites (e.g. flysas, virginatlantic, ba, sterling) Group 3 – travel insurance sites (e.g. columbusdirect) Group 4 – luggage (e.g. tumi) Group 5 – clothing (e.g. versace, lacoste) Group 6 – news sites (e.g. CNN, BBC) Group 7 – social networking sites (e.g. Facebook, Myspace)  You must look at a minimum of 3 sites  For each website, use Wave ( http://wave.webaim.org/ ) to examine the reported accessibility of each sitehttp://wave.webaim.org/ Page 3

4. © Simeon Keates 2008 Exercise – part 2 Question: How does Wave compare with CynthiaSays?  Now try the Vischeck colour simulator (http://www.vischeck.com/vischeck) on the same siteshttp://www.vischeck.com/vischeck  And then try a screen reader (http://webanywhere.cs.washington.edu/)http://webanywhere.cs.washington.edu/ Question: Have you changed your opinion about the overall accessibility of the sites? Page 4 Answer: Performs same checks. Output more visual (and usable). Answer: No(?)

5. © Simeon Keates 2008 Exercise – part 3 Deliverable:  Next week you will be testing your own sites  Develop a plan for how you will test your sites to make sure that they are as accessible as possible Page 5 Have all groups done this? Note: need for valid HTML/XML version before sites can be fully tested with screen reader software, etc.

6. © Simeon Keates 2008 Designing for Web accessibility Page 6

7. © Simeon Keates 2008 The components of Web accessibility ( source: W3C WAI ) Many components need to work together to make an accessible web site:  Content - the information in a Web page or Web application, including: Natural information such as text, images, and sounds Code or markup that defines structure, presentation, etc.  Web browsers, media players, and other "user agents”  Assistive technology, in some cases - screen readers, alternative keyboards, switches, scanning software, etc.  Users' knowledge, experiences, and in some cases, adaptive strategies using the Web  Developers - designers, coders, authors, etc., including developers with disabilities and users who contribute content  Authoring tools - software that creates Web sites  Evaluation tools - Web accessibility evaluation tools, HTML validators, CSS validators, etc. Page 7

8. © Simeon Keates 2008 How the components relate… Page 8

9. © Simeon Keates 2008 The implementation cycle  When Web browsers, media players, assistive technologies, and other user agents support an accessibility feature, users are more likely to demand it and developers are more likely to implement it in their content.  When developers want to implement an accessibility feature in their content, they are more likely to demand that their authoring tool make it easy to implement.  When authoring tools make a feature easy to implement, developers are more likely to implement it in their content.  When an accessibility feature is implemented in most content, developers and users are more likely to demand that user agents support it. Page 9

10. © Simeon Keates 2008 The implementation cycle (in pictures) Page 10

11. © Simeon Keates 2008 When one component is weak…  If an accessibility feature is not implemented in one component, there is little motivation for the other components to implement it …  …when it does not result in an accessible user experience.  For example, developers are unlikely to implement an accessibility feature that authoring tools do not support and that most browsers or assistive technologies do not implement consistently. Page 11

12. © Simeon Keates 2008 When one component is weak…  If one component has poor accessibility support, sometimes other components can compensate through "work-arounds" that require much more effort and are not good for accessibility overall. For example, Developers can do more work to compensate for some lack of accessibility support in authoring tools; for example, coding markup directly instead of through a tool Users can do more work to compensate for some lack of accessibility support in browsers, media players, and assistive technology and lack of accessibility of content; for example, using different browsers or assistive technologies to overcome different accessibility issues  However, this does not always work… Page 12

13. © Simeon Keates 2008 When one component is weak… Page 13

14. © Simeon Keates 2008 Guidelines for different components The W3C Web Accessibility Initiative (WAI) develops Web accessibility guidelines for the different components: Authoring Tool Accessibility Guidelines (ATAG) addresses authoring tools Web Content Accessibility Guidelines (WCAG) addresses Web content, and is used by developers, authoring tools, and accessibility evaluation tools User Agent Accessibility Guidelines (UAAG) addresses Web browsers and media players, including some aspects of assistive technologies  WAI guidelines are based on the fundamental technical specifications of the Web, and are developed in coordination with: W3C technical specifications (HTML, XML, CSS, SVG, SMIL, etc.) Page 14

15. © Simeon Keates 2008 Guidelines for different components Page 15

16. © Simeon Keates 2008 Web Content Authoring Guidelines (1.0) 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. 2. Don't rely on color alone. Ensure that text and graphics are understandable when viewed without color. 3. Use markup and style sheets and do so properly. Mark up documents with the proper structural elements. Control presentation with style sheets rather than with presentation elements and attributes. 4. Clarify natural language usage Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text. Page 16

17. © Simeon Keates 2008 Web Content Authoring Guidelines (1.0) 5. Create tables that transform gracefully. Ensure that tables have necessary markup to be transformed by accessible browsers and other user agents. 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. 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. Page 17

18. © Simeon Keates 2008 Web Content Authoring Guidelines (1.0) 8. Ensure direct accessibility of embedded user interfaces. Ensure that the user interface follows principles of accessible design: device-independent access to functionality, keyboard operability, self- voicing, etc. 9. Design for device-independence. Use features that enable activation of page elements via a variety of input devices. 10. Use interim solutions. Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly. Page 18

19. © Simeon Keates 2008 Web Content Authoring Guidelines (1.0) 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. 12. Provide context and orientation information. Provide context and orientation information to help users understand complex pages or elements. 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. 14. Ensure that documents are clear and simple. Page 19

20. © Simeon Keates 2008 Web Content Authoring Guidelines (1.0)  Each checkpoint has a priority level assigned by the Working Group based on the checkpoint's impact on accessibility.  [Priority 1] You must satisfy this checkpoint -otherwise, 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.  [Priority 2] You should satisfy this checkpoint. Otherwise, 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] You may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents. Page 20

21. © Simeon Keates 2008 Example Priority 1 checkpoints 1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). 2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup. 5.1 For data tables, identify row and column headers. 12.1 Title each frame to facilitate frame identification and navigation. 6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. 11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. Page 21

22. © Simeon Keates 2008 Example Priority 2 checkpoints 3.2 Create documents that validate to published formal grammars. 3.3 Use style sheets to control layout and presentation. 3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values. 3.5 Use header elements to convey document structure and use them according to specification. 3.6 Mark up lists and list items properly. 13.4 Use navigation mechanisms in a consistent manner. 5.3 Do not use tables for layout unless the table makes sense when linearized Page 22

23. © Simeon Keates 2008 Example Priority 3 checkpoints 4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs. 9.4 Create a logical tab order through links, form controls, and objects. 9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls. 13.5 Provide navigation bars to highlight and give access to the navigation mechanism. 4.3 Identify the primary natural language of a document. 13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. 13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc. Page 23

24. © Simeon Keates 2008 Web Content Authoring Guidelines 2.0  Web Content Accessibility Guidelines 1.0 was published in May 1999.  WCAG 2.0 was published on 11 December 2008.  WCAG 2.0 applies broadly to more advanced technologies; is easier to use and understand; and is more precisely testable with automated testing and human evaluation.  WCAG 2.0 focuses on 4 main areas: Perceivable Operable Understandable Robust Page 24 Perception Motor Cognition

25. © Simeon Keates 2008 Web Content Authoring Guidelines 2.0  Perceivable Provide text alternatives for non-text content. Provide captions and alternatives for audio and video content. Make content adaptable; and make it available to assistive technologies. Use sufficient contrast to make things easy to see and hear.  Operable Make all functionality keyboard accessible. Give users enough time to read and use content. Do not use content that causes seizures. Help users navigate and find content. Page 25

26. © Simeon Keates 2008 Web Content Authoring Guidelines 2.0  Understandable Make text readable and understandable. Make content appear and operate in predictable ways. Help users avoid and correct mistakes.  Robust Maximise compatibility with current and future technologies. Page 26

27. © Simeon Keates 2008 10 quick tips Page 27

28. © Simeon Keates 2008 10 quick tips (1-5) 1. Images & animations. Use the alt attribute to describe the function of each visual. 2. Image maps. Use the client-side map and text for hotspots. 3. Multimedia. Provide captioning and transcripts of audio, and descriptions of video. 4. Hypertext links. Use text that makes sense when read out of context. For example, avoid "click here.” 5. Page organization. Use headings, lists, and consistent structure. Use CSS for layout and style where possible. Page 28

29. © Simeon Keates 2008 10 quick tips (6-10) 6. Graphs & charts. Summarize or use the longdesc attribute. 7. Scripts, applets, & plug-ins. Provide alternative content in case active features are inaccessible or unsupported. 8. Frames. Use the noframes element and meaningful titles. 9. Tables. Make line-by-line reading sensible. Summarise. 10. Check your work. Validate. Use tools, checklist, and guidelines at http://www.w3.org/TR/WCAG Page 29

30. © Simeon Keates 2008 Exercise Page 30

31. © Simeon Keates 2008 Exercise – part 1  Last week you were asked to prepare a plan for testing the accessibility of your own site  This week…  …do it! Page 31

32. © Simeon Keates 2008 Exercise – part 2  Prepare a 5 minute presentation  Address the following questions: Did you consider accessibility issues when you designed the site? What was your testing plan? Which user capabilities did you test for (e.g. colour blindness)? What further tests do you think are necessary? With the knowledge of accessibility issues that you have gained, would you have designed the site differently if “accessibility” had been a stated design goal at the outset? If so, how? Page 32