Accessibility awareness: just because it's not broken, doesn't mean it's working

As front-end developers, it’s our job to turn data into something you can see on a webpage.

We use code, like HTML, CSS and JavaScript. These make sense of basically everything you do on the internet.

We work with our content designers to make sure we’ve got the words right, and if something’s not right in the code, we can usually tell because the page looks funny.

But, if you’re using assistive technology, a page that seems fine could actually be full of bugs and totally inaccessible.

If we told our stakeholders that we could build them a page, but 20% of people would receive a 404 error and wouldn’t be able to see it, they wouldn’t be too happy. Not having good accessibility is no different.

Often poor accessibility is a mixture of small but insurmountable obstacles that stop people being able to use your content.

It’s not something to be afraid of. Once you’ve got the right mindset, most things can be fixed easily.

Here are our top 5 accessibility bugbears and how to solve them.

1. Video and images

It’s very hard to escape pictures and videos online. They cause misery during accessibility audits which is unnecessary as it’s easy to get the basics right. You just need to understand the problem.

People using screen-readers won’t be able to access what an image shows unless you have decently descriptive alt text.

Don’t use images with text on them, screen readers can’t read that text.

Similarly, users with hearing impairments won’t be able to access what’s in a video if there’s no transcript. You should also think about adding captions and audio description depending on what’s in the video.

The basic premise is that nothing on the page should be unavailable to a user. If it’s not possible to do this, you need to provide an alternative.

Look at our content toolkit for more.

2. Forms

Bad forms are something you come across all the time when you’re looking at accessibility. Remember a few simple things, you’ll see a lot of your worst problems will disappear.

First, all fields need to be labelled in the HTML. This includes the inputs lining up with the field label. Grouping fields can sometimes improve usability.

All your fields should be keyboard operable. This means people tabbing or using a screen-reader can move about the screen and still know what you’re talking about.

Secondly, think about other little bits of microcopy. These are things like error messages, help messages and that sort of thing. If they’re not helping the user, why are they there?

An error message that reads ‘invalid input’, is going to stump someone using a screen-reader. It's pretty confusing in general. If someone handed you a form in real life, you wouldn’t give it back and say ‘wrong!’, you’d be a bit more pragmatic. Something more descriptive like, ‘You need to enter a UK address’, is much more helpful.

We've got more about this in our forms toolkit.

3. Maps and documents

For accessibility PDF is often a four-letter word. The internet is full of them and most of them aren’t accessible. Unlike HTML, PDFs aren’t accessible to screen readers, unless you add in tags and labels manually. Some are scanned images, which are totally invisible to a screen-reader.

PDFs have a place. They’re okay for large documents in certain circumstances. In these cases, you should take the time to make them accessible. We explain how to make documents accessible in our toolkit. But in most cases, the default should be HTML.

Other bits of fancy functionality, like maps, are trickier. Think about what it is you’re trying to do, do you need them? Maps convey a lot of information which your user might not need to complete their task. Dropping a location on a map is difficult to do without a mouse, when all you need from someone is their postcode. If you think a map is helpful for most of your users, you have to think of a good alternative to sit alongside it for those who aren't able to use them. This could be alt text, descriptions or interactivity.

4. Carousels

Carousels normally appear just below the navigation at the top of a page. They rotate content across the page.

The problem with carousels is if you’re using your keyboard to navigate a page, as many people using screen readers do, that content is difficult to use. There’s often no way for you to navigate it and jolts you around the screen.

Luckily, this isn’t hard to solve. Make sure the carousel is paused by default and all functionality is keyboard operable.

Also, for users who may have cognitive impairments, allow enough time between the carousel changes to view what’s there.

Or, better yet, talk to a content designer about what you’re trying to achieve with your carousel. We know that carousels aren’t massively effective and often user needs can be met in other ways. We’re trying to provide the user with functional content rather than flashy gimmicks.

5. Planning, procuring and plugins

By far the best way to solve your accessibility woes, is to avoid them altogether. This is easy if you talk to us front-end devs and content designers before anything big happens. We can make sure that accessibility is baked into whatever we deliver. It's much harder to remove things after the baking process has begun.

Sometimes, as a developer, it feels like we’re at the tech coalface, far below where all the decisions are made. Though we talk code, we’re also pretty fluent in human. Include us in your planning. Let us know your goals, your fears, your wildest desires! This will help us deliver something that’s better for your users.

Similarly, when you’re procuring new stuff, or refreshing old things, ask for help. You're responsible for your content being accessible. That includes, plugins and third parties.

Make sure you know what you mean by ‘accessible’, and that it’s included in new contracts.

Make things better

If you recognise some of these problems, but you're not sure where to start, have a look at our accessibility toolkit.

Blog Service Transformation