Accessi­bility in a digital design process

Published: 22 February 2022

In short

Designers have the power and responsibility to allow people to access a website. I think we can bake that into our process by:

Over the past few years, I’ve learned things about accessibility. How to make specific components, or check colour contrast. There’s a lot of very specific information, especially for developers. Or articles on the very basics: what disabilities and accessibility are. Or, even more common, paraphrasings of the WCAG. But how do you work towards an accessible product? How should you change your design process? Or: how do you get started with accessibility as a designer?

I’ve read one article on guidelines and key principles and one with three approaches. Expanding on that, I’ve got some ideas on approaches for web design. That means a lot will translate to app design and other digital formats, too. It also means, however, that it’s not a tried and true methodology. Rather, you should see this as a note-to-self. A reminder of what I think might work, so I can try it out and check if it does.

Why accessibility specific design approaches? Because that bakes accessibility into the product from the start. It relieves the developers from having to fix our work by patching accessibility issues which could have been prevented. That’s not their job. It’s our job to deliver (or collaborate on) accessible designs. That leads to a better end result—and happier colleagues.

The basics

What accessibility is

It’s about access

Sometimes you’ll have to explain what accessibility is. Here’s my short version of it: it’s about allowing people to access something. You could think of permanent disabilities, like visual impairments such as blindness, motor disorders, or problems with balance (such as vestibular disorders), but that’s not all; it’s about anyone using the web. For example, there are also temporary and situational impairments, such as having a broken arm, spotty internet connection, or being in a very sunny location.

Guidelines

To make digital products more accessible, the World Wide Web Consortium (W3C) maintains the Web Content Accessibility Guidelines. If you haven’t read them yet, you could start with a designer focussed set (which is also a bit easier to read).

These guidelines allow us to test the accessibility of a product. It’s often used in legislation, such as the European Accessibility Act coming up in 2025. That means it’s not the most simple text to read and, more importantly, it only covers the bare minimum of what you should pay attention to. It makes sure people can technically use the product, but it doesn’t by itself make it a pleasant experience.

Inclusive design includes accessibility

Some consider it an end product of an inclusive design process, but I would say inclusive design is just broader than accessibility. Mostly, it also looks at identity, culture and situation, and it’s about involving people in the design process and giving them power.

Why it is important

It feels weird trying to convince someone that it is important to make a product which can be used by people. Why would you exclude about a fifth or even half1 of all people, by not making your website accessible? But just to be sure, these are some benefits of making a product accessible:

  1. Access to information and communication technologies is a human right
  2. In allowing more people to use the product, it will increase our favourite metrics (like active users, click through rates, profits, etc.)
  3. It’s good for search engine optimisation (SEO), so the website is easier to find
  4. It leads to innovation and an easier-to-use product for everyone
  5. it decreases the amount of ‘unnecessary’ customer support requests2
  6. For a lot of ‘new’3 products, it will become legally required in the EU, so it decreases legal risks
  7. Doing it from the start is not that difficult4, while it does reduce costs later on, due to fewer bugs and complaints
  8. It includes people, which is just nice and probably ethical

So I’d say it’s a no-brainer: we should definitely design accessible products. But how do we ensure we make our products accessible?

Consider hurdles

At the start of a project, it’s good to consider what kinds of hurdles people could face. There are a lot of general hurdles which are relevant for all kinds of products. For those, guidelines like the WCAG should cover the basics. However, we could check how disabilities or situations interact with our specific product. What kinds of problems might arise? And how can we design a pleasant and usable experience for the people who experience those disabilities?

Perhaps, there are also more specific hurdles for our product. For example, some websites won’t need videos, but if ours does, being deaf or sitting in a loud room pose a hurdle to accessing the audio of that content. We need to add captions to fix that (and maybe a transcript, too).

Consider other interactions, too: using a wheelchair might not prevent someone from using a website. But if you’re making the website for a theatre with stairs in front of the entrance, suddenly the most important part of the journey has become inaccessible. We might not be able to fix that, but we could try to get someone to install a ramp.

We can do this in the beginning, but extend it if we come across more hurdles later on. Similarly, we can use it to write up some requirements (videos should have captions), but also to check how interactions we designed would work combined with those hurdles.

A starting point of things to think about:

Make a list of possible hurdles (disabilities, skills, circumstances, resources)

Do research, not just with active users

Hopefully, we’re already doing research into the people who use your product. However, it’s important to specifically include people who use assistive technologies, might face extra hurdles and/or don’t use our service (yet). This way, we uncover more needs and we prevent survivorship bias. In other words: we’re not just talking to people who have been able to survive the current obstacles like jargon, lack of keyboard support, and confusing parallax pages.

We can turn the results of this research into the usual formats: need-based personas, journey maps, or just a list of pain points. This way we expose hurdles (existing or possible) to our stakeholders, colleagues and ourselves. In turn, that makes it easier to make accessible design decisions later on.

Do explorative research with people who use assistive technologies and/or don’t already use the product

Start simple, then enhance

Good web developers like to work with progressive enhancement: the product has a basis which will work, but is enhanced by extra features if they are available. You might think of escalators, which still work as stairs when the power is gone, except the distance between two steps is a little high.

We can also apply this concept to our design: just text will always work, but we can enhance it with more exciting layouts, colours, visuals, and animations. A screen reader will read text out and announce roles of elements, while a screen will show icons which help the user understand the content even more quickly.

Using progressive enhancement changes our design process in subtle ways, and touches all kinds of elements.

Flows and content: priority guides

With a wireframe, we might be tempted to use images to explain things, or create interactions where the focus order5 is unclear. So, I think starting with priority guides is smart, without adding any visuals. That forces us to focus on textual content and roles, so we automatically think about how it’s read by a screen reader or a braille reader (or a crawler from a search engine!).

Some additional benefits of using priority guides:

Even more benefits are listed in the article which introduced me to priority guides.

Then, when we’re turning the long list of items into a useful layout, make sure the developer and testers still know the focus order. So, either keep the priority guide up-to-date and make it a part of the documentation/handover, or add annotations to our visual design deliverables. This is also a good moment to think about the differences between left-to-right (e.g. English) and right-to-left (e.g. Arabic) versions of the site.

Colours: start with one

I once got the advice to start in grayscale and then only add one colour, like red. After starting this way, we can just use our brand or design system colours, of course. But it feels like good accessibility advice, because it forces us to:

Visuals: enhance, don’t replace

When adding visuals, make sure to keep the text available. For example, combine an icon with text, or only a small part of our target audience will understand its meaning. The same goes for images: a screen reader uses the alt text of an image (and everyone needs it when the image file isn’t loading), so make sure images have a meaningful text alternative.

When it comes to videos, we might not have the transcript available at this point in the process, but we can still define how the video and transcript should live next to each other.

Additionally, do we really need several full-width photos of two megabytes? Or would a line drawing suffice? The first makes a visit to our website eat up a significant portion of someone’s monthly data plan, while the second might work just as well. So: consider for each large asset (images, videos, fonts, tracking scripts) whether it actually adds value and if there’s a lighter weight version.

Animations: keep it small

Animations can support the understanding of the interface: they tell us what we could do and what the computer is doing. Large or pulsating animations might do the job very well for some people, but make sure that if we need them, there is an alternative (small or no animation). Otherwise, it will cause problems with something like a vestibular disorder or epilepsy.

Interactions: make it easier

For each interaction, it’s nice to start with a keyboard-only version. So if we need to rearrange elements, add buttons to move the element up and down. Then, we can add a second mode of interactions: for example, use the mouse to click-and-drag the element to a different position. The keyboard version is still available to those who use something like speech input or just their keyboard, but the mouse version allows other people to do it in a faster way.

Start with a priority guide, then enhance (without throwing out the textual versions)

Test what you design

Testing is part of any good design process. We test our prototypes to figure out whether we’re designing the right thing, or to find usability problems. And either we or our quality assurance team check whether there are bugs in our products before we launch them. The same can apply to accessibility. We figure out if the interaction works and whether our technical implementation doesn’t cause problems.

Accessible prototypes

HTML

When we create prototypes, we might be tempted to sketch something on paper or make a clickable prototype. However, those don’t work well with assistive technologies out of the box. So, we could try our hand at HTML. The prototype will then work for most people and technologies. We can turn our priority guide into a simple web page using a few elements, like

It’s easy to make changes, and maybe even easy to add interactivity by using javascript or just creating different HTML files for different states (just as we might do with your design tool). If we share and discuss this prototype with our fellow developers, they will be able to provide valuable input and raise (accessibility) concerns earlier on.

Figma

However, we’re already learning one new thing (accessibility), so it might not be attractive to take up another (development). Luckily, Figma allows us to turn on an ‘accessibility mode’, which turns our prototype into HTML. We should pay attention to a few things:

It will probably not be perfect (nor will our own HTML be perfect), but it might allow us to already test more things with more people.

Webflow

Alternatively, something like Webflow might be an option. They are working actively to make the output adhere to the WCAG, so that sounds promising. However, we still need to pay close attention to how we build the pages and use the correct elements. Webflow provides some guidance on how to do this.

Testing a live product

Once our designs are built, or if we’re doing an expert review of an existing product, we might want to figure out how accessible they are.

Automated

The easiest way to get started is using automated testers like the Axe browser plugin, but we shouldn’t rely on just that, because it won’t find everything. Partly because the tools are not perfect, but more importantly because some things can’t be tested automatically. We could also use similar tools in the development pipeline, so we don’t have to run these tests ourselves.

Manual

We could also test it ourselves, by hand. We can try out everything using a keyboard and learn how to use a mobile screen reader, VoiceOver on macOS or another desktop screen reader to check a product. Still, this isn’t perfect, since someone who uses a screen reader daily will have different strategies to surf the web than us.

Of course, we can combine automated and manual testing. At gov.uk, they’ve outlined how they do that.

Testing with people

I hope it’s clear we also need to do usability testing with people who use assistive technologies such as braille readers. It’s smart to let people use their own device while doing usability testing, so:

These tests will be similar to usability tests, but we can get some help from people who wrote about moderating usability testing with people with disabilities.

Test concepts with accessible prototypes

Perform automated, manual and usability tests of live products

Change your organisation

It’s great if we are changing our design process to create more accessible products. However, we will achieve very little and tire ourselves out if we try to do it all on our own. So, we have to change our organisation. Everyone involved in creating the product should be aware of accessibility concerns, we should have colleagues who have lived experience with disabilities and our bosses should show they care (and act like it), among other things. That way, our accessible designs won’t be lost. Getting there is outside the scope of this post, but luckily the UK Department for Work and Pensions has dedicated a post to that.

Make your organisation inclusive and focussed on accessibility

Resources

So now we know why and how we could change our process to (hopefully) make our products more accessible. However, there’s a lot more to learn.

Thanks for proofreading, Yvonne and Simon!

Keep on learning

Articles about…

Books

Videos

These help understand how people use technology in different circumstances.

Courses

Newsletters

Helpful to be reminded of new developments and learn more in small bits.

Checklists

WCAG based checklists to check our work, by…

Posters

Organisations/collectives

These organisations have a lot of further readings and resources.

Personal blogs

There are a lot of people who write about accessibility. A lot of them are (primarily) developers, which could make it a little harder to apply their writing in design.

Footnotes

  1. As mentioned, accessibility is not just about disabilities. But if you would want to put numbers on it, that’s the most straightforward, and there are about 1.3B or 16% people globally with a disability and 3.4M or 20% in the Netherlands. Additionally, about half of people in the Netherlands use basic accessibility features on their phone. ↩

  2. Note that as part of an inclusive product or service, good customer support is essential. Having enough people available to answer emails, respond to chat messages and pick up the phone is still important, but it frees them from helping people who get stuck with a product which just isn’t accessible. ↩

  3. The act applies to “products placed on the market after 28 June 2025”, however I’m unsure if a new version of existing software fits within that scope. However, since things like “pre-recorded time-based media” are explicitly excluded, I’m assuming that a new release of software does need to adhere to this law. ↩

  4. Okay maybe that’s a lie; accessibility is difficult, just as much as design in general is difficult. It takes effort, requires us to get out of our comfort zone and discover we’re wrong about a lot before making something useful and usable. However, if you focus on accessibility from the start, it doesn’t have to cost a lot of extra investment. That’s what I’m trying to say. ↩

  5. When you use the Tab key to move through a form (or Shift+Tab to go back) or any other part of a website, the focus jumps from one element to the next in a specific order: the focus order. This is the same as the order of the elements in the code, by default. ↩