The document discusses how BS 8878 helps organizations embed accessibility and digital inclusion. It presents the business case for accessibility and provides guidance on how to strategically embed accessibility within an organization. It outlines a process for identifying key decisions that impact accessibility throughout a web product's lifecycle and recommends documenting these decisions to ensure best practices. The standard helps organizations consider inclusive design, target audiences, delivery platforms, and assurance testing to launch products that meet accessibility needs.

1. © hassellinclusion
How BS 8878 brings together
usability accessibility
Prof Jonathan Hassell
Director, Hassell Inclusion ltd.
Chair, BSI IST/45
Camp Digital Manchester
29th March 2012
hassellinclusion

2. © hassellinclusion
Thinking of Accessibility as Compliance with Standards…
… gets rid of some of your legal and reputational risks

3. © hassellinclusion
But it’s not the key to your success…
And, without thinking of the people you’re trying to help,
it’s not exactly exciting…

4. © hassellinclusion
And for a lot of people it feels like this…

5. © hassellinclusion
Listening to your diverse audiences need’s…
identifies challenges…
but innovation often follows a challenge

6. © hassellinclusion
IST/45 view: what accessibility really should be…
• all about disabled people
• aim shouldn’t be accessibility… or even usability…
but a great user experience for disabled and elderly people
• whether they can get the right value out of what you create
• exactly what you aim for, for every other audience
• you don’t want to exclude 10m+ people from using your products…
• so why don’t more organisations do it?

7. © hassellinclusion
How does BS8878 help?
– presents the business-case for accessibility and digital inclusion
– gives advice for how to embed accessibility strategically within an organisation
– shows a process which identifies the key decisions
which are taken in a web product’s lifecycle which impact accessibility
– recommends an informed way of making these decisions…
– and a way of documenting all of this to ensure best practice
Organizational
Web
Accessibility
Policy
Web
Product
Accessibility
Policy
Web
Product
Accessibility
Statement

8. © hassellinclusion
The accessibility of your web products
is in all these people’s hands…
Designers Writers
Project Mgrs Product Mgrs
Finance Legal Marketing Strategy
Snr Mgrs
Research TestersDevelopers

9. © hassellinclusion
Embedding motivation
Designers Writers
Project Mgrs Product Mgrs
Finance Legal
Snr Mgrs
Research TestersDevelopers
• Need to motivate each
group…
• Or just use a business
case for the top level and
set policy top to bottom…
– check out OneVoice business
cases…
Marketing Strategy

10. © hassellinclusion
Embedding responsibility
Designers Writers
Project Mgrs Product Mgrs
Finance Legal Marketing Strategy
Snr Mgrs
Research TestersDevelopers
• Work out whose
responsibility accessibility
should ultimately be…
• Make sure they delegate
(and monitor results) well
• Make sure those delegated
to are trained in their
responsibilities

11. © hassellinclusion
Embedding through
strategic policies
Designers Writers
Project Mgrs Product Mgrs
Snr Mgrs
TestersDevelopers
Finance Legal Marketing Strategy
• create an Organizational Web Accessibility Policy to strategically embed accessibility
into the organization’s business as usual
• including where accessibility is embedded in:
• web procurement policy
• web technology policy
• marketing guidelines
• web production standards
(e.g. compliance with WCAG, browser support, AT support)

12. © hassellinclusion
Harmonising accessibility
with user-centred/inclusive design processes
• relating web accessibility to wider human-
centred and inclusive design practices
From:
ISO/FDIS 9241-210
Human-centred design for
interactive systems
• and bringing in concepts of
user-personalised
approaches…

13. © hassellinclusion
Yes,
there are
16steps
(sorry…)
1. Purpose
2. Target audiences
3. Audience needs
4. Preferences restrictions
5. Relationship
6. User goals
1st
stage:
The right
research
thought
before you
start
7. Degree of UX
8. Inclusive cf. personalised
9. Delivery platforms
10. Target browsers, OSes, ATs
11. Create/procure, in-house/contract
12. Web technologies
2nd
stage:
Making
strategic
choices
based on
that
research
13. Web guidelines
14. Assuring accessibility
15. Launch information
16. Post-launch plans
3rd
stage:
Production,
launch,
update
cycle

14. © hassellinclusion
An informed way of making good decisions
• every decision taken could affect
whether the product will include or
exclude disabled and elderly people
• so every decision should be:
– recognised as a decision
– have all options and implications
considered
– made based on justifiable reasoning
– noted in the Web Product’s
Accessibility Policy for transparency
• at every step of the process

15. © hassellinclusion
BS8878 Product process
- 1st stage: doing the right research thought before you start…
1. Purpose
2. Target audiences
3. Audience needs
4. Preferences restrictions
5. Relationship
6. User goals
1st
stage:
The right
research
thought
before you
start

16. © hassellinclusion
2. Define its target audiences
• can you predict/control who
will use it?
– e.g. an Intranet
– or an extranet
• or will be used by a range of
audiences?
• is it designed for a particular
audience?

17. © hassellinclusion
3. Analyse the needs of those audiences for the product
– questions:
• what are their general needs from the user experience of a web product?
• do they have specific needs from the product?
– how are you going to research these needs?
• general desk research into
‘disabled people’s use of the web’
• your own research – surveys, ethnographic
research into the context, preferences and specific
product needs of your audiences
– like you might do for non-disabled audiences…
– resulting in personas etc.

18. © hassellinclusion
4. Note any platform or technology preferences restrictions
– for example:
• lack of ability to download install plug-ins or browser updates
• IT policy restrictions in offices, colleges preventing use of browser preferences,
installation of assistive technologies
• strong platform preferences due to worries of cost/complexity/security
– will impact on technology choice, platform choice, reliance on ATs to mediate
website experiences
• cf. rich-media technologies like Flash
and ‘alternative versions’
• accessibility isn’t about luddite-ism;
it is about understanding what your audience
really need…

19. © hassellinclusion
BS8878 Product process
- 2nd stage: making strategic choices based on that research
7. Degree of UX
8. Inclusive cf. personalised
9. Delivery platforms
10. Target browsers, OSes, ATs
11. Create/procure, in-house/contract
12. Web technologies
2nd
stage:
Making
strategic
choices
based on
that
research

20. © hassellinclusion
7. Consider the degree of user-experience the product will
aim to provide
– degrees:
• technically accessible
• usable
• satisfying/enjoyable
– an example for online Pacman:
• Technically accessible
= can control Pacman using a switch
• Usable
= have a chance of winning as the ghosts
adapt to the speed of interaction of my switch
• Satisfying
= have the right level of challenge (not too easy or too hard)
– define the aim for each combination
of user group and user goal
– BS8878 doesn’t tell you what level you should pick, just lets you know what the options are,
and asks you to choose a level you feel you can justify

21. © hassellinclusion
8. Consider inclusive design and user-personalized approaches
– non-individualized/inclusive
• accessibility through guidelines, inclusive design, ATs, user-testing…
– user-personalized allows…
• users to specify their needs and then…
– finds a suitable product from a number of alternative versions, or
– adapts the web product to those needs
• often through ‘additional accessibility measures’
– circumstances where a personalised approach could be useful:
• where a ‘one size fits all’ approach doesn’t work for all your target audiences
• if individual relationship with audience is possible/expected (e.g. eLearning) then a personalised
approach might be expected
• for audiences with restrictions on browser, installation etc.
– user-personalized should always complement,
never replace, inclusive design approaches

22. © hassellinclusion
– which platforms are you going to support,
and what degree of accessibility will you aim to achieve?
– useful research to have:
– are you in control of which platforms your users will use your product on?
– no, if it’s available publicly via a browser
– yes, if it’s an intranet or only available as an app
– are your users likely to have a preference on the platforms on which to use your
product?
– options for degree of accessibility to aim for across different platforms?
1. one accessible product for desktop, hope standards will make it work on other platforms
2. as (1) but with UI tweaks (device detection) and accessibility testing on other platforms
3. versions optimised for each platform, including appropriate UI and functionality subset,
fully tested
9. Consider the delivery platforms you will support
(and their accessibility implications)

23. © hassellinclusion
BS8878 Product process
- 3rd stage: production, launch and maintenance (lifecycle)
13. Web guidelines
14. Assuring accessibility
15. Launch information
16. Post-launch plans
3rd
stage:
Production,
launch,
update
cycle

24. © hassellinclusion
14. Assure the product’s accessibility through production
– creating an accessibility test plan
• which testing methods will be used…
• at what points of the production process…
– sticking to the plan
– finding out whether you are achieving your target
degree of UX
– when the ideal isn’t possible…
Quality of data
User testing
User reviews / interviews
Remote testing
Expert walkthrough
Heuristics
Automated testing
Testing with assistive technologies
Cost

25. © hassellinclusion
15. Communicate accessibility decisions at launch
• working out which compromises you can launch with…
and which you can’t…
– achieving the minimal viable product and managing accessibility risk
• communicating all those decisions compromises to your audiences…
– in an easily found accessibility statement on your website
– which your audiences can understand… Confusing
help
text:
A
number
of
sites
accessed
by
par3cipants
provided
help
pages
which
were
so
technical
that
they
were
prac3cally
useless.
Men3on
of
plugins
and
cookies
resulted
in
complete
confusion
by
the
users
and
apprehension
about
whether
they
were
able
to
follow
the
instruc3ons
given.

26. Rob Wemyss
Head of Accessibility
Royal Mail Group
“BS 8878 is an integral part
of our web accessibility
strategy.
It has given us the
framework to help reduce
costs and improve the
quality when delivering
accessible web products for
our customers.”

27. © hassellinclusion
Summary: in a team/organisation that follows BS8878
• you’ll be expected to take accessibility seriously by product managers
• you’ll be in a team where each member knows what accessibility expects from them
• they’ll ask you to follow a user-centred design process (like I guess you want anyway)
• they’ll ask you for/give you real-world user-research to help good decision making
• you’ll be empowered to make decisions re accessibility, as long as you can justify them,
and write them down
• you’ll have the freedom to create product variations where users’ needs diverge
• you’ll have a place to find best practice help for accessible design beyond the web
• you’ll be asked to test products for accessibility, alongside usability, to the level the
budget will allow (and they’ll be aware of the limited benefits of cheap options)
• you’ll be freed from the impossibility of doing everything you could possibly do for v1.0,
as long as you tell your audience why and when they’ll get what they need

28. © hassellinclusion
If you need support training – I’m happy to help...

29. © hassellinclusion
Training
support for
Embedding
Standards
Innovation
www.hassellinclusion.com
hassellinclusion
Strategy
research

30. © hassellinclusion
Get latest news, tools, blogs, training:
www.hassellinclusion.com/bs8878/
Join the community:
www.meetup.com/bs8878-web-accessibility/

31. © hassellinclusion
e: jonathan@hassellinclusion.com
t: @jonhassell
w: www.hassellinclusion.com