Tips for making accessibility a core design principle

1. Make accessibility part of your process

When there is pressure to hit a deadline, accessibility is often the first thing to be dropped from the project, or delayed on the assumption that it can be factored in later. The reality is that it's hard (often impossible) to change things once they're built. Good accessibility depends on the choices you make from the beginning of the project, and sometimes those choices can't be unmade. If you choose a JavaScript framework that can't produce accessible code, there isn't much chance you'll be able to change it at a later date for example. Even the things that can be changed come at a cost. If you choose designs that make it difficult for anyone without 20/20 vision to read your content, changing them after the fact will cost time and money.

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.

Useful things:

• Accessibility for project managers *
• A process driven approach to accessibility
• Accessibility in an Agile lifecycle

* Ignore the note about using BS8878 in this article. BS8878 is an old proprietary standard from 2010.

2. Follow the guidelines

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.

3. Treat accessibility as a creative challenge

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.

Useful things:

• Why bother with accessibility?
• Selfish accessibility
• Make the web work for everyone

4. Test for accessibility and simulate sub-optimal conditions

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.

Useful things:

• Basic screen reader commands for accessibility testing
• Narrator dev mode
• Juicy Studio Readability test
• Colour blindness simulator

5. Get the most out of HTML

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.

Useful things:

• Accessibility APIs: a key to web accessibility
• The accessibility tree training guide
• Developer's guide to accessibility mechanics
• HTML5Accessibility

6. Make use of ARIA

It isn't always possible to use HTML elements as they were intended, perhaps because you're using a framework that has poor accessible output, or perhaps because there are no HTML elements for the thing you want to create (like a set of tabs for example). Accessible Rich Internet Applications (ARIA) is a set of attributes that can be applied to HTML or SVG to polyfill accessibility for screen readers. Coupled with JavaScript to provide the expected interaction and behaviour, it's perfectly possible to create accessible custom widgets and components.

If you are implementing custom controls, you should consider early what their accessibility problems are going to be, and think about building in solutions using JavaScript and/or WAI-ARIA. Chris Mills, Senior Technical Writer, Mozilla

Useful things:

• Introduction to ARIA
• ARIA accessibility

7. Discover design patterns

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

8. Learn the fundamentals

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:

• Teach-Access tutorial (designers and developers)
• Google Introduction to web accessibility (developers)

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.

Useful things:

• Accessibility testing tools
• Tenon API
• Chrome accessibility Developer tools
• aXe
• Wave
• TPG testing tools

9. Consider accessibility if it's not in the brief

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

10. Fix whatever you can

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

12. Investigate resources

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!

13. Do the hard work so users don't have to

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