Overview
By the end of this chapter, you will be able to identify various criteria required to build accessible web pages; create accessible images on a web page; create accessible forms on a web page; and use Axe to identify accessibility issues in web pages.
In this chapter, we will look at the importance of accessibility in developing web pages. We will look at the techniques and tools available to a web developer to make the content reach as wide an audience as we possibly can, and this means doing what we can to make text, forms, images, and interactions accessible.
Introduction
In the previous chapter, we looked at how we can add animation to our web pages using HTML and CSS. We learned how we can use motion and transitions to great effect to enrich our web pages and add visual flair.
In this chapter, we are going to look at a very important but sometimes overlooked aspect of web development, that is, accessibility. This chapter is about making a web page available to everyone. It is about removing barriers by making our code as easy to use as possible for as wide a range of users as possible. The web is an open platform, and we should strive to make its content accessible to as many people as we can. The web should work for everyone.
As a web developer, this means we have a great responsibility to use the tools available to us to make accessible websites. HTML has a lot of features that are designed to make web pages accessible and, in this chapter, we will look at several of these – alt attributes, form labels, and fieldsets, to name a few.
We will start by identifying some common issues that can cause web pages to become inaccessible. We will look at how a combination of thinking with an accessibility mindset from the outset of our project and using semantic HTML as intended will solve a lot of these issues.
We will also look at some of the tools that are available to help us improve the accessibility of our web pages. We will be looking at a tool called Axe that can automatically flag accessibility issues.
Finally, as an activity, we will look at a page with some accessibility issues and use what we have learned in this chapter to identify and fix those issues.
Note
Accessibility is a long word often shortened to the numeronym (a word abbreviated with numbers) a11y. The term a11y is a useful one to recognize as it is widely used when talking about accessibility and, if you are researching the subject, a web search for a11y will return useful results.
What Is Accessibility?
Accessibility is a very important subject for the web and web developers, but it is one that isn't always that well understood. By learning about the accessibility improvements we will look at in this chapter, we can help a lot of users. We can remove barriers for the following:
- Those with visual impairments who cannot get information from images that do not have a text alternative
- People who have hearing impairments and cannot get information from media (audio or video)
- Those with physical impairments that prevent them from using a mouse
By making our web pages accessible to those who are differently abled, we also make the pages more usable by those who may face technical limitations. Accessibility issues are not only limited to the aforementioned scenarios but also include users on mobile devices, users who are on a website in a location with a lot of background noise or during a presentation or on a monitor that is not well calibrated, and where color contrast may be an issue. Simply put, accessibility improves usability.
The web is a great platform for distributing content, and the main purpose of that content is to reach as many people as possible. Whether our reasons are due to ethics, profit margins, fear of litigation, or pure empathy, there are no good reasons to ignore the accessibility needs of our users.
You'll be happy to hear that we've already learned about a lot of the techniques we need to make our web pages as accessible to as many people as we can. Before we progress, let's review some of the accessibility concepts we have covered in the preceding chapters and how we will be building upon them in this chapter.
In Chapter 1, Introduction to HTML and CSS, and Chapter 7, Media – Audio, Video, and Canvas, we talked briefly about the alt attribute on the img tag. In the next section of this chapter, we will look at how we can make images accessible to visually impaired users (and those with image loading disabled) using the alt attribute in the right way in more detail. The context in which an image is used and the information it conveys means we should use different approaches for alt text.
In Chapter 2, Structure and Layout, we learned about some of the semantic blocks for structuring a web page. In the Semantic HTML section in this chapter, we will further explore how we can use HTML tags appropriately to provide a good accessible experience for our users.
In Chapter 4, Forms, we looked at creating HTML forms. We will reinforce some of that learning by focusing on the fundamentals for making these forms accessible, including connecting labels to inputs correctly and keyboard accessibility.
In Chapter 7, Media – Audio, Video, and Canvas, we also learned about techniques for adding captions to our audio and video content and making that content available to users who can't hear it (because they have hearing difficulties, their speakers don't work, or they are in, for example, a library and can't use their speakers).
An area we have not covered previously and one that is specific to enhancing the accessibility of web pages is the Web Accessibility Initiative's set of web standards for Accessible Rich Internet Applications (WAI-ARIA).
The WAI-ARIA standards are extensive and are often used to enhance web pages with a lot of dynamism. Put simply, where a web application uses JavaScript to update the page often, WAI-ARIA can help maintain the meaning of the page, keep a user's focus in the right place, and keep behavior accessible.
A good example of WAI-ARIA in action is if we have a JavaScript triggered modal with an alert message in it. If the modal trigger is not properly implemented, a screen reader navigating a page may miss the update to the page when the modal appears and the screen reader may, unexpectedly, continue to browse the page beneath the modal. With WAI-ARIA, we can tell the browser that an element should be treated as a modal with the aria-modal attribute. This will add focus to the modal content and prevent interaction with content outside the modal when that modal is triggered.
Without going into great detail, we will mention a few of the attributes that WAI-ARIA provides, where they are useful, and how to supplement them or correspond them to the accessible HTML implementation we are learning about.
First, we will look at how we can make our HTML images accessible.
Accessible Images
As the saying goes, a picture is worth a thousand words, and images can add a lot to a web page. Some pictures are decorative, whereas others are an important piece of content that gets your web page's message across with great impact.
Every time we add an image to a web page, there are accessibility considerations we should take into consideration in order to make an accessible image. Not all users may be able to see an image. For example, if a user requires a screen reader or other form of non-visual browser to be able to navigate through a web page, they will require a textual description of an image to be able to garner any meaning from it. It can also be the case that a user does not download images because of limitations on network bandwidth or for security reasons. All of these users will benefit from an alternative text description of an image.
The way we can provide this information is through the alt attribute, which we learned about in Chapter 1, Introduction to HTML and CSS, and again in Chapter 7, Media – Audio, Video, and Canvas. An alt attribute should provide a meaningful text alternative to an image.
For example, if we were to add an image to our web page that showed an infographic with some important business data, such as the budget for this and last year, the information – any text, labels, or the numbers the bars represent – would not be accessible to a non-visual browser if they were included in the image. We would need to add an alt tag that expressed that information.
The following img tag could be used to provide an image and an appropriate alt text:
<img src="bar-chart.png" alt="Bar graph of profits for 2019 (£40,000), which are up £20,000 on profits for 2018 (£20,000)" />
The following is the image of our infographic:
Figure 9.1: Image of a bar graph
The following screenshot shows the alt tag (with the image not loaded). The alt tag can also be read by a screen reader:
Figure 9.2: The alt text for the bar graph image
There are a few decisions we should consider when we add an alt attribute, and these depend on the nature of the image (or images) on our web page.
Note
The W3C provides a decision tree that can be very useful for making a decision about what content you need to provide in the alt attribute of an image on your web page. You can find it at https://packt.live/33CzxxW.
As we have shown in the previous example, informative images need a text alternative. Where an image provides the user with information in the form of a diagram, graph, photo, or illustration that represents data or a concept, there should also be an alt text attribute. We should, at least, provide a short text description of the essential information the image conveys. Often, and this especially applies where the information in the image is complex, we need to back this up with more text content or with a table of data.
If an image is purely decorative, we should still provide an alt attribute, but we don't need to add any text. We just add an alt attribute with an empty string (alt=""). Decorative images include those that are used for visual styling and effects.
Images that are described by surrounding text on the page can also be considered decorative. If the information that's conveyed by an image is also described as text on a web page, you can again add an empty alt tag.
If an image has a functional role, for example, it is an icon that's used as a button or a link, we need to provide alternative text that describes the function rather than the image. For example, where an image of a floppy disk is used as a button for saving a file, we would provide the alt text "Save" or "Save file" rather than something such as "Floppy disk icon", which would describe the image but would not be useful for a user who wanted to use that functionality.
Where multiple images are used to convey a single piece of information, we can add alt text to the first image to provide a description. The rest of the images can then have an empty alt attribute. For example, in the forthcoming exercise, we will create an element for showing a rating using five separate star images. By adding an alt text description to the first image and empty alt attributes to the other images, we inform the user of the rating, even when the images are not visible.
Here is the relevant code:
<div class="rating">
<img src="images/full-star.png" alt="Rated 3 and a half out of 5 stars" />
<img src="images/full-star.png" alt="" />
<img src="images/full-star.png" alt="" />
<img src="images/half-star.png" alt="" />
<img src="images/empty-star.png" alt="" />
</div>
Having seen the basics of the alt attribute, we will implement this in the following exercise, where we will make the rating section of a typical product page accessible. We will make the group of images accessible with the appropriate use of alt text.
Exercise 9.01: Accessible Ratings
In this exercise, we are going to create a product page. We are going to include an element for showing a product rating. This is a common UI pattern seen on eCommerce sites or anywhere users can rate cultural artifacts such as books and films. The rating will be represented by 5 stars, and a rating can be any value from 0 to 5 stars, rising in increments of a half.
To create the rating element, we will use five separate images. We will make the group of images accessible by providing alt attributes to express the information of our set of images. In other words, we will describe the rating given.
The following screenshot is what the product page will look like when it's finished. For this exercise, we will give the product a rating of 3 and a half stars:
Figure 9.3: Product page with ratings UI
The steps are as follows:
- First, create and save a file named Exercise 9.01.html. In Exercise 9.01.html, copy the following code to set up a basic HTML page:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Exercise 9.01:Accessible rating</title>
<style>
html {
box-sizing: border-box;
}
*, *:before, *:after {
box-sizing: inherit;
}
body {
padding: 0;
margin: 0;
font-family: Arial, Helvetica, sans-serif;
font-size: 16px;
line-height: 1.7778;
}
</style>
</head>
<body>
</body>
</html>
- In the body element, add a div with a class attribute with the "container" value. This is where our product markup will be hosted:
<div class="container"></div>
- We want the product to be centered on the page, so we will use flexbox to center the contents of the container in CSS. By setting the flexbox flow to a column with no wrapping, the elements within that container will flow vertically, one after another. We add the following declaration block to the style element:
.container {
display: flex;
align-items: center;
justify-content: center;
flex-flow: column nowrap;
}
- We are going to create a product item page that shows an item with a title, a description, and a rating. We can add the initial markup for the product – a section element with the "product" class attribute and child elements for a product image, as well as a heading and a paragraph for the description. We add this to the body element:
<section class="product">
<img class="product-image" src="images/product.png" alt="Product" />
<h2 class="product-heading">Product Description</h2>
<p class="product-description">
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus scelerisque, sapien at tincidunt finibus, mauris purus tincidunt orci, non cursus lorem lectus ac urna. Ut non porttitor nisl. Morbi id nisi eros.
</p>
<hr class="divider" />
</section>
- To style the product item, we will add the following CSS declarations. This defines a box for the product with a shadow around it and the content centered:
.product {
width: 50vw;
min-width: 640px;
margin: 2rem;
padding: 1rem 2rem;
display: flex;
justify-content: center;
flex-flow: column nowrap;
border-radius: 3px;
box-shadow:
rgba(0, 23, 74, 0.05) 0px 6px 12px 12px,
rgba(0, 23, 24, 0.1) 0 6px 6px 6px,
rgba(0, 23, 24, 0.3) 0 1px 0px 0px;
}
.product-heading {
margin: 0;
}
.product-image {
padding: 0;
margin: 2rem auto;
width: 60%;
height: 100%;
}
.product-description {
width: 100%;
}
.divider {
width: 100%;
}
- To create the UI element for showing the ratings, we will add a div element with a rating class attribute and five image elements as children. Each of these images will either show a star, a half-filled star, or an empty star. We will add this below the description at the end of the product section:
<div class="rating">
<img src="images/full-star.png" />
<img src="images/full-star.png" />
<img src="images/full-star.png" />
<img src="images/half-star.png" />
<img src="images/empty-star.png" />
</div>
- We need to add some more CSS declarations to the style element to center the ratings and to keep the size of the rating responsive while the container is resized due to window width. We have added flex-shrink to each rating image as this will allow the image to shrink in order to fit the available space:
.rating {
margin: 1rem auto;
width: 60%;
display: flex;
flex-wrap: row nowrap;
}
.rating img {
width: 20%;
flex-shrink: 1;
}
- Next, we will add alt attributes to each image element with an empty string. This means that the images will be treated as decorative:
<div class="rating">
<img src="images/full-star.png" alt="" />
<img src="images/full-star.png" alt="" />
<img src="images/full-star.png" alt="" />
<img src="images/half-star.png" alt="" />
<img src="images/empty-star.png" alt="" />
</div>
The five image elements are required to describe some information that our users may find useful. At the moment, our rating element does not describe that information in a text-based format. A screen reader user would not get information about the product rating and that could hamper their choice.
- By adding the rating information as the value of an alt tag for the first image, we provide the necessary information for non-visual users:
<div class="rating">
<img src="images/full-star.png" alt="Rated 3 and a half out of 5 stars" />
<img src="images/full-star.png" alt="" />
<img src="images/full-star.png" alt="" />
<img src="images/half-star.png" alt="" />
<img src="images/empty-star.png" alt="" />
</div>
We've added alt attributes to each of the images, but only the first one describes the information portrayed by the set of images. This provides information for a user who cannot see the visual representation of the images and means that the ratings are accessible and useful.
If you now right-click on the filename in VSCode on the left-hand side of the screen and select open in default browser, you will see, the final result that will look like the screenshot that was provided at the beginning of this exercise.
The following screenshot shows the product page without images. The alt text shows that we can still get the information provided by the images when the images are not available. The rating is shown as "Rated 3 and a half out of 5 stars" so that a user who has a screen reader could make a decision about this product with the same information as a user who can see the images:
Figure 9.4: Product page with alt text replacing images
In the next section, we are going to look at what we can do to make HTML forms accessible to users.
Semantic HTML
As web developers, one of the biggest opportunities we have for creating accessible web pages is the use of semantically correct HTML. What this means is that we should make use of the correct HTML tags to define the meaning of the content of our page.
Instead of using div elements to create the sections of a page, we should use the elements provided by HTML5 – section, header, footer, main, aside, and nav. Also, we should use h1-h6 and use the right level of heading, depending on our document structure and nesting.
You will sometimes hear the structural elements of the web page being called landmarks, and that is because they provide structural points of reference that a screen reader can move between on a web page. This helps speed up browsing and navigation for a non-visual user. Keeping this structure well defined and simple will be of real benefit to screen reader users.
We've covered this throughout the previous chapters. In particular, in Chapter 2, Structure and Layout, we learned about structuring a web page with the appropriate elements. By structuring the document properly, we can make sure the users browsing our web pages can understand the structure and navigate through it as easily as possible.
Accessible Forms
We learned about HTML forms in Chapter 4, Forms. Making forms accessible is very important because forms are one of the key areas where users will interact with your site. This is where users will sign up, send feedback, or pay for goods.
Making forms accessible takes some thinking, and there are fundamental practices we should follow when we are creating forms for a web page. By following these practices, we will have gone a long way toward making accessible forms and web pages.
The techniques we will look at here are as follows:
- Labels and input fields
- Fieldset
A common mistake that's found in forms across the web can be seen here:
<p>First name:</p>
<br />
<input type="text" id="first-name" />
The following screenshot shows the result of this markup:
Figure 9.5: Form markup
Visually, this markup may look fine. This may be how we've designed the input and label. However, the problem for a user of a screen reader is that the text First name: is not associated with the input. A screen reader would not read out the text when navigating to the form field.
We need to provide labels for our form inputs, and we need to make sure that the labels are correctly associated with those input fields.
To make the preceding example accessible, we can do one of two things:
- We can associate a text label with a form input field using a label element with a for attribute. The value of the for attribute must match an id attribute value on the appropriate form field. For example, the following code provides the label First name and it is associated with the input with the ID "first-name".
<label for="first-name">First name</label>
<input type="text" id="first-name" />
- We can wrap the input with the label, again creating an association between the two. This would look like this:
<label>First name: <input type="text" /></label>
In both cases, we now have a form field associated with a label. When a screen reader user navigates to the input element with the ID "first-name", the screen reader will read out the label First name. This explains what information the input field is expecting without the user relying on a visual association.
When forms get more complex with a large number of input fields, they can be difficult to navigate through and understand. We often use white space and visual groupings to break up the form, but that doesn't work if a user is browsing with a screen reader. To meaningfully break the information up into understandable groupings, we can use the fieldset and legend elements.
A fieldset element wraps a set of form input fields. You can add a legend element nested in the fieldset element to provide a textual caption for the fieldset. As a screen reader user, this grouping and text caption helps the user understand what they are being asked to input and provides context.
As an example, the following code creates a form with two fieldsets. The first set of fields asks for the user's address and the second set asks the user to choose their favorite color. The use of a fieldset helps all users understand that the two fieldsets are grouped separately:
<form>
<fieldset>
<legend>Provide your address:</legend>
<label for="house">House</label>
<input type="text" id="house" />
<br />
<label for="street">Street</label>
<input type="text" id="street" />
<br />
<label for="zipcode">ZIP code</label>
<input type="text" id="zipcode">
</fieldset>
<fieldset>
<legend>Choose a favorite color:</legend>
<input type="radio" value="red" id="red" name="color">
<label for="red">Red</label>
<input type="radio" value="green" id="green" name="color">
<label for="green">Green</label>
<input type="radio" value="blue" id="blue" name="color">
<label for="blue">Blue</label>
</fieldset>
</form>
The result of the preceding code (with default user agent styling) is shown in the following screenshot:
Figure 9.6: Form with fieldsets and legend
Visually, the two different fieldsets are obvious and thematically relate the input fields. For a screen reader, the second fieldset might be read as follows:
Choose a favorite color radio button Red, radio button Green, radio button Blue.
Having looked at some of the fundamental techniques we can use to make forms accessible, we will put these techniques into practice in the next exercise by creating an accessible signup form.
Exercise 9.02: Accessible Signup Form
We are going to create an accessible HTML form in this exercise. The form will be a simple example of a signup form and we will focus on making it accessible by providing the appropriate fields with labels and grouping them as fieldsets. By doing this, we will learn how to make an accessible form.
We can see the wireframe of the form in the following diagram. This is a signup form; it is simple and functional, and we will particularly focus on making sure it is accessible by making use of the label and fieldset elements:
Figure 9.7: Wireframe of the signup form
As we can see from the wireframe, the form will have a heading (Sign-up Form), two fieldsets each with a legend (Add user's details and Set a password), a submit button with the Sign-up label, and the five input fields with corresponding labels for First name, Last name, E-mail, Password, and Confirm Password.
The steps are as follows:
- First, create and save a file named Exercise 9.02.html. In Exercise 9.02.html, copy the following code to set up a basic HTML page:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Exercise 9.02: Accessible signup form</title>
<style>
html {
box-sizing: border-box;
}
*, *:before, *:after {
box-sizing: inherit;
}
body {
padding: 0;
margin: 0;
font-family: Arial, Helvetica, sans-serif;
font-size: 16px;
line-height: 1.7778;
}
</style>
</head>
<body>
</body>
</html>
- We want to create a form, so we'll add a class attribute with the "signup" value, which we will use for styling. We will add a h2 heading element to the form with the text content Sign up form so that we know what the form is for:
<form class="signup">
<h2>Sign up form</h2>
</form>
- Next, we'll add our input fields to the form. The information we want to capture is the user's first and last name, an email address, and a password. We also need a button to submit the form. We will use the label element to provide the appropriate labeling to each field. To make sure each label/input pair is on a separate line, we are going to use the br element. We have connected each label to an input using the for attribute and a corresponding id on the input:
<form class="signup">
<h2>Sign up form</h2>
<label for="first-name">First name:</label>
<input type="text" id="first-name" />
<br />
<label for="last-name">Last name:</label>
<input type="text" id="last-name" />
<br />
<label for="email">E-mail:</label>
<input type="email" id="email" />
<br />
<label for="password">Password:</label>
<input type="password" id="password" />
<br />
<label for="confirm-password">Confirm password:</label>
<input type="password" id="confirm-password" />
<br />
<button type="submit" class="signup-button">Sign-up</button>
</form>
The following screenshot shows our form at this stage:
Figure 9.8: Unstyled form with inputs and labels
- We can improve the layout of the form to help make the experience better for visual users. Add the following CSS to the style element in order to add some whitespace around the form, style the Sign-up button so that it's more visually interesting and so that it stands out more, and increase the size of the input fields so that they take up a whole line:
.signup {
margin: 1rem;
}
.signup-button {
-webkit-appearance: none;
appearance: none;
padding: .5rem 1rem;
background: #7e00f4;
color: white;
font-size: 1rem;
border-radius: 3px;
margin: 1rem 0;
outline: none;
float: right;
cursor: pointer;
}
.signup-button:hover,
.signup-button:focus {
background: #500b91;
}
.signup label {
display: inline-block;
width: 150px;
}
.signup input {
width: 100%;
height: 2rem;
margin-bottom: 1rem;
}
If you now right-click on the filename in VSCode on the left-hand side of the screen and select open in default browser, you will see the following screenshot that shows the effect of styling the form with the preceding CSS code. It makes the form more visually appealing and easier to work with:
Figure 9.9: Styled signup form
- All our users will benefit from partitioning the form thematically. It will make it easier to understand for both, visual and non-visual browsers alike. We will do this by separating the password and user data portions with the fieldset element. We will give each part a legend element to describe the information being requested.
The first fieldset is for user details:
<fieldset>
<legend>Add user's details:</legend>
<label for="first-name">First name:</label>
<input type="text" id="first-name" />
<br />
<label for="last-name">Last name:</label>
<input type="text" id="last-name" />
<br />
<label for="email">E-mail:</label>
<input type="email" id="email" />
</fieldset>
The second fieldset is for setting a password:
<fieldset>
<legend>Set a password:</legend>
<label for="password">Password:</label>
<input type="password" id="password" />
<br />
<label for="confirm-password">Confirm password:</label>
<input type="password" id="confirm-password" />
</fieldset>
- To finish, we add some styling to the fieldset element by adding the following declaration to the style element:
.signup fieldset {
margin: 1rem 0;
background: #f5ffff;
border: 2px solid #52a752;
}
The end result will be similar to what is shown in the following figure. The screenshot shows the final output – an accessible signup form:
Figure 9.10: The accessible signup form we have created
This form has been labeled and the labels are paired appropriately, to form fields. The form fields are grouped to help a user make sense of them. All users will benefit from these structural grouping and labeling techniques and they will allow screen reader users to sign up successfully.
In this exercise, we have created an accessible form and learned about grouping parts of a form and associating labels with inputs to make sure users can access the form using a screen reader.
In the next section, we will look at keyboard accessibility. The keyboard provides input for many users who cannot use a mouse. As developers, we cannot take mouse usage for granted. Many users find the mouse difficult or impossible to use and many use the keyboard out of necessity or as a preference.
Keyboard Accessibility
For some of our web page's users, a mouse may not be of much use. It requires the ability to follow a visual pointer on screen, a certain amount of sensitivity of touch, and fine motor skills.
Whenever we test our web pages, we should check that we can use the keyboard to get to all the content and that we can interact successfully without using a mouse.
We can navigate through a web page using the following keys on the keyboard:
- Tab
- Shift + Tab
- Enter
To navigate a web page, we use the Tab key to cycle through elements on the web page. We can see this if we open the Exercise 9.02.html file and use the Tab key. Shift + Tab will cycle in the reverse order. We can use the two in combination to move back and forth through the elements of the web page.
In the following screenshot, you can see the default focus ring on the First name input field:
Figure 9.11: Form with focus on the First name field
In the following screenshot, we see that the focus ring has moved to the Last name input. This is because we pressed the Tab key:
Figure 9.12: Form with focus on the Last name field
To submit a form or interact with a link or button, we can use the Enter key. In the case of buttons, we can also use the Spacebar to use the button.
To toggle the radio and checkbox input fields, we can use the spacebar.
Checking that styling or JavaScript has not made the tab order confusing is very important for keyboard accessibility.
We should also make sure that our interactive elements, such as buttons and input fields, have some differentiation for when they have focus. We can do this with the :focus pseudo-class in CSS.
Making sure you can consistently interact with the elements on your web page using a keyboard helps you know with confidence that a user will not find barriers when using your web page.
Accessible Motion
CSS animations and transitions have become a massive part of creating rich and visually interesting web pages. We learned about animating our web pages in Chapter 8, Animations. Motion can add a lot to a web page and can help us highlight content or make content changes more obvious.
With power comes responsibility, and in the case of motion, we should consider whether repeated transitions and animations may cause a user distraction and, in some cases, irritation or make for a difficult user experience.
In particular, repetitive motion, parallax effects, and flicker effects can be really bad for people with vestibular disorders, where such motion can cause severe discomfort and even nausea.
As browsers get better integration with operating systems, they can make use of more fine-grained accessibility configurations. In the case of motion, a media query has been added to most modern browsers, which we can use to check whether the user prefers to have reduced levels of motion. We can combine this, responsively, with our CSS transitions and animations to give a user the appropriate experience.
The media query is prefers-reduced-motion and it has two possible values: reduce or no-preference.
For example, the following CSS would apply an animation only if the user has no preference regarding the prefers-reduced-motion media query:
<div class="animation">animated box</div>
<style>
.animation {
position: absolute;
top: 150px;
left: 150px;
}
@media (prefers-reduced-motion: no-preference) {
.animation {
animation: moveAround 1s 0.3s linear infinite both;
}
}
@keyframes moveAround {
from {
transform: translate(-50px, -50px);
}
to {
transform: translate(50px, 100px);
}
}
</style>
We can test this media query by configuring the accessibility setting in our operating system. To do so, do the following:
- On Mac, go to System Preferences > Accessibility > Display and toggle the Reduce motion checkbox.
- On Windows, this preference can be controlled via Settings > Ease of Access > Display > Show Animations.
The following screenshot shows the Accessibility Display preferences on Mac with the setting for Reduce motion selected:
Figure 9.13: Mac display preferences with the Reduce motion toggle
In the next section, we will look at how we can use tools to help understand and audit a web page for accessibility problems.
Accessibility Tools
There are a lot of in-built and third-party tools available that can help with different aspects of accessibility.
A great number of tools have been created that can help us with the accessibility of our web pages. Some are good for diagnosing issues and auditing pages for structural issues, some help us check tab order and keyboard accessibility, and some help us with design decisions around color contrast and text legibility.
In this section, we are going to look at the Axe accessibility checker, which can be used to audit a web page or site to highlight issues in our semantics and HTML structure that may cause accessibility issues.
Axe Tool
Axe is a tool from Deque. It is a popular accessibility testing tool that can be used to flag issues on our web pages. There are several versions of the tool, but we are going to look at the free Chrome extension.
To install the Axe extension, we can go to the Chrome web store at https://packt.live/2WSY7Iz.
If you are running the Axe tool on a local file (file://), you may have problems with Axe throwing an error. The solution is to do the following:
- In your browser, navigate to https://chrome.google.com/webstore/category/extensions.
- Find the Axe extension (with the heading axe - Web Accessibility Testing).
- Click the details button.
- Locate the Allow access to file URLs switch and enable it.
This will allow you to run the Axe extension on local web pages.
The tool is added as an axe tab in the Chrome web developer tools. Open the web developer tools and select the Axe tab. You will see the panel shown in the following screenshot:
Figure 9.14: Axe accessibility checker Chrome extension
To run the accessibility checker, we click the ANALYZE button in the left-hand panel. This will check the site we are currently on and report any issues it has detected from analyzing the markup.
The following screenshot shows the reported results from running Axe on a web page. In the left-hand panel, we can see a summary of all the issues that were found. These can be anything from semantic HTML issues, through incorrect levels of nested headings, to color contrast issues. The right-hand panel provides a more detailed description of an issue, including the location of the issue and what can be done to fix the issue:
Figure 9.15: Axe accessibility checker report
Taking the preceding screenshot as an example, we can see that four different issues have been reported on in the analyzed page. The issues are as follows:
- Document must not have more than one banner landmark
- Ensures landmarks are unique
- All page content must be contained by landmarks
- Elements must have sufficient color contrast
Several of these refer to landmarks, which we learned about in the Semantic HTML section. The results are flagged for the following reasons:
- An HTML page should only have one banner landmark (meaning, the HTML header element or the WAI-ARIA role="banner" attribute) this is because it makes the web page easier for non-visual users to navigate and find their way around.
- A landmark should be unique, which means it should have a unique combination of role and label. This helps to distinguish between landmarks. Again, this improves navigation around the web page.
- All the content of a page should be contained within a landmark (such as a header, footer, nav, or role="banner"), and again, this is important for web page navigation.
- Strong color contrast helps users to distinguish text from its background and helps all visual users, especially those with visual impairments. Axe can detect low contrast levels between a foreground (text color) and background color and will flag such issues.
These are just a few of the many topics that the Axe tool can and will flag for you.
In this section, we've looked at the Axe tool and some of the results it flags. Next, we will try it out on a web page of our own.
Exercise 9.03: Using Axe
In this exercise, we will run the Axe tool on a web page and analyze the findings in the report it creates.
The steps are as follows:
- First, create and save a file named Exercise 9.03.html. In Exercise 9.03.html, copy and paste in the following code to set up an HTML page. The page is the bare bones of quite a simple layout and contains some landmarks (such as nav, header, and footer). We will open this page in the browser where we have the Axe extension. The following screenshot shows this page:
Figure 9.16: Site structure
- Next, open the developer tools and select the Axe tab. Then, run the Axe analysis tool by clicking the Analyze button.
- The results of running the tool on this page will be a set of five flagged issues on the page. The resulting issues are as follows:
Elements must have sufficient color contrast
Document must not have more than one banner landmark
Document must have one main landmark
Ensures landmarks are unique
All page content must be contained by landmarks
- We will look at each issue one by one. The details of the first result are selected by default.
As shown in the following screenshot, we have several elements with insufficient color contrast. From the issue description, we can see that this is because the top nav has a yellow background and white text. The text is barely visible:
Figure 9.17: Details of the "Elements must have sufficient color contrast" issue
- Select the next result (Document must not have more than one banner landmark). This issue is caused by having both a header element and a div element with role="banner". Both of these landmarks have the same purpose and role in an HTML page. We can see the suggested solutions in the following screenshot:
Figure 9.18: Details of the "Document must not have more than one banner landmark" issue
- Next, we select the third result (Document must have one main landmark). This issue is caused by having no main element or element with a role="main" included on the page. We have a div with class="content", but we could benefit our users by making this a main element. Again, we see the suggested solution in the following screenshot:
Figure 9.19: Details of the "Document must have one main landmark" issue
- Next, we select the fourth result (Ensure landmarks are unique). This issue is similar to the second one and is caused by the same problem (that we have a header and an element with role="banner"). This means that the two landmarks are not unique. We can see the solution in the following screenshot:
Figure 9.20: Details of the "Ensure landmarks are unique" issue
- Next, we select the final result (All page content must be contained by landmarks). The cause of this issue is the content being in a div that is not a landmark (the div with class content). Again, we can fix this by changing this div to a main element. We can see the solution in the following screenshot:
Figure 9.21: Details of the "All page content must be contained by landmarks" issue
By running the Axe tool, we have found some issues early in the development of a web page, when they can be easily solved. The Axe tool has helped us discover these issues quickly and has suggested solutions.
In this exercise, we have seen how the Axe web accessibility checker can help us identify structural, semantic, and visual accessibility issues in our web pages.
To put into practice all the skills we have learned in this chapter, we will finish with an activity in which we will use the Axe tool to diagnose some issues with a web page. We will then fix the issues that have been flagged for us.
Activity 9.01: Making a Page Accessible
You have been asked by a client to look at the accessibility of their product feedback page. The client has received several complaints from users trying to send feedback. The client has provided the source code for the page and wants you to make changes to improve the accessibility of the page.
The steps are as follows:
- First, make a copy of the activity_1_inaccessible.html file and rename it Activity 9.01.html. The code for activity_1_inaccessible.html is at https://packt.live/2NqdLYY.
- Run the Axe accessibility checker tool on this page.
- In the Axe tool's summary, you should see five types of issues flagged by the Axe tool.
- Fix each of the issues with the techniques you have learned about in this chapter and the hints that are given by the Axe tool.
- Then, run the Axe tool again to check that the issues have been fixed.
Note
The solution to this activity can be found in page 609.
Summary
In this chapter, we learned about accessibility. We looked at some of the simple techniques we can employ to make our web pages accessible. We also learned about the right ways to use alt text and text descriptions to make the images we embed in a web page accessible to users who can't see the image. We then learned about making forms accessible and about controlling a web page via the keyboard.
Most importantly, we raised awareness about a topic that affects a lot of people and an area that all web developers should champion.
In the next chapter, we will look at how build tools can help us with developing complex modern websites and how we can use preprocessors to expand the capabilities of what we can do in web development.