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

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

BS8878 context and history

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 © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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’© jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

Reinforced by emerging web personnel directions• The rise of the Product • Changing organisational Manager 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_internatiohttp://www.bbctraining.com/documents/product_mgt_report.pdf © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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

BS8878 and human-centred/inclusive design- harmony, specificity, and a challenge• relating web accessibility to • and bringing in wider human-centred and concepts of user- inclusive design practices personalised, needs- based, ‘holistic’ approaches… From: ISO/FDIS 9241-210 Human-centred design for interactive systems © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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) © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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… © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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… © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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 Web Web Product Product Accessibility Accessibility Accessibility Policy Policy Statement © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

The accessibility of web products is in thesepeople’s hands… Snr Mgrs Finance Legal Marketing Strategy Project Mgrs Product Mgrs Techies Designers Writers Testers © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

Embedding motivation• How to motivate each group…• Or just use a Snr Mgrs business case for the top level and set policy… – check out OneVoice business cases… Finance Legal Marketing Strategy Project Mgrs Product Mgrs Techies Designers Writers Testers © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

Embedding responsibility• Work out whose responsibility accessibility should Snr Mgrs ultimately be…• And make sure they delegate (and monitor results) well Finance Legal Marketing Strategy• Incl. ensuring those delegated to are trained in their responsibilities Project Mgrs Product Mgrs Techies Designers Writers Testers © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

Embedding through creating 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 Mgrs Product Mgrs Project embedded in: • web procurement policy • web technology policy • web production standards (e.g. compliance with WCAG, browser support, AT support) Techies Designers Writers Testers © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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 Finance Legal Marketing Strategy Project Mgrs Product Mgrs Techies Designers Writers Testers © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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 © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

Keep a logof your decisions

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 Why decisions which impact them… that choice? – through the Web Product’s Accessibility Statement, published as part of the product – cf. VPATs (info for buyers) © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

Product process - 1st stage: doing the rightresearch & 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? © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

2. Define its target audiences• can you • is it designed for a • or will be used by a predict/control who particular audience? range of audiences? will use it? – e.g. an Intranet – or an extranet © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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, ‘disabled people’s use of the web’ 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. © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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… © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

5. Define the relationship the product should have with itsaudiences – 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 © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

6. Define the user goals and tasks the web product needs toprovide – 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? © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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

7. Consider the degree of user-experience the product will aimto 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 © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

8. Consider inclusive design & user-personalized approaches (1) – 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 © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

8. Consider inclusive design & user-personalized approaches (2) • an example of user-personalized approach: BBC MyDisplay (coming soon) © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

9. Consider the delivery platforms to support (1) – Remember… not just web on a computer any more… © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

9. Consider the delivery platforms to support (2) – With different screen sizes… © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

9. Consider the delivery platforms to support (3) – And input devices… © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

9. Consider the delivery platforms to support (4) – And different capabilities… XHTML WAP CSS Browser options ATs MHEG © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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? © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

11. Choose to create or procure the product, in-house orcontracted-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 © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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, • if you are selecting and how do you ensure the integrating other tools, technologies you use will create a components or services, how do product which is accessible? you ensure that they will allow the – whether the technology supplies creation of an accessible techniques for WCAG 2.0 product? – whether the technology exposes – putting these considerations in content, structure and the selection criteria functionality to assistive – especially ensuring any authoring technologies on the platform tool is ATAG compliant © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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 © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

14. Assure the product’s accessibility through production Quait ofdaa ly t – creating an accessibility test plan • which testing methods will be used… • at what points of the production Us er tes ting process… Remote tes ting – sticking to the plan Us er reviews / interviews – when the ideal isn’t possible… E xpert walkthrough Heuris tics making the decision – is it ready to Tes ting with as s is tive technologies launch? A utomated tes ting • how much accessibility risk are you Cost happy to accept for launch? • any mitigating factors? (workarounds, post-launch fixes) – how to communicate imperfect aspects to audiences at launch © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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. © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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… © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

BS8878 – next steps…

IST/45 want your feedback on BS8878 Is it just for show? Or will it work in the wild? © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

Just for Britain, or useful globally? – let us know what you think ? © jonathanhassell@yahoo.co.uk http://www.hassellinclusion.com/bs8878/

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

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

http://www.hassellinclusion.com	969
http://webcache.googleusercontent.com	1
http://translate.googleusercontent.com	1

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

by BS8878 community of practice

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 971

Statistics