The perfect team for accessibility: how BS8878 could get you what you really want

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

Why are you here…?

You’re likely to have bought in…

You’re probably knowledgeable about accessibility already…

You may have had many successes bringing this valueto your work…

But you’ve probably also had numerous frustrations wherethe products you created didn’t live up to your values…

… as the people you were working with/for didn’t sharethose values

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

So you can punch harder…

Or, preferably, be pushing at an open door…

Or, better yet, be actively encouragedto work the way you want

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

So how do you get there from here…?

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?

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 Web Web Product Product Accessibility Accessibility Accessibility Policy Policy Statement

The accessibility of your web productsis in all these people’s hands… Snr Mgrs Finance Legal Marketing Strategy Project Mgrs Product Mgrs Developers Designers Writers Research & Testers

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

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

Embedding through strategic policies Snr Mgrs 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 embeddedMgrs Project in: Product Mgrs • web procurement policy • web technology policy • marketing guidelines • web production standards Developers Designers (e.g. compliance with WCAG, browser support, AT support) Writers Testers

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

1st stage: 1. Purpose Yes, The right 2. Target audiences research & thought 3. Audience needs before youthere are 4. Preferences & restrictions start 5. Relationship 6. User goals 16 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 steps 12. Web technologies 3rd stage: 13. Web guidelines Production,(sorry…) 14. Assuring accessibility launch, update 15. Launch information cycle 16. Post-launch plans

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 ©

1st stage: 1. Purpose The right 2. Target audiences research & thought 3. Audience needs before you 4. Preferences & restrictions start 5. Relationship 6. User goalsBS8878 Product process- 1st stage: doing the right research & thought 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 • is it designed for a particular • or will be used by a range of will use it? audience? audiences? – e.g. an Intranet – or an extranet

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 • your own research – surveys, ethnographic research ‘disabled people’s use of the web’ 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…

5. Define the relationship the product should havewith 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 tasksthe 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?

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

7. Consider the degree of user-experience the productwill 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-personalizedapproaches – 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

9. Consider the delivery platforms you will support (and their accessibility implications) – 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

10. Choose target browsers, OSes & ATsto 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 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

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

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

13. Use web guidelines to direct accessible webproduction – 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 throughproduction – creating an accessibility test plan Quality of data • which testing methods will be used… • at what points of the production process… User testing – sticking to the plan Remote testing – finding out whether you are achieving your target User reviews / interviews degree of UX Heuristics Expert walkthrough – when the ideal isn’t possible… Testing with assistive technologies Cost Automated testing

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.

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…

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 & Innovation support for BS8878 StandardsStrategy &research www.hassellinclusion.com

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

e: jonathan@hassellinclusion.comt: @jonhassellw: www.hassellinclusion.com

The perfect team for accessibility: how BS8878 could get you what you really want

by Jonathan Hassell

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 22

Statistics