Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Implementing Accessibility

Implementing Accessibility

ustwo™ invited me back, this time to speak to their developers about how I go about testing the accessibility of our applications and what they should be thinking about.

Joshua Marshall

August 29, 2013
Tweet

More Decks by Joshua Marshall

Other Decks in Technology

Transcript

  1. GDS Joshua Marshall Joshua Marshall Developer & Accessibility Lead Government

    Digital Service @partiallyblind GDS Joshua Marshall
  2. Implementing Accessibility or “How to work on something with a

    ton of moving parts and people that’s supposed to satisfy the entire adult population of the UK with just one platform”
  3. GDS Joshua Marshall GDS Joshua Marshall Hello (again) ustwo™ Thanks

    for inviting me back. This talk will cover a few things, but mostly they revolve around: What do I do? What does being Accessibility Lead for the GDS entail? Who do I do it for? Who gets extra development help and why? How do I do it? How do we actually go about designing and building things that are good enough for an entire country? When can you stop? How do you know when it’s good enough to release?
  4. Welcome to GOV.UK The best place to find government services

    and information Simpler, clearer, faster Contents Services and information Departments and policy What people are viewing on GOV.UK More on GOV.UK Driving and transport Includes car tax, MOT and driving licences Benefits Includes tax credits, eligibility and appeals Businesses and self-employed Tools and guidance for businesses Employing people Includes pay, contracts and hiring Passports, travel and living abroad Includes renewing passports and travel advice by country Education and learning Includes student loans and admissions Working, jobs and pensions Includes holidays and finding a job Housing and local services Owning or renting and council services Crime, justice and the law Legal processes, courts and the police Money and tax Includes debt and Self Assessment Births, deaths, marriages and care Parenting, civil partnerships, divorce and Lasting Power of Attorney Disabled people Includes carers, your rights, benefits and the Equality Act Citizenship and living in the UK Voting, community participation, life in the UK, international projects This website replaces Services and information Departments and policy The websites of all government departments and many other agencies & public bodies are being merged into GOV.UK Search GOV.UK This is part of what I do. Publishing platform & replacement for Directgov, BusinessLink and all departmental and agency sites. Rather than have loads of different experiences we made one consistent platform for gov publishing. Simpler for users - they shouldn’t have to understand the structure of gov to interact with it.
  5. Welcome to GOV.UK The best place to find government services

    and information Simpler, clearer, faster Contents Services and information Departments and policy What people are viewing on GOV.UK More on GOV.UK Driving and transport Includes car tax, MOT and driving licences Benefits Includes tax credits, eligibility and appeals Businesses and self-employed Tools and guidance for businesses Employing people Includes pay, contracts and hiring Passports, travel and living abroad Includes renewing passports and travel advice by country Education and learning Includes student loans and admissions Working, jobs and pensions Includes holidays and finding a job Housing and local services Owning or renting and council services Crime, justice and the law Legal processes, courts and the police Money and tax Includes debt and Self Assessment Births, deaths, marriages and care Parenting, civil partnerships, divorce and Lasting Power of Attorney Disabled people Includes carers, your rights, benefits and the Equality Act Citizenship and living in the UK Voting, community participation, life in the UK, international projects This website replaces Services and information Departments and policy The websites of all government departments and many other agencies & public bodies are being merged into GOV.UK Search GOV.UK Departments Topics Worldwide How government works Get involved Policies Publications Consultations Statistics Announcements The Prime Minister The Prime Minister is head of the UK government. He is ultimately responsible for all policy and decisions. He: oversees the operation of the Civil Service and government agencies appoints members of the government is the principal government figure in the House of Commons The Prime Minister is David Cameron MP and he is How government works In the UK, the Prime Minister leads the government with the support of the cabinet and ministers. You can find out who runs government and how government is run, as well as learning about the history of government. Who runs government Search Now that the site is live and we’re just maintaining it for the most part, most of my time is spent on testing. Involved in design/UX, some development. Lots of teaching how to build stuff well, pushing best practice. I’m the annoying “but what about...” guy.
  6. GDS Joshua Marshall GDS Joshua Marshall 60% testing 20% education

    10% advocacy 10% development This is a rough breakdown of my schedule recently. Lots of speaking with other devs & designers about what they should be thinking about, how to build accessibly, engaging with public if they run into problems, training, justifying our approach with the public & departments, giving talks... If I’m lucky I get to do a bit of development stuff too.
  7. Who do I do it for? GOV.UK and the transactions

    we’re rebuilding are expected to work for every citizen who has to use them, so every adult living in the UK, plus other foreign nationals who may be visiting or want to settle here. That’s approx 40-50 million people, regardless of ability, disability, language or education level. Currently that’s roughly 1 million visits per day with no real way of knowing what access needs they may have.
  8. Important note! I’m not pretending that all 40-50 million need

    accessibility help. But we have built the site from the ground up to accommodate different needs: use of language means reading age is targetted at 11 and up. Don’t need to understand gov-speak. That helps lower literacy, non-English speakers including those who’s primary language is BSL - not just foreign nationals. Simplifying design and language aids comprehension for everyone including disabled users == win/win for everyone.
  9. GDS Joshua Marshall GDS Joshua Marshall It probably won’t work

    for everyone at first. That’s ok. A quick caveat: You can’t please everyone out there. Accessibility is very subjective and emotive. What you do depends on your product and your audience, but do a minimal amount and your product will be better than most out there who don’t bother at all, even though it’s the law. The Equality Act (2010) is explicit about not excluding people based on gender, race, disability etc. Pick small, achievable, trackable goals and build from there. Make them part of your regular process.
  10. GDS Joshua Marshall GDS Joshua Marshall I probably have to

    do more than you. That’s ok too. GOV.UK is an extreme example. People don’t choose to interact with gov, they have to. We can’t screw it up or cut corners without it really affecting people, but we can fail so long as we acknowledge the failure, fix it quickly, and learn from it. Your product’s needs will be different. Research your audience and aim to be as inclusive as the product will allow. Building Whale Trail will be very different to GOV.UK, but there are plenty of parallels.
  11. How do I do it? So what’s the process we

    follow to start from nothing and end up with our end product? I have some rules to help with that...
  12. GDS Joshua Marshall GDS Joshua Marshall Build accessibility into your

    workflow We work in lowercase a agile sprints, usually fortnightly, some weekly. We build MVP’s of everything, with clear discovery / alpha / beta / release product cycles. Use that to your advantage: get in early with feature requests and expectations. Iterate. The expectation for us is that everything has to be accessible. It’s not optional. Nothing should be released as a “final” product if the accessibility isn’t good enough. It may be tweaked later but the core should be solid.
  13. GDS Joshua Marshall GDS Joshua Marshall Build for your platform

    For us, our platform is the web. No apps, one responsive website. If you’re building an iOS or Android app, use the strengths of the platform. Apple and Google have done the hard work baking in accessiblity support, use what’s appropriate. Leading by example will get you press and recognition within the a11y community. Action sells products. Do the hard work and people will thank you for it.
  14. GDS Joshua Marshall GDS Joshua Marshall Build for inclusion This

    is for everyone We had a design principle that said “build for inclusion”, but we’re iterating it. After giving it some thought, we didn’t like the inference that you had to decide to include certain users, shouldn’t we be doing that already? We quite liked Tim Berners Lee’s tweet during the Olympics opening ceremony so we’ve nicked it.
  15. Tim Berners-Lee @timberners_lee​ 10,542 RETWEETS 2,402 FAVORITES This is for

    everyone #london2012 #oneweb #openingceremony @webfoundation @w3c Reply Retweet Favorite 10:08 PM - 27 Jul 12 Follow More Reply to @timberners_lee @webfoundation @w3c Joe N @Joe​ wow @timberners_lee just tweeted from his desk in the middle of the stadium @webfoundation @w3c 27 Jul Details Ben Perreau @perreau​ Oh @timberners_lee our glorious hero. Now i'm starstruck. #london2012 27 Jul Details Mark McAndrew @markmcan​ @timberners_lee speechless! awesome! 27 Jul Details ashley highfield @ashleyhi​ @timberners_lee nice. 27 Jul Details Derick Rethans @derickr​ Most definitely one of the most important British things for me personally. Way to go @timberners_lee ! 27 Jul Home Connect Discover Me Search Screen readers are important, but they’re not the be all and end all... For us we have to support screen readers, screen magnifiers and speech recognition packages. We have to consider BSL. If you’re putting out an iOS app, make it work with VoiceOver. For Android make it work using TalkBack. Dealing with AT is like browser support but with even more inertia and resistance to upgrading. Upgrading might be impossible for some, some AT is really expensive, not everyone is willing to upgrade if what they have now works for them. How are you going to deal with that?
  16. GDS Joshua Marshall GDS Joshua Marshall Develop a testing workflow

    Bad news: we have to support a lot of AT and it’s really hard to automate most of the testing. Good news: there are amazing consultants and companies out there if you don’t have in-house skills yet, and there are great tools that help. Every major feature addition? Test it. End of a product cycle? Test it again. Doesn’t have to be massively formal or expensive, I test our stuff in house long before it goes to a formal user test. But get it in front of real users once you have something solid. Typically we want to user test by the end of beta at a minimum. Treat it like browser support. Test in product x on platform y, rinse, repeat.
  17. GDS Joshua Marshall GDS Joshua Marshall Decide what to support

    We currently actively test in: 5 screenreaders - JAWS, NVDA, VoiceOver, WindowEyes and Supernova 3 magnifiers - ZoomText, Magic, Supernova plus the built in OS magnifiers 1 speech recognition package - Dragon Naturally Speaking, plus the odd ad-hoc Siri testing For most of those we need to support the current version, plus one or two previous releases. YMMV but it’s up to you based on your customers what you’ll need to support.
  18. GDS Joshua Marshall GDS Joshua Marshall Have someone own it

    This is one of the most important ones for me, and not just because it’s my job. Having a clear owner who the buck stops at is helpful for teams and the organisation. That owner won’t do all of the work, you should be empowering your designers and developers to do that, but having there be someone you can refer back to when needed is really helpful. So is a consistent “voice” across the org.
  19. My testing setup 27” iMac & Macbook Air Windows VM

    for IE6, IE7, IE8, IE9 and IE10, combination of XP, Windows 7 and Windows 8. Firefox in each. Latest version of Mac OS, every now and then need 10.7 or 10.6 but it’s rare given low userbase. Copies of last two versions of ZoomText, JAWS, WindowEyes, Magic, Supernova.
  20. GDS Joshua Marshall GDS Joshua Marshall Colour blindness •Sim Daltonism

    •ColourFilter SD is a Mac app that checks all major forms of colour blindness: http://michelf.ca/projects/sim-daltonism/ Colour Filter is an online tool: http://colorfilter.wickline.org Both will give you a good view into how well your colour palettes will work across the spectrum
  21. GDS Joshua Marshall GDS Joshua Marshall Colour contrast •WCAG Contrast

    Checker •Accessibility Developer Tools for Chrome Contrast Checker is a Firefox extension: http://www.niquelao.net/wcag_contrast_checker/ ADT for Chrome: https://chrome.google.com/webstore/detail/fpkknkljclfencbdbgkenhalefipecmb I prefer the Firefox version but they’re both handy. There are online checkers too. The ratio isn’t human friendly but you’ll learn to get a feel for what will pass over time. Large text helps solve things.
  22. GDS Joshua Marshall GDS Joshua Marshall Screen-readers •ChromeVox •VoiceOver •NVDA

    •Lynx* ChromeVox Chrome plugin: http://www.chromevox.com/ VoiceOver is built into Mac OS - not 100% like JAWS but it’s good: https://www.apple.com/accessibility/osx/voiceover/ NVDA is a good enough open source (and free) SR: http://www.nvaccess.org/download/ NVDA is getting better all the time. If it overtakes JAWS to be the most popular Windows-based SR I’d be a happy bunny. Lynx isn’t a SR but it’ll give you a good view of your HTML structure and whether you may run into problems further on: http://lynx.browser.org
  23. GDS Joshua Marshall GDS Joshua Marshall Vision simulators •NoCoffee Vision

    Simulator •built-in OS magnifiers NoCoffee is a Chrome extension that lets you experiment with different types of vision issues: http://accessgarage.wordpress.com/2013/02/09/458/ It’s REALLY handy for making sure your UI is clear enough, contrast is good etc. Magnifiers will give you a good view of how people with advanced macular degeneration have to use your tools. Try using zoom at 800% and see how quickly you lose focus and get tired...
  24. GDS Joshua Marshall GDS Joshua Marshall Automated checkers •WAVE toolbar

    •Deque FireEyes WAVE is good for testing page by page: http://wave.webaim.org/toolbar/ FireEyes is helpful for more thorough audits: http://www.deque.com/deque-fireeyes Both are Firefox only, both will save your sanity when you try and meet the spec The Rake task is something I’ve been using lately while developing locally. Checks a few things are present, like skip links, the main element, could be more useful but it’s an okay heads-up when testing new things.
  25. The best tool of all? Mine’s called Léonie, she’s a

    consultant for us. She’s a blind developer and she’s amazing. I hired her at the start of the beta of GOV.UK and she’s helped us since then. She’s our expert screen reader user, but because she’s a developer she provides amazing feedback about what isn’t working and why, and how we can improve what we’re building. I love her, and GOV.UK is a far better product because of her. Find a Léonie to help you.
  26. GDS Joshua Marshall GDS Joshua Marshall How do you learn

    how to do it? Bad news: docs are generally a bit rubbish. Good news: they’re getting better. The community is filled with people who share. You adding it into PPP helps promote more of that.
  27. 1. Introduction 2. Editorial content 3. Images 4. Structure/function/layout 5.

    Audio and video content (A/V) 6. Forms 7. Documents 8. Links 9. Document history Accessibility Guidelines v1.9 1. Introduction 2. Editorial content BBC Guidelines S&G Home S&G About Accessibility Use of Colour Flicker and Movement Games Keyboard Access Multimedia Accessibility PDF Accessibility Screen-Reader Testing Guidelines Self-voicing Guidelines Subtitling Guidelines Text Equivalents Text Links Mobile Accessibility Design & Editorial Infrastructure Policy Red Button Technical Glossary Contacts This standard outlines the requirements and recommendations for making BBC websites accessible with respect to editorial content and user experience. Other technical aspects of accessibility are covered in the technical standards, e.g. Semantic Mark-up, CSS, Javascript, XHTML, etc. Other aspects of accessibility are covered in separate standards, e.g. subtitles, use of colour, flicker and movement, games, keyboard access, text equivalents, text links etc. Top of page 2.1 You MUST provide an accessible alternative to any potentially inaccessible core content, including all plug-in content, UNLESS this can be proven to be technically or practically impossible. 2.2 All accessible alternative content MUST be updated in line with and at the same time as the original content. 2.3 You MUST provide an appropriate text equivalent for each non-text element of the core content. See the Textual Equivalents Standard. 2.4 Where the language in the document changes (e.g. from English to Welsh), you MUST indicate this with a tag containing a Lang attribute. 2.5 All text of more than two lines MUST be left aligned (if published language is naturally ranged left e.g. English), except for tabular data and where the formatting is integral to the meaning of the text, e.g. poetry. 2.6 You SHOULD use plain language and avoid jargon. Sign in News Sport Weather iPlayer TV Radio More… Search Search DOCS EDITING DISCUSSION BLOG COMMUNITY ISSUES HOME DOCS CONCEPTS ACCESSIBILITY Web Platform Docs is currently in Web Platform Docs is currently in alpha alpha. Join our community of contributors and help . Join our community of contributors and help us reach us reach beta! See the Editor's Guide to learn how to get involved. Are you skilled in CSS? Please help us reach our goal of complete CSS property articles by July in our weekly Web Platform Wednesday ! Web accessibility basics Summary Accessibility is making the Web work for people with a diverse range of abilities. Accessibility is essential for developers and organizations that want to create high quality websites and web tools, and not exclude people from using their products and services. Accessibility is vital to enable people with disabilities to participate equally on the Web. It is a legal requirement in some cases, and a best practice in all cases. This page provides an overview of web accessibility and links to resources for more information. We suggest that you read through this whole page first, then go back and follow the links to learn more. The Web is for all people The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability. Thus the impact of disability is radically changed on the Web because the Web removes barriers to communication and interaction that many people face in the physical world. However, when websites, web technologies, or web tools are badly designed, they can create barriers that exclude people from using the Web. For example, an inaccessible website could: prevent people who are deaf from getting information from a podcast or video CONTENTS Summary The Web is for all people What is web accessibility? Web accessibility is essential for equal opportunity Understand how people use the Web Accessibility requirements ARIA The components of web accessibility Web Content Tools People - web content creators and web users Business case Older users Mobile Web Learn more from W3C WAI References and acknowledgements • EDIT ▾ TOOLS ▾ LOG IN ▾ A Primer To Vestibular Disorders Key facts, definitions, demographics and causes of vestibular disorders. How–to: Use Skip Navigation links Use skip nav links to ease keyboard user fatigue and frustration. How–to: Use TITLE attributes Short answer: Avoid using title attributes except in a few special MYTH: Screen readers don’t use JavaScript 98.6% of all screen readers have JavaScript enabled. Latest Posts The Accessibility Project The Accessibility Project A community-driven effort to make web accessibility A community-driven effort to make web accessibility easier. easier. Learn more Learn more Learn more Contribute on Github Contribute on Github Contribute on Github A11Y Project A11Y Project Archives Archives Checklist Checklist Resources Resources About About The BBC are fantastic at sharing what they discover, their Standards are great, so is their Mobile guidance. http://www.bbc.co.uk/guidelines/futuremedia/accessibility/ http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile_access.shtml WebPlatform.org is getting better all the time. Same goes for a11yproject.com. People like Jared Smith at WebAIM.org do a stellar job of documenting best practices, we’ve made a start with ours in the Service Design Manual
  28. Digital by Default Service Standard Start using the manual Feedback

    Government Service Design Manual From April 2014, digital services from the government must meet the new Digital by Default Service Standard. Read the standard » Think differently about digital delivery Discover what it means to be part of an agile, user- focused and multidisciplinary team, delivering digital services in government. Start building digital by default services Making a service Learn about the different phases of service design and get guidance for the phase you're in now. Discovery A short phase, in which you start researching the needs of your service’s users, find out what you should be measuring, and explore technological or policy-related constraints. Learn about the discovery phase Service managers Designers Guides and resources for… Government Service Design Manual Build services so good that people prefer to use them Search The BBC are fantastic at sharing what they discover, their Standards are great, so is their Mobile guidance. http://www.bbc.co.uk/guidelines/futuremedia/accessibility/ http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile_access.shtml WebPlatform.org is getting better all the time. Same goes for a11yproject.com. People like Jared Smith at WebAIM.org do a stellar job of documenting best practices, we’ve made a start with ours in the Service Design Manual
  29. Request Test Sanity check Provide feedback Fix Rinse/repeat Our testing

    process generally goes: * get a request to test new feature x or new product y * test the overall structure - is it consistent with the rest of the site? * test in JAWS, NVDA, VoiceOver, ZoomText, Dragon * check colour contrast & colour usage, check for style as well as well as code checks * give feedback to the product team responsible * iterate until you’re happy it’s good enough to launch
  30. When can you stop? You stop when it’s been put

    in front of a range of actual users and they’ve successfully completed their task from start to finish. May sound hard to quantify but it’ll depend on your product. We start with MVP, not everything needs a lot of additional work, but you should be confident that you’re releasing something that is a good enough starting point. You can always build on it so long as you haven’t regressed and broken it for someone.
  31. GDS Joshua Marshall GDS Joshua Marshall It’s never finished. That’s

    ok. The things we’re building are definite discrete products so it’s easier to see what needs testing and when. I have to test around everyone’s roadmaps and release dates, as well as fitting the testing around everything else going on. Sometimes it’s hard to do that, some things arrive when the product is mostly ready for launch. Hopefully the exception rather than the rule. It’s repetitive and boring since so much is manual, but you have to get over that. The effort you put in is really helping someone out there.
  32. GDS Joshua Marshall GDS Joshua Marshall If I can leave

    you with one thing: webaim.org/blog/10-easy-accessibility-tips/ If you don’t know where to start, start with this. Jared Smith is brilliant. Taking care of these 10 things will make a massive difference to the usability of your product. Simple things like alt text, like adding landmarks, like focus indicators, decent form labels, they all add up. The more tiny things you do, even if visually they don’t add anything for you, the easier you just made it for someone to use your thing.