How BS8878 relates to WCAG 2.0, PAS 78, Mandate 376 and UCD Standards

© jonathanhassell@yahoo.co.uk
http://www.meetup.com/bs8878-web-accessibility/
BS8878 – embedding accessibility
into real-life web product management
Jonathan Hassell (@jonhassell)
Chair, BSI IST/45
BSI/CETIS Accessibility Standards Workshop
28th
February 2011

http://www.hassellinclusion.com/bs8878/
A brief history of British accessibility standards…
• why did we need a British Standard?
– because we have British law around accessibility
• and not just for public-sector websites, all sites…
– in 2005, research by the British Disability Rights Commission revealed
sites weren’t doing well
• and no existing standards made it easy enough
for site owners to know what to do
• so the DRC commissioned BSi to create PAS-78 to try and help
– a guide to the process of commissioning, producing and maintaining a website
from a site owner’s point of view
– a non-technical person’s guide
to how standards should be used
to help ensure a development project
results in an accessible product
• launched in March 2006, broadly
welcomed by UK site owners

The one constant on the web is change…
• PAS-78 needed updating to handle:
– 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 rich/media-media entertainment
(games, IPTV, eLearning etc.)
• the move from Provider-Produced content,
to User-Generated content (blogs,
Facebook etc.)
– increasing number of devices on which
websites are viewed:
• mobile phones, tablets, IPTV…
– increasing use of non-W3C technologies
• html alternatives => modal alternatives
– increasing use of “off the shelf” tools rather
than bespoke development
– increasing use of on-site ‘accessibility tools’

Reinforced by emerging web personnel directions
• The rise of the Product
Manager
http://www.bbctraining.com/documents/product_mgt_report.pdf
• Changing organisational
structure of teams and key
personnel impacting product
accessibility:
– Technologists/coders (c. 2000)
– User Experience Designers
(c. 2008)
– Web Product Managers (c. 2010)
http://www.bbc.co.uk/blogs/bbcinternet/2010/12/on_un_inter
national_day_of_per.html

BS8878 and WAI – different aims, perfect partners
WCAG useful for:
• websites
• techies – list of what
I have to do with the
tech (e.g. headings)
• designers – list of
what I have to do
with my design (e.g.
colour contrast)
• requirements mgrs –
list of what I have to
include as features
(e.g. subtitles)
Slight problem:
• All mixed together…
BS8878 useful for:
• a guide for
organisations to
embedding
accessibility
• a process for product
managers to apply to
product development
• a guide to WAI
documents
• … and other useful
standards,
guidelines,
processes at the
points in the
process they help
Other WAI documents
useful for:
• browser creators
• CMS/tool creators
• mobile site creators
• Evaluation
• How disabled people
use the web
• How to get the best
of a browser
• How disabled people
should feedback to
an organisation
• etc. etc.

BS8878 and human-centred/inclusive design
- harmony, specificity, and a challenge
• 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, needs-
based, ‘holistic’
approaches…

How it fits with Mandate M/376
• Mandate 376 will introduce…
– “European technical requirements and test methods for
eAccessibility applying to all ICT products and services
sold to the Public Sector”
• BS8878 does not introduce technical requirements but
advice on process and embedding
• BS8878 is not about all ICT products, just web products
– although web products are certainly ICT products
• BS8878 is not about the final product being sold, but the
process of it being created or procured
• BS8878 is not just Public Sector, but Private Sector too
(because UK law requires this)

How we created BS8878
• 3 year’s work
• Created by accessibility experts on IST/45 from:
– BBC, Lloyds Banking Group, Nomensa, Open University, JISC,
Pinsent Masons, University of Southampton, British Computer
Society, COI, IBM, RNIB, United Response, Opera, AbilityNet,
Vodafone, RNID
• Reviewed publicly by:
– 328 experts from the UK and worldwide
– Including: W3C, Adobe, experts in personalisation, aging, mobile,
IPTV, inclusive design, user research and testing,
disability evangelism…

Organisation level:
embedding accessibility into BAU

Preamble: why “web products…”?
– not just websites but also workplace apps, RIAs, SaaS, widgets, mobile
apps
– not just web on a computer any more…

What is BS8878 about?
– Advice for how to embed accessibility strategically within an organisation
– A process which identifies the key decisions which impact accessibility
which are taken in a web product’s lifecycle
– An informed way of making these decisions
– A way of documenting all of this to ensure best practice
– cf. ISO 9241-20
Organizational
Web
Accessibility
Policy
Web
Product
Accessibility
Policy
Web
Product
Accessibility
Statement

The accessibility of web products is in these
people’s hands…
Techies Designers Writers
Project Mgrs Product Mgrs
Finance Legal Marketing Strategy
Snr Mgrs
Testers

Embedding
motivation
Snr Mgrs
Techies
• How to motivate
each group…
• Or just use a
business case for
the top level and set
policy…
– check out OneVoice
business cases…
Designers Writers Testers

Embedding
responsibility
Snr Mgrs
Techies
• Work out whose
responsibility
accessibility should
ultimately be…
• And make sure they
delegate (and
monitor results)
well
• Incl. ensuring those
delegated to are
trained in their
responsibilities
Designers Writers Testers

Embedding through
creating strategic policies
Snr Mgrs
Techies Designers Writers Testers
• 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
• web production standards (e.g. compliance with WCAG, browser
support, AT support)

Embedding through
a standard process
Snr Mgrs• for every product, follow a user-centred production process
• the process identifies the key decisions which impact whether the
product will include or exclude disabled and elderly people…
• across the whole of the web product’s lifecycle
Techies Designers Writers Testers

An informed way of making good decisions
• every decision taken will
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

More uses for the web product accessibility policy
• to help communicate accessibility
requirements for any procurement
• to check conformance with BS8878…
this requires:
– addressing all the recommendations
– checking the decision processes in
the product’s accessibility policy to
provide evidence of following the
recommendations
– justifying any course of action that
deviates from these recommendations
• to inform the product’s users of
decisions which impact them…
– through the Web Product’s
Accessibility Statement, published
as part of the product
– cf. VPATs (info for buyers)
Why
that choice?

Product process - 1st stage: doing the right
research & thinking before you start…

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?

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?

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.

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, but it is
about understanding what your audience
really need…

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

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?

Product process - 2nd stage: making
strategic choices based on that research

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 degree to aim for, for each
combination of user group and user goal
• in practice, you may define the degree for the whole product and
note individual user group/goal combinations as exceptions from that degree
– BS8878 doesn’t tell you what degree you should pick, just what the
options are, and asks you to choose a degree you feel is justifiable

– 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
8. Consider inclusive design & user-personalized approaches (1)

• an example of user-personalized approach:
BBC MyDisplay (coming soon)
8. Consider inclusive design & user-personalized approaches (2)

9. Consider the delivery platforms to support (1)
– Remember… not just web on a computer any more…

– With different screen sizes…

– And input devices…

– And different capabilities…
WAP
ATs
MHEG
XHTML
CSS
Browser
options

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?

11. Choose to create or procure the product, in-house or
contracted-out
– are you going to create the product in-house, or contract out its creation
– are you going to create the product from scratch, or by selecting and
integrating tools, software, components or services
• 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 contract includes
the requirements and aims from
your accessibility policy so far

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

Product process - 3rd stage: production,
launch and maintenance (lifecycle)

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

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
– when the ideal isn’t possible…
making the decision – is it ready to
launch?
• how much accessibility risk are you
happy to accept for launch?
• any mitigating factors? (workarounds,
post-launch fixes)
– how to communicate imperfect
aspects to audiences at launch
Quality of data
User testing
User reviews / interviews
Remote testing
Expert walkthrough
Heuristics
Automated testing
Testing with assistive technologies
Cost

15. Communicate accessibility decisions at launch
– communicating all those decisions 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.

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
– be very careful in deciding how often you update the UX of the product
• updates to your target audiences’ assistive technologies improve or uphold its
accessibility
– ensure all audience feedback re the product’s accessibility is reviewed
and dealt with well
• ensure your audience let you know their thoughts
• and make sure you know how to deal with them…
– ensure the product’s accessibility policy and statement are updated to
reflect this…

IST/45 want your feedback on BS8878
Is it just for show? Or will it work in the wild?

Just for Britain, or useful globally? – let us know what you think
?

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

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

• 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 me your details
via the form on the next slide or visit
hassellinclusion.com/book
Find out how to implement BS 8878
in my book…

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

Get in touch…
e: jonathan@hassellinclusion.com
t: @jonhassell
w: www.hassellinclusion.com

How BS8878 relates to WCAG 2.0, PAS 78, Mandate 376 and UCD Standards

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (17)

Semelhante a How BS8878 relates to WCAG 2.0, PAS 78, Mandate 376 and UCD Standards

Semelhante a How BS8878 relates to WCAG 2.0, PAS 78, Mandate 376 and UCD Standards (20)

Mais de Jonathan Hassell

Mais de Jonathan Hassell (10)

Último

Último (20)

How BS8878 relates to WCAG 2.0, PAS 78, Mandate 376 and UCD Standards

Notas do Editor