February 5, 2024

person using a braille keyboard

3 Quick & High-Impact Tips to Maximise Website Accessibility

Contents
Facebook
Twitter
LinkedIn

As web developers, the accessibility of our websites is vital. This ensures usability by users with impairments and disabilities. This responsibility is not just a moral imperative but also a strategic one. Accessible websites typically perform better in search engine rankings. This is thanks to enhanced user experiences, lower bounce rates, and increased traffic.

Accessibility in web development is a vast and multifaceted topic. So it’s challenging to cover every detail in a single post. This isn’t intended to be an exhaustive guide to web accessibility, but rather a starting point. It’s important to recognise that even small, thoughtful changes can significantly impact how users interact with your website.

Below, I’ve highlighted three small and straightforward changes that you can use right now. These changes should be quick and easy to make and will lead to a significant return of investment for the time taken.

Semantic HTML

Semantic HTML simply put, is to use the correct HTML tags for the job. This practice is crucial. Yet often overlooked by developers, especially those who are relatively new. It remains one of the simplest and most important actions to enhance accessibility in your website or app. Correct semantic use of HTML tags can also often lead to faster development due to much “cleaner” code. Below are some considerations for ensuring correct use:

Proper Use of Headings

HTML Headings <h1> through to <h6> should be used in a consistent and logical manner. This conveys the structure of content on a web page. For instance, an <h1> tag is typically used for the main title of the page, <h2> for major section titles, <h3> for subsections, and so on. A common mistake by developers is to use headings purely for their visual appearance. This often leads to illogical sequences, like jumping from <h1> to <h3> without an <h2> between them. This mistake is common as it can seem harmless at first glance. But such practices can confuse screen reader users and complicate page navigation.

Overuse of Divs

Overusing <div> tags for page layout is one of the most commonly made semantic HTML mistakes. It’s preferable to use semantic elements like <header>, <nav>, <article>, <section>, <aside>, and <footer> . Divs have their place in markup, but using them when a more descriptive tag is available will make it more difficult for screen readers and search engines to understand the structure of the page.

Images with Descriptive Alt Tags

Visually impaired users rely on alt (alternative text) tags to convey the meaning of images on your web page. When writing alt tags, aim for concise, descriptive text and avoid redundant phrases like “image of”. Descriptive images may not need alt tags at all. So it is important to consider what information a user who cannot see the image would miss. Then provide alt tags for images that convey important details.

An Example of Bad Semantic HTML

Below is an example of poor semantic HTML involving the aforementioned issues. There are missteps in this code related to the overuse of div elements, lack of alt attributes for images, and improper use of heading hierarchy. See if you can spot them.

				
					<!DOCTYPE html>
<html>
<head>
    <title>Inaccessible Web Page</title>
</head>
<body>
    <div>
        <h2>Website Title</h2>
    </div>
    <div>
        <div>
            <img decoding="async" data-src="image.jpg" src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" class="lazyload"><noscript><img decoding="async" src="image.jpg"></noscript>
        </div>
        <div>
            <h5>Subheading</h5>
            <div>Content...</div>
        </div>
    </div>
    <div>
        <div>More Content...</div>
    </div>
    <div>
        <span>Contact Us</span>
    </div>
</body>
</html>

				
			

An Example of Good Semantic HTML

Below is an example of good semantic HTML. Notice how the elements in this example are more distinguishable. Writing code like this produces a more accessible end product. You will also decrease the time you spend on maintenance and future development.

				
					<!DOCTYPE html>
<html>
<head>
    <title>Web Page</title>
</head>
<body>
    <header>
        <h1>Website Title</h1>
    </header>
    <main>
        <section>
            <img decoding="async" data-src="image.jpg" alt="Descriptive text of the image" src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" class="lazyload"><noscript><img decoding="async" src="image.jpg" alt="Descriptive text of the image"></noscript>
            <h2>Subheading</h2>
            <p>Content...</p>
        </section>
        <article>
            <p>More Content...</p>
        </article>
    </main>
    <footer>
        <h2>Contact Us</h2>
    </footer>
</body>
</html>
				
			
paint rollers leaving lines of paint in green, red, orange and blue across a white background
Photo by David Pisnoy on Unsplash

2. Adequate Colour Contrast

Sufficient colour contrast in websites is another overlooked, important aspect of accessibility. Although it’s fairly intuitive for developers to recognise extremely poor colour contrast. It can be beneficial to look to the Web Content Accessibility Guidelines (WCAG) for this. Because there are varying degrees of colour vision deficiency.

WCAG 2.0 level AA stipulates that the contrast ratio must be at least 4.5:1 for regular text and 3:1 for larger text. WCAG 2.1 standards specify that graphics and user interface components, like the borders of form inputs, should have a minimum contrast ratio of 3:1. For the more stringent WCAG Level AAA, the requirements are a contrast ratio of at least 7:1 for normal text and 4.5:1 for larger text.

Text is considered large if it is 14 points (roughly 18.66 pixels) and bold or bigger, or if it is 18 points (approximately 24 pixels) or larger.

Now, as useful as this information is, my brain certainly can’t distinguish a 4.5:1 contrast ratio from a 3.5:1. Like most esoteric subjects, the internet provides a solution. WebAIM has created a useful calculator for this very topic.

3. Accessible Forms

Forms can be a crucial components of a website’s functionality, so it’s vital that all users can effectively interact with them. Below are some of the most common pitfalls when creating accessible forms:

Labels

Descriptive <label> tags should be used for every input field. For screen reader users, this is crucial to understand what each field represents. Additionally, you should ensure that the ‘for’ attribute in the label tag matches the id of the corresponding input field. While placeholder text can be useful, it shouldn’t replace labels.

Fieldsets and Legends

Usage of <fieldset> and <legend> tags in HTML indicate grouped elements. When you have a set of related form controls, like radio buttons or checkboxes. You should group them with the <fieldset> tag and describe the group with the <legend> tag. This helps screen readers understand the relationship between elements.

Focusable Elements

Make sure all interactive elements can be focused using the keyboard. For example, text fields, checkboxes, radio buttons, dropdown menus. Avoid using elements that are not inherently focusable (like <div> or <span>) for interactive purposes. Unless, you make them focusable through ARIA roles and tab index.

An Example of a Form with Poor Accessibility

Below is an example of an HTML form with bad accessibility practices. See if you can spot them all!
				
					<form>
    <input type="text" id="name" placeholder="Name">
    <input type="email" placeholder="Email">
    <div>Favorite Color:</div>
    <input type="radio" name="color" value="red"> Red
    <input type="radio" name="color" value="blue"> Blue
    <input type="radio" name="color" value="green"> Green
    <input type="submit" value="Submit">
</form>
				
			

An Example of a Form with Good Accessibility

Here is an example of a form following good accessibility practices. Notice how we’ve grouped related fields with a <fieldset> tag, included labels for each form input and ensured that each element is focusable.
				
					<form>
    <label for="name">Name:</label>
    <input type="text" id="name" name="name">
    
    <label for="email">Email:</label>
    <input type="email" id="email" name="email">
    
    <fieldset>
        <legend>Favorite Color</legend>
        <label for="red">Red</label>
        <input type="radio" id="red" name="color" value="red">
        <label for="blue">Blue</label>
        <input type="radio" id="blue" name="color" value="blue">
        <label for="green">Green</label>
        <input type="radio" id="green" name="color" value="green">
    </fieldset>
    
    <input type="submit" value="Submit">
</form>

				
			

Wrapping Up

Web accessibility is often an afterthought and a nice-to-have if time permits. But, by ensuring good habits throughout development and a bit of additional user testing. You can ensure an accessible user experience with little to no more development time.

This should inform users of the importance of web accessibility and give some practical examples of quick ways to improve your website of this front. However, there are many brilliant resources below if you want to dive deeper into this topic:

WCAG Guidelines

Web Accessibility in Mind

MDN Docs

Got a project?

Let us talk it through