Diverse User Experience Presentation by Kath Moonan (Web Accessibility Expert) from Centre for HCID Open Day, April 21st, 2010 held at City University.

1. Diverse user testing

2. Include diverse users early and often Following WCAG and testing with diverse users before launch can result in unexpected additional costs

3. A note on language:Why diverse and not disabled? Many users with diverse needs do not classify themselves as disabled: Dyslexic users Deaf users Moderate impairments – mild vision, motor impairment Older users

4. Labels

5. Following WCAG does not guarantee a website will be accessible

6. Diverse user testing often happens too late

7. Accessibility is still perceived as mainly technical – the developer’s problem

9. Non-jargon

10. Concise

11. Clear & accurate

12. Summarised

13. Rich media enhanced

14. Intuitive

15. Usable

16. Attractive

17. Relevant

18. Legible

20. Semantic or structured markup

22. Typical accessibility life cycle Requirements (technical) Specifications (technical) Prototyping (technical build / some design considerations) Testing – to WCAG guidelines Testing – with diverse users

23. Benefits of diverse user testing Test usability and accessibility in the same test Test work flow and relevance Test beyond technical compliance Encourage and deepen engagement with diverse users and accessibility

24. Cost of diverse user testing at beta or live Cost No. of changes Accessibility testing Requirements Deployment Development

25. Disadvantages to testing at beta or live Fixes may now be prohibitively expensive No time to apply fixes Require drastic changes to site structure Due a perception that IA does not impact accessibility Require drastic changes to visual design Due a perception that graphic design doesn’t impact accessibility and that users know how to adjust their browsers Problems may come as an unpleasant surprise “we followed WCAG and tested for usability, what’s happening?”

26. Scenario: costly fixes Thissite.co.uk implement mega menus following accessibility and usability best practices. The site is tested for technical accessibility and usabilty tests are conducted with non-disabled users. Thissite are proud of their usable and accessible site until they have it tested with diverse users…

27. Mainstream users and mega menus Even Jakob Nielsen gives the thumbs up to mega menus “it takes a lot for me to recommend a new form of drop-down. But, as our testing videos show, mega drop-downs overcome the downsides of regular drop-downs. Thus, I can recommend one while warning against the other.” Nielsen, http://www.useit.com/alertbox/mega-dropdown-menus.html For accessibility Nielsen recommends using JS to filter keyboard users and provide navigation within the regular page.

29. Mega menus – difficult or impossible Keyboard only users Excessive tabbing to get to options Tiring and frustrating Screen reader users As above with the added difficulty of comprehending mental model of navigation Screen magnification software users Menu is very difficult to interact with when magnified

31. Mega menus – difficult or impossible Voice recognition software users Incompatible with assistive technology Users with a cognitive impairment Mental overload, overwhelming

32. Nielsen solution to mega menus Information architecture needs to be robust, accessible and easy to use If a standard usability testing does not include diverse users – the fallback solution will go untested Which is the primary way many people will interact with the website Result: A site which ticks the accessibility and (mainstream) usability boxes is inaccessible in practice and fixes are prohibitively expensive

33. From web accessibility to universal web design Integrate diverse users into mainstream UCD

34. Integrating accessibility Don’t leave accessibility to the developer EVERYONE is RESPONSIBLE Don’t assume WCAG = accessible website Ensure you have the right expertise Include diverse users as early and often as possible – integrate diversity into your workflow Vary participants - different needs and impairments

35. 10% of the UK population have an impairment 10% of every sample group and activity should reflect this

36. General points Accessibility does not just mean screen readers Avoid pigeon holing – people are individuals Many people have more than one condition Accessibility for type of impairment does not mean accessibility for all Ensure facilities are accessible – building and equipment Disability awareness – communication, language http://uiaccess.com/accessucd/interact.html

37. Impairment categories & range Vision Blindness - mild vision Hearing Deaf - mild hearing loss Motor Paralysis / loss of limb - pain / discomfort Cognitive Moderate learning difficulty - dyslexia

38. Additional expertise and equipment You may have an accessibility specialist in house Information in PAS 78, Just Ask and WebAim about working with diverse users Hire an accessibility expert to work with your team Focus rooms, testing lab need to be equipped with adjustable furniture, correct software Beware of Morae and assistive technologies Consider different versions of software, hardware considerations You may need a BSL interpreter

39. Integrating diverse users or diverse user test? Integration Little and often One is better than none (include as many users as possible) Any participant with an impairment that affects how they use the web Supplement with expert reviews and heuristic evaluations from other user groups Single, separate test One (possibly two) tests at end of development stage 6 – 10 participants from different categories of impairment Test participants represent as broad a range as possible Often happens in isolation from other UCD activities

40. Working with diverse users – recruitment Existing – you may be already working with diverse users Find out about mild impairments in all screening – dyslexia, mild vision, hearing, motor, colour blindness Specialist recruitment Finding diverse users – disability groups and organisations, recruitment agencies Ensure participants fit with other user profiles Agencies Need guidance on recruiting users with additional needs Range or severity of disability Knowledge / use of assistive technology

41. Recruitment – potential barriers Hard to identify the right point of contact (with time to help) in a charity or organisation Persistence, long term relationships, posters and information May be much more difficult for participant to travel – prohibitive Additional budget / taxis / parking Go to the participant Unwillingness to be a “guinea pig” (medical model of disability) Long term relationships, engagement in the process, word of mouth

42. Planning Gathering user information and requirements should include diverse users Same activities as non-disabled users Additional information Find out about the accessibility issues they face and how they overcome challenges Competitor analysis User solutions based on access need Scenarios that use personas with disabilities

43. Personas Same information as non-disabled personas Information about impairment Impact on computer use Experience of assistive technology Create personas based on interviews and research Adapt sample personas http://www.w3.org/WAI/redesign/personas http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/#usage

44. Development – implementing accessibility Avoid: Too much accessibility Over-complex solutions Thoroughly testing fallback solutions Incremental evaluation of prototypes, designs, HTML protoypes Personas, expert review, holistic approach

45. Testing - recruitment Conduct expert reviews, heuristic evaluations and walk throughs If there is more than one cycle of testing vary participant types Focus on target users (but don’t ignore others) Focus on high impact

46. Testing considerations Evaluator should be experienced in working with people with disabilities Adjusting room and equipment for participants needs Allow more time for screen reader users (generally) Setting goals and benchmarks Knowing when to stop – frustration, barriers, losing confidence After the test Don’t allow participants to leave with low confidence Explain what the issues were – what you will do to help fix them Antonia Hyde tells participants what the right answers are Share knowledge

47. Conclusions Incorporate accessibility into existing UCD Involve EVERYONE It is possible to conduct testing in-house Work collaboratively with accessibility experts Read Design Meets Disability – Graham Pullin Just Ask – Shawn Henry

48. Thanks Kath.moonan@googlemail.com Twitter: ladymoonan