How to Make Your Website Accessible in 2024: A Practical Guide

Web accessibility used to be considered a nice-to-have, but due to the recent exponential rise in web accessibility lawsuits across the US, it’s becoming a must-have.

You may be thinking - well my company isn’t big enough to become a target but that’s where you’re wrong! According to sources, in 2023, a whopping 73% of ADA lawsuits were directed toward companies with less than $25 million in revenue. So, let’s explore how to make your website accessible in 2024 and protect your company against possible litigation.

Building an accessible website is very similar to building a website with a good user experience. The only difference is - when building with accessibility in mind, you are not cherry-picking which users will get to have a good experience, and which won’t.

Good Web Accessibility =
Good User Experience

Treating a website’s accessibility as part of the UX should be a mindset shift you can make in 2024. You’ll see how suddenly it becomes an integral part of your development process.

Think of all the UX features we consider before deploying a website, such as:

• Turning the header logo into a link to the homepage for easier navigation;
• Making sure there are loading spinners to indicate the submission process is pending;
• Providing useful hints and clear error messages for input elements.

Seems like UX designers, web developers, and business owners really care about their users, right? Well, not all users.

A quick browse through some of the most visited websites in the world reveals countless accessibility flaws and it makes you wonder: if all these websites are so inaccessible, how exactly do people with disabilities get their information, read the news, watch movies, listen to music, buy stuff, make reservations, communicate with others online, and just go about their lives in a web-driven world? Well, with a lot of difficulties.

As developers, we shouldn’t think of a website as completed until it has been made accessible to the best of our capabilities.

We would never deploy a site with a design that looks bad on small screens, a site that has broken links, or one that doesn’t display error messages upon entering invalid credentials. So why would we deploy a website with a captionless video, images that don’t have alt tags, or tiny, hard-to-read text?

If you are a developer just starting to learn about web accessibility, or you know a bit of theory but find it hard to make your website accessible in real-life scenarios, this article will be helpful.

Let’s begin by reviewing a few foundational concepts before getting a taste of some practical examples.

What Does Making A Website Accessible Actually Mean?

Building an accessible website means we design and develop the website in such a manner that it is perceivable, operable, understandable, and robust for all users, including people with permanent and temporary disabilities.

Optimize Your Website for Permanent Disabilities

This category includes users who are blind, have color blindness, users who are deaf, users who have a motoric impairment (shaking arms, bad eye-to-hand coordination, etc), users who are missing fingers or a whole hand, etc.

Optimize Your Website for Temporary Disabilities

Think of users who have broken their arm and can’t use the mouse, people who have chronic headaches so instead of looking at the screen, they use software that reads and announces web content, or people who recently had eye surgery, so for a particular time period, they can’t look at the screen either.

Optimize Your Website for Situational Disabilities

This category covers situations we have all found ourselves in. Remember trying to watch a video in a loud place (coffee shop, mall, hotel lobby) and relying on reading the captions instead of listening to audio?

Or imagine being outdoors and for some reason needing to use your device - and the content you are looking at is barely visible due to the sun hitting the screen.

All of these are users we must consider when building with accessibility in mind. There are quite a lot of things to worry about when making your website accessible.

To make sure we are building the accessible web properly, let’s talk about some rules and regulations. I see you rolling your eyes, but stay with me for a few minutes.

Web Accessibility Standards: W3C Guidelines and Techniques

The W3C (World Wide Web Consortium) developed a set of WCAG (Web Content Accessibility Guidelines) to help standardize web accessibility development.

The Web Content Accessibility Guidelines (WCAG) standards are stable and referenceable when they’re published as a “W3C Recommendation” web standard:

• WCAG 2.0 was published on December 11th, 2008;
• WCAG 2.1 was published on June 5th, 2018, and an update was published on September 21st, 2023;
• WCAG 2.2 was published on October 5th, 2023.

Web Content Accessibility Guidelines describe, as the name implies, the guidelines on how to make your website accessible and provide an inclusive web experience for everyone, including people with disabilities

Some guidelines are essential to having an accessible web page, while others are optional and describe ways to improve the web accessibility. Depending on how essential they are and how easy or hard they are to implement, guidelines are divided into three levels of conformance:

• Level A (Adequate) - essential and easiest to implement;
• Level AA (Acceptable) - a higher level of conformance that covers a wide range of disabilities;
• Level AAA (Enhanced) - the highest level of conformance; it can be very hard to achieve without significantly impacting design or functionality.

Techniques are ways of implementing Web Content Accessibility Guidelines (WCAG). They are not required and are not the only way to meet WCAG. You can use your own technique as long as you check the success criteria of the guidelines.

To make your website accessible in 2024, you should learn how to read the latest WCAG. So, let’s take a look at WCAG 2.2’s first guideline:

Web Accessibility Success Criterion 1.1.1 Non-text Content (Level A)

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

I will not list the exceptions here, to keep things simple for now, but you can find the complete WCAG 2.2 SC 1.1.1 exceptions list on their website.

But here is an example of what the guideline refers to. Imagine a website that provides rental accommodation in the countryside. It has a section with an image element (non-text content) that conveys information like this:

Book your stay in our wonderful cabin!

Here is an image of a cabin that visually informs us of what the cabin looks like.

We want the blind user to have as much of an inclusive experience as everybody else, so we need to add a caption or alternative text for this image:

Nestled among towering pines, a cozy wooden cabin awaits, offering rustic charm, and a crackling fireplace, beckoning for a peaceful vacation escape.

Now, that conveys information, it creates a feeling, an impression of what the cabin is like. Upon hearing the description, you can imagine the cabin, smell the pines, and hear the crackling of the fireplace.

Providing alt text for images is one of the techniques for passing the web accessibility success criteria for this particular guideline. To roughly summarize it, you can use the alt text attribute to describe an image that conveys information. Here is what it looks like in the source code:

  <img src="cabin.png"  
    alt="Nestled among towering pines, a cozy wooden cabin awaits,  
      offering rustic charm, a crackling fireplace,  
      beckoning for a peaceful vacation escape." />  
        

Before moving on, let’s make a quick note about what a screen reader is because I’ll be mentioning it a lot.

A screen reader is a software that helps visually impaired individuals access and navigate digital content by converting text and visual elements into speech or Braille output. It reads aloud the content displayed on a screen, enabling users to interact with computers, smartphones, or other devices.

Performing A Quick Manual Web Accessibility Audit

To understand how to make your website accessible, you need to analyze it first. Now that you learned the basics of rules and regulations — let’s try and do a quick web accessibility audit of a sample website.

Open this webpage that I crafted specifically for our web accessibility audit and let’s follow the steps below.

There are a lot of different things to check for when performing web accessibility audits, but let’s focus on finding some of the most common issues by investigating the following:

• Keyboard accessibility;
• Image alt tags;
• Headings hierarchy;
• Semantic meaning of elements;
• Color contrast.

Keyboard Accessibility

There are many users who are unable to use the mouse to navigate a web page. Anybody who is blind or has severe vision impairment is not able to use the mouse because they can’t see where the mouse cursor is.

People who are missing a hand might want to use either regular or one-handed keyboards for navigation. People whose hands shake might decide to use a keyboard if they feel that makes it easier to get around the website.

Navigating with keyboard

To make your website accessible for users who can use only the keyboard to navigate the page, load the page I created, then start pressing the tab key on your keyboard to shift focus through all the focusable elements on the page. You should be able to focus all the links, buttons, inputs… Basically, anything that is an interactive element.

Press TAB to focus on the next element, or SHIFT + TAB to focus on the previous element. Make sure you can focus all the links in the header, including the icon representing the brand logo and a homepage link.

When you get to the Make an Appointment form, make sure you can focus all input fields. When you get to Pet Type, notice that you have to use arrow keys to select a different radio button, but after pressing the TAB key you switch focus to the next field in the form.

After you get to the Preferred day of next week, you have to press either SPACE or ENTER to open the selection and then use the arrow keys again and ENTER to select the option you want. This is the expected behavior of accessible form fields.

When you get to the footer, be sure you can focus and go to all the social media links (the links in the example only lead back to the homepage).

Focus Indicators

For users who use screen readers, screen readers will announce all the focusable elements (links, buttons, inputs), but to make your website accessible for users that have less severe vision impairment, it’s important to be able to see the focus indicators that specify which link, button or form field is currently focused.

It’s usually a different color of an outline or a border that draws attention to the focused element, but it can be any other visual indicator, like a highlighted background or a change in text color.

When performing a web accessibility audit, you would make sure that all the focus indicators are visible and distinguishable.

Now try filling in the form fields, then focus the Submit button and press ENTER.

By the way, the form won’t really be submitted anywhere, so you don’t have to worry about the website collecting any real or mock data you entered.

Dialog Windows

A confirmation dialog pops up. Make sure that once the dialog pops up, the focus is shifted to interactive elements inside the dialog. If that didn’t happen, this would not be a good user experience for a visually impaired user and it wouldn’t make your website accessible for them, because they need to know they are inside of a different space now and they should have focused on the next interactive element, which, in this case, is the CANCEL button.

Now press TAB. Press it a couple of times. The focus should keep switching between the CANCEL and the OK button. This is a so-called tab trap or a keyboard trap. You should be careful when using keyboard traps because you don’t want to accidentally put a keyboard user in a keyboard trap they can’t get out of.

A keyboard or tab trap is a web accessibility technique that ensures that, once inside of a particular space, the user can only switch focus between elements in that particular space, and the user needs to exit this space if they want to focus other elements on the page. Pressing any of the available buttons is a necessary next move for the user. In the case of the dialog window, this is expected behavior, but you must provide the user with an option to close it. After clicking OK, the form is submitted.

Image alt tags

To make your website accessible, a very important factor to consider is that all images that provide visual information must have alt tags. Images on a web page will be announced by the screen reader and if they don’t have alt text assigned, the screen reader will either read the src path of the image or simply announce “unlabeled graphic”. You understand how that is completely useless for the user.

Let’s do an experiment — and see what happens if the images don’t load in the browser. In this case, only alt texts will be displayed and you’ll see if you can make sense of these descriptions. If you are using Chrome, press the info button in the URL bar. Go to Site settings > Images > select Block.

After a page reload, you won’t see any images successfully loading. But you will see alt text instead. And that is what the screen reader will read if you provide alt text for the images. Make sure the images that don’t need to convey any info simply use alt=”” as their alt attribute. This will tell the screen reader to simply skip the image announcement. For the ones that do need to convey information, you must describe the content of the image. Checking to see if the alt texts describe the images correctly is an important part of a web accessibility audit.

Heading Hierarchy

Having a properly structured heading hierarchy is a simple concept that often goes overlooked. Take a look at the web page and see if you can identify the h1, h2, and h3 tags. If you managed to do that, you probably did it because you could differentiate between font sizes.

That’s not something everybody can notice right away—screen reader users surely can’t.The screen reader announces the headings by announcing the heading level and the text that it holds. If there is a natural order of headings that the screen reader comes across, it will be easy for the user to make sense of the page.

By natural order, I mean this:

• One h1 heading per page — because the page only has one title and one main heading, and this needs to be the first heading on the page;
• The next encountered heading should be the h2 heading and if there are any sub-headings of the h2, those should be h3 headings, and so on;
• If you do encounter an h3 heading, this must be a subheading of a previously encountered h2. If there is an h3 heading on the web page, but there is no h2 on the page, this is a web accessibility problem.

Even if the font size or overall design of the Appointment form heading might seem different than other headings, it’s still considered an h2. If it were h3, that would make it the subheading of the previous h2 of the page, which is Hundreds of Happy Customers. That just would not make much sense, would it?

Semantic Meaning of Elements

It seems like the <div> is the most popular choice of HTML tags in the wild, and this is a horrible practice if you are trying to make your website accessible.

Stop using <div> for all elements on your webpage. The headings should be placed in one of the <h> tags, paragraphs should be within the <p> tag, and elements containing navigation should be placed in the <nav> tag. Put page header in <header>, page footer in <footer>, and so on.

Why? Because that’s what they are!

The screen readers have a great functionality that helps users navigate the page elements and this helps users go straight to elements like forms, links, headers, and footers and avoid tabbing through a whole webpage to complete a task.

Color Contrast

Having good color contrast is essential to making your website accessible for all users. It’s not just about a better reading experience, but also about ensuring that some users can properly perceive the text on the screen. People with color blindness, cataracts, or glaucoma can find it extremely difficult to read text that has low contrast with its background. Pay extra attention next time you are exploring a new website — developers tend to build dark footers, and very often they forget to make sure the text in the footer is bright enough to read.

To check if your color contrast passes an accessibility check, download a free color contrast checker software. Then use it to check if the text in the header of the app has sufficient contrast.

Select the foreground color picker and pick the color of one of the letters from the header. Then select the background color picker and pick the header background color.

You’ll get the contrast ratio result according to WCAG 2.1 for three different use cases:

• The non-text contrast use case does not apply here since we are checking the text;
• Both small and large text checks pass for conformance level AA;
• The check for large text for conformance level AAA passes, but the check for small text fails.

If you don’t feel like downloading software, there are other, online contrast checkers you can use as well. Some browsers have a contrast checker utility integrated within the dev tools, but using Color Contrast Checker can provide more insight when dealing with text that, for example, stands on a gradient background, because it provides a pixel-precise contrast check.

Automate Your Web Accessibility Audit

There are, of course, tools to help make this audit process faster and help you make your website accessible and then maintain accessibility. One tool I particularly like is Lighthouse. Lighthouse is an open-source, automated tool for improving the quality of web pages.

It offers website performance metrics, web accessibility analysis, progressive web apps, and SEO audits.

A particularly handy tool that builds on top of Lighthouse is PageSpeed Insights. Just enter your site’s URL and it will give back useful stats. Let’s take a look at what happens when you analyze our test website. Copy and paste the URL of the website we manually inspected into the PageSpeed Insights input box and take a look at the results:

Press the green Accessibility circle to scroll down to the Accessibility section. The Lighthouse Accessibility score is a weighted average of all accessibility audits. The audits are listed below either as PASSED, FAILED, or NOT APPLICABLE.

Go take a look at some of the audits marked as “PASSED” and notice the Image elements have [alt] attributes audit. It successfully passed the web accessibility audit and it is much easier to check this with a tool like Lighthouse than manually where you have to inspect images one by one.

Caution! Knowing if the alt text actually portrays the appropriate information about the image is something you need to figure out on your own. A picture of a cat should not have the alt text that reads “dog”. Even if the Lighthouse marks it green, it’s not correct.

Now let’s do a Lighthouse audit for another page on the same website

This page looks almost exactly the same as the homepage, but it was intentionally made less accessible. Go through the failed audits and see what you get.

The problematic elements from a failed audit are listed visually and with code references, like the alt text failure that occurs on the inaccessible page. Each audit provides a link to learn more about different web accessibility topics. These are excellent resources if you are learning how to make your website accessible.

Lighthouse’s accessibility audit has another section to check out, the Additional Items To Manually Check (10). We covered some manual web accessibility audit items in previous examples, like making sure every interactive element is operable with a keyboard. But make sure to go through each of these items, because they are a great way of exploring web accessibility topics.

Making Your Website Accessible in 2024: Next Steps

Embracing the accessibility culture in your organization is of utmost importance when striving to improve your website’s accessibility. Establish and document ground web accessibility rules, create an accessibility checklist to go through when building websites, share knowledge with other team members, and make sure everybody is accountable for making the website accessible.

Copywriters should write content that is semantically correct, simple to understand, and that uses inclusive language. Designers should take care of proper color contrast, avoid using small font sizes, and use simple and conventional web elements to make sure the pages are clean and easy to consume. Project managers must make sure enough time and resources are available to make your website accessible.

Start thinking about accessibility in the early stages of project development. Making developers somehow patch up a website’s accessibility is a mission impossible if the website wasn’t written and designed in an accessible manner in the first place.

Remember: Whenever a webpage’s UX feels a bit complicated to a young, able-bodied, tech-savvy person, very often the same page might present a completely inaccessible and unusable experience for someone else. Pay extra attention to these pages and conduct thorough web accessibility checks.

Lastly: if making your website accessible in 2024 seems like a daunting task you’d rather not deal with, you can always call for help.