This is part 2 of a 2 part series, you can find the previous post here: “What exactly is web accessibility?”
In our last post, we introduced the concept of accessibility and what it means to us & our users.
In this post, we’re going to focus on what exactly we can do as application builders to make sure our experiences are being designed for all users.
Defining what a perfect accessibility experience looks like can be an extremely difficult task. This is because different apps will have different requirements and a variety of different users.
The good news is there are some basic areas that, if we can learn about and build into our workflow as engineers, we’ll be able to create accessible user experiences with very little overhead.
Let’s take a look at these.
Write Semantic HTML
“Semantic HTML is the use of HTML markup to reinforce the semantics, or meaning, of the information in webpages and web applications rather than merely to define its presentation or look.” — Wikipedia
Writing semantic HTML is considered one of the best practices in all aspects of web dev not just for accessibility. When we write semantic HTML it makes it easier for accessibility tools to interpret the structure of the page, navigate it with ease and clearly understand its meaning.
Let's take a look at some key areas where semantic HTML can be really important to get right.
Anchors & Buttons
Both anchors and buttons convey a meaning to the user, be sure to understand when and how to use both.
<a></a>) are used for navigation. If the user is going to be moved to a different part of the current page or to a totally new page you should use an
<button></button>) are used for submitting forms or executing code on a users click. Don’t be tempted to use
<div> with an onClick event, you should strive to use a
<button> in these situations.
When you need to display related bits of data, like the ingredients for a recipe you should avoid using basic div’s and instead use the
In the case of ingredients for a recipe, where the order of the ingredients doesn’t matter we can use the
<li> tag in conjunction with
If the order of the items in the list is critical to the meaning of the data, for example, if they are steps in a recipe, then you should use
Part of good web design practice is having the page broken down into sections with each section having a visible heading that conveys the meaning of that section.
When building this, be sure to use heading tags such as
<h1> <h2> <h3> etc instead of
<div> with the class of “heading1” to style it like a heading. Having headings helps users quickly jump between content on the page.
❗ Pages should have exactly 1
<h1>, no more, no less.
❗ Don’t skip heading levels i.e don’t have lots of
<h2> tags and then under them use
<h4>, you should use
When building forms you should make sure to use the
<label> element and that it is correctly “linked” using the
forattribute with the correct form element.
When an accessibility tool comes across an input field like
<input type="text>it has no idea what this means, is it a search field? An address field? 🤷. However, if correctly labelled it’s able to communicate the text within the label to aid the user in understanding the context.
Even if you don’t want the text to be visible next to a form field, you should still use a label. In this case, you can visually hide this label.
❓ You can learn more about how to effectively visually hide elements here: “How to visually hide content”
When building the markup of your webpage, instead of defining everything in a series of meaningless
<div>’s, learn about and utilise the range of “landmark” HTML elements we have access to for the main parts of your site.
You can use the likes of
<footer> to describe the main chunks of your page.
<nav> can be used for your..err..navigation links.
<form> on parts of the page where the user is expected to enter data.
<section> to wrap distinct parts of related elements, ones that cannot be expressed using the other landmarks. Be sure to give each section a heading.
By using landmarks, you are allowing users to quickly and easily identify and jump to a specific part of the site. For example, to find the navigation to change page, they would no longer have to go through everything on the page and work out if it is the navigation or not, they can simply skip to the
You can read more about semantic HTML on html.com.
❗ Semantics are really important for screen readers. Get familiar with a screen reader to help understand how others might use your app. Is your app still usable? abilitynet.org is a great resource to read more about screen readers.
Use Colors With Strong Contrast
The use of color on webpages is super important, we use them to communicate intent (e.g. errors), draw attention (e.g. call to action buttons) and just generally make the site look appealing.
When considering our use of colors, it’s important to remember that not everyone sees colors in the same way. To help us with this we can think about something called “contrast”.
Contrast in its simplest form is the difference between two colors, in web accessibility, this usually means the difference between a foreground and a background color.
Here are some examples of where the choice in colors & contrast can have an impact.
When you are deciding on your button colors, make sure that the color of the text has sufficient contrast to the color of the button.
❗ Remember to think about other states a button could be in also and how the contrast is there i.e. hover and disabled button states
Don’t Use Color Alone
When trying to convey some form of meaning, for example in a legend of some sort, avoid using just color. Colors can be almost indistinguishable from one another for color blind users.
Take this example where as well as using different colors, different visuals are used for each option, making the difference between each clearer.
Another example is form validation. Using color alone to inform a user that a field is missing can make it extremely difficult for a color blind user to identify which field it is that they need to fill in.
Be sure to use text and icons in conjunction with color to get the attention of the user.
Don’t Ignore Focus State
For users with motor impairments, the ability to use a keyboard to navigate a site is extremely important.
Focus is how the user determines which element on the page is “selected”. For the developer, focus means what element keyboard events are going to impact e.g. typing in an input field or submitting a form.
We help communicate the focus of an element by using a “focus ring”, by default browsers will show a focus ring on elements.
Don’t be tempted to remove these focus rings entirely. If the default browser focus rings really don’t fit with your website then why not get creative?
Check out an example of how Slack displays the focus of a button:
If you need to make small changes to the focus ring you can use the
outline CSS property to control the size, color and style of the ring. You can also use
outline-offset to control how close or far away you want the focus ring to the element.
If you want to do something a little more advanced, you can set
outline:none on the element and apply some custom styles using the
❗ Try using your applications only using a keyboard, using Tab & Shift + Tab to move around the site. Can you see what you’re focused on? Can you interact with everything?
Images & Icons
The use of images & icons in web design is incredibly popular. They are used to delight, inform and grab the attention of users.
Images are an incredibly important consideration when it comes to accessibility given the very visual nature of them and how, as we’ve discussed, not everyone is on the same playing field in this regard.
One of the most powerful tools we have access to when it comes to making images accessible is the
alt attribute. The
alt attribute allows us to provide some form of descriptive text for the image, allowing accessibility tools to understand the context and meaning of an image.
There are different “types” of images that we use in our web designs, each with its own accessibility strategy.
Let's walk through a few of the more common image types you’re likely to come across and how we might deal with them in an accessible way.
Informative images are images that are used to graphically convey ideas, concepts and information. Most images you use are likely to be informative images.
Take this example image. It indicates steps required to wash your hands.
Because the meaning here is displayed visually, we can use the
altattribute to communicate its meaning.
Decorative images contain no additional information for the user. These could be images used for presentational purposes such as patterned backgrounds or dividers for content.
Let’s take this image that we might use to visual divide two sections of content, it serves no purpose other than for decorative purposes.
So we know we should be using alt text to communicate intent, but what if there is no intent?
Well in this case we need to tell accessibility tools to effectively ignore this image, we can do this by setting the
alt attribute to nothing.
❗ It’s important to add the
alt attribute and leave it blank rather than not adding it at all. If you don’t add it then accessibility tools will read out the name of the file instead, which can just be confusing!
Functional images, like the name suggests are images used for a specific function. These functions include the use of images as anchors or buttons.
An example of a functional image that we use commonly are the logos in the headers of websites, these are often an image contained within an anchor, take Amazon for example.
Remember to use semantic HTML here. Use a button or anchor tag with the image inside. Be sure to communicate in the alt text the meaning e.g. “Homepage” if an anchor goes to the homepage or “Search” if you’re using an image for a search button.
Images of Text
Ideally, when adding images to our sites we should endeavour to not use images with text on and instead use a combination of background images & text in the DOM.
Understandably there will be times where text on an image is unavoidable such as content that is changed regularly and potentially by a “non-technical” individual, an example of this could be some promotional images.
When dealing with these types of images we should always make sure the alt attribute contains the text that is displayed on the image.
Other Interesting Bits
We’re probably all familiar with the DOM that the browser creates when loading a webpage. As well as creating the DOM the browser also creates what is known as an accessibility tree.
The Accessibility Tree, as the name implies is a tree-like structure that contains the nodes on the page and their associated properties that are relevant to accessibility, for example
role. Nodes that are “hidden” aren’t found in the Accessibility Tree e.g. elements with
This tree is used by screen reads and other assistive devices.
You can learn about how to see the accessibility tree in your browser on accessibleweb.com.
Finding Accessibility Issues
Taking all of the info we learnt above and applying it to an already existing codebase seems like a daunting experience — where to begin?
There are a variety of free and easy to use tools & browser extensions that can make finding and fixing accessibility issues real easy.
A free audit tool from google that covers a range of areas important to web dev including accessibility. Available standalone, through a CLI or built-in as part of Chrome dev tools.
Easy to use chrome extensions that can help you quickly audit your site for accessibility issues.
Use Pa11y to automate accessibility checks as part of your build pipeline.
Funkify is a chrome extension that allows you to empathise with your users. It allows you to apply filters to the page you have open that simulates a variety of different accessible users’ profiles. It can simulate variations of color blindness, trembling hands, blurry vision & even dyslexia.
As developers, designers, product managers — web content creators, we become responsible for the inclusivity of the product we work on.
Web accessibility is not an easy task but can be a rewarding one, knowing that you’re doing the right thing is extremely satisfying.
If you don’t know where to start — just get stuck in, try and use your app without a mouse navigating with your keyboard only, or close your eyes and try using a screen reader, listen to what your website says and you will see it from a brand new perspective.
The key problem with accessibility is the lack of awareness and empathy so if you’re going to take away one thing, take this:
Be a champion, share awareness and understanding with people you work with, help them become empathetic and aware of the issues people struggling with disabilities face on a day to day basis.
Let’s make the web a better place. 🙂
This post was researched, written & edited in collaboration with Kinga Koziol.