Diverse User Experience by Kath Moonan

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

Thanks

[email protected]

Twitter: ladymoonan