Usability and Accessibility Lecture 7 – 09/03/10

© Simeon Keates 2010

Usability and AccessibilityLecture 7 – 09/03/10Dr. Simeon Keates


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)

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 2


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 3

Answer: Performs same checks. Output more visual (and usable).

Answer: No(?). Some groups said “Yes!”


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 4

Have all groups done this?

Note: need for valid HTML/XML version before sites can be fully tested with screen reader software, etc.


Quantifying exclusion

Page 5


How are people excluded?

For example, dexterity:

• can pick up items, turn handles and control switches with one hand but not the other

• has severe difficulty utilising products (i.e.: picking and pouring a full kettle)

• cannot pick up a cup or turn a handle with either hand

Page 6


Users Capabilities

Physical Attributes

Information requirements

Ergonomic Features

Page 7


Information available

For capabilities:

Great Britain Follow-up Survey (Grundy et al., 1999)

Thirteen capability scales ranging from

• 0 (fully able) through

• 0.5 (minimal impairment) to

• 12.5 (most severe impairment)

Page 8


Typical capability scale

Page 9


Disability score

• Weighted disability score = worst

+ 0.4 second worst

+ 0.3 third worst

• Score then mapped to a ten point severity category

Page 10


Severity category

Page 11


For physical attributes:

Adult data (Peebles and Norris, 1998)

Older adult data (Smith et al., 2000)

Information available

Page 12


A three level approach:

Review the ideal product

Review the requirements

Review the actual product

Product assessment

Page 13


A four-step review process:

Specify the context of use

Assess physical attributes

Assess capability demands

Eliminate multiple counting

Product assessment

Page 14


A case study - the kettle

(a) An early kettle (b) Corded kettle (c) Cordless kettle

Page 15


Consider the following example:

The ideal product demands no more than drinking from a cup

The actual product is a metal cordless kettle

The requirements suggest a lighter, smaller kettle is possible

A case study - a kettle

Page 16


In this case it will be assumed that:

The kettle will be positioned to suit the height and mobility of the user

The actions required will be to fill the kettle with water, switch it on and to pour the boiling water into a cup

Specify the context of use

Page 17


In this case it may be assumed that:

Hand and finger size have no significant impact on the users’ ability to use the products

Assess physical attributes

Page 18


Assess capability demands

Page 19



-2

0

2

4

6

8

10

-2 0 2 4 6 8 10Sensory Capability

Mot

ion

Cap

abili

ty

Scale:

1m

Full Capability

Page 20



-2

0

2

4

6

8

10


Mot

ion

Cap

abili

ty

Scale:

1m

Full Capability

Product

demands

Page 21



-2

0

2

4

6

8

10


Mot

ion

Cap

abili

ty

Scale:

1m

Full Capability

Product

demands

Page 22


Assessment summary

Page 23


Why quantify?

• A better product is a more inclusive product

• Or a more inclusive product is a better product?

• Hence managers and designers need be able to evaluate the inclusive merit of their products

Summary

Page 24


• We can quantify exclusion

• We can identify sources of exclusion

• Thus, we can counter exclusion

Summary

Page 25


• Q - The death of “inclusive” design?

– Is it possible to design to ‘include’ users?

• Q - What level of exclusion is reasonable or acceptable?

• Q - Cannot or will not?

Some questions to ponder...

Page 26


Putting accessibility into the design process

Page 27


Designing for accessibility - Key features

It is imperative that the user wants and needs for the product are identified accurately

Designing for accessibility relies on the ability to identify potential accessibility difficulties with a product

Those difficulties need to be prioritized and then fixed or removed

Page 28


Designing for accessibility - Reactivity or proactivity?

Reactivity - retrospective design consideration

Proactivity - designed for accessibility

• cheap

• perceived to be easiest

• not particularly effective

• accessible products

• perceived to be expensive/difficult

• can be very effective - if done correctly

Page 29


Designing for accessibility - Identifying causes of exclusion

User observation• “Gold” standard, but potentially pricey

Self assessment• Fast, cheap, highly variable

Expert assessment• Depends on the expert

Simulation• More repeatable than self-assessment• Can all impairments be simulated?

Page 30


Designing for accessibility - Remedying causes of exclusion

Can this feature be removed?• Do we need it?

Can this feature be changed to make it more accessible?• Can we make it bigger?

Can a complementary method of offering the functionality be added?• Can we add a second button?

Can the functionality be offered in an alternative way?• Does it have to be a button? Can it be a slider?

Can an auxiliary aid (or assistive technology) be offered to supplement to feature?• Can we persuade the user to buy another bit of kit to use this product?

Page 31


Level 1 - Problem requirements

Defining the problem Original design or review? Identify user wants

Example tools Engineering Requirements Capture techniques Usability analyses of existing designs Talking to people (e.g. users, design commissioners) Sociological models

Page 32


Level 2 - Problem specification

Defining the functions What should this product do?

Example approaches Workflows Task diagrams, etc.

Page 33


Level 3 - Output to user

Output mechanics of system Nature of output (e.g. aural, visual) Output media (e.g. screens, speakers) Anthropometrics / ergonomics User sensory capabilities Environment

Example tools Anthropometric/ergonomic data sets Population capability data

Page 34


Level 4 - User mental model

Mapping system behaviour to user expectations Content Structure Order of interaction User mental model User cognitive capabilities

Example tools Cognitive walkthrough Questionnaires / interviewing

Page 35


Level 5 - Input from user

Allowing the user to control the system Nature of input (e.g. analogue, text) Input media (e.g. keyboard, mouse, buttons) Ergonomics / anthropometrics User motor capabilities

Example tools User performance trials User models (e.g. Fitts’ Law, MHP)

Page 36


Level 6 - Functional attributes

Verify and validate functionality Does the system offer the required functionality? Is the system practically acceptable to the users?

Example tools Formal usability analyses & user trials Discount analyses (e.g. heuristic evaluation) Questionnaires / interviews

Page 37


Level 7 - Social attributes

Verify and validate match to user wants and aspirations Is the system socially acceptable to the users? Does the user want to use it?

Example tools Formal usability analyses & user trials Questionnaires / interviews

Page 38


7 level model - summary

Level 1 - Problem requirements Level 2 - Problem specification

Level 3 - Output to user Level 4 - User mental model Level 5 - Input from user

Level 6 - Functional attributes Level 7 - Social attributes

Page 39


Universal Access and Royal Mail

1 in 7 Royal Mail customers “disabled”

Must comply with DDA...

… and lead by example

Page 40


Case study - The Personal Information Point

Page 41


Applying the 7 level approach to the PIP

Level 1 -

Level 2 -

Level 3 -

Level 4 -

Level 5 -

Level 6 -

Level 7 -

What are the system requirements?

How does the user receive information from the PIP?

Does the user understand what is happening/required?

How does the user enter information?

Does the PIP meet the functionality needs?

What is the aim of the PIP?

Does the PIP meet the stated aim?

Page 42


LEVEL 1 - System aims

Objectives Introduce Royal Mail customers to technology Pathfinder for future ‘kiosks’

Users

• Typical Royal Mail customers

Design suggestions• Aims need to be more clearly defined

Page 43


LEVEL 2 - System requirements

Objectives

Not really defined!!! Reduce queue length Improve customer service DDA compliant

Users

• Typical Royal Mail customers

Design suggestions•Tasks and functionality need to be specified

Page 44


LEVEL 3 - User output

Concept system Visual video footage - LCD screen Audio soundtrack - telephone handset

Assessment• Screen too high and not adjustable ?• Audio output not duplicated ?• Visual output not duplicated ?

Page 45


Screen too high…

Page 46


Screen too high

Female population (16+) = 24,125,000 Female population (65+) = 5,475,000

% excluded (16+) = 25% % excluded (65+) = 50%

Total excluded (16+) ≈ 6,000,000 Total excluded (65+) ≈ 2,700,000

Page 47


Output not duplicated

Hearing: “Difficulty following a conversation against background noise”

(16+) = 1,922,000 (65+) = 1,232,000

Vision: “Has difficulty seeing to read ordinary newspaper print”

(16+) = 1,313,000 (65+) = 871,000

Page 48


LEVEL 3 - User output

Concept system Visual video footage - LCD screen Audio soundtrack - telephone handset

Assessment• Screen too high and not adjustable -• Audio output not duplicated -• Visual output not duplicated -

6,000,000

1,900,000

1,300,000

Design suggestions• Lower screen with adjustable angle• Information channel duplication

Page 49


LEVEL 4 - User understanding

Concept system No content at time of assessment However, planned to have National Savings products

Assessment• Not possible for this level• However, review your earlier exercise on this…

Design suggestions• Use another product for this!

Page 50


LEVEL 5 - User input

Concept system 6 buttons - high position No support for user

Assessment• Need to stand ?• Reaching and dexterity ?

Page 51


Input exclusions

Need to stand: “Often needs to hold on to something to keep balance”

(16+) = 3,145,000 (65+) = 1,621,000

Page 52


Input exclusions

Reach and Stretch “Cannot hold one arm out in front or up to head (but can with other

arm)”

(16+) = 1,072,000 (65+) = 579,000

Dexterity “Can turn a tap or control knob with one hand but not with the other…”

(16+) = 2,921,000 (65+) = 1,451,000

Page 53


LEVEL 5 - User input

Concept system 6 buttons - high position No support for user

Assessment• Need to stand -• Reaching and dexterity -

3,145,0004,000,000

Design suggestions• Offer physical support• Reduce reach and stretch requirements

Page 54


LEVELS 6+7 - Evaluations

Total exclusions: (16+) = 5,661,000 (capability) + 6,000,000 (anthropometrics)

= 11,661,000 (out of 46,900,000)

= 24.8%

(65+) = 2,953,000 (capability) + 2,700,000 (anthropometrics)

= 5,653,000 (out of 9,273,000)

= 61.0%

Problem: Are we double counting???

Page 55


Better calculations

We do not know how the anthropometric and capability exclusions are related• From different data sets

But we can make a simple correction We need to assume that the distributions are independent…

Page 56


Better calculations

Imagine 2 random variables…

p(Type A) = 1 in 3 (i.e. ⅓) p(Type B) = 1 in 4 (i.e. ¼)

p(Type A and Type B) = p(Type A) × p(Type B)

= ⅓ × ¼

= 1 / 12 (i.e. 8.3%)

Page 57


Better calculations – 16+

p(Excluded by capability) = 5.661,000 / 46,900,000

= 0.121 p(Excluded by anthropometrics) = 6,000,000 / 46,900,000

= 0.128 p(Excluded by both) = 0.121 × 0.128

= 0.015

p(Excluded) = p(Excluded by capability) +

p(Excluded by anthropometrics) –

p(Excluded by both)

= 0.121 + 0.128 – 0.015

= 0.234 (i.e. 23.4% or 10,975,000 people)

Page 58


Better calculations – 65+

p(Excluded by capability) = 2,953,000 / 9,273,000

= 0.318 p(Excluded by anthropometrics) = 2,700,000 / 9.273,000

= 0.291 p(Excluded by both) = 0.318 × 0.291

= 0.093

p(Excluded) = p(Excluded by capability) +

p(Excluded by anthropometrics) –

p(Excluded by both)

= 0.318 + 0.291 – 0.093

= 0.516 (i.e. 51.6% or 4,780,000 people)

Page 59


LEVELS 6+7 - Evaluations

Level 2population coverage

Level 4

populationcoverage

Level 3

Population coverage

Current design

User-awaredesign

Needing assistance

Estimatedlower bound

Estimatedupper bound

Page 60


Summary

23.4% of all UK adults could not use the concept PIP 51.6% of “target” adults (65+) could not use the PIP Results verified by RNIB

Use of the 7 Level Model:

• Highlighted the deficiencies in a systematic manner• Generated design revision suggestions• Encouraged Royal Mail to insist on better accessibility for the PIP

Page 61


Designing for Web accessibility

Page 62


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 63


How the components relate…

Page 64


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 65


The implementation cycle (in pictures)

Page 66


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 67



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 68



Page 69


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 70


Guidelines for different components

Page 71


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 72



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 73



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 74



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 75



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 76


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 77



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 78



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 79


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 80

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 81



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 82


10 quick tips

Page 83


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 84


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 85


Exercise

Page 86


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 87


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 88

Documents

Usability and Accessibility Lecture 7 – 09/03/10