An Introduction to Web Accessibility

First of all, thank you for taking the first step towards building a more accessible web by clicking on this article. It won’t give you all the answers, but I hope it will give you a good basis to start from.

What is web accessibility?

Simply put, web accessibility means ensuring that everyone can access the web, regardless of any additional requirements that your user might have. Making sure that a visually impaired user can navigate your website and not miss out on any important content. Making sure that a user with a motor skills deficiency can still click on all interactive elements. Making sure that your content is as easy to read as possible.

Web accessibility is sometimes referred to as ‘A11y’. The A11y Project states that this is because there are 11 characters between the ‘A’ and the ‘y’ in ‘Accessibility’. Similarly, ‘A13y’ (‘Accountability’) is also seen once you start delving more into web accessibility because accessibility doesn’t exist without accountability. You should hold yourself accountable for putting out the most accessible code that you can.

Why is web accessibility so important?

While I could talk here about the ‘Purple Pound’ (the monetary value that customers with additional requirements bring, as consumers), I wouldn’t do it justice. Instead, if you’d like to learn more about the Purple Pound, take a look at Purple’s website, where I’ve linked to a wonderful infographic that they created.

Instead, I’d like to talk about the moral and ethical side of accessibility. As web developers, we don’t know our audience when we’re building a website, so it’s always best to design your site for everyone. If you don’t, then you risk losing out on a large portion of your user base. On top of that, excluding anyone is never good, even if it’s unintentional, and depending on the type of site you’re building, it could even get you into some serious legal trouble.

If you want a more in-depth discussion of the ethics of web accessibility, an explanation of some assistive technologies, and an exploration into the best accessibility testing tools I’ve found, check out my Accessibility in Code - A11y Series 1 article.

The basics

Semantic HTML

The first important thing to consider when coding an accessible website is semantic HTML. It’s the first thing that most developers learn when doing frontend web development, but it’s the one that’s most often overlooked. It’s so easy to just create a website made of <div> elements and call it done, but that doesn’t provide all the information that a screen reader user would need.

So let’s take a look at Heading tags, which are often used incorrectly. Every page or <section> or <article> should have its own <h1> tag containing the main heading of the page, often referred to as the page title. This should match the title <meta> tag (which displays in the tab bar at the top of your browser). Every heading tag after that should appear in descending order, to divide up the content inside each heading.

Using semantic heading tags allows users to quickly scan the headings on your site, to skip to the topic that interests them. This helps all kinds of users, including screen reader users, users with ADHD, and even users who simply don’t have much time to read through your site. The Bureau of Internet Accessibility has an article called What are H Tags? How Headings Affect User Experience, which is really good for understanding why heading tags are so important in a webpage.

Of course, headings are just one example of semantic HTML. I won’t go too much into detail, mainly because I already have in a previous article, Semantic HTML: A11y Series - 4. You can also find more information on UX Design’s article, Semantic HTML: the foundation of web accessibility, and W3 Schools has a wonderful reference guide if you wanted to take a look at all the possible semantic elements you can use.

Alt text

Next, let's discuss possibly the most well-known accessibility feature - alt text. Alt text (short for ‘alternative text’) is what a screen reader will read out to a user in place of an image. This alt text will also display if an image fails to load on the webpage. This text should be descriptive but concise and doesn’t need to include ‘An image of’ or ‘A photo of’. For instance, for an image of 3 red roses, if you set the alt text to ‘Three red roses’, a screen reader will read ‘Image. Three red roses'.

Harvard University has a good article called Write good Alt Text to describe images for some further reading, and I wrote an article called Alt text with Images - A11y Series 3 which explores alt text in more detail.

Colour contrast

The final basic of web accessibility that I’ll cover today is colour contrast. If you don’t consider the colour contrasts on your site, many colour blind users can be completely cut off from being able to see important information.

I have a close friend who is colour blind, so I have many stories and examples of this, but my favourite one was when I was creating an ice-themed web game for a Hackathon. We had purple and blue as our main colours, including on the health bar. When testing the game for us, my friend kept dying. When I asked him why he pointed out that he saw those shades of blue and purple as the same colour - he literally couldn’t see the health bar!

There are different levels of colour contrast that you can meet, with A level being the most basic, AA level being standard on the web, and AAA level being for if you want to be as accessible as possible. Most developers would aim for AA level, as AAA level can severely limit your designs. There’s a slightly complicated calculation that is used to work out the contrast level, which I’ve explained more fully in my article Colour & Accessible Websites - A11y Series 2.

There are many ways of checking the colour contrast on your site, with my favourite being WebAIM’s Contrast Checker. For gorgeous images that show you how the colours look, I’d recommend colourcontrast.cc, which is also really good if you want to document your colour contrast journey.