Diverse user testing<br />
Include diverse users early and often <br />Following WCAG and testing with diverse users before launch can result in unex...
A note on language:Why diverse and not disabled?<br />Many users with diverse needs do not classify themselves as disabled...
Labels<br />
Following WCAG does not guarantee a website will be accessible<br />
Diverse user testing often happens too late<br />
Accessibility is still perceived as mainly technical – the developer’s problem<br />
Content<br />The trinity of accessible web design<br />Design<br /><ul><li> Relevant
 Non-jargon
 Concise
 Clear & accurate
 Summarised
 Rich media enhanced
 Intuitive
 Usable
 Attractive
 Relevant
 Legible
 Scaleable</li></ul>Markup<br /><ul><li> Standards compliant (W3C)
 Semantic or structured markup
 Progressive enhancement </li></li></ul><li>Content<br />The three circles of information architecture<br />Users<br />Con...
Typical accessibility life cycle<br />Requirements (technical)<br />Specifications (technical)<br />Prototyping (technical...
Benefits of diverse user testing<br />Test usability and accessibility in the same test<br />Test work flow and relevance ...
Cost of diverse user testing at beta or live<br />Cost<br />No. of changes<br />Accessibility<br />testing<br />Requiremen...
Disadvantages to testing at beta or live<br />Fixes may now be prohibitively expensive<br />No time to apply fixes<br />Re...
Scenario: costly fixes<br />Thissite.co.uk implement mega menus following accessibility and usability best practices.<br /...
Mainstream users and mega menus<br />Even Jakob Nielsen gives the thumbs up to mega menus<br />	“it takes a lot for me to ...
Mega menus – difficult or impossible<br />Keyboard only users<br />Excessive tabbing to get to options<br />Tiring and fru...
Mega menus – difficult or impossible<br />Voice recognition software users<br />Incompatible with assistive technology<br ...
Nielsen solution to mega menus<br />Information architecture needs to be robust, accessible and easy to use<br />If a stan...
From web accessibility to universal web design<br />Integrate diverse users into mainstream UCD <br />
Integrating accessibility<br />Don’t leave accessibility to the developer<br />EVERYONE is RESPONSIBLE<br />Don’t assume W...
10% of the UK population have an impairment<br />10% of every sample group and activity should reflect this<br />
General points<br />Accessibility does not just mean screen readers<br />Avoid pigeon holing – people are individuals<br /...
Upcoming SlideShare
Loading in …5
×

Diverse User Experience by Kath Moonan

1,288 views

Published on

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

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,288
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Diverse User Experience by Kath Moonan

  1. 1. Diverse user testing<br />
  2. 2. Include diverse users early and often <br />Following WCAG and testing with diverse users before launch can result in unexpected additional costs<br />
  3. 3. A note on language:Why diverse and not disabled?<br />Many users with diverse needs do not classify themselves as disabled:<br />Dyslexic users<br />Deaf users<br />Moderate impairments – mild vision, motor impairment<br />Older users<br />
  4. 4. Labels<br />
  5. 5. Following WCAG does not guarantee a website will be accessible<br />
  6. 6. Diverse user testing often happens too late<br />
  7. 7. Accessibility is still perceived as mainly technical – the developer’s problem<br />
  8. 8. Content<br />The trinity of accessible web design<br />Design<br /><ul><li> Relevant
  9. 9. Non-jargon
  10. 10. Concise
  11. 11. Clear & accurate
  12. 12. Summarised
  13. 13. Rich media enhanced
  14. 14. Intuitive
  15. 15. Usable
  16. 16. Attractive
  17. 17. Relevant
  18. 18. Legible
  19. 19. Scaleable</li></ul>Markup<br /><ul><li> Standards compliant (W3C)
  20. 20. Semantic or structured markup
  21. 21. Progressive enhancement </li></li></ul><li>Content<br />The three circles of information architecture<br />Users<br />Context<br />Inclusive web design<br />Diagram by http://semanticstudios.com/<br />
  22. 22. Typical accessibility life cycle<br />Requirements (technical)<br />Specifications (technical)<br />Prototyping (technical build / some design considerations)<br />Testing – to WCAG guidelines<br />Testing – with diverse users<br />
  23. 23. Benefits of diverse user testing<br />Test usability and accessibility in the same test<br />Test work flow and relevance <br />Test beyond technical compliance<br />Encourage and deepen engagement with diverse users and accessibility<br />
  24. 24. Cost of diverse user testing at beta or live<br />Cost<br />No. of changes<br />Accessibility<br />testing<br />Requirements<br />Deployment<br />Development<br />
  25. 25. Disadvantages to testing at beta or live<br />Fixes may now be prohibitively expensive<br />No time to apply fixes<br />Require drastic changes to site structure<br />Due a perception that IA does not impact accessibility<br />Require drastic changes to visual design<br />Due a perception that graphic design doesn’t impact accessibility and that users know how to adjust their browsers<br />Problems may come as an unpleasant surprise<br />“we followed WCAG and tested for usability, what’s happening?”<br />
  26. 26. Scenario: costly fixes<br />Thissite.co.uk implement mega menus following accessibility and usability best practices.<br />The site is tested for technical accessibility and usabilty tests are conducted with non-disabled users.<br />Thissite are proud of their usable and accessible site until they have it tested with diverse users…<br />
  27. 27. Mainstream users and mega menus<br />Even Jakob Nielsen gives the thumbs up to mega menus<br /> “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.”<br />Nielsen, http://www.useit.com/alertbox/mega-dropdown-menus.html<br />For accessibility Nielsen recommends using JS to filter keyboard users and provide navigation within the regular page. <br />
  28. 28.
  29. 29. Mega menus – difficult or impossible<br />Keyboard only users<br />Excessive tabbing to get to options<br />Tiring and frustrating<br />Screen reader users<br />As above with the added difficulty of comprehending mental model of navigation<br />Screen magnification software users <br />Menu is very difficult to interact with when magnified<br />
  30. 30.
  31. 31. Mega menus – difficult or impossible<br />Voice recognition software users<br />Incompatible with assistive technology<br />Users with a cognitive impairment<br />Mental overload, overwhelming<br />
  32. 32. Nielsen solution to mega menus<br />Information architecture needs to be robust, accessible and easy to use<br />If a standard usability testing does not include diverse users – the fallback solution will go untested<br />Which is the primary way many people will interact with the website<br />Result: A site which ticks the accessibility and (mainstream) usability boxes is inaccessible in practice and fixes are prohibitively expensive<br />
  33. 33. From web accessibility to universal web design<br />Integrate diverse users into mainstream UCD <br />
  34. 34. Integrating accessibility<br />Don’t leave accessibility to the developer<br />EVERYONE is RESPONSIBLE<br />Don’t assume WCAG = accessible website<br />Ensure you have the right expertise<br />Include diverse users as early and often as possible – integrate diversity into your workflow<br />Vary participants - different needs and impairments <br />
  35. 35. 10% of the UK population have an impairment<br />10% of every sample group and activity should reflect this<br />
  36. 36. General points<br />Accessibility does not just mean screen readers<br />Avoid pigeon holing – people are individuals<br />Many people have more than one condition<br />Accessibility for type of impairment does not mean accessibility for all<br />Ensure facilities are accessible – building and equipment<br />Disability awareness – communication, language<br />http://uiaccess.com/accessucd/interact.html<br />
  37. 37. Impairment categories & range<br />Vision<br />Blindness - mild vision<br />Hearing<br />Deaf - mild hearing loss<br />Motor<br />Paralysis / loss of limb - pain / discomfort<br />Cognitive<br />Moderate learning difficulty - dyslexia<br />
  38. 38. Additional expertise and equipment<br />You may have an accessibility specialist in house<br />Information in PAS 78, Just Ask and WebAim about working with diverse users<br />Hire an accessibility expert to work with your team<br />Focus rooms, testing lab need to be equipped with adjustable furniture, correct software<br />Beware of Morae and assistive technologies<br />Consider different versions of software, hardware considerations <br />You may need a BSL interpreter<br />
  39. 39. Integrating diverse users or diverse user test? <br />Integration<br />Little and often<br />One is better than none (include as many users as possible)<br />Any participant with an impairment that affects how they use the web<br />Supplement with expert reviews and heuristic evaluations from other user groups<br />Single, separate test<br />One (possibly two) tests at end of development stage<br />6 – 10 participants from different categories of impairment<br />Test participants represent as broad a range as possible<br />Often happens in isolation from other UCD activities<br />
  40. 40. Working with diverse users – recruitment<br />Existing – you may be already working with diverse users<br />Find out about mild impairments in all screening – dyslexia, mild vision, hearing, motor, colour blindness<br />Specialist recruitment<br />Finding diverse users – disability groups and organisations, recruitment agencies<br />Ensure participants fit with other user profiles<br />Agencies<br />Need guidance on recruiting users with additional needs<br />Range or severity of disability<br />Knowledge / use of assistive technology <br />
  41. 41. Recruitment – potential barriers<br />Hard to identify the right point of contact (with time to help) in a charity or organisation<br />Persistence, long term relationships, posters and information<br />May be much more difficult for participant to travel – prohibitive<br />Additional budget / taxis / parking<br />Go to the participant<br />Unwillingness to be a “guinea pig” (medical model of disability)<br />Long term relationships, engagement in the process, word of mouth<br />
  42. 42. Planning<br />Gathering user information and requirements should include diverse users<br />Same activities as non-disabled users<br />Additional information<br />Find out about the accessibility issues they face and how they overcome challenges<br />Competitor analysis<br />User solutions based on access need<br />Scenarios that use personas with disabilities<br />
  43. 43. Personas<br />Same information as non-disabled personas<br />Information about impairment<br />Impact on computer use<br />Experience of assistive technology<br />Create personas based on interviews and research<br />Adapt sample personas <br />http://www.w3.org/WAI/redesign/personas<br />http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/#usage<br />
  44. 44. Development – implementing accessibility<br />Avoid:<br />Too much accessibility<br />Over-complex solutions<br />Thoroughly testing fallback solutions<br />Incremental evaluation of prototypes, designs, HTML protoypes<br />Personas, expert review, holistic approach <br />
  45. 45. Testing - recruitment<br />Conduct expert reviews, heuristic evaluations and walk throughs<br />If there is more than one cycle of testing vary participant types<br />Focus on target users (but don’t ignore others)<br />Focus on high impact<br />
  46. 46. Testing considerations<br />Evaluator should be experienced in working with people with disabilities<br />Adjusting room and equipment for participants needs<br />Allow more time for screen reader users (generally)<br />Setting goals and benchmarks<br />Knowing when to stop – frustration, barriers, losing confidence<br />After the test<br />Don’t allow participants to leave with low confidence<br />Explain what the issues were – what you will do to help fix them<br />Antonia Hyde tells participants what the right answers are<br />Share knowledge<br />
  47. 47. Conclusions<br />Incorporate accessibility into existing UCD<br />Involve EVERYONE<br />It is possible to conduct testing in-house<br />Work collaboratively with accessibility experts<br />Read<br />Design Meets Disability – Graham Pullin<br />Just Ask – Shawn Henry<br />
  48. 48. Thanks<br />Kath.moonan@googlemail.com<br />Twitter: ladymoonan<br />

×