1

Beyond the Guidelines: Assessment of usability and accessibility

from the users’ perspective.

Jenny Craven, CERLIM, Manchester Metropolitan University

j.craven@mmu.ac.uk

2

Accessibility and Usability

• Accessibility - the capability of a system to cater for the needs of disabled people.

• Usability - the capability of a system to behave in a way which most closely accords with human behaviour.

Carey (2005), Accessibility: The Current Situation and New Directions: www.ariadne.ac.uk/issue44/carey/intro.html

3

World Wide Web Consortium

W3C

WAI

UAAG WCAGATAG

4

World Wide Web Consortium (W3C)

• Web Accessibility Initiative (WAI) Web Content Accessibility Guidelines (WCAG) Priority Levels:– Priority One: A web content developer MUST

satisfy this checkpoint.– Priority Two: A web content developer SHOULD

satisfy this checkpoint.– Priority Three: A web content developer MAY

address this checkpoint.“…otherwise one or more groups will find it

somewhat difficult to access information in the document…”

www.w3.org/TR/WCAG10/

5

Accessible web design (taken from WAI Quick Tips)

• Use ALT attribute for images and animations.

• Use client-side MAP and text for hotspots.

• Provide captioning and transcripts of audio and descriptions of video.

• For Hypertext links, use text that makes sense when read out of context.

6

Accessible web design (taken from WAI Quick Tips)

• Use headings, lists and consistent structure. Use CSS for layout and style where possible.

• Summarize or use the longdesc attribute for graphs and charts

• Provide alternative content for scripts, applets and plug-ins.

• Use NOFRAMES and meaningful titles• Make line by line reading of tables sensible.• Use tools, checklist and guidelines to check

and validate work.

7

Why users are important

• Help identify what users really want from an accessible web – beyond Quick Tips.

• Can identify things automated tools cannot, or may miss – accessibility/usability conflicts.

• May have a non-technical approach to using the Web which designers could overlook.

• Help to demonstrate WHY websites need to be accessible (not just how to do it).

• Help provide a broader view of accessibility.

8

Potential problems for different users

• Users with limited access:– Low bandwidth.– Text only access.– Small screen.– Public access only (can’t personalise).

• Users with language differences:– English not first language.– Using a site which adopts complex/ambiguous

language (e.g. legal).– Limited reading skills.

9

Potential problems for different users• Visually impaired users:

– No/poor text alternatives for graphics and/or multimedia.– Colour is used for navigation (press red button).– Inability to adjust colours, fonts etc.– Link text does not make sense out of context.– Information flow is not meaningful.– No keyboard navigation.

• Hearing impaired users:– No captions or audio descriptions.– Limited reading skills.

• Cognitive problems:– Inconsistent navigational aids.– Complex/ambiguous language.– Ambiguous descriptions.

• Physically impaired users:– No keyboard navigation.– Does not provide keyboard shortcuts.– Tab order is not logical.

10

The EIAO project is co-funded by the European Commission, under the IST contract 2003-004526-STREP.

11

The European Internet Accessibility Observatory

• A technical basis for a European Internet Accessibility Observatory (EIAO) consisting of: A set of web accessibility metrics; An Internet robot for automatically and frequent collecting data on web accessibility and deviations from web standards ( the WAI guidelines); A data warehouse providing online access to collected accessibility data.

• The collection of web accessibility metrics and the tools for automated data collection and dissemination will be continuously improved by feedback from end users and user testing to sharpen the relevance of the automatically collected data.

12

Objectives of user requirements assessment

• Identification of accessibility problems they had experienced.

• Ranking of specific accessibility problems (minor, serious).

• Which web sites or elements of a site they felt excluded from.

• What improvements they would like.• Any other issues not yet covered.

13

Methods for conducting user requirements assessment

• Selection and recruitment of participants: contacts, RNIB Research Database; FAST User Forum; MMU Learning Resource Unit; Disability Groups.

• Quantitative data gathering: Questionnaires – online, email, Word.

• Qualitative data gathering: follow-up interviews – phone, email.

14

Selection of participants• Ideal

– A mix of novice and expert users

– Different age groups– Different ethnic

minorities– Range of disabilities– People who use a

variety of assistive technologies.

– People who need to make screen adjustments.

• PracticalNielsen:

– As little as 5 users.– Ideally around 15

users.DRC Study:

– People with visual disabilities will identify most potential accessibility barriers.

– People using screen reading technology and screen magnification.

15

EIAO user requirements participants

• Visually impaired.• Hearing impaired.• Physically impaired.• Learning/literacy difficulties.• Users of alternative devices such

as PDAs or mobile phones.• English not first language.

16

EIAO FindingsProblems:• Keyboard access (shortcut keys, tab

navigation and/or keyboard navigation).• Lack of ALT text or poor use of ALT text.• Problems relating to the organisation of

the page.• Inability to navigate the site.• Poor use of Titles mark-up for web pages.

17

EIAO Findings

Problems:• Confusing use of language such as

acronyms and abbreviations.• Problems using multimedia.• Slow download times and having to

download software.• Inability to personalise pages.

18

EIAO Findings

Excluded from:• Images.• Multimedia (e.g. FLASH).• Forms (in particular, complex forms).

19

EIAO Findings

Improvements:• Organisation of the page or site.• Use of correct mark-up such as titles.• Keyboard navigation.• Use of appropriate ALT tags.

20

ALT text comments“No excuse for graphics just for the sake of it,

when not needed – a library catalogue does not need to use graphics to attract people to use their catalogue pages.”

“Inappropriate ALT text - Customer Services telephone number displayed as a graphic with the ALT text as " Customer Services telephone number"!”

21

Page navigation comments

“Pages sometimes are too big so that you have to keep scrolling down and down.”

“Navigation is a problem when using the in-built magnification because you can only view about 2 lines at a time.”

“Not always confident using skip nav. Worried I may miss information.”

22

Other comments“Keywords and use of combo boxes to select

terms are difficult to get right, often get 'no results found' because you have missed out a step of the search process.”

“Terms used are not always consistent with the print version, e.g. tried to search online for something that was in a catalogue using the same terms used in the print version, but found different terms were used in the online version.”

“Don't always understand why some result have been returned, seem to bear no relation to the terms you used and what you are looking for.”

23

How do these findings relate to the W3C Guidelines?

Relevance to WCAG

0

1

2

3

4

5

6

7

KeyboardNav

ALT Text Page Org Site Nav Mark-up

Problems identified

Ch

eck

po

ints

ide

nti

fie

d

Priority 1

Priority 2

Priority 3

24

Frequency of checkpoints identified

WCAG Checkpoints identified

Priority One

Priority Two

Priority Three

25

Summary of user requirements assessment.

• Guidelines provide technical advice and solutions….

• But, different users have different requirements and often a different focus.

• User assessment helps to consider other people’s situations and perspectives.

• This helps web designers and web managers consider the broader picture….

• This can help inform and justify decisions which help make websites more accessible.

26

Ways to involve users:• Ask staff in your organisation to form a user

group for ad-hoc feedback on developments.• Always provide a mechanism for feedback on

your web site.• Include user testing costs in your web

development budgets so you can pay staff or enlist users.

• Participate in online discussion groups.• Contact existing forums and users groups e.g

ISdAC (but be prepared to pay for their time).

27

Further reading:• Craven, J. and Snaprud, M. (2005). Involving users in the

development of a web accessibility tool. Ariadne Issue 44 <www.ariadne.ac.uk/issue44/craven/intro.html>

• Disability Rights Commission (DRC) (2004). The Web: Access and Inclusion for Disabled people. A formal Investigation conducted by the Disability Rights Commission, London: DRC.

• ISdAC: http://www.isdac.org/en/index.php• Krug, S. (2000). Don't make me think!: a common sense

approach to web usability. Indiana: New Riders. • Nielsen, J. (2000). Why you only need to test with 5 users.

Alertbox, March 19.• Weisen et al (2005). Web accessibility revealed: the Museums,

Libraries and Archives Council Audit. Ariadne Issue 44 <www.ariadne.ac.uk/issue44/petrie-weisen/intro.html>.

• EIAO project website: www.eiao.net• EIAO via CERLIM website:

www.cerlim.ac.uk/projects/eiao/index.php