Beyond the Guidelines: Assessment of usability and accessibility from the users’ perspective.

1. Jenny Craven, CERLIM, Manchester Metropolitan University j.craven@mmu.ac.uk Beyond the Guidelines:Assessment of usability and accessibility from the users’ perspective.

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

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. 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. Practical Nielsen: 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. Selection of participants

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 Findings Problems: • 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?

24. Frequency of checkpoints identified

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