Diverse user testing
Include diverse users early and often
Following WCAG and testing with diverse users before launch can result in unexpected additional costs
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
Labels
Following WCAG does not guarantee a website will be accessible
Diverse user testing often happens too late
Accessibility is still perceived as mainly technical – the developer’s problem
Content
The trinity of accessible web design
Design
Markup
• Relevant
• Non-jargon
• Concise
• Clear & accurate
• Summarised
• Rich media enhanced
• Intuitive
• Usable
• Attractive
• Relevant
• Legible
• Scaleable
• Standards compliant (W3C)
• Semantic or structured markup
• Progressive enhancement
Content
The three circles of information architecture
Users
Context
Diagram by http://semanticstudios.com/
Inclusive web design
Typical accessibility life cycle
1. Requirements (technical)2. Specifications (technical)3. Prototyping (technical build / some design
considerations)4. Testing – to WCAG guidelines5. Testing – with diverse users
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
Cost of diverse user testing at beta or live
Requirements DeploymentDevelopment
No. of changesCost
Accessibility
testing
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?”
Scenario: costly fixesThissite.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…
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.
Mega menus – diffi cult 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
Mega menus – diffi cult or impossible
• Voice recognition software users– Incompatible with assistive technology
• Users with a cognitive impairment– Mental overload, overwhelming
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
From web accessibility to universal web design
Integrate diverse users into mainstream UCD
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
10% of the UK population have an impairment
10% of every sample group and activity should reflect this
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
Impairment categories & range
• Vision– Blindness - mild vision
• Hearing– Deaf - mild hearing loss
• Motor– Paralysis / loss of limb - pain / discomfort
• Cognitive– Moderate learning difficulty - dyslexia
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
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
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
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
Planning
• Gathering user information and requirements should include diverse users
• Same activities as non-disabled usersAdditional 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
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
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
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
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
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