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

© Simeon Keates 2008

Usability with ProjectLecture 7 – 30/09/09Dr. Simeon Keates


And now for something (not quite) completely different

Guest lecturer: Peter Olaf Looms

Page 2


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 site

Page 3


Exercise – part 2

Question: How does Wave compare with CynthiaSays?

Now try the Vischeck colour simulator (http://www.vischeck.com/vischeck) on the same sites

And then try a screen reader (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(?)


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.


Designing for Web accessibility

Page 6


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


How the components relate…

Page 8


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


The implementation cycle (in pictures)

Page 10


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



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



Page 13


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


Guidelines for different components

Page 15


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



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



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



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



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


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



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



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


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



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



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


10 quick tips

Page 27


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


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


Exercise

Page 30


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


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

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

Documents

simeon keates slide

web page

web accessibility page

web browsers

news sites

accessibility feature

web developers designers

web application