By Léonie Watson01 Jun 2017Tutorials
Accessibility pioneer Léonie Watson quizzes some of the web industry's most knowledgeable experts for their thoughts on making websites and apps more accessible
Accessibility pioneer Léonie Watson quizzes some of the web industry's most knowledgeable experts for their thoughts on making websites and apps more accessible
Many things need to be considered during the production lifecycle: privacy, performance, security, creativity, internationalisation, usability, and interaction to name a few. Another thing is accessibility. It's just as important as other considerations (and the only one required by law), but for many reasons it is often left out. So I've asked some smart people from across the web to share their tips for making accessibility a core design principle.
Always build with accessibility in mind. When you do, ensuring accessibility will be almost effortless as compared to a retrofit. Estelle Weyl, Open Web Evangelist, Instart Logic
Make accessibility part of your process and part of every project; from requirements gathering and the project brief, through building and testing, to launch and into maintenance. Whether you follow an agile or waterfall methodology, make sure you include time for accessibility. If there is good accessibility knowledge across your team, you may only need to allow extra time for testing, but if there is an accessibility knowledge gap then you may need to allow a little longer for development and/or preparatory training.
* Ignore the note about using BS8878 in this article. BS8878 is an old proprietary standard from 2010.
When accessibility is a project requirement it helps to use an established framework as your starting point. Depending on the thing you're creating (a website, webapp, or native app), there are different sets of guidelines you can use.
The Web Content Accessibility Guidelines (WCAG) from the W3C are the most well known. First released as WCAG 1.0 in 1999, WCAG 2.0 (released in 2008) is the current version and also the basis of accessibility legislation in many parts of the world. Although some of the guidelines can be adapted for mobile accessibility, WCAG 2.0 is predominantly focused on website accessibility. WCAG 2.1 (scheduled for release in 2018) will include guidelines for mobile accessibility, but it is still too early to know exactly what that might look like.
Access is a primary structural pillar of the web as it was imagined... and with education and encouragement can in fact happen if we all start accepting that this is more than responsibility; we are all accountable. This has brought me back to core WCAG guidelines which we've had for some twenty years now. Molly E. Holzschlag, Open Society and Technology Initiative (OSATI)
If you're creating a native app, the BBC Mobile Accessibility Guidelines are a good place to start, and the BBC HTML Accessibility Guidelines are a possible alternative to WCAG 2.0. There are even guidelines for game designers, in the form of the Game Accessibility Guidelines.
Useful as these guidelines are, they contain a lot of information and supporting documentation. Until you find your way around it can be difficult to know which guidelines you need to think about based on your role in the production team. Whether you're a project manager, graphic or interaction designer, frontend or backend developer, content producer, QA, or some combination of these roles, you are responsible for accessibility. If you're using WCAG 2.0, then the Accessibility Responsibility Breakdown helpfully explains which guidelines people in different production roles need to think about.
Too often, accessibility is thought of as a challenge to creativity; but if we consider it as a creative challenge, we open up whole new realms of possibility. The trick to really good accessibility is not to compromise on functionality or features, or to constrain asthetic appeal, but to make functional and creative experiences that are accessible as well.
With any design, you need to be sure it’s right for all users, so it solves whatever the problem is in the first place. It’s easy for designers to follow trends because it looks fun to make, or because it simply looks cool - but that’s ultimately bad design. Instead we should ask how the problem can be solved in creative and interesting ways. Tom Waterhouse, Illustrator and Game Designer, 2dForever
To do this we need to understand who it is we're making things for. An interesting thing about humans, is that the ones in terrific health, with perfect eyesight and hearing, who can read and write well, who can multi-task efficiently, and who are fully functional all of the time, are the ones in the minority. The rest of us wear glasses, are in noisy environments, have disabilities, have broken wrists or ear infections, are pushing a shopping trolley, have hangovers, are on alousy wifi connection, are colour-blind, are out in bright sunshine or pouring rain, are... you get the picture. When we think about the people in our target audience, about the only thing we can be absolutely sure of is that they will be human. Everything else is up for grabs - and that is the real accessibility challenge.
Unless you know someone with a disability, accessibility can feel unfamiliar. That can make us fearful of getting it wrong because we know it's important to so many people, and sometimes that means we shy away from doing it at all. The familiarity gap might not be as big as you think though.
If you've asked Siri, Google Talk or Cortana to do something, you've experienced the same technology and interaction that drives speech recognition tools. If you asked them to read you something (like an email or web page), you've also experienced the same technology that drives screen readers. If you ever played pirates as a child and used a kitchen roll tube as a telescope, that reduced viewport on the world is broadly similar to the reduced viewport someone using screen magnification experiences. These are all simple versions of the same technologies and/or experiences that someone using an assistive technology will have.
I have a few tips I give my students. One is to test their interfaces with keyboard only. Most of them don’t even know this is possible. So that’s a good exercise. Another tip I give them is to test their (visual) designs in sub-optimal conditions. Look at a design through almost shut eyes. Make sure it works in the sun. In a shaking tram. In the dark. On a smoke stained ancient Dell laptop. With the touchpad of that laptop. With colour blindness simulators. Vasilis van Gemert, Design Lecturer, vasilis.nl
So have a go. Abandon your mouse and make sure that everything works with the keyboard; turn on the screen reader that comes free with your OS, to get a sense of how things sound; use the zoom function on your touch device or in your browser, to experience things at high magnification; turn off your speakers, to find out whether multimedia content is still understandable; apply filters, to glimpse your content as someone who is colour-blind will see it; or put your content through a readability test, to find out how difficult it is to read and understand.
When you use HTML as intended you get a lot of accessibility for free, including information about the name, role and state of HTML elements. When the browser creates the DOM it also creates an accessibility tree that can be accessed by assistive technologies using different platform accessibility APIs.
The web was designed by many very smart people having long debates and putting in lots of thought trying to make it as good as it can be for everyone... Make the most of all HTML can offer, avoid reinventing the wheel, you may find your site is most of the way to being pretty accessible out of the box. Ada Rose King, Samsung Internet
The browser also handles keyboard support and interaction for you. When you use one of the HTML interactive elements like a link, button, or form field, the browser makes sure it can be focused on and used properly with a keyboard, with touch, or with a mouse. When you use other HTML elements to recreate those things, you have to do all those things yourself; you need to script support for mouse, keyboard, and touch interactions, and you also need to polyfill useful information like the role, name and state of those elements.
The ARIA Authoring Practices Guide (APG) is a collection of design patterns for common interface components (like checkboxes, tabpanels, sliders, toggle buttons, toolbars etc.). If you're building a web app, the APG is a useful resource for making sure your interface components are accessible.
Look at the ARIA Authoring Practices Guide... When I was first starting out ARIA seemed really confusing to me. There are just so many attributes and it's not clear when to use them... Now I feel like I have a better understanding of why the different attributes exist and when to use them. Plus it tells me which keyboard patterns to support! Rob Dodson, Chrome Developer Advocate, Google
Another (growing) collection of accessible design patterns is the Inclusive Components Club. Useful books on this topic include Apps for All, and Inclusive Design Patterns (both by Heydon Pickering).
Most schools and colleges still don't teach accessibility as a core design principle, and of course not everyone in a production team will have studied a web related course in the first place. Fortunately there are some good (and free) online courses you can take to help get the fundamentals you need:
As well as things you can test yourself (like keyboard accessibility), there are tools you can use throughout development to help you get accessibility right. It is important to understand that these tools cannot test for everything that is important, but they are an effective way to monitor certain accessibility features whilst you're in production.
It's in everyone's interest to build accessible websites... Know your fundamentals, and keep checking them during development. I find it too easy to build software that works in the "ideal" environment but with no real consideration for a11y, progressive enhancement, SEO and the like. Checking myself constantly as I go along makes for better software. Remy Sharp, author of terminal.training
There are tools you can incorporate into your build processes, tools that you can point at an individual page, and tools that you can use as aids to manual accessibility checking. It's usually a good idea to pick one or two tools to work with so you get the best of different modes of testing. Play around with a few different tools to find the ones that work best for you and your team. If you want some help getting started, the UK Gov recently published an audit of automated tools (from the first two groups), using accuracy, quality and cost as metrics.
If accessibility isn't part of the project brief you were given, or if your client hasn't mentioned it, that shouldn't stop you. Making things accessible is our responsibility as professionals working in this industry, we shouldn't need to ask permission to do our jobs properly. You might not have time or budget to do it all, but once you make accessibility part of your standard way of doing things, you'll be surprised just how much you can accomplish. Once upon a time you learnt how to code, to design, and to understand interactions, so learning how to do all those things with accessibility in mind is certainly within your grasp (if it isn't already).
Doing something is always better than doing nothing, every small change simply means your product is better optimised, with more people able to have a good experience with it. Ian Hamilton, Accessibility Specialist
Do what you can; design with good colour contrast, write content that is easy to read, use typography that is easy to see, structure your content clearly, make things work consistently, keep designs clutter and distraction free, provide captions, write helpful text descriptions for images. Fix whatever you can, and encourage others across the production team to fix whatever they can too; between you, you'll quickly start to make a big difference to an awful lot of people.
Break the problem down into manageable chunks, and make progress towards your ultimate goal. For example, if you only have a few videos on your site, adding captions is a fairly straight forward process. Testing your colour contrast with one of the various online tools and adjusting the colours to pass is also straightforward. David Storey, Edge team, Microsoft
One of the wonderful things about the web, is the many ways it enables us to communicate and collaborate. Accessibility has a role to play here too of course.
Twitter recently introduced the ability to describe images in tweets, so blind and partially sighted people can enjoy them too. Facebook has an auto-description feature that will attempt to describe images automatically, but you'll be much better at describing the pictures you upload than some bot, so use the photo caption field to provide a descriptive title for the image.
Add alt text on Twitter. Eric Meyer, CSS Pioneer and Co-Founder of An Event Apart, meyerweb.com
When you tweet, think about how you write. Cramming information into 160 characters is practically an art form, but no-one will thank you for compressing it into a series of unintelligible acronyms and abbreviations - especially not people with cognitive disabilities that affect reading or comprehension.
If you share content on YouTube or Vimeo, provide a transcript that includes the spoken dialogue and sound effects from the original video content. Better still, provide captions that can be read in real-time whilst watching the video, so that deaf and hard of hearing people can enjoy it too. Google has an autocaps feature that will create captions automatically. It's a great time-saver, but be sure to check the accuracy of the captions before you make them public.
Most of us learn by watching other people, looking at things other people have made, reading books and tutorials, and most of all by asking questions. So where are the places to do all of those things?
If you have accessibility questions, the A11y Slackers channel is full of people from around the world who'll try to help. Note: "a11y" is a short way of writing "accessibility"; there are 11 characters between the "a" and "y" (and it's pronounced "a eleven y").
If you prefer email, then the WebAIM forum or the W3C Web Accessibility Initiative Interest Group (WAI IG) are both good places to ask questions.
Don't assume anything, listen to the people who actually know accessibility. Robin Berjon, CTO, science.ai
There are blogs from recognised accessibility agencies like The Paciello Group, Nomensa, and Deque, and from bigger companies like Microsoft and Facebook. Places like Smashing Magazine, SitePoint.com, and netmag often publish accessibility related articles, plus many other blogs including Tink.UK, Karl Groves, Juicy Studio, WebAxe, Marco Zehe, Government Digital Service (GDS) and others.
Many conferences now include talks on accessibility, so check out the YouTube or Vimeo feeds for events like FrontTrends, You Gotta Love Frontend, From the Front, ffconf, Fronteers, CSS Day and others. Lots of meetups regularly feature talks on accessibility, including London Web Standards, Front End London, A11y Toronto, Bay Area Inclusive Design and Accessibility meetup, and others. If you go to a meetup in your local area, encourage them to invite someone along to come and speak about accessibility!
"Do the hard work so our users don't have to", was one of the original design principles for the Gov.UK platform. It's a compelling sentiment that is critical to making products (websites, webapps, apps or applications) that people can use, and accessibility is an integral part of getting that right.
Doing the hard work to make a service work well for everyone will make your service better - for everyone. Tom Loosemore, Group Director of Digital Services, The Co-Op
Don't underestimate the difference you can make. If you improve the accessibility of just one thing, you'll be taking a step in the right direction; if you make accessibility part of your standard practice, you'll be a good role model for people coming into the industry, if you push yourself to learn more about accessibility, you'll encourage the people around you to do the same; if you make accessibility "business as usual", you'll be surprised how quickly that becomes the way it is.
You'll never be perfectly accessible to everyone. But that's no reason not to strive to be better. Bruce Lawson, Co-Author of Introducing HTML5, brucelawson.co.uk
Accessibility doesn't have to be perfect (nothing on the web is perfect after all); it just has to be a little bit better than yesterday. Now, let's get out there and see what we can do about that!
My thanks to Estelle Weyl, Molly Holzschlag, Tom Waterhouse, Vasilis van Gemert, Ada Rose King, Chris Mills, Rob Dodson, Remy Sharp, Ian Hamilton, David Storey, Eric Meyer, Robin Berjon, Tom Loosemore, and Bruce Lawson, for taking the time to share these thoughts. I appreciate your help.
Léonie Watson (aka Tink) began using the internet in 1993, turned it into a web design career in 1997, and (despite losing her eyesight along the way) has been enjoying herself thoroughly ever since.
Léonie is communications director and principal engineer at The Paciello Group (TPG), and also works with Government Digital Service (GDS) on the GOV.UK platform.
As a member of the W3C Advisory Board, and co-chair of the W3C Web Platform WG (working on specs like HTML5), Léonie is closely involved with the web standards community. She is frequently asked to talk about web standards and/or accessibility at conferences.
In her spare time Léonie blogs on tink.uk, writes for tech journals like Smashing Magazine, SitePoint.com and net magazine. She also loves cooking, dancing and drinking tequila (although not necessarily in that order).