Presentation given by Jonathan Hassell (Director of Hassell Inclusion and lead author of BS8878) at a11yLDN unconference London, Sept 2011. Covers: how BS8878 could help set up the perfect environment in which people who care about accessibility can work; what accessibility is really all about (inclusive UX); how BS8878 helps organisations understand the business case for accessibility; how to embed accessibility in their business-as-usual; how different job roles each contribute to whether a product includes or excludes disabled and elderly people; how policies can facilitate or inhibit accessibility; now to make good decisions about accessibility; how to ensure you have the right user-research so your decisions are made on facts not assumptions; what BS8878 enables UX staff to do more easily; how hassell inclusion can help you move forwards in implementing BS8878

1. The perfect team for accessibility:
How BS8878 could get you what you
really want…
Prof Jonathan Hassell (@jonhassell)
Director, Hassell Inclusion ltd.
Chair, BSI IST/45
a11yLDN unconference
21st September 2011

2. Why are you here…?

3. You’re likely to have bought in…

4. You’re probably knowledgeable about accessibility already…

5. You may have had many successes bringing this value
to your work…

6. But you’ve probably also had numerous frustrations where
the products you created didn’t live up to your values…

7. … as the people you were working with/for didn’t share
those values

8. You’d like a bit of help so you know how to fight better…

9. So you can punch harder…

10. Or, preferably, be pushing at an open door…

11. Or, better yet, be actively encouraged
to work the way you want

12. Because what you really want is to work like this…
• to be expected to take accessibility seriously by product managers
• to be in a team where each member knows what accessibility expects from them
• to be asked to follow a user-centred design process (like I guess you want anyway)
• to be asked you for/given real-world user-research to help your decision making
• to be empowered to make decisions re accessibility, as long as you can justify them, and
write them down
• to have the freedom to create product variations where users’ needs diverge
• to have a place to find best practice help for accessible design beyond the web
• to be encouraged to test products for accessibility, alongside usability, to the level the
budget will allow
• and to 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

13. So how do you get there from here…?

14. ©
• the full guide on how to transform your organisation
to achieve the consistent creation of web sites and
apps that are usable and accessible to all your
customers, at the most efficient cost
• with practical case-studies from leading
accessibility experts worldwide, including:
• Jennison Asuncion (Canada),
• Debra Ruh & Jeff Kline (USA),
• Andrew Arch (Australia)
• David Banes (Qatar)
• Axel Leblois (UN)
For information on the book’s publication, free
access to video case-studies, and a chance of
winning the book… click below
For the full answer, read my forthcoming book
- available summer 2014

15. IST/45 values: 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?

16. 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

17. 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

18. 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

19. 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

20. 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)

21. 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…

22. Yes,
there are
16
steps
(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

23. ©
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

24. ©
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

25. 1. Define the purpose of the web product
– without knowing this, you don’t have a basis for
sensible decisions…
– web 2.0’s much wider purposes for websites,
including:
• the move from informative web content to:
– web as tools (“Software as a Service”)
– web as fun/entertainment (games, IPTV)
• the move from Provider-Produced content to:
User-Generated content (blogs, Facebook etc.)
– the challenges and costs of making products with
different purposes accessible can vary hugely, eg:
• costs of subtitles, audio-description for video
• can 3D experiential games be truly made accessible?
• whose responsibility is it to make UGC accessible?

26. 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?

27. 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.

28. 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…

29. 5. Define the relationship the product should have
with its audiences
– optimising your product’s relationship with its target audiences…
– is the product going to consider its audiences to be:
• Individuals (incl. personalisation functionality, via logins or cookies)
• more general groups of users
– impacts on whether the audience may expect an ‘inclusive’ or ‘personalised’ accessibility
approach

30. 6. Define the user goals and tasks
the web product needs to provide
– what goals are your audiences going to
come to your product to achieve?
– are there specific goals which are
more important to your different audiences?
– what goals are core, and what are not?
• e.g. on iPlayer: finding and playing a
programme is core…
being able to share it with your
friends might not be…
– how will you define your product
is successful in enabling its target
audiences to achieve these goals?

31. ©
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

32. 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

33. 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

34. – 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)

35. 10. Choose target browsers, OSes & ATs
to support
– what are you going to do about handling accessibility across browsers, OSes and ATs?
– the less you have to support, the cheaper…
• each browser has its quirks…
• and different screenreaders can require lots of testing and code workarounds…
– how to decide…
• do you have any ability to control/standardise the browsers, OSes and ATs your target audiences will use?
– this is do-able for an intranet or extranet, but not for a public site
• if not, how many of the combinations of browser, OS and AT that are available on your supported platforms
is it reasonable to support?
– what’s used by your audiences?
– is it reasonable to ask your audiences to change browser, OS or AT?
• can you use user-personalised approaches like additional accessibility provisions or alternatives to get
around restrictions?

36. 11. Choose to create or procure the product,
in-house or contracted-out
• are you going to create the product from scratch, or by selecting and
integrating tools, software, components or services?
• are you going to create the product in-house, or contract out its creation?
• if contracting out, how do you ensure that the supplier is able to deliver to
the accessibility requirements and aims for the product?
– checking out their capabilities
– ensuring the ITT/contract includes
the requirements and aims from
your accessibility policy so far

37. 12. Define the web technologies to be used
– what underlying technologies are you going to use to create the web product?
• if you are selecting and integrating other
tools, components or services, how do you
ensure that they will allow the creation of an
accessible product?
– putting these considerations in the selection
criteria
– especially ensuring any authoring tool is ATAG
compliant
• if creating the product bespoke, how do you
ensure the technologies you use will create a
product which is accessible?
– whether the technology supplies techniques
for WCAG 2.0
– whether the technology exposes content,
structure and functionality to assistive
technologies on the platform

38. 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

39. 13. Use web guidelines to direct accessible web
production
– the bit everyone knows…
– using the best accessibility guidelines for the platform and technology
being used…
– including a choice on conformity levels, where they exist…
– the complications:
• this isn’t just WCAG 2.0…
(although that’s the basis…)
• what about mobile?
• and IPTV?
• and what about older people
– are their needs the same
as disabled people’s?
– BS8878 here is a guide to what
guidelines are appropriate
in each of these cases

40. 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

41. 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
participants provided help pages which were so
technical that they were practically useless. Mention
of plugins and cookies resulted in complete
confusion by the users and apprehension about
whether they were able to follow the instructions
given.

42. 16. Plan to assure accessibility in all post-launch updates
– include post-launch accessibility monitoring in your test plan, to ensure:
• updates to the product improve or uphold its accessibility
• updates to your target audiences’ assistive technologies improve or uphold its accessibility
– take care how often you change the product…
– ensure all audience feedback re the product’s accessibility is reviewed and dealt with well
• how to ensure your audience let you know their thoughts
• and how to deal with them…
– ensure the product’s accessibility policy and statement are updated to reflect this…

43. 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

44. If you need support & training – I’m happy to help...

45. ©
• the full guide on how to transform your organisation
to achieve the consistent creation of web sites and
apps that are usable and accessible to all your
customers, at the most efficient cost
• with practical case-studies from leading
accessibility experts worldwide, including:
• Jennison Asuncion (Canada),
• Debra Ruh & Jeff Kline (USA),
• Andrew Arch (Australia)
• David Banes (Qatar)
• Axel Leblois (UN)
For information on the book’s publication, free
access to video case-studies, and a chance of
winning the book… send us your details
via the form on the next slide
If you want to help yourself, read my forthcoming book
- available summer 2014

46. Training &
support for
BS8878
Standards
Innovation
www.hassellinclusion.com
Strategy &
research

47. e: jonathan@hassellinclusion.com
t: @jonhassell
w: www.hassellinclusion.com