how bs8878 - the uk web accessibility standards - bring together accessibility and usability

© 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


Thinking of Accessibility as Compliance with Standards…

… gets rid of some of your legal and reputational risks


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…


And for a lot of people it feels like this…


Listening to your diverse audiences need’s…��identifies challenges…��but innovation often follows a challenge


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?


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


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 & Testers Developers


Embedding motivation

Designers Writers


Finance Legal

Snr Mgrs


•  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


Embedding responsibility

Designers Writers



Snr Mgrs


•  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


Embedding through ��strategic policies

Designers Writers


Snr Mgrs

Testers Developers


•  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)


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…


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& thoughtbefore 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


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


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& thoughtbefore you start


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


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


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


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


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


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


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


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.

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


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


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


Training & support for Embedding

Standards

Innovation

www.hassellinclusion.com

hassellinclusion

Strategy & research


Get latest news, tools, blogs, training: www.hassellinclusion.com/bs8878/

Join the community: www.meetup.com/bs8878-web-accessibility/


e: [email protected] t: @jonhassell w: www.hassellinclusion.com

how bs8878 - the uk web accessibility standards - bring together accessibility and usability

Technology