But not everyone experiences the web in the same way. Websites are difficult to use for people who have visual, hearing, or mobility impairments. These barriers make it harder to navigate content, and in some cases, make the web completely inaccessible.

This handbook will help you understand accessibility and how to implement it. Whether you are a beginner or an intermediate developer, you'll learn basic accessibility practices and some advanced techniques. This will help you make your website more inclusive.

Let’s get started.

Table of Contents

• What is Accessibility?

• Basic Accessibility Practices

  • Semantic and Non-Semantic HTML

  • Text Content

  • Page Layouts

  • Interactive Elements

  • Keyboard Accessibility

  • Form Labels

  • Links

  • Table Accessibility

• Additional CSS and JavaScript Practices

  • Styling Form Elements

  • Color Contrast

  • JavaScript Practices

• Advanced Accessibility Practices: WAI-ARIA

  • The role attribute

  • aria-* attribute

  • Dynamic Content Attributes

  • Form Validation and Errors

  • Using non-semantic elements as buttons

• Multimedia Accessibility

• Mobile Accessibility

What is Accessibility?

Accessibility (A11y) is an important practice in web development that aims to make the website usable (accessible) for all people. This includes people who have disabilities that make it difficult for them to use websites. By making a website accessible to everyone, including people with disabilities, we ensure that they have the same opportunities as we do. We’re also helping to make the web a more inclusive place overall.

What kind of disabilities should we consider? In broad terms:

• Visual impairments: blindness, blurred vision, and colour blindness

• Hearing impairments: low to no hearing

• Mobility Impairments: difficulty with physical movement(s)

• Cognitive Impairments: like Dyslexia and ADHD

People with visual impairments commonly use devices like screen readers to visualise and understand a website’s content, for example. So a big part of web accessibility is designing a website that can be easily accessed by a screen reader.

There are various practices that you, as a developer, can follow to make a website accessible, which I’ll cover in this handbook.

Basic Accessibility Practices

Accessibility is not just an added feature on top of a website you’ve already developed. It is a practice that needs to be followed throughout the development process. Whenever you are creating content on the web page, ask yourself if it is really accessible.

Another important point is that accessibility is not just for people with impairments. It benefits everybody by making a website easier to use, thus improving overall user experience.

How do you achieve good accessibility? Well, there are some practices that you should follow while writing HTML, CSS, and JavaScript code. We’ll discuss some basic practices in this section.

Before we get into it, let’s start by understanding what semantic and non-semantic HTML tags are:

Semantic and Non-semantic HTML

Non-semantic HTML tags do not convey specific meaning or purpose. They can be used for anything, depending on the CSS styling and JavaScript functionality. Examples of non-semantic tags are: <div> and <span>. These tags are mostly used as containers for wrapping other elements.

Semantic HTML tags clearly describe their purpose to the browser and the developers through their names. They improve code readability and also help with SEO (Search Engine Optimisation). Examples of semantic tags include: <button>, <a>, <header>, <footer>.

You can find a list of all semantic elements here.

Importance of using semantic HTML

An essential part of accessibility is using the correct HTML element for its intended purpose. This means, for example, using a <button> tag when you want to render a button.

But why use semantic elements? After all, you can use CSS to make a <div> look like a button. True, but using semantic elements is important for the following reasons:

• Semantic elements have built-in styles and functionality that you otherwise would need to add through CSS and JavaScript. This makes them easier to use.

• They make the code easier to read and maintain, as you can actually see the elements being used rather than seeing a bunch of divs everywhere.

• Screen readers can easily read and interpret semantic elements, helping people with visual impairments.

In the following sections, we’ll understand basic accessibility practices for each type of content you render on HTML. We'll explore how to use the correct HTML tags for each situation, helping you see how choosing the right tag for its purpose improves accessibility.

Feel free to test each example with a screen reader. On Mac, use ⌘+F5 to activate VoiceOver, Mac’s built-in screen reader. For Windows, you can use the built-in screen reader called Narrator by pressing Ctrl + Windows Key + Enter.

Text Content

When writing text content, it’s important to use the correct elements for headings, paragraphs, and lists. Let’s understand with the following examples.

Let’s say you write headings and paragraphs in the following way:

<span id="heading1">Heading 1</span>
<br />
<br />
<span id="heading2">Heading 2</span>
<br />
<br />
This is one paragraph
<br />
<br />
This is another paragraph

This approach has the following problems:

• The screen reader won’t be able to distinguish between headings and paragraphs – it would just read out the contents in one go, thus confusing people who depend on screen readers.

• It’s difficult to style individual paragraphs, since there are no selectors. Even if you add a <span> to each one, it requires extra CSS styling.

• It also contains unnecessary line breaks which can be avoided by using the right elements.

The above code is an example of bad semantics. This is what you should do instead:

<h1>Heading 1</h1>
<h2>Heading 2</h2>
<p>This is one paragraph</p>
<p>This is another paragraph</p>

Here, we have used the right semantic elements for the text content, which has the following benefits:

• A screen reader is able to distinguish the headings from the paragraph text by reading out the heading level before reading the text.

• h1, h2, and p come with built-in styles and they each render on a new line. This eliminates the need to use line breaks.

• The code looks cleaner and is much more readable.

Lists

To render a list of items, we have the following approaches. The non-semantic approach just groups a bunch of divs together and applies CSS styles to them.

<h2>TODO List</h2>
<div id="mylist">
  <div>Make Breakfast</div>
  <div>Do Laundry</div>
  <div>Complete blog post</div>
</div>

Again, this achieves the desired output but it’s difficult for screen readers to identify this content as a list of items. Instead, use semantic elements:

<h2>TODO List</h2>
<ul id="mylist">
  <li>Make Breakfast</li>
  <li>Do Laundry</li>
  <li>Complete blog post</li>
</ul>

This helps screen readers identify the element as an unordered list and read out each item. <ul> also comes with default styles and bullet points for each list item. You can also use <ol/> for numbered lists, where the screen reader reads out the number on each list item.

You can test the above examples with Mac’s VoiceOver to see the difference.

Emphasized Text

Emphasized text refers to highlighted text that gives importance to certain words or phrases within a piece of content. When adding emphasized text, it’s important to use the right semantic elements like <strong> and <em>.

<p>For best results, use <em>fresh ingredients</em> when cooking.</p>

<p>The process of water turning into gas is called <strong>evaporation</strong>.</p>

These elements add some built-in styles to the text like bold and italic. Also, if you test with VoiceOver, you’ll notice that it puts some emphasis on the text inside these elements. This helps people using screen readers identify emphasised text.

You may also add some colour to the emphasized text. But, there’s no need to add a lot of styles, else it may cause confusion. Visit MDN Docs-Emphasis and Importance to learn more about text emphasis in HTML.

Abbreviations

Next, when writing abbreviations (or acronyms), it’s a good practice to make them visually different and also include the full expansion of the acronym. You can also add some simple styling to the abbreviation. Learn more about abbreviations in MDN Docs-Abbreviations.

Other best practices

Apart from the above, there are a few other practices that are good to follow:

• Use clear language, wherever possible. For example, expand abbreviations: instead of Jan, write January.

• When writing ranges, avoid using dashes if possible, write 1 to 5 instead of 1-5.

• Avoid using characters that may confuse users when a screen reader reads them out, for example ~ or *.

• Avoid excessive exclamations and emojis.

Also, when writing CSS for text content, remember these practices:

• When using styles like font sizes, line height, and letter spacing, ensure that the text is comfortable to read.

• Your headings should stand out from the other text, in case you are using CSS styles. Usually, this is achieved by just using the right heading tags.

• Text color should have 4.5:1 contrast with the background. See the Color Contrast section for details.

If you want more tips on styling text, visit MDN Docs - CSS Text Styling.

Page Layouts

Page layout is concerned with how the content is laid out on the screen. When you start designing a web page, your first thought is how your content should be positioned on the screen.

Typically, a web page consists of a header, nav bar, footer, main content, and sidebar. In the bad old days (phrase borrowed from the docs, sorry), developers used tables to create page layouts consisting of these elements.

But tables made the layouts incredibly complex and hard to maintain. Table layouts are also difficult for screen readers to read, affecting accessibility.

Nowadays, there are much better ways to write page layouts. If you are including a header, nav bar, and footer along with the main content, you can use the following semantic elements:

<header>
  <h1>Header</h1>
  <nav>
    <!-- main navigation in here -->
  </nav>
</header>

<!-- Here is our page's main content -->
<main>
  <!-- Main content here -->
</main>

<footer>
  <!-- footer content in here -->
</footer>

Let’s understand each tag used above (skip if you already know):

• <header>: Represents the introductory section of a webpage, typically containing headings, logos, or navigation links.

• <nav>: Defines a navigation section that contains links to other parts of the website or page, providing easy access to important sections.

• <main>: Represents the main content area that focusses on the primary purpose of the page or the website, excluding common elements like header, footer, or sidebar (may include sidebar depending on the website).

• <footer>: Represents the bottom section of the web page, typically containing metadata, copyright information, or links to related resources.

These elements are called sectioning elements. Following are advantages of using these elements:

• The layout is clear with each element clearly describing its purpose, making the code readable and maintainable.

• Using the right semantic elements makes screen readers identify each part of the layout, thus helping visually impaired users understand how the website is structured.

Of course, you can write the above layouts by using divs, but sectioning elements provide good semantics and help users understand the type of content they are navigating.

Interactive Elements

These consist of elements through which a user interacts with the web page. These elements include buttons, form fields, links, and so on.

Keyboard Accessibility

Each interactive element on a web page should be navigable through the keyboard. This gives a user flexibility while navigating your website. Keyboard accessibility is really helpful for people with mobility impairments that may struggle to use a mouse.

For instance, visit this page and try to navigate to each interactive element by pressing Tab on your keyboard. You can also press Enter/Spacebar to click on a button or a link. This should give you an idea of what a keyboard-accessible website looks like.

For the most part, using the right semantic elements should ensure keyboard accessibility, as they come with built-in functionality. Check out the following example:

<p>
  Visit my blog at 
  <a href="https://www.freecodecamp.org/news/author/KunalN25/">freecodecamp.org</a>
</p>

<button>Click me</button>
<button>Click me again</button>

<div>
  <input type="text" placeholder="Enter your name" />
</div>

Here, we have used the correct semantic elements for the hyperlink, button, and input element. All these elements can be accessed through Tab and interacted with using Enter/Spacebar. Check out other form-related elements in this list.

Some people use a div or span and make them look like an anchor tag or a button with CSS styling. But this is bad for accessibility for two reasons:

• div and span are not tab-able by default. So, even if you do make a div look like a button, the user cannot navigate to it using the keyboard.

• Screen readers won’t be able to identify them as buttons, while in the case of semantic elements, they read these elements out as buttons or links.

But if you absolutely have to use a div to create a clickable element, include the following attributes:

<div id="customButton" role="button" tabindex="0">Click me</div>

Here, we have added two attributes, tabindex and role. We’ll understand the role attribute in a later section.

The tabindex attribute takes an integer that specifies the tab order of tab-able elements, instead of the default top to bottom tab order. A positive integer means the element is focussed in an order specified by the attribute’s value.

But using tabindex to change the default tab order is not recommended, as it may cause confusion for keyboard navigators and affect accessibility. And frankly, it’s not necessary.

You should only ever use the following two values:

• tabindex=”0” makes an element tab-able which means it can be accessed through a keyboard in the natural tab order.

• tabindex=”-1” means the element is not reachable via keyboard navigation.

These attributes make the div behave like a button, but there’s a small piece of JS code you still need to add to make the button clickable via Enter/Return:

document.getElementById("customButton").addEventListener("keydown", (event) => {
  if (event.key === "Enter") {
    document.activeElement.click();
  }
});

Here, we have added an event listener to the element that listens for the keydown event. If the key pressed is Enter, then it calls the element’s onclick method.

If you are using a non-semantic element as a button, you need to add this extra code to make it work like a button. So, only use it if it's absolutely necessary. Otherwise, it's always better to use the correct semantic element in the first place.

Keyboard Accessibility is important for audio and video controls too. We’ll discuss this in the Multimedia Accessibility section.

Form Labels

A form label is some text that describes what you need to enter in a form field. Adding labels to form fields is a necessary practice since it lets the user know how to fill the form. But using the right semantic elements is important.

You could do the following and still achieve the desired output:

Enter name: <input type="text" id="name" name="name" />

This is not good for screen reader users, as it does not read out what the input field is for. Even if it reads out “Enter name”, the user may not associate it with the input field. Instead, use the <label> element for form labels.

<div>
      <label for="name">Enter name:</label>
      <input type="text" id="nameField" name="name" />
    </div>

The for attribute associates the label with the input field. With this, when the screen reader’s focus is on the input field, it reads out the label, followed by “edit field” to let the user know they should enter their name in the input field.

Check out the form with the label and form without the label in these examples for more clarity. Use Mac’s Voiceover (⌘+F5) or Windows’ Narrator (Ctrl+Windows+Enter) to see how it reads out the form elements.

Using <label> offers more advantages:

• By linking a <label> to an input field with the for attribute (clickable association), clicking on the label focuses on the input field.

• Clickable association with input field helps the user’s select small inputs like checkboxes or radio buttons.

• It follows semantic HTML and specifies that the text is being used as a form label.

Lastly, remember that the label text should clearly describe what the user should enter into the field. For examples, “Enter name” or “Enter email”.

This applies to buttons as well. Ensure that button text is descriptive enough to tell the user what they are clicking on. Vague texts like “Click me!” or “Click here!” are not helpful. Examples of descriptive text are “Submit Form” or “Download Report” that give the users a clear idea of the button’s action.

Along with these, links also come under interactive elements. But since there are a lot of examples for Links, I’ll discuss them in their own section now.

Links

Links are a key part of web pages as they allow the user to navigate the website. Links serve different purposes: going to a different page in the same website, going to an external website, or downloading something. In this section, you’ll learn about several practices with links that contribute towards accessibility.

Linking to External Websites

When you add a link that lets users open an external website, including the target=_blank attribute opens the link in a new tab.

<a href="https://www.wikipedia.org/" target="_blank"> Wikipedia </a>

This is helpful for users as they don’t need to exit the website, saving them from the hassle of navigating back to the website.

Also, if your link opens in a new tab, it’s a good idea to mention it so the screen readers can read it out and help visually impaired users.

<a href="https://www.wikipedia.org/" target="_blank" >
Wikipedia (opens in new tab)
</a>

Similarly, if your link opens a non-HTML file, like a pdf or docx, you should mention it:

<a target="_blank" href="jan-salary-slip.pdf">
Salary-January (PDF)
</a>

Alternatively, you can use an icon to indicate a link opening in new tab.

<a href="https://www.wikipedia.org/" target="_blank">
  Wikipedia
  <img src="new-tab-icon.png" alt="Opens in new tab" style="width:16px; height:16px; margin-left:5px;">
</a>

When using an icon, make sure that you include the alt attribute with description about the image. We’ll understand its purpose in the Multimedia Accessibility section.

Skip Links

A skip link is a link element placed at the top of a page that links directly to the main content of the page. This allows the users to skip the headers and all the navigation menus, and directly jump to the main content of the page. This is helpful on websites where there’s lot of repetitive content on top like menus or banners.

Skip links are especially helpful for people who are visually impaired and who might be using screen readers. These links provide a way to bypass repetitive navigation menus and directly access the main content. This also helps keyboard navigators, thus saving time and enhancing the user experience.

To add a skip link, add an anchor tag at the very top, just under the body tag, and link it to the main content.

<body>
 <a href="#main">Skip to main content</a>
    <header>
      <h1>Page Title</h1>
      <nav>
        <ul id="nav-links">
          <li><a href="/">Home</a></li>
          <li><a href="/about">About</a></li>
          <li><a href="/blog">Blog</a></li>
          <!-- other nav links -->
        </ul>
      </nav>
    </header>
    <main id="main">
      <!-- Main Content -->
    </main>
</body>

The skip link is keyboard accessible and is also read out by the screen reader. Clicking on it takes you straight to the main content. Visit WebAIM and press Tab on your keyboard to see skip links in action.

Link Styling

By default, links created with the anchor tag are visually different from non-link text. This is because the anchor tag has built-in styles like colour, text-decoration, focus-ring (displays when you tab on to the link with the keyboard) and hover effects.

Links should look different from the other text so they’re easily distinguishable. As you saw above, the browser does that for you, so you don’t need to do much. But if you are adding custom styles to the link that fit in better with your theme, you need to follow some best practices:

• Links should have different colors for default, visited, focus and hover states.

• Link text color should be different from the non-link text and should have different styling.

• Link text color should have a contrast of 3:1 between other text and 4.5:1 contrast between background color. See the Color Contrast section for more understanding

An example of custom styling for links is shown below (from the Docs):

a {
  color: #ff0000;
}

a:hover,
a:visited,
a:focus {
  color: #a60000;
  text-decoration: none;
}

a:active {
  color: #000000;
  background-color: #a60000;
}

With the help of pseudo-classes, this adds different styles for when link is hovered, previously visited, focussed (with the keyboard), or active (when the link is being clicked).

You can experiment with different colors and styles, but don’t remove the cursor: pointer or outline properties. Both are important for people using keyboard navigation.

Remember, links already have built-in styles for all the link states. Only add your own if you want something in line with your website’s theme.

Avoid using onclick handlers

Links are used to navigate to another web page on the same website or navigate to an external website. Specifying the link in the href attribute does this for you without any need to add JavaScript code.

But some people add an onclick attribute to anchor elements, to make them behave like buttons and set href=”#” or href="javascript:void(0)" to avoid page refresh. This causes unexpected behaviour and may lead to the following problems:

• Copying or dragging this link adds an unnecessary # or void(0) to the URL, which does not make sense.

• Clicking the link immediately scrolls the page to the top, which may lead to the user losing track of where they were.

• If JavaScript is still downloading, clicking the link does nothing and the web page becomes unresponsive.

It is also bad for semantics and accessibility, as people using screen readers may get confused. If you want to add JavaScript functionality on click of an element, just use a <button>. Only use links when navigating to a proper URL.

Meaningful Link Text

Similar to buttons, when writing link text, keep it meaningful and descriptive and avoid using “Click here” or “Click this”.

<p>
  For more information about accessibility
  <a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility">
    click here
  </a>
</p>

Instead of the above, do this:

<p>
  For more information about accessibility, visit
  <a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility">
    MDN Docs - Accessibility
  </a>
</p>

Check out the Good Links and Bad Links examples from the docs. You can also test them with VoiceOver (⌘+F5).

Link Proximity

If your web page has a lot of interactive elements like links and buttons, ensure that they are spaced properly to prevent accidental clicks. This helps people with Motor Control Issues that may click on the wrong link.

Using the margin property should be enough to ensure spacing.

Table Accessibility

In the page layouts section, we saw that using tables for creating page layouts is an outdated practice. However, tables can still be used if you want to display a large amount of data in tabular form. Incorporating accessibility in tables helps screen readers interpret them and help visually impaired users.

Check out MDN Docs - Table Accessibility to understand best practices.

Additional CSS and JS Practices

Most of your accessibility goals should be achieved with HTML alone. But there are certain things to keep in mind when writing CSS and JavaScript to ensure you don't break accessibility.

Styling Form Elements

When styling form elements, remember the following:

• Do not remove the default styles for focus outlines, hover, and disabled state in form elements. You may modify them as per your site design, but they should still be visible.

• Ensure that your labels and placeholder texts are visually clear. Follow colour contrast practices (next section).

• For clickable areas like buttons and inputs, ensure they are large enough so the user can click comfortably.

• Success and Error messages should be physically distinguishable from labels and other text content.

Color Contrast

When you choose colors for your website, your text and background colour should have a good colour contrast. A good color contrast ensures that the text is easily readable by all users (and it also helps people with color blindness in particular).

The WCAG (Web Content Accessibility Guidelines) recommends the following contrast ratios:

Let’s understand the colour contrast ratings:

• AA rating refers to the minimum ratio your colour contrast should be such that the site’s content is readable. As you can see in the table above, this requires a 4.5:1 minimum ratio for body text, a 3:1 ratio for large-scale text, and a 3:1 ratio for active user interface components and graphical objects.

• AAA rating is the ideal standard for accessibility that ensures high contrast for your website. This requires a 7:1 ratio for body text, a 4.5:1 ratio for large-scale text, and isn’t defined for UI components/graphical objects.

Choose a contrast ratio that aligns well with your design, but try to keep it to at least AA rating. To check colour contrast ratio between two colors, you can use the following tools:

• Color Contrast Checker

• Chrome Developer Tools - Identifies text in your website not meeting AA and AAA ratings

JavaScript Practices

Mouse-specific events

When you have functionality triggered by events like mouse-over and mouse-out, they cannot be accessed by people that depend on keyboard navigation. So, to make the functionality accessible by keyboard, you need to add the same event handlers to events like focus and blur.

Client side form validations

When you submit data through a form, the data is validated to check if you have entered valid data. Often, when the data is sent to the server, the server validates the data and lets the UI know if the validation has failed.

To make the website user-friendly, it helps to add form validations on the client-side, so users can get instant feedback if they have entered incorrect data, since the server-side mechanism may take time. This is a very small step towards improving user experience.

Check out the Form Validation Example to understand more.

Apart from the above, one thing you should remember is not to use JavaScript for anything and everything. JavaScript can be used to generate any form of HTML and dynamically apply CSS styling. It is very helpful if you have dynamic content on your website.

But if you have too much HTML generated by JavaScript, it gets hard for screen readers to keep track of the dynamic changes. This makes the website difficult to read for impaired users. So, make sure you don't overuse JavaScript when simple HTML would be enough.

Accessibility for dynamic content updates is covered in the next section.

Advanced Accessibility Practices: WAI-ARIA

As applications started to get bigger and more complex, developers started needing a new set of accessibility features. Semantic elements alone were not enough, especially for complex elements like date pickers and custom widgets.

Depending on semantic HTML does not help when content is updated dynamically on the web page. Nowadays, all websites built with JavaScript have content that isn’t loaded initially, but updated dynamically based on user interactions.

WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) was introduced to add more accessibility features wherever they were needed. It defines a set of HTML attributes that you can use to provide additional semantics to your website and improve accessibility.

In the following sections, you’ll learn which attributes were introduced and how you can use them to enhance accessibility.

The role attribute

The role attribute helps add semantic information to non-semantic elements by defining their “role” on the web page. With roles, screen readers can accurately read non-semantic elements and help identify them for people with disabilities.

W3C defines several roles that you can use, depending on their purpose. But keep in mind that you should only use role when necessary. In most cases, it’s better to just use the right semantic elements like <button>, <nav>, <header>, and so on.

But, when semantic elements are not fulfilling your purpose, roles can help. So, let’s understand how to use them with some examples:

If you want to create a button with custom div, adding the role attribute specifies that this element is being used as a button.

<div role="button" tabindex="0">Click Me</div>

When you test this with Mac’s VoiceOver (⌘+F5), it reads out the element as a button. As discussed before, always include the tabindex attribute.

But if you want to use a div instead of a button, you still need to add JavaScript functionality, as explained in the the Keyboard Accessibility section.

Another example is if you are writing a custom link. You can use the following role, so that the screen reader interprets this as a link:

<div role="link">Visit our website</div>

Apart from interactive elements, role attribute can also be used to define elements as navigation menus, side bars, banners, etc. If you are using non-semantic elements for these purposes, always include a role, like the following:

<div role="navigation">
    <!-- Navigation menu items -->
</div>

In this case, the screen reader announces this as a navigation area.

Also, if you have an element that serves as an alert for the user, including the following role makes the screen reader announce it as soon as it shows up on the screen, even if it doesn’t have focus:

<div role="alert">
  Please respond to this alert
</div>

You can find the full list of available roles at MDN Docs: WAI-ARIA Roles.

aria-* attributes

Apart from role, ARIA (Accessible Rich Internet Applications) defines extra attributes to enhance the accessibility of web applications. These attributes give screen readers more information about elements, helping people with disabilities better understand them.

If native semantic elements or the role attribute alone are not sufficient, aria-* attributes can provide extra context. You can find a full list of these attributes in MDN Docs-ARIA.

In the following sections, we’ll see how role and aria-* attributes can improve accessibility. We won’t cover all the attributes here, but we’ll focus on the most commonly used ones.

Dynamic Content Updates

When a web page loads for the first time, its content is read out by the screen reader. But screen readers cannot capture dynamic content, that is content that gets added or removed.

For example, when a web page is showing live sport updates, it gets updated almost every minute. Screen readers will only read out the content displayed when the page is first rendered, but don’t show dynamic updates.

This is not really a problem for many users, but for people with visual impairments, screen readers may not be able to read the changes on the page. Most modern websites are dynamic in nature, so it’s important to consider accessibility of dynamic content updates.

Check out the aria-no-live example from MDN Docs. It loads a new quote every 10 seconds, which you can see clearly as a user with no visual impairment. But the screen reader only reads the initial page content and does not announce the updates. This is not good for accessibility.

To fix this, WAI-ARIA provides the aria-live attribute that makes the screen reader read out content that is updated. You can add this attribute to the element that contains the dynamic content.

It takes the following three values:

• aria-live="off": Default value that means no content is read out

• aria-live="polite" Updates only announced when the user is idle

• aria-live="assertive": Content read out as soon as it is updated.

Depending on the importance of the update, you can decide which value to use.

<div aria-live="polite">
    <!-- Dynamic Content here -->
</div>

In this case, the screen reader waits till the user is done with their current task before announcing the update.

You can add more detail here. With the above attribute, only the text that is updated is read out. But, screen reader users may get confused as to which part of the page is being read out. So, it is helpful if the entire element is read out.

<div aria-live="assertive" aria-atomic="true">
    <!-- Dynamic Content here -->
</div>

The aria-atomic attribute tells screen readers to read out the entire element as a single atomic unit. This avoids confusion for visually impaired users. Check out the aria-live example from MDN Docs with Mac’s VoiceOver (⌘+F5). It reads out the entire element when the content is updated.

Form Validation and Errors

Let’s say you have added some validation to your form through JavaScript. When the validation fails, an error message gets added on the screen. For example, a required message shows up if you have missed a field.

The implementation for error handling involves creating an element containing an error message or a list of errors that render on certain conditions, depending on the JavaScript code. Just as we discussed in the previous section, the screen reader does not read out new content updates.

So, we should make sure that the screen reader reads out the error message as soon as it shows up, to let visually impaired users know that an error has been thrown. We can use the following attributes for this purpose:

<div class="errors" role="alert" aria-relevant="all">
  <ul></ul>
</div>

The alert role does two things. It semantically identifies this element as a piece of important information. Secondly, this role turns the element into a live region which means the screen reader is notified immediately if there are any changes.

The aria-relevant attribute describes what changes need to be announced in a live region. The attribute takes a space-separated list of the following values:

• additions: Announces new content added to the live region

• removals: Content removed from the live region is read out

• text: Announces any modifications to existing content.

It also takes a value all which is a shorthand for additions removals text, meaning all three types of content are read out.

You can check the Form Validation Example from the MDN Docs.

Next, let’s see what to do if we want to mark certain fields as required. Normally, we’d add visual cues like a * and the following message at the top of the form:

<p>Fields marked with an asterisk (*) are required.</p>

This is helpful for regular users, but visually impaired users may get confused as to which fields are required. To make it easier for them, we can use the aria-required attribute.

<input type="text" name="name" id="name" aria-required="true" />

With this attribute, the screen reader mentions this field as “required” while reading it out.

When you are creating input fields, it’s important to include a label, as some screen readers do not read out placeholder text. If you don’t want to include a label field, here are the following alternatives:

You can use the aria-label attribute to add labels to input fields that do not have a label associated with them.

<input type="email" name="email" aria-label="Enter email" />

This attribute provides some text to be read out by a screen reader to describe the input field.

You can go one step further and use the aria-labelledby attribute that uses another element to act as a label for the input field. For example:

<div>
  <span id="emailLabel">Enter your email</span>
  <input type="email" name="email" aria-labelledby="emailLabel" />
</div>

The screen reader reads out the text inside the <span> element to describe the input element. This is similar to having a <label> with a for attribute. You can also use this attribute to reference other interactive elements like <button> or <a> that do not have a label field to reference them.

Keep in mind that the aria-labelledby attribute only defines an accessible name for the element – it does not provide other functionality like clicking on the label to focus on the input element. It’s better to use <label> with a for attribute.

We have already discussed form labels in the Interactive Elements section.

You’ve now seen some of the different attributes that WAI-ARIA offers and how they enhance accessibility. You can visit MDN Docs: WAI-ARIA to check out additional details I may have missed.

Before we move on, remember one thing: use WAI-ARIA only when necessary. Usually, semantic elements are able to achieve majority of your accessibility goals. Don’t over-use WAI-ARIA as they might end up complicating your code.

Multimedia Accessibility

A website’s content is not restricted to text. It also often consists of multimedia content like images, audio, and video. In a lot of cases, multimedia content is easier to understand than text content. While this is true for many users, it poses challenges for users with disabilities.

People with visual impairments cannot see images and people who are deaf or hard of hearing cannot easily interpret audio content. So, as developers, it’s our job to make this type of content accessible for everyone. Let’s understand how to make this possible:

Images

Since people with visual impairments cannot see images, they depend on a screen reader to describe the image. Just writing an img tag with src attribute does not help.

<img src="temple.jpg" />

By default, the screen reader reads out the file path or URL of the image. A file name might give some idea of the image, but still does not describe it.

So, it’s helpful to add an alt attribute to an img. The alt attribute provides an alternate text for the image, and its purpose is to describe the image.

<img
  src="temple.jpg"
  alt="The Meenakshi Temple, situated in Madurai, a South Indian City is dedicated to goddess Meenakshi, a form of Parvati"
/>

Here, instead of reading the file path, the screen reader reads out the alternate text – that is, the value of the alt attribute. The alternate text should provide a description of the image to help users understand what it’s conveying. So, instead of just saying “Temple”, the user knows which temple is being depicted in the image.

You can also add extra context to the image with the title attribute.

<img
  src="temple.jpg"
  alt="The Meenakshi Temple, situated in Madurai, a South Indian City is dedicated to goddess Meenakshi, a form of Parvati"
  title="The Meenakshi Temple"
/>

When focussed on the image, the screen reader reads out the alt text and the title.

Let’s take another example which uses an alternative to the alt attribute:

<img src="temple.jpg" aria-labelledby="temple-label" />
<p id="temple-label">
  The Meenakshi Temple, situated in Madurai, a South Indian City is dedicated to
  goddess Meenakshi, a form of Parvati
</p>

Here, instead of using the alt attribute, we have used the aria-labelledby attribute to link the paragraph element to the image. The text inside p acts as an alternate text for the image. This is helpful if you need to use the same text as an alternate text for different images.

Sometimes, we use images as icons for headers and navigation menus, just for decoration. Usually, these images are not relevant to understand the content of the page. In these cases, you add an empty alt attribute.

<h3>
  <img src="page-icon.png" alt="" />
  History of Meenakshi Temple 
</h3>

If you skip the alt attribute, the screen reader reads out the entire image URL. To avoid this, use an empty alt attribute, so the screen reader simply announces it as an image and moves on, preventing unnecessary distractions for users.

You can also use role=”presentation” to skip reading the image path or alternative text.

Audio and video

When using the <audio> and <video> elements, remember to include multiple sources – that is, provide the audio and video in different formats. For browsers that do not support the formats you have mentioned, include a fallback download link so they can access the resource.

<audio controls>
  <source src="audio.mp3" type="audio/mpeg" />
  <source src="audio.ogg" type="audio/ogg" />
  <p>
    Your browser doesn't support HTML video. Here is a
    <a href="video.mp3">link to the video</a> instead.
  </p>
</audio>
<video controls>
  <source src="video.mp4" type="video/mp4" />
  <source src="video.webm" type="video/webm" />
  <p>
    Your browser doesn't support HTML5 video. Here is a
    <a href="video.mp4">link to the video</a> instead.
  </p>
</video>

Next, let’s understand the shortcomings of using native HTML controls for audio and video.

• They cannot be styled with CSS, so they may not align with your website’s theme.

• The play/pause buttons are not keyboard accessible.

• They don’t have functionality to forward or rewind the video.

To overcome these limitations, we’ll create our custom video player in the next steps. To start, let’s create a container for the video content:

<div class="controls">
  <button class="play-pause">Play</button>
  <button class="stop">Reset Video</button>
</div>

These will work as the play/pause and reset buttons. Then, let’s remove the controls attribute from the <video> to replace them with our custom controls.

const videoPlayer = document.querySelector("video");
videoPlayer.removeAttribute("controls");

Why do we remove it at run time? Let’s say JavaScript does not load due to some issue. In this case, the user can still use the native controls. Next, let’s add some functionality to our buttons:

const playPauseBtn = document.querySelector(".play-pause");
const resetBtn = document.querySelector(".reset");

playPauseBtn.onclick = () => {
  if (videoPlayer.paused) {
    videoPlayer.play();
    playPauseBtn.textContent = "Pause";
  } else {
    videoPlayer.pause();
    playPauseBtn.textContent = "Play";
  }
};

resetBtn.onclick = () => {
  videoPlayer.pause();
  videoPlayer.currentTime = 0;
  playPauseBtn.textContent = "Play";
};

• The video player object is of type HTMLMediaElement, that contains several methods you can use to control the video.

• For the play/pause button, we add a toggling functionality, with the play() and pause() methods.

• To reset the video, we pause it and set the current time to 0.

Now, our custom video player is keyboard accessible, and able to be styled with CSS. You can also add additional functionality like forward/rewind, a timer, and a progress bar. The steps are similar for a custom audio player.

Check out the MDN Docs for more detail about this functionality.

Audio Transcripts

People who are deaf or hard of hearing cannot easily access audio content. So to make it accessible, you need to add transcripts under any audio or video form of content.

If you run a business, you could pay a professional to do the transcripts. Check out the docs for options. To show the transcript on the UI, you could use a show/hide panel. Referring to the docs, see the audio transcript UI (source code) for an example.

If the audio is a recording of some presentation, you should attach links to any documents or presentation decks. Also, include a description for any visual content being referenced.

Video Closed Captioning and Subtitles

First, let’s understand the difference between captions and subtitles. They are implemented in a similar way and visually, they look the same – but their purposes are different.

Captions denote who’s speaking and describe other sound effects in the video. They are mostly added with people who are deaf or hard of hearing in mind. Subtitles help people who don’t understand the language being spoken in the video, by translating it to text that uses the language of their choice.

Let’s see how to add subtitles to your videos. We write subtitles in WebVTT, a format that contains text along with the range of timestamps indicating which text you want in each part of the video. Following is an example of a subtitles file:

WEBVTT

1
00:00:01.230 --> 00:00:02.606
This is the first subtitle.

2
00:00:04.739 --> 00:00:06.074
This is the second.

Save this file and name it with a .vtt extension. To link this file to your video, include it in a <track> element:

<video controls>
  <source src="video.mp4" type="video/mp4" />
  <track
    src="captions.vtt"
    kind="subtitles"
    srclang="en"
    label="English"
    default
  />
</video>

You should include the <track> element inside the <video> element and placed after all the sources. It has the following attributes:

• kind mentions the type of file being referenced.

• srclang indicates the language the subtitles are in.

• label indicates the text that is shown while the user is selecting a language

• src is the path or URL of the subtitles file, that is the .vtt file we created previously.

This will show subtitles for the specified timestamps. This will not only help people with hearing impairments, but is also useful for people who don’t understand the language, or those who are working in a noisy environment.

For people who are visually impaired, you could also include text that describes certain visuals in parts of the video. This text would be read out by screen reader.

You can also add custom styling to subtitle menu and subtitle text. Check out MDN Docs - Adding captions and subtitles to HTML video for the implementation.

Mobile Accessibility

We have covered many key accessibility practices so far, and they should work well on mobile phones as well. But there are some additional considerations you can follow for mobile users.

First, let’s talk about mouse-specific events. We have already seen how to make mouse-specific events accessible in the JavaScript Practices section. Events like mousedown or mouseup are often used for drag and drop functionalities.

But these are not accessible for touchscreen users, so you should add the same functionality to touch-specific events like touchstart and touchend. The following example is in the context of drag and drop:

source.ontouchstart = (e) => {
  // initiate drag
};

dest.ontouchend = (e) => {
   // drop
};

Next, you have to ensure that you are following responsive design when designing your web pages. Responsive designs make sure the website looks good on both desktop and mobile phones. I have written a detailed guide on responsive design, so check it out if you are interested.

Some other mobile accessibility practices that are good to know:

• Do not disable zoom on your website. Both fully-sighted users as well as those who have visual impairments may need to zoom in to read the website’s content on smaller screens.

• When writing navigation menus, you’d normally conceal it and provide a hamburger icon to open it, as the screen is much shorter/smaller on a mobile phone. In these cases, the hamburger menu should be easily accessible. Check out the example of a good hamburger menu from the docs, in mobile view.

• When creating forms, try to minimise the amount of typing the user needs to do, as it can get annoying for mobile users. This is especially important if your website is primarily designed for mobile users. Check out the docs for examples.

Visit MDN Docs-Mobile Accessibility if you want to learn more.

Testing Accessibility with Tools

There are several tools you can use to test the accessibility of your page. Lighthouse in Chrome Developer Tools is an open source tool that analyses a web page for performance, accessibility, SEO, and more. It generates a report on how a page performs in these areas.

Let’s see how it helps in analysing the accessibility of a page:

Open Chrome Dev Tools and navigate to the Lighthouse tab. Click on “Analyse Page Load” and wait for a few seconds. It will show a report that contains info on how your web page scored on Accessibility and other metrics. It will list down any accessibility issues you may have.

Let’s take the following example:

<h1>Welcome</h1>
<img src="image.jpg" />
<button tabindex="2">Click Here</button>
<div onclick="alert('Clicked!')" class="button">Click Me</div>
<form>
  <input type="text" />
</form>

When tested with the Lighthouse audit, it yields the following results:

As you can see, it’s scored 74 on accessibility, meaning there is room for improvement. It has also shown the accessibility issues within your HTML code, as you might have guessed looking at the code:

• Image elements do not have alt attribute

• Form input does not have a label

• tabindex value is greater than 0.

Let’s correct these issues and run the test again:

This time, it has scored 100 on Accessibility since we have followed all the basic practices.

As you can see, this is a really simple HTML page, and it’s much harder to achieve a score of 100 for large websites. But, you should aim to achieve as high a score as possible. This shouldn’t be too challenging if you make accessibility a part of your development process.

The accessibility score on it’s own does not mean your website is fully accessible. You also need to test the following:

• Manual testing with a screen reader (Mac’s Voiceover or Windows’ Narrator).

• Keyboard accessibility – test whether each and every part of your website is keyboard accessible

• Simulating your website with different color contrasts for different visual impairments.

For simulating, Chrome Developer Tools provides a Rendering tool to emulate your website on different preferences, like light/dark mode, high/low color contrast, reduced motion and various visual impairments.

To access it, open Developer Tools, do ⌘+shift+P (Ctrl+Shift+P on Windows) and type “Rendering”. It will open the following window:

If you have added media queries like the following, you can select these preferences and test whether your website behaves accordingly:

@media (prefers-reduced-motion) {
    * {
        animation: none;
    }
}

So, when you select prefers-reduced-motion, you can test if all the animations have been disabled, and how your website functions.

Apart from the Developer Tools, there’s an NPM plugin called eslint-plugin-jsx-a11y that evaluates React JSX code for accessibility issues.

You can find all the code snippets on GitHub.

Conclusion

Accessibility isn’t just a feature added on top of your code – it should be a part of the development process. When you make a website accessible to everyone, it not only increases your user base, but also promotes inclusivity.

Even though the primary benefactors of accessibility are people with disabilities, it also benefits other users by making the website easier to use overall. A lot of the practices mentioned in the article, like using semantic elements, adding the right attributes, and so on are very easy to follow and go a long way towards ensuring accessibility.

If you are a beginner, you have already done a great job learning about accessibility. Start including simple accessibility practices in your projects. Over time, including these practices will become a natural habit.

I hope this handbook becomes your go-to resource for anything related to accessibility. If you think I've missed something or need clarification on any concepts, feel free to reach out to me on Twitter. For more content on web development, check out out my profile.

References

• MDN Docs-Accessibility

• Web Dev Simplified- Guide on Accessibility

In this article, I'll share some ways CSS can support accessibility so you can start using these techniques in your own projects.

Prerequisites

To follow along with this tutorial, you should have a basic understanding of HTML, CSS, and a little bit of Javascript.

Update Focus Styles

The browser provides default focus styles for interactive elements like buttons or input fields. But sometimes these default focus styles might not be ideal for your design system – especially if the colors used in your design are too close to the default colors. This might make it difficult to notice.

Also, different browsers have different default focus styles and you might want to standardize the focus styles to ensure uniformity.

You can change the default focus style of an element in CSS using the :focus pseudo-class. For example, the default focus style for an input element is a blue outline in Chrome and a blue outline with outline offset in Firefox, to update the default focus styles of an input element you can do this:

input:focus {
  outline: 2px solid #007BFF;
  outline-offset: 2px;
  border-radius: 1rem;
}

Avoid Content Shifts

Content shifts can happen when you’re lazy loading images, where images load progressively as the user scrolls down the page. Sometimes the image pushes the content around it downwards, shifting the text you're reading out of place.

Content shifts can also happen during dynamic content fetching, especially when new content like text, images, or ads is added to the page without reserving space for it in advance.

Content shifts can be frustrating, especially for users:

• With cognitive disabilities who may lose track of where they are in the content.

• Using screen magnifiers, where the shift can cause them to lose their zoomed-in focus.

• Navigating with a keyboard, as it can mess up the natural tab order and make navigation confusing.

You can pre-allocate space for content to prevent shifts by using the min-height or aspect-ratio properties. Here's how you can allocate space for an image to prevent content shift before the image has fully loaded.

img {
    width: 100%;
    height: auto;
    aspect-ratio: 16/9;
    object-fit: cover; /* Ensures the image fits well within the allocated space */
}

You can also use animations or transitions when dynamically loading content to add smooth transitions for new content. So, instead of a sudden shift, the content slides in gracefully, reducing the perception of disruption.

.new-content {
    transition: margin 0.3s ease-in-out, opacity 0.3s ease-in-out;
}

Reduce Motion

Rapid animations or really complex transitions can be disorienting for users with motion sensitivity, which could lead to discomfort like headaches, dizziness, or vertigo (for users with vestibular disorders).

You can use CSS’s prefers-reduced-motion media query to reduce or disable animations for users.

Personally, instead of disabling animations completely, I replace complex, distracting animations with more subtle ones to maintain functionality while respecting user preferences.

Here's how to use prefers-reduced-motion to create a simpler animation:

/* Default animation */
@keyframes complexAnimation {
    0% { transform: translateX(0); opacity: 0; }
    50% { transform: translateX(100px); opacity: 0.5; }
    100% { transform: translateX(0); opacity: 1; }
}

.element {
    animation: complexAnimation 2s ease-in-out;
}

/* Simpler animation for reduced motion preference */
@media (prefers-reduced-motion: reduce) {
    @keyframes simpleAnimation {
        0% { opacity: 0; }
        100% { opacity: 1; }
    }

    .element {
        animation: simpleAnimation 1s ease-in-out;
    }
}

Here’s an example from the code above. If you have reduced motion enabled you’ll see a fading ball instead of a moving ball:

Note: If you want to see the reduced motion in action, you can enable it in the rendering tab on Google Chrome.

Focus Within for Nested Elements

You can highlight or style a parent element when any of its child elements receive focus to make it clear which group (like form inputs or dropdown menus) is currently being interacted with.

To do this, you can use CSS’s :focus-within pseudo-class which is used to style an element when any of its descendants receive focus either through keyboard navigation or user interaction.

For example, to highlight a fieldset when any item in the group is focused in a grouped control, you can do this:

<style>
 fieldset {
   padding: 10px;
   border: 1px solid #ccc;
 }

 fieldset:focus-within {
   border-color: #007BFF; /* highlight the fieldset when a user focuses on any input */
 }
</style>

<fieldset>
  <legend>Choose a color:</legend>
  <label><input type="radio" name="color" value="red"> Red</label>
  <label><input type="radio" name="color" value="green"> Green</label>
  <label><input type="radio" name="color" value="blue"> Blue</label>
</fieldset>

Customize Contrast Options

Sometimes you may be working on a design that uses lots of colors and might not maintain high contrast between text and background to fit an aesthetic. Or perhaps you're working on a design with lots of bright colors. In these cases, you should consider how your application renders for different users.

Some users with low vision or certain types of color blindness might need high contrast mode to differentiate text from the background more clearly. Other users sensitive to bright colors might prefer a softer, less jarring visual experience.

Some of these users might have their systems set to high or low contrast to help improve their experience. To customize their experience, you can use the CSS prefers-contrast media query.

The prefers-contrast media query allows you to tailor the contrast of your website or application based on the user's system settings.

Here's an example of using prefers-contrast:

/* default styling preference */
body {
    background-color: white;
    color: black;
}

/* high contrast preference */
@media (prefers-contrast: more) {
    body {
        background-color: black;
        color: white;
    }
    a {
        color: yellow;
    }
}
/* low contrast preference */

@media (prefers-contrast: less) {
    body {
        background-color: #f0f0f0;
        color: #333;
    }
    a {
        color: #555;
    }
}

In the example above, the prefers-contrast: more option ensures that when a user prefers high contrast, the background is black and the text is white, with yellow links for better visibility.

The prefers-contrast: less adjusts the color scheme to a softer color for users who prefer less contrast. The default style is used if the user has no specific contrast preference or if their preference is not detected.

Note: If your design uses minimal colors and maintains high contrast between text and background or you're working with a design where text is minimal and the focus is on visual content (like image galleries or video players), you might not need prefers-contrast as much. But it's still good practice to consider contrasts.

Enable Dark Mode

You can use CSS to accommodate users’ preferences for dark or light modes. You can achieve this through the CSS prefers-color-scheme media query. The browser can detect the user's color preference and apply the style if provided in CSS.

Here's an example of how you can add a dark mode style to your site using CSS variables:

:root {
  --background-color: #ffffff;
  --text-color: #000000;
}

@media (prefers-color-scheme: dark) {
  :root {
    --background-color: #000000;
    --text-color: #ffffff;
  }
}

body {
  background-color: var(--background-color);
  color: var(--text-color);
}

In the example above, the variables get updated if the browser detects a dark color scheme preference.

If you want to allow users to toggle between modes manually, you can use JavaScript for this:

<style>
 /* Default light mode styles */
  body {
   background-color: #ffffff;
   color: #000000;
  }
 /* Dark mode styles */
  body.dark-mode {
   background-color: #000000;
   color: #ffffff;
  }
</style>

<button id="toggle-theme">Toggle Theme</button>

<script>
  const toggleButton = document.getElementById('toggle-theme');
  toggleButton.addEventListener('click', () => {
   document.body.classList.toggle('dark-mode');
  });
</script>

Use rem Units for Responsive Typography

Using rem units for responsive typography can help enhance accessibility to adapt more dynamically to a user's preference. Since rem is relative to the root font size (typically set by the browser or user), it scales with changes in the base font size. This helps ensure that text remains readable without breaking layouts.

Users can set a preferred font size in their browser or operating system for better readability. When you use rem, the website content scales according to this setting which ensures that the text is not too small or too large for the users (which can happen when using fixed units like px).

When users zoom in using browser settings or increase their preferred text size, the rem-based text will scale appropriately.

The default root font size (usually 16px) is typically inherited from the browser, but you can set it explicitly if needed:

html {
  font-size: 100%; /* Default 16px */
}

After setting the root font size, you can use rem unit for the rest of your content. For example:

h1 {
  font-size: 2.5rem; /* Equivalent to 40px if root is 16px */
}

p {
  font-size: 1rem; /* Equivalent to 16px */
}

Use Animations to Enhance UX

CSS animations can enhance accessibility when used thoughtfully. They can help create an engaging and understandable experience for users.

Here are some ways that animations can help improve accessibility:

• You can use animations to indicate loading state to visually communicate to users that the system is working on a task.

• Using animated text effects, like fades or scaling on headlines or important sections, can help guide users' eyes to important content. This can be useful for people with cognitive disabilities who benefit from clear visual hierarchies.

• Subtle transitions for state change instead of having abrupt changes (like a modal popping up instantly) can create smoother transitions between different interface states.

• Using animated highlights or shaking effects on form fields can provide visual feedback to users about input errors. You should pair these animations with labels or ARIA attributes to make it clear what the user needs to correct.

• Animations can help users track focus, especially keyboard users or those with visual impairments. CSS transitions that highlight focused elements (for example by enlarging buttons or changing the border) assist users in understanding where they are within the page.

Best Practices:

• Ensure animations are used purposefully, not just for aesthetic reasons.

• Avoid overly long or continuous animations that can distract or annoy users.

• Combine animations with other accessible features, such as screen reader announcements, to ensure all users understand content changes.

Conclusion

When considering accessibility, well-structured HTML forms the foundation of an accessible page – but CSS also plays a vital role in enhancing that structure.

CSS alone cannot fix poorly structured HTML. But when it’s applied thoughtfully to a solid foundation, it ensures a more inclusive and engaging experience by improving visual hierarchy, readability, and interaction for users of all abilities.

Combining accessible HTML with CSS not only improves the user interface but also provides support for assistive technologies.

Thank you so much for reading this article. If you found it helpful, consider sharing. Happy coding!

You can connect with me on LinkedIn.

In this in-depth tutorial, I'll break down some key HTML attributes that enhance accessibility, explaining what they do, and when to use them effectively.

Prerequisites

To follow along with this tutorial, you should have a basic understanding of HTML and a little bit of Javascript knowledge as well.

Table of Contents

1. What are ARIA Attributes?

2. The alt Attribute

3. The aria-label Attribute

   • Best practices for Using aria-label

4. The aria-labelledby Attribute

   • How is aria-label Different from aria-labelledby?

   • Best Practices for Using aria-labelledby

5. The aria-describedby Attribute

   • Best Pracices for Using aria-describedby

6. The role Attribute

   • Common role Values

   • Best Practices for Using the role Attribute

7. The aria-controls Attribute

   • Best Practices for Using aria-controls

8. The aria-selected Attribute

   • Best Practices for Using aria-selected

9. The tabindex Attribute

   • Possible tabindex Values

   • Best Practices for Using tabindex

10. The title Attribute

    • Accessibility Concerns with title

    • Best Practices for Using the title Attribute

11. Using the for Attribute in label

    • Best Practices for Using the for Attribute

12. The scope Attribute

    • Possible scope Values

    • Best Practices for Using scope

13. The aria-hidden Attribute

    • Best Practices for Using aria-hidden

14. The inert Attribute

    • Best Practices for Using inert

15. The aria-live Attribute

    • Possible Values for aria-live

    • Best Practices for Using aria-live

16. The aria-roledescription Attribute

    • Best Practices for Using aria-roledescription

17. The aria-atomic Attribute

    • Best Practices for Using aria-atomic

18. Conclusion

What Are ARIA Attributes?

Most of the attributes listed in this article are ARIA attributes. ARIA, which stands for Accessible Rich Internet Applications, is a set of attributes defined by the W3C (World Wide Web Consortium) to enhance the accessibility of web applications.

ARIA attributes provide additional information to assistive technologies like screen readers. Using them correctly can make complex web applications more accessible to individuals with visual, auditory, or motor impairments.

One key principle of using ARIA is that sometimes it's best not to use it. Although this might seem contradictory, you should only ARIA attributes when necessary. Overusing ARIA can disrupt the experience for users relying on assistive technologies. While sighted users might not notice any issues, excessive or improper use of ARIA can negatively impact accessibility.

The alt Attribute

The alt attribute likely isn't new to you if you've used HTML images. You use it to provide alternative text that displays when an image isn't properly shown on the screen.

But the most important use of the alt attribute is for accessibility. If the alt attribute is not present in an image element, then a screen reader may announce the name of the image file or the URL of the image instead of explaining what it's showing. This can be unhelpful and we don't want that.

The content in the alt attribute should be concise because its primary purpose is to briefly describe an image for those who cannot see it. This includes users who rely on screen readers, search engines, and users with slow internet connections where images may not load. If the alt text is too long, it may include unnecessary details that don't add value to the user's understanding.

The alt attribute is different from an image caption. Captions are visible and can provide more context or additional information about an image. Using a caption as alt text can make it too long and redundant.

If the image is purely decorative, then the alt attribute should be left empty. If an image has an empty alt attribute, an assistive tool will skip it. This is important to help keep users focused on the content and not distract them with unnecessary information.

Here's an example of how you can use the alt attribute:

<p>Lions are remarkable for their powerful roars, 
which can be heard up to five miles away. 
These roars are used to communicate with other 
members of the pride, as well as to ward off rival lions and intruders. 
Although lions are often associated with the African savannah, 
a small population of Asiatic lions still exists in India's Gir Forest, 
making them one of the world's most endangered big cats.</p>

<img src="lion.jpg" alt="a lion" /> <!-- brief and gives context to the paragraph -->

<img src="background-stars.png" alt="" /> <!-- This image is purely for 
decoration so it's left empty -->

The aria-label Attribute

The aria-label attribute is used to provide an accessible name to an element that might not have visible text. A common example of this is a button that contains an image or SVG.

A lot of elements have an accessible name – the accessible name is the content inside the element. The accessible name for the heading in this example is "Frequently Asked Questions"

<h1>Frequently Asked Questions</h1>

Everyone, including people using assistive technology, would clearly understand the meaning of the example above because it contains visible content.

But in the example below, a user relying on a screen reader might miss the content in the button if it doesn't have an aria-label. This is because the content in the button is an SVG and the SVG does not contain any visible content:

<button aria-label="Search">
    <svg
      fill="#000000" 
      height="20px"
      width="20px"
      xmlns="http://www.w3.org/2000/svg" 
      viewBox="0 0 488.4 488.4">
        <g stroke-width="0"></g>
        <g stroke-linecap="round" stroke-linejoin="round"></g>
        <g><g>
        <g>
          <path d="M0,203.25c0,112.1,91.2,203.2,203.2,203.2c51.6,0,98.8-19.4,134.7-51.2l129.5,129.5c2.4,2.4,5.5,3.6,8.7,3.6 s6.3-1.2,8.7-3.6c4.8-4.8,4.8-12.5,0-17.3l-129.6-129.5c31.8-35.9,51.2-83,51.2-134.7c0-112.1-91.2-203.2-203.2-203.2 S0,91.15,0,203.25z M381.9,203.25c0,98.5-80.2,178.7-178.7,178.7s-178.7-80.2-178.7-178.7s80.2-178.7,178.7-178.7 S381.9,104.65,381.9,203.25z" />
        </g> 
        </g></g>
    </svg>
</button>

Do not overuse the aria-label. Not all content needs an aria-label – for example, if you have a button that contains an image with alt, or an SVG with a title, then those attributes act as the accessible name for that element.

<button>
    <img src="search-icon.png" alt="Search" /> <!-- no need for aria-label -->
</button>

<!-- Another example -->

<button>
  <svg
    fill="#000000"
    height="20px"
    width="20px"
    role="image"
    xmlns="http://www.w3.org/2000/svg"
    viewBox="0 0 488.4 488.4">
        <title>Search Icon</title> <!-- Accessible name -->
        <g stroke-width="0"></g>
        <g stroke-linecap="round" stroke-linejoin="round"></g>
        <g><g>
        <g>
         <path d="M0,203.25c0,112.1,91.2,203.2,203.2,203.2c51.6,0,98.8-19.4,134.7-51.2l129.5,129.5c2.4,2.4,5.5,3.6,8.7,3.6 s6.3-1.2,8.7-3.6c4.8-4.8,4.8-12.5,0-17.3l-129.6-129.5c31.8-35.9,51.2-83,51.2-134.7c0-112.1-91.2-203.2-203.2-203.2 S0,91.15,0,203.25z M381.9,203.25c0,98.5-80.2,178.7-178.7,178.7s-178.7-80.2-178.7-178.7s80.2-178.7,178.7-178.7 S381.9,104.65,381.9,203.25z" />
        </g> 
        <g><g>
  </svg>
</button>

You should use the aria-label sparingly and appropriately. Overusing the attribute can lead to several issues:

• The aria-label content is not visible to sighted users. If a user with a cognitive disability is using a screen reader for support, they might not understand why they’re hearing different information from what they see on the screen.

• Using aria-label extensively across a large codebase can make the HTML harder to maintain. You may struggle to track where labels are coming from, especially if they’re set programmatically or in multiple places.

Best Practices for Using aria-label

• Whenever possible, use visible text labels. They’re easier to understand and maintain, and they ensure consistent experiences for all users.

• When Possible: If there is already a visible label on the page, use aria-labelledby to link the element to the existing text instead of creating a new label with aria-label (we'll talk about this below).

• If you use aria-label, keep the text short and to the point. It should describe the element’s purpose in as few words as possible.

The aria-labelledby Attribute

The aria-labelledby attribute is used to associate an element with another element that serves as its label. It links the target element to one or more other elements on the page that contain the text that should be used as the label.

You can use this attribute when there is already a visible text label or when the label needs to be composed of multiple text elements.

For example, you can use aria-labelledby in a <section> element to associate it with a heading or other text that serves as a label for the entire section.

<h2 id="about-heading">About Us</h2> 
<section aria-labelledby="about-heading"> <!-- use the id of the h2 -->
    <p>We are a company dedicated to providing excellent service...</p>
</section>

<h2 id="services-heading">Our Services</h2>
<section aria-labelledby="services-heading">
    <p>We offer a wide range of services including...</p>
</section>

Sometimes, you might want to combine multiple pieces of text as the label. You can do this by listing multiple IDs in the aria-labelledby attribute:

<h1 id="dialog-title">Confirmation Required</h1>
<p id="dialog-description">Are you sure you want to delete this item?</p>
<button aria-labelledby="dialog-title dialog-description">Yes</button>

The aria-labelledby is similar to the aria-label in that its purpose is to provide an accessible element.

How is aria-label Different from aria-labelledby?

aria-label directly assigns a string of text as a label for an element. This text is not visible on the screen but is announced by assistive technologies like screen readers. It’s typically used when there is no visible text label.

aria-labelledby points to one or more existing elements on the page (using their id attributes) that should be used as the label for the element. The label text is visible to all users because it’s part of the content of another element.

Best Practices for Using aria-labelledby

• Use aria-labelledby over aria-label when there is already text on the page that can serve as the label. This reduces redundancy and ensures that both sighted users and screen reader users see the same content.

• The id attributes referenced by aria-labelledby must be unique on the page and correctly point to existing elements. If the ID is missing or incorrect, the label won’t work, leading to accessibility issues.

• When combining multiple labels, ensure that the resulting label makes sense when read together. The order of IDs in aria-labelledby matters, as screen readers will read the labels in the order they are listed.

• Like aria-label, avoid overusing aria-labelledby in situations where a simpler approach (like using a visible label element directly) would suffice. This helps keep the code maintainable and reduces the cognitive load for users.

The aria-describedby Attribute

The aria-describedby attribute is used to associate an element with one or more elements that provide additional descriptive information about it. The aria-describedby attribute is used to provide additional context or instructions to an element.

Unlike aria-labelledby, which is meant to provide a label or name, aria-describedby is intended to give users more detailed information or context about an element, often to supplement what they already know from the label.

<label id="full-name">Full name</label>
<input type="text" aria-labelledby="full-name" aria-describedby="info">
<span id="info">Enter your full name.</span>

When both aria-labelledby and aria-describedby are used on the same element, screen readers will first announce the label (from aria-labelledby), then the role of the element (for example, "button"), and finally the description (from aria-describedby).

Best Practices for Using aria-describedby

• Apply aria-describedby when you need to provide users with additional context or instructions that go beyond the label. This is particularly useful for forms, complex controls, or any element that might require clarification.

• While aria-describedby is meant for more detailed descriptions, avoid overly long text. Keep the description focused on what the user needs to know to interact with the element effectively.

• Just like with aria-labelledby, ensure that the elements referenced by aria-describedby have unique and relevant id attributes. The content of these elements should be directly relevant to the element they describe.

The role Attribute

The role attribute is used to specify the role of an element. You can use it to override the default role of a semantic element. It helps assistive technologies understand how an element should be interpreted or interacted with.

When using non-semantic elements (like <div> or <span>) to create interactive controls (buttons, dialogs, tabs, and so on), the role attribute informs assistive technologies of the element’s intended behavior. You can also use the role to define landmark roles that assist in navigation, such as banner or complementary, which defines the structure of the page for screen reader users.

Common role Values

Roles for Landmark Regions:

• banner: Represents the site header.

• navigation: Defines a navigation section of the page, often for site or page navigation links.

• main: Marks the main content of a document, distinct from sidebars, footers, and so on.

• contentinfo: Represents the footer information.

This example below is just for demonstration purposes – you should use the right semantic element when possible:

<div role="banner">
    <h1>My Website</h1>
</div>

<div role="navigation">
    <ul>
        <li><a href="#home">Home</a></li>
        <li><a href="#about">About</a></li>
    </ul>
</div>

<div role="main">
    <h2>Welcome to My Website</h2>
    <p>Here is some main content...</p>
</div>

<div role="contentinfo">
    <p>&copy; 2024 My Website</p>
</div>

Roles for Widgets and Interactive Elements:

• button: Represents a button element, which users can click to trigger an action.

• dialog: Marks a dialog box or modal that requires user interaction.

• alert: Identifies an element as an important message or alert that requires user attention.

• tablist, tab, tabpanel: Used for tabbed interfaces, where tablist contains the tabs, and each tab controls the visibility of its corresponding tabpanel.

<div role="button" tabindex="0" onclick="submitForm()">Submit</div>

<div role="dialog" aria-labelledby="dialog-title" aria-modal="true">
    <h2 id="dialog-title">Confirmation</h2>
    <p>Are you sure you want to proceed?</p>
    <button onclick="closeDialog()">Close</button>
</div>

Example of Tabbed panel:

<div role="tablist" aria-label="Sample Tabs">
    <button role="tab" id="tab-1" aria-controls="panel-1" aria-selected="true" tabindex="0">Tab 1</button>
    <button role="tab" id="tab-2" aria-controls="panel-2" aria-selected="false" tabindex="-1">Tab 2</button>
    <button role="tab" id="tab-3" aria-controls="panel-3" aria-selected="false" tabindex="-1">Tab 3</button>
</div>

<div role="tabpanel" id="panel-1" aria-labelledby="tab-1">
    <h2>Content for Tab 1</h2>
    <p>This is the content of the first tab.</p>
</div>

<div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>
    <h2>Content for Tab 2</h2>
    <p>This is the content of the second tab.</p>
</div>

<div role="tabpanel" id="panel-3" aria-labelledby="tab-3" hidden>
    <h2>Content for Tab 3</h2>
    <p>This is the content of the third tab.</p>
</div>

Best Practices for Using the role Attribute

• Always prefer using native HTML elements that already have the appropriate role (for example, <button>, <header>, <nav>, <main>). This provides better accessibility support across a wider range of browsers and devices.

• Don't overuse or misuse the role attribute as this can lead to confusion and reduced accessibility. Use role to enhance or clarify when needed, not to replace semantic HTML.

• Understand implicit roles. Many HTML elements have implicit roles. For example, an <a> element with an href attribute automatically has the link role. Avoid adding redundant role attributes to these elements.

The aria-controls Attribute

The aria-controls attribute informs a screen reader that the element is controlled or affected by another element. It's commonly used to indicate that a component (like a button or a tab) controls or interacts with another part of the page (like a panel or a menu). It is also used in interactive components such as tabs, accordions, and sliders to describe which parts of the page are affected when the user interacts with the component.

For example, you can use aria-controls on a tab button to indicate which panel each button controls:

<!-- Tab Buttons -->
<button id="tab1" aria-controls="panel1">Tab 1</button>
<button id="tab2" aria-controls="panel2">Tab 2</button>

<!-- Content Panels -->
<div id="panel1" role="tabpanel">Content for Tab 1</div>
<div id="panel2" role="tabpanel">Content for Tab 2</div>

Best Practices for Using aria-controls

• Ensure that the ID used in aria-controls matches the id of the controlled element exactly.

• Use aria-controls in conjunction with role and state attributes like aria-selected, or role="tabpanel" to provide more complete information about the controlled elements and their states.

• Apply aria-controls to interactive elements such as buttons or links that have a direct effect on other elements. It is not typically used for non-interactive content.

The aria-selected Attribute

The aria-selected attribute is used to indicate the current selection state of an element within a group of selectable items. A selectable item could be an option in a menu, a tab in a tabbed panel, or an item in a list box.

Here's an example of the selection state in a list box. aria-selected="true" in option 1 indicates that Option 1 is currently selected.

<!-- Listbox -->
<ul role="listbox">
  <li role="option" aria-selected="true">Option 1</li>
  <li role="option" aria-selected="false">Option 2</li>
  <li role="option" aria-selected="false">Option 3</li>
</ul>

Best Practices for Using aria-selected

• Use aria-selected="true" for the selected item and aria-selected="false" for non-selected items. The value should be a string, not a boolean.

• Ensure that the visual state of the element (for example, active tab or selected option) matches the aria-selected value. Inconsistent states can lead to confusion for users of assistive technologies.

• Use aria-selected in conjunction with appropriate role attributes (for example, role="option" for listbox items) to provide complete context.

• Ensure that aria-selected is updated dynamically as users interact with the interface. For example, when a user selects a new option, update the aria-selected attribute accordingly.

The tabindex Attribute

The tabindex attribute is used to control the keyboard navigation of an element. You can use it to activate focus for non-interactive elements like div, p, or span or disable focus for interactive elements like button, a, input. You can also use it to control focus order on a page.

Possible tabindex Values

Positive values: Elements with positive values become focusable and are included in the tab order with their numbers determining the order in which they are focused. Elements with lower numbers are focused before elements with higher numbers.

<button tabindex="2">Cancel</button> <!-- This will recieve focus last -->
<button tabindex="1">Submit</button> <!-- This will recieve focus first -->

Elements with the same values will be navigated in the order in which they appear.

Note: Using positive tabindex values can lead to a confusing and non-intuitive tab order. It is generally better to use tabindex="0" for elements that should be part of the natural tab order.

Zero: You use this to make an element focusable and include it in the natural tab order based on its position in the document. It's useful for making elements focusable that are not normally focusable (like <div> or <span>).

<div role="button" tabindex="0">Submit</div> 
<!-- The element becomes focusable using the keyboard -->

Negative values: You use this to remove an element from the tab order, meaning it cannot be focused using the Tab key. But it can still be focused programmatically (via JavaScript). It's useful for elements that should not be focusable by default but may need to be focusable under certain conditions.

<input type="text" name="name">
<input type="text" name="other-names" tabindex="-1">
<input type="text" placeholder="email">

<!-- other-names will be skipped when tabbing through the inputs; 
only name and email will receive focus -->

Best Practices for Using tabindex

• Rely on the natural tab order as much as possible. Use tabindex="0" to include elements in the tab order and avoid using positive values unless absolutely necessary.

• Using positive tabindex values can create an unpredictable tab order and make it harder for users to navigate. It's better to use the default flow and tabindex="0".

• Use tabindex="-1" for elements not intended to be focused.

• Ensure that the focus order follows a logical and intuitive sequence, which matches the visual layout and interaction flow of the page.

• Test with keyboard and assistive technologies.

• When dynamically adding or removing focusable elements (for example, through JavaScript), ensure that focus management is handled properly to maintain a smooth experience.

The title Attribute

The title attribute in HTML is used to provide additional information about an element. The content in the attribute shows in a tooltip when a user hovers over the element containing the title. It can be applied to most HTML elements, including links, images, and form fields.

You can use the title attribute to provide a brief explanation or description of the content of an element. For example, you can use it to clarify the meaning of abbreviations or acronyms when used with the <abbr> tag.

<abbr title="World Wide Web">WWW</abbr>
<!-- Hovering over "WWW" displays the tooltip "World Wide Web," 
explaining the abbreviation. -->

<img src="logo.png" 
alt="Company Logo" 
title="This is the logo of our company">
<!-- Users will see "This is the logo of our company" 
when hovering over the image. -->

Accessibility Concerns with the title Attribute

The title attribute can be useful, but it comes with some accessibility concerns:

• Screen readers do not consistently announce the title attribute, especially when there is also an alt attribute – or they may ignore it altogether. Users of assistive technologies may miss out on the information provided by the title attribute, especially if they rely solely on screen readers.

• The tooltip generated by the title attribute typically appears only on hover with a mouse or trackpad. Users who navigate with a keyboard or touch screen may not have access to this information.

• The content of the title attribute is hidden by default and only revealed on hover. This makes it less accessible to users who don't know they need to hover to get additional information.

• Tooltips can be difficult to read because they often disappear quickly, and their content might be truncated or too long to fit within the tooltip window.

Best Practices for Using the title Attribute

• Avoid relying solely on the title attribute. Ensure that critical information is available in a more accessible manner, such as visible text or ARIA attributes.

• Use the title attribute for supplementary, non-essential information that enhances user experience but isn’t critical to understanding the content.

• For form inputs, use the aria-describedby attribute to associate additional instructions with a form element. Use visible labels or descriptions instead of or in addition to the title attribute to ensure that all users have access to the information.

• If you use the title attribute, keep the text brief and to the point. Long tooltips can be difficult to read and may get truncated.

Using the for Attribute in label

The for attribute, when used in <label>, is used to connect a label to its corresponding form control element – that is <input>, <select>, or <textarea>. Screen readers will announce the label when the assigned input is focused. When used correctly, clicking on the label will focus on the corresponding input.

The value of the for attribute should match the id of the input it is associated with:

<label for="fullname">Full Name</label>
<input type="text" id="fullname">
<!-- When the user clicks on the "Full Name" label, 
the cursor will focus on the corresponding input field. -->

Best Practices for Using the for Attribute

• Ensure that each form control has a unique id attribute so that the for attribute can correctly reference it. Avoid using duplicate id values on the same page.

• Avoid empty for attributes. If there’s no associated form control, it can confuse users of assistive technologies.

• Position labels close to their associated form controls. Typically, labels should be placed above or to the left of the form controls for optimal readability and usability.

The scope Attribute

The scope attribute is used in HTML tables to define the relationship between table headers and the cells they describe. The attribute is particularly important for accessibility because it helps screen readers and other assistive technologies understand the structure of the table and convey the correct information to users.

The scope attribute is applied to <th> (table header) elements to specify whether the header applies to a row, a column, or a group of rows or columns

Possible scope Values

• row: Indicates that the <th> element is a header for a row. In the example below, scope="row" is used for the first <th> element in each row, indicating that the header applies to the entire row.

<table>
    <tbody>
        <tr>
            <th scope="row">Product A</th>
            <td>$1000</td>
            <td>$1200</td>
            <td>$1100</td>
        </tr>
        <tr>
            <th scope="row">Product B</th>
            <td>$900</td>
            <td>$950</td>
            <td>$1000</td>
        </tr>
    </tbody>
</table>

• col: Indicates that the <th> element is a header for a column.

<table>
    <thead>
        <tr>
            <th scope="col">Name</th>
            <th scope="col">Age</th>
            <th scope="col">Occupation</th>
        </tr>
<!-- The scope="col" attribute indicates that each <th> element 
serves as a header for the corresponding column beneath it. -->
    </thead>
    <tbody>
        <tr>
            <td>Jane</td>
            <td>30</td>
            <td>Engineer</td>
        </tr>
        <tr>
            <td>Tobe</td>
            <td>25</td>
            <td>Designer</td>
        </tr>
    </tbody>
</table>

• rowgroup: Indicates that the <th> element is a header for a group of rows. In the example below, the rows "Marketing Department" and "Sales Department" have the scope="rowgroup" attribute to indicate that these rows act as headers for the groups of rows that follow:

<table>
  <thead>
    <tr>
      <th scope="col">Department</th>
      <th scope="col">Employee Name</th>
      <th scope="col">Position</th>
      <th scope="col">Salary</th>
    </tr>
  </thead>
  <tbody>
    <!-- Row Group for the Marketing Department -->
    <tr>
      <th scope="rowgroup" colspan="4">Marketing Department</th>
    </tr>
    <tr>
      <th scope="row">Amari Pere</th>
      <td>Marketing Manager</td>
      <td>$75,000</td>
    </tr>
    <tr>
      <th scope="row">Uyati Hope</th>
      <td>SEO Specialist</td>
      <td>$65,000</td>
    </tr>

    <!-- Row Group for the Sales Department -->
    <tr>
      <th scope="rowgroup" colspan="4">Sales Department</th>
    </tr>
    <tr>
      <th scope="row">Timini Prosper</th>
      <td>Sales Manager</td>
      <td>$80,000</td>
    </tr>
    <tr>
      <th scope="row">Delilu Pink</th>
      <td>Account Executive</td>
      <td>$70,000</td>
    </tr>
  </tbody>
</table>

• colgroup: Indicates that the <th> element is a header for a group of columns. In the example below, scope="colgroup" is used to indicate that the first row of headers applies to groups of columns (Q1 and Q2), while scope="col" and scope="row" are used for individual columns and rows.

<table>
    <thead>
        <tr>
            <th scope="colgroup">Region</th>
            <th scope="colgroup">Q1</th>
            <th scope="colgroup">Q2</th>
        </tr>
        <tr>
            <th scope="col">Sales</th>
            <th scope="col">Profit</th>
            <th scope="col">Sales</th>
            <th scope="col">Profit</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <th scope="row">North</th>
            <td>$2000</td>
            <td>$400</td>
            <td>$2500</td>
            <td>$500</td>
        </tr>
        <tr>
            <th scope="row">South</th>
            <td>$1500</td>
            <td>$300</td>
            <td>$1800</td>
            <td>$350</td>
        </tr>
    </tbody>
</table>

Best Practices for Using the scope Attribute

• Always define scope for complex tables to clarify the relationship between headers and data cells.

• Simplify table structures when possible. While the scope attribute helps with accessibility, consider simplifying table structures where possible. If a table is too complex, it might be difficult for all users to understand, even with proper markup.

• For particularly complex tables, consider using ARIA attributes like aria-labelledby or aria-describedby to provide additional context and ensure that all users can navigate the table effectively.

• After applying the scope attribute, test the table with screen readers to ensure that the relationships between headers and data cells are announced correctly.

• Don’t use scope in situations where it’s unnecessary. For simple tables where each header is clearly associated with a single row or column, HTML’s default behavior is usually sufficient.

The aria-hidden Attribute

The aria-hidden attribute is used to control the visibility of an element for assistive technologies while it's still visible on the screen. You can use it to hide purely decorative elements, like icons or images, that don't add meaningful information to the content. This helps prevent screen readers from reading unnecessary information.

<button>
    <span aria-hidden="true">🔍</span>
    Search
</button>

You can also use it to hide content that has already been announced to prevent redundancy in what screen readers announce. For content that is toggled on and off (like modals, or expandable sections), you can use aria-hidden to hide the inactive content from screen readers, ensuring that they only interact with the visible, active content.

<button>
    <span aria-hidden="true">✉</span> <!-- hide decorative icon -->
    <span>Messages</span>
</button>

You can also use aria-hidden when creating complex widgets (like carousels or tabbed interfaces) to hide inactive panels or slides from assistive technologies, focusing their attention on the active part of the widget.

<div id="menu" aria-hidden="true">
    <!-- Menu content here -->
</div>

<button onclick="toggleMenu()">Toggle Menu</button>

<script>
    const toggleMenu = () => {
        const menu = document.getElementById('menu');
        const isHidden = menu.getAttribute('aria-hidden') === 'true';

        menu.setAttribute('aria-hidden', !isHidden);
    }
</script>

Best Practices for Using aria-hidden

• Only use aria-hidden when you need to hide content from screen readers to avoid overwhelming users with redundant or irrelevant information.

• Do not use on elements that users need to interact with, like buttons or links.

• Ensure that aria-hidden accurately reflects the visibility of elements on the screen. If an element becomes visible or hidden via JavaScript or CSS, update aria-hidden accordingly to maintain accessibility.

• In a team environment, document why and where aria-hidden is used in your codebase, so that other team members understand its purpose and can maintain it properly.

The inert Attribute

The inert attribute prevents an element and all of its descendants from being focusable, interactive, or perceivable by assistive technologies. When an element has the inert attribute, it cannot receive focus, be clicked on, or be interacted with in any way. It's also hidden from assistive technologies like screen readers.

Unlike aria-hidden, which only affects accessibility, inert applies to all user interactions. The inert attribute can be used to disable sections of a page that are temporarily irrelevant, such as during form validation errors, while loading data, or when a certain section is hidden but still in the DOM. It can also be used in complex user interfaces like multi-step forms or wizards to ensure that users only interact with the current step or section

The most common use of inert, however, is in a modal, where you want to prevent users from interacting with the background content while the modal is open.

Like in the example below, when the modal is open the inert attribute is added to the main content, making it non-interactive and hidden from screen readers. When the modal is closed, the inert attribute is removed, and the main content becomes interactive again.

<div id="main-content" inert>
    <p>This is the main content of the page. It will be inactive when the modal is open.</p>
</div>

<div id="modal" role="dialog" aria-modal="true">
    <h2>Modal Title</h2>
    <p>This is the content inside the modal.</p>
    <button onclick="closeModal()">Close Modal</button>
</div>

<script>
function openModal() {
    document.getElementById('main-content').setAttribute('inert', '');
    document.getElementById('modal').style.display = 'block';
}

function closeModal() {
    document.getElementById('main-content').removeAttribute('inert');
    document.getElementById('modal').style.display = 'none';
}
</script>

Best Practices for Using the inert Attribute

• Ensure that when you use inert, the visually inactive or disabled state of elements is clear to sighted users. For example, dimming or blurring background content when a modal is open can complement the inert attribute.

• Don't overuse inert, as doing so might unintentionally make significant portions of your page non-interactive and inaccessible. Use it judiciously to manage user focus and interaction only when necessary.

• When dynamically adding and removing the inert attribute, ensure that it is properly removed when no longer needed so that users can regain access to previously disabled content.

The aria-live Attribute

You can use the aria-live attribute to notify assistive technologies about dynamic content changes on a webpage. When aria-live is applied to an element, screen readers are alerted when the content inside that element is updated, ensuring that users are informed about important changes that occur after the page has initially loaded.

This attribute can be useful for content that updates dynamically, such as notifications, alerts, chat messages, or stock prices. It ensures that users are aware of changes that might otherwise go unnoticed.

Possible Values for aria-live

There are three main values: off, polite, and assertive.

• off: Default value, updates to the element will not be announced by screen readers.

• polite: Updates will be announced by the screen reader, but only after the user has finished interacting with the current task or reading other content. This ensures that the update does not interrupt the user’s current activity.

In the example below, each new message is added to the #messages container, which has aria-live="polite". The screen reader will announce the new message only after the user finishes their current activity.

<div id="chat-window">
    <div id="messages" aria-live="polite">
        <!-- Existing messages are here -->
        <div>John: Hello!</div>
        <div>You: Hi there!</div>
    </div>
</div>

<button onclick="addMessage()">Send Message</button>

<script>
function addMessage() {
    const newMessage = document.createElement('div');
    newMessage.textContent = 'Alice: How are you?';
    document.getElementById('messages').appendChild(newMessage);
}
</script>

• assertive: Updates will be announced immediately, interrupting whatever the screen reader is currently announcing. Use this for urgent or critical information that requires the user’s immediate attention.

In the example below, updates to the stock prices are placed within a container that has aria-live="assertive".

<div id="stock-ticker" aria-live="assertive">
    <!-- Initial stock prices -->
    <div id="stock1">Stock A: $100</div>
    <div id="stock2">Stock B: $150</div>
</div>

<button onclick="updateStockPrices()">Update Prices</button>

<script>
function updateStockPrices() {
    document.getElementById('stock1').textContent = 'Stock A: $95';
    document.getElementById('stock2').textContent = 'Stock B: $155';
}
</script>

Best Practices for Using aria-live

• Use aria-live="polite" for non-critical updates to avoid disrupting the user’s experience. Reserve aria-live="assertive" for urgent updates that require immediate attention, such as critical errors or security warnings.

• Be mindful of how often you use aria-live elements on a page. Overusing it can lead to an overstimulating experience for users who rely on screen readers, as they may be overwhelmed by frequent announcements.

• Don’t use aria-live on content that doesn’t need to be announced, or on content that’s already being communicated to the user in another way.

• aria-live is particularly useful for content that is updated dynamically, such as live sports scores, breaking news, or chat applications. Make sure that the user is kept informed of important updates as they occur.

The aria-roledescription Attribute

You can use aria-roledescription to provide a human-readable, localized description for the role of an element. It overrides the implicit or explicit role value for screen readers, and allows developers to create more intuitive and context-specific descriptions for complex or unconventional user interface components that may not have a standard role name.

You can use it to provide a clearer explanation of the element’s purpose or functionality.

In the example below, screen readers will announce it as "Bookmark Button" instead of just "Button."

<button role="button" aria-roledescription="Bookmark Button">
    <span aria-hidden="true">⭐</span> Save this page
</button>

You can also use it to support internationalization, like providing role descriptions in different languages.

<button role="button" aria-roledescription="Search Button" lang="en">
    <span aria-hidden="true">🔍</span> Search
</button>

<button role="button" aria-roledescription="Botón de busqueda" lang="es">
    <span aria-hidden="true">🔍</span> Buscar
</button>

<button role="button" aria-roledescription="Bouton de recherche" lang="fr">
    <span aria-hidden="true">🔍</span> Recherche
</button>

Best Practices for Using aria-roledescription

• Only use aria-roledescription when the standard role does not sufficiently describe the element's purpose.

• The description should be short, clear, and directly related to the element's function. Avoid using jargon or overly technical language.

• aria-roledescription should be used alongside an appropriate ARIA role, not as a replacement. The role provides the foundational context (like "button" or "listbox"), while the description adds clarity.

• If your application supports multiple languages, ensure that the aria-roledescription values are localized to match the user's language preferences. This helps provide a consistent and understandable experience.

• Ensure that the aria-roledescription does not repeat or conflict with other ARIA attributes or element labels. It should complement, not duplicate, the information already provided.

The aria-atomic Attribute

You can use the aria-atomic attribute to control how updates to an element are announced by assistive technologies. When aria-atomic is set to true, it indicates that when changes occur within the element, the entire content of the element should be treated as a single unit and announced in full by the screen reader (rather than announcing only the changed parts).

In cases where updates to part of an element might make the overall context unclear, aria-atomic helps by providing a full announcement of the element's content, giving users a complete understanding of the context.

It is often used in conjunction with aria-live. While aria-live determines how updates are announced (politely or assertively), aria-atomic controls whether the entire content is read or just the changes.

<div id="news-ticker" role="region" aria-live="polite" aria-atomic="true">
  Breaking News: Major storm expected this weekend.
</div>
<button onclick="updateHeadline()">Update Headline</button>
<script>
function updateHeadline() {
    document.getElementById('news-ticker').innerText = 'Breaking News: Stock market hits record high!';
}
</script>

Best Practices for Using aria-atomic

• Apply aria-atomic="true" only to elements where a full announcement of updates is essential for understanding the context.

• When using aria-atomic="true", ensure that the content within the element provides consistent and complete context to users.

• Use aria-atomic in combination with aria-live to specify how updates should be announced. This ensures that the updates are announced in the appropriate manner and with full context.

Conclusion

Understanding and effectively using HTML attributes for accessibility is crucial for creating inclusive web experiences. By understanding and using these attributes appropriately, you can ensure that your application has a great user experience for all visitors.

Resources

• Providing Accessible Names and Descriptions

• MDN ARIA

• No ARIA is better than Bad ARIA

• ARIA examples by properties and states

Thank you so much for reading, I hope this guide helps you create more accessible web content. If you found it helpful, consider sharing.

You can connect with me on LinkedIn.

Modals are common and sometimes required. And if they're not implemented correctly, they can be a significant barrier. Ensuring that modals are accessible means they are usable by everyone, including people who rely on assistive technologies.

In this article, we'll build a modal and follow the guidelines to make it accessible.

Prerequisites

To follow along with this tutorial, you should have:

1. Basic HTML knowledge: Understand how HTML elements and attributes work.

2. Basic JavaScript knowledge: Familiarity with basic JavaScript concepts like functions, event handling, and DOM manipulation is helpful.

3. Understanding of ARIA: While the tutorial explains ARIA roles and attributes, having a basic understanding of accessibility concepts can be beneficial.

When Should You Use a Modal?

Using modals effectively requires careful consideration of the user experience. Here are some guidelines to help you decide if you should use a modal or not:

• You should use modals when the user needs to make a critical decision, such as confirming a potentially destructive action (for example, deleting an item) or agreeing to terms and conditions

• You can use a modal when a task requires the user’s complete focus and does not rely on information from the rest of the page (for example, filling out a form or completing a payment process).

• You can use a modal for displaying temporary or transient information that doesn’t need to be permanently visible on the page (for example, alerts, notifications, or brief messages).

• You should avoid using modals for tasks that require extensive interaction or input, such as lengthy forms or complex workflows. These can be frustrating in a modal because of limited space and navigation constraints.

• You should avoid using modals for actions a user will need to perform frequently, as this can become repetitive and annoying. Inline options or tooltips might be better for repetitive actions.

• You should not use modals if they interrupt the user’s natural flow on the site, especially if the content or action in the modal is not urgent or important.

Modal Accessibility Guidelines

Here are some tips to help you build useful and accessible modals:

• Provide a descriptive aria-labelledby attribute that points to the modal's title or heading. If there is no title, use aria-label to provide a short, descriptive label.

• Always include a visible and easily accessible close button within the modal, usually in the top-right corner. Label this button clearly, for example, with the text "Close" or an icon with aria-label="Close".

• When the modal opens, move the keyboard focus to the first interactive element within the modal (usually a close button). When the modal closes, return the focus to the element that triggered the modal.

• Keep the keyboard focus within the modal while it is open.

• Allow users to close the modal by pressing the Escape key.

Following these guidelines, let's build a modal.

I prefer using the right HTML tags to build components, and in this case I'll be doing exactly that using the dialog tag.

How to Build a Modal Using the dialog Tag

In case you're not familiar with the dialog tag, it was introduced in HTML5. You use it to create dialog boxes like popups, alerts, and modals. It offers built-in methods and attributes that make it easier to manage dialog behavior without needing extensive JavaScript. The javascript built-in methods are show(), showModal(), and close().

show() and showModal()

The show() method is useful for a non-blocking dialog. This means that the dialog appears on top of the current content, but users can still interact with other parts of the webpage (clicking buttons, links, and so on) while the dialog is open.

This is useful in situations where the dialog is providing information that doesn’t require the user’s immediate attention. Here's an example:

<!-- Previous content here -->
<dialog id="dialog-box">
<!-- More content here -->
</dialog>

<script>
    const dialog = document.getElementById('dialog-box');
    dialog.show();
</script>

Result:

The showModal() method opens the dialog in a modal mode. This means that the dialog takes focus, and interaction with the rest of the webpage is blocked until the dialog is closed. The user cannot click on or interact with any other part of the page.

Depending on the browser, a semi-transparent backdrop appears behind the dialog, visually indicating that the rest of the page is not interactable.

When a dialog is opened with showModal(), focus is automatically trapped within the dialog. The user can only tab through elements inside the dialog, and the focus will loop within the dialog’s content until it is closed. Here's an example:

<dialog id="dialog-box">
<!-- More content here -->
</dialog>

<script>
    const dialog = document.getElementById('dialog-box');
    dialog.showModal();
</script>

Result:

The <dialog> element has default styles but can be customized using CSS to match your design. You can style the dialog box, add animations, or modify the backdrop. The backdrop can be styled using the ::backdrop selector. For example:

dialog::backdrop {
    background: rgba(0, 0, 0, 0.7);
}

The dialog also comes with some built-in accessibility features like focus management, backdrop, automatic announcement on open, and pressing the ESC key will close the dialog.

You can add the autofocus attribute to the first interactive element in the modal, such as the first input in a form or the close button. Alternatively, you can rely on the <dialog> element's native focus management.

Avoid using tabindex on the <dialog> element, as it is not an interactive element like a button or link. The <dialog> serves as a container for interactive content, and it is not intended to receive direct user focus.

The <dialog> element provides a native way to create modals. If you're building a custom modal, make sure its accessibility features match those of the native <dialog> element.

Bringing it all together:

<style>
    dialog::backdrop {
        background: rgba(0, 0, 0, 0.7);
    }
</style>
<body>
    <button id="open-dialog">Open Dialog</button>
    <dialog id="dialog-box">
        <h2>Modal title</h2>
        <div>
          <!-- More content here -->
          <button id="close-dialog" autofocus>Close</button>
        </div>
    </dialog>

<script>
    const dialog = document.getElementById("dialog-box");
    const openButton = document.getElementById("open-dialog");
    const closeButton = document.getElementById("close-dialog");

    openButton.addEventListener("click", () => {
      dialog.showModal();
    });
    closeButton.addEventListener("click", () => {
      dialog.close();
    });
</script>
</body>

You'll notice that I didn't use the aria-label attribute on the dialog as I listed in the guidelines. Well, that's because the dialog element, if well-structured, doesn't necessarily need one. In this case, there's a visible label in the dialog element (the h2 element).

If there are no visible labels present then you need to add one. Like in this example:

<dialog id="confimation-dialog" aria-label="Confirmation Dialog">
    <p>Are you sure you want to proceed?</p>
    <button id="close-dialog" autofocus>Close</button>
</dialog>

What is the inert Attribute?

When a modal is open, a screen reader might still navigate to and around content outside the modal. You would generally want the user's focus to be restricted to the modal itself, or stop the user from accidentally clicking on elements outside the modal to prevent confusion and errors. In these cases, you'll need the inert attribute.

The inert attribute makes an element and all of its descendants non-interactive and inaccessible to assistive technologies. When a modal is open, using the inert attribute on the rest of the page content will ensure that only the modal content can be accessed, making the dialog experience clearer.

How to Use the inert Attribute

When a modal is opened, you can apply the inert attribute to the rest of the page content (typically the <main> element). When the modal is closed, you remove the inert attribute.

Here's an example showing how to use inert with a modal dialog:

<body>
    <header>Site Header</header>
    <main id="main-content">
        <button id="open-dialog">Open modal</button>
        <p>This is the main content of the page.</p>
        <!-- More content here -->

    </main>
    <!-- Move the dialog outside the main element -->
    <dialog id="dialog">
        <h2>Modal Title</h2>
        <p>This is the content inside the modal.</p>
        <button id="close-dialog" autofocus>Close</button>
    </dialog>

    <script>
        const dialog = document.getElementById('dialog');
        const mainContent = document.getElementById('main-content');
        const openButton = document.getElementById('open-dialog');
        const closeButton = document.getElementById('close-dialog');

        openButton.addEventListener("click", () => {
           mainContent.setAttribute('inert', '');
          dialog.showModal();
        });

        closeButton.addEventListener("click", () => {
           dialog.close();
        });

        // the dialog elemnt has a close event, which is called when a user calls the close() method or presses the esc key
        dialog.addEventListener("close", (event) => {
           mainContent.removeAttribute("inert");
        });
    </script>
</body>

How to Animate the Open and Close States

When a modal appears (open state) or disappears (close state), it can be jarring for users if this transition happens abruptly. Animating these states can create a smoother user experience by gradually introducing or removing the modal, making it feel more natural.

Why Animate the Open and Close States?

Animating the open and close states of a modal can:

• Enhance User Experience: A smooth animation can make the transition less abrupt and more engaging.

• Draw Attention: Subtle animations can help guide the user's focus to the modal content when it appears.

• Maintain Consistency: Consistent animations across your UI can create a cohesive and professional feel.

By default, the dialog is set to display:none when closed and display:block when open. You cannot transition from none to block in CSS, but you can combine the display properties with transform or opacity. The transform property can be used to scale or move the modal, while opacity controls its transparency.

Here’s an example of how you might animate a modal:

dialog {
  animation: zoom-out 0.5s ease-out;
}

/* an open attribute is added to the dialog when it is open  */
dialog[open] {
    animation: zoom-in 0.5s ease-out;
}

/* The display property in the keyframes is critical 
because it toggles the modal’s visibility on and off.  */
@keyframes zoom-in {
    0% {
      opacity: 0;
      transform: scale(0.1);
      display:  none;
    }
    100% {
      opacity: 1;
      transform: scale(1);
      display: block;
    }
}

@keyframes zoom-out {
    0% {
      opacity: 1;
      transform: scale(1);
      display: block;
    }
    100% {
      opacity: 0;
      transform: scale(0);
      display: none;
    }
}

Final result:

Conclusion

The <dialog> element is the native way to create modals. It provides built-in accessible features for both keyboard and screen reader users

The <dialog> element is of two types, modal and non-modal. You can create a non-modal dialog using the show() method, and the showModal() method will create a modal dialog.

When you're not using the native dialog element, ensure your custom modal matches the native dialog in terms of accessibility to ensure a uniform experience for all users

You should also always remember to autofocus the most immediate interactive element, the dialog can do this by default.

Finally, you can use the inert attribute on other elements to prevent those elements from being accessed when the modal is open.

Resources:

• W3c Dialog role

• MDN: The Dialog element

Thank you so much for reading this article. If you found it helpful, consider sharing. Happy coding!

You can connect with me on LinkedIn.

Web accessibility aims to make it possible for anyone to access web content. There are common accessibility best practices for designers, developers, and writers. This article will cover some best practices for creating technical content.‌

What is Web Accessibility?

Web accessibility is the practice of making it possible for anyone to consume or create content on the web, regardless of any health, economic, geographic, or language challenges they may have.

Why is Web Accessibility Important?

It is important to apply web accessibility best practices in your projects for a number of reasons.

First, it'll help you reach a wider audience. When a person who may have different abilities comes across some data on the web – say on your website – they'll want to learn more or use the data. But if they are not able to access it, you will not be happy or have a good experience.

Imagine how many people are unable to utilize the web because they are not considered when devs and designers are making decisions about how the product, website, or tool will be built.

Another important thing about accessibility is that it improves your brand's quality. Letting people know you are an accessibility-oriented person or company by implementing it in your work shows that you want your information to be available t everyone. It also displays your versatility in your craft and your ability to improve and adapt with changing times and trends.

Also, as an individual, applying accessibility best practices benefits you as well. There are possible employment opportunities for developers and designers with great accessibility skills.

Good accessibility practices mean good SEO practices too, which can result in more visibility for your work.

Finally, accessibility is enforced by law in certain countries around the world, and web accessibility strategies are implemented by certain countries. There could be legal consequences if you overlook accessibility on your websites and apps.

How to Write Accessible Technical Documentation

Software engineers have a key role in making the web accessible. But when it comes to writing documentation, technical writers also have a role to play in improving web accessibility.

Technical writers help write various types of content, like user guides, tutorials, API references, code documentation, and so on.

Now, let's look at some of the best practices for implementing web accessibility in technical writing. These strategies will help improve your documentation and make it more user-friendly and accessible to everyone.

Use clear headings and paragraphs

When writing content, you should make sure to use headings – along with the proper heading hierarchy (H1 for the title of the page/article, H2 for major headings, H3 for subheadings, and so on).

Also, make sure to break your content up into paragraphs so it's easier to read and understand.

When you introduce a new topic, use a heading to call that out. When you talk about smaller topics within that section, use subheadings to alert the reader.

Headings are also important to help screen readers understand a page's contents and how to navigate through them. So use headings to help guide readers through the text in a logical manner.

You denote headings in markdown with hashes. Here's an example of headings in hierarchical order.‌

# Use H1 for the page title

## Use H2 for major headings 
This heading is a main heading for the main section content. 

### Use H3 for subheadings 
This heading is a subheading that goes deeper into one of the main section's points.

Make your content clear and concise

Overall, try to keep your sentences quite short in your docs. This makes them easier to read and understand (for everyone). You can also use images or videos to provide more details if needed.

Make sure you give the full meanings of any acronyms you are using for the first time. Also, always use simple sentences, and try not to use ambiguous words.

Here's an example of an overly complex, long sentence with difficult vocabulary:

The web3 running on the Blockchain structure which is transparent, secure, immutable, decentralized would require the processes of artificial intelligence, where it would read data, process, and store information.

This is better:

Web3 is built on the transparent, secure, unchangable, and decentralized structure of the blockchain. It uses artificial intelligence processes to read, process, and store information.

Your content should contain the main points you're trying to make, removing all forms of ambiguity.‌ ‌

Use informative link text

All your in-line links should use clear, detailed, and descriptive text. You can describe the link's purpose or the company's name if it is a brand, for example.

Links are important for improving the ranking of a page. And using links like "Click here" or "Read More" is not all that helpful, as they don't tell the reader much about what they'll find at that link.

For instance, if I wanted to link a W3C (World Wide Web Consortium) accessibility tutorial to this article, I could use the following format: Check out these resources for content writers by W3C.

Add alt text and captions to media content

Images

Adding descriptive text to the alt text attribute allows screen readers to be able to read out the alt text associated with an image. Alt text also helps search engine bots that crawl the page know how to classify that content.

When you're adding alt text, describe the purpose of the image and not what the image is. For instance, let's say you're using an image that shows some shipping containers in a section that is about containerization.‌

Various containers on a ship in motion to illustrate the packaging structure and process of a digital container.

Instead of writing alt text like "various containers on a ship in motion", you could write "various containers on a ship in motion to illustrate the packaging structure and process of a digital container."

While alt text serves as an alternative for the image, captions give more details about the image. You can use HTML to insert image captions. Markdown does not support image captions, but markdown documentation sites usually have a way around it (for example, through plugins – ReadTheDocs, MkDocs – or inserting HTML via a custom component –Docusaurus).

As an example, I'll show you how to add image captions in Docusaurus.

How to add image captions in a Docusaurus .md file:

• Create a folder components in the src folder.

• Create a file named figure.jsx.

• Add this line of code to it:

import React from "react"; 
import useBaseUrl from "@docusaurus/useBaseUrl"; 
export default function Figure({ src, caption }) {
  return ( 
  <figure> <img src={useBaseUrl(src)} alt={caption} /> 
  <figcaption>{`Figure: ${caption}`}</figcaption> </figure> 
  ); 
}

• Go to the .md file where you have the image and import the code.

import Figure from '@site/src/components/figure'; 
import figure1 from 'path-to-image';

• Add it to the file.

<Figure caption="This is a caption for the image" alt="This is alt text" src={figure1} />

The image will now display with a caption.

A screenshot example of image caption

‌Videos

To caption videos, HTML is a great option. But if you are using markdown, you can embed videos from YouTube and Vimeo using the <iframe> tag. These apps offer in-built caption support so you can enable captions before adding the embed code.

You could also install third-party plugins for this purpose.

Here's another tip: avoid flashing content in your videos as it could lead to seizure triggers. If your video has flashing bright colours, ensure that it does not exceed two times within a second.

Add transcripts to audios and videos

It's a good idea to add transcripts to your audio and video content. Not everyone will want to watch or listen to the content. But they may be curious to know what it is about.

By adding a transcript, you make it easier for anyone to navigate through the content and get the information that they need.

Transcript for audio

For audio content, you can insert transcripts using HTML. Here's an example:

<audio controls muted><!--Always set your audios to muted--> 
    <source src="ringtone.mp3" type="audio/mpeg"></source> 
</audio> 
<code> 
    <p>Here is a transcription of the text</p> 
    00:03 = I am going to be productive today<br><br> 
    00:05 = I am going to be productive today<br><br> 
    00:08 = I am going to be productive today<br><br> 
    00:10 = I need to be productive today<br><br> 
    00:11 = I have to be productive today<br><br> 
    00:13 = I should be productive today<br><br> 
    00:16 = I am going to be productive today<br><br> 
    00:18 = I ought to be productive today<br><br> 
    00:21 = I have to be productive today<br><br> 
    00:23 = Productivity matters to me <br><br> 
</code>

For markdown documentation sites like Docusaurus, you can create a custom component.‌

• In your src/components folder, create a file named transcript.jsx.

• Insert this code:

import React, { useState } from 'react'; 
export default function Transcript({ }) { 
  const [showTranscript, setShowTranscript] = useState(false); 
  const toggleTranscript = () => { 
    setShowTranscript(!showTranscript); 
  }; 
  return ( 
    <div> <a href="#" onClick={toggleTranscript}> { 
    showTranscript ? 'Hide transcript' : 'View transcript'
    } 
    </a> {showTranscript && ( <div id="transcriptText"> (insert your transcript text here) </div> )} 
    </div> 
  ); 
}

• Go to your markdown file and import it.

import Transcript from '@site/src/components/transcript'; 

<Transcript />

‌

A screenshot of the audio transcript output

‌Note: I added some tweaks to the code to make transcript display optional. You can edit it if you want the transcript to show as the page loads.

Transcript for video

Now for videos, YouTube is a great option. It provides inbuilt transcripts for your videos. So, you can always embed YouTube videos in your docs.

The transcript is in the video description after the main details. The transcript will display with the timestamps when you click the "Show Transcript" button.

Add code snippets and use the colour contrast technique

How to add code snippets

Use code blocks within the text to explain code instead of images. You could also use code snippets to showcase the output of your code. Unless it is necessary to add an image, you should use code snippets.

For instance,

index.html

<!DOCTYPE html> 
<html> 
    <head> 
        <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>A calculator app</title> 
        <link rel="stylesheet" href="styles.css"/> 
    </head> 
    <body> 
    </body> 
</html>

This will allow screen readers to read through the code, which they are not able to do with screenshots.

A screenshot of the above code

Colour contrast technique

The colour contrast technique implies using colours that are opposite or heavily contrasting.

For example, using black text on a white background has a high contrast, as opposed to using light brown text on a brown background.

When combining colours, you could use an accessible colour palette like Color Safe.‌

Using a pale white colour on a green background gotten from Color Safe

Add translation options

There are documentation sites that provide translation options where you can build your docs in multiple languages, websites like Jekyll. This is an example.

Docusaurus is also another doc site that provides multilingual options using Crowdin or Git.

• Follow through this guide to set up translation and localization on Docusaurus using Git.

• Follow through this guide to set up translation and localization on Docusaurus using Crowdin.‌

Use accessibility testing tools

There are tools you can use to check for errors in accessibility in your docs. Some examples are WAVE (Web Accessibility Evaluation Tool) and AXE (Accessibility Engine).

Also, you can get the NVDA(NonVisual Desktop Access) screen reader to test out your content. This software will let you know how the content of your documentation will be perceived by a user using a screen reader.‌

Set up an improvement or suggestion box

Finally, it may not be possible to cover the needs of every user. So you could add a suggestion or improvement box, allowing users to send feedback about how you could further improve the content. Hearing firsthand from users can help you know how best to make the docs accessible for them.

To add an improvement box, you could use an external form link that stores the users' inputs or you could set up the suggestion box in the docs.

How to add an external form link in Docusaurus

You would need to create a custom component for that.

• Go to src/components folder and create a file feedback.jsx.

• Add this code:

import React from 'react'; 

export default function FeedbackButton({ href }) {
  return ( <a href={href} target="_blank" rel="noopener noreferrer" > Give Feedback </a> ); 
};

• In your markdown file import it:

import FeedbackButton from '@site/src/components/feedbackbutton';

• Insert the link

<FeedbackButton href="https://forms.google.com" />

When you run it on your docs, it should showcase a link to Google forms. Google Forms is an example, you could add the link to your company website or server. Here's what it'll look like:

A feedback link for suggestion in a docs site

Summary

To follow and implement these accessibility best practices, you can consider creating or using an already made style guide. This can help you consistently implement these practices and make it easier for you and other technical writers on your team.

There are style guides focused on accessibility for technical writers, such as the following:

1. Accessibility style guide by Heyawhite

2. Write accessible documentation by Google for developers

3. Writing for Accessibility by MailChimp content style guide

That sums up my tips about web accessibility practices in writing. I'm a technical writer, and you can reach out to me on Instagram or hire me via Upwork. Thank you for reading.‌

Web accessibility ensures that everyone, regardless of their abilities, can perceive, understand, navigate, and interact with the web. This inclusivity not only broadens your audience but also reflects social responsibility and compliance with legal standards.

Here's what we'll cover:

1. What is Web Accessibility?
2. Best Practices for Web Accessibility
   – Use semantic HTML
   – Use sufficient contrast
   – Make all functionality keyboard accessible
   – Provide alt text for images
   – Use ARIA roles when necessary
   – Ensure forms are accessible
   – Caption and transcribe audio and video
   – Design consistent, predictable navigation
3. Automation Tools for Accessibility Testing
4. Wrapping Up

What is Web Accessibility?

Accessibility in web design means creating web pages that can be used by people with a wide range of abilities and disabilities. This encompasses auditory, cognitive, neurological, physical, speech, and visual impairments.

Key Principles of Accessibility

The Web Content Accessibility Guidelines (WCAG) provide a framework for making web content more accessible to people with a wide range of abilities and disabilities. These guidelines are based on four key principles, often summarized as POUR, each crucial for creating a universally accessible web.

Here's a deeper look into what these principles mean in practice:

1. Perceivable: Information and user interface components must be presented in ways that all users can perceive. This means providing text alternatives for non-text content (like images), creating content that can be presented in different ways without losing information (such as using a simpler layout), and making it easier for users to see and hear content.
   Example: Providing alt text for images. Alt text allows screen reader users to understand the content and context of the images, making visual content accessible.
2. Operable: User interface components and navigation must be operable by everyone. This includes ensuring all functionalities are accessible via keyboard, giving users enough time to read and use content, and not designing content in a way that is known to cause seizures.
   Example: Implementing keyboard navigation. All interactive elements like links, buttons, and form fields should be accessible using a keyboard, making them accessible to users who cannot use a mouse.
3. Understandable: Information and operation of the user interface must be understandable. This means making text readable and understandable, and ensuring that web pages appear and operate in predictable ways.
   Example: Using consistent navigation menus. Keeping navigation menus consistent across a website helps users with cognitive disabilities learn and remember how to navigate.
4. Robust: Content must be robust enough to be reliably interpreted by a wide variety of user agents, including assistive technologies. This includes ensuring compatibility with current and future user tools.
   Example: Using clean, validated HTML. Well-structured and standard-compliant HTML ensures content can be interpreted by different browsers and assistive technologies.

By integrating these principles into web design, developers and designers can create more accessible and inclusive digital environments. Each principle plays a crucial role in ensuring that the web is a space for everyone, regardless of their abilities or disabilities.

Best Practices for Web Accessibility

Use Semantic HTML

Semantic HTML involves using HTML elements according to their intended purpose rather than just for presentation. It's about structuring your website with elements that describe their meaning and role in the document structure.

This practice is crucial for assistive technologies, like screen readers, which rely on this structure to interpret and navigate content.

How to implement semantic HTML

Consider a typical webpage layout comprising a header, main content, a navigation menu, and a footer. Instead of using non-semantic <div> tags for these sections, you should use the semantic elements <header>, <main>, <nav>, and <footer> respectively.

Here's an example:

<header>
  <!-- Site logo, header content -->
</header>
<nav>
  <!-- Navigation links -->
</nav>
<main>
  <!-- Main content -->
</main>
<footer>
  <!-- Footer content -->
</footer>

Why semantic HTML is useful:

1. Accessibility: Screen readers can easily navigate and interpret the content. For example, a user can skip directly to the main content or easily find the navigation menu.
2. SEO benefits: Search engines favor well-structured content. Semantic elements make it easier for search engine bots to understand the content of a webpage, potentially improving search rankings.
3. Maintainability: Semantic HTML leads to cleaner, more readable code, making it easier for developers to understand and maintain.

Using semantic HTML is the foundation of web accessibility, ensuring content is accessible and meaningful to all users, including those using assistive technologies.

Use Sufficient Contrast

Contrast refers to the difference in color and brightness between the text and its background. Ensuring sufficient contrast is vital for readability, especially for users with visual impairments like color blindness or low vision. High contrast between text and background makes it easier for these users to read and understand content.

How to implement good contrast

Imagine a webpage with light gray text on a white background. This combination might look aesthetically pleasing but can be hard to read for many users.

To improve contrast, you could change the text color to a much darker shade, like black or dark gray.

/* Low contrast example */
.low-contrast-text {
  color: #757575; /* Light gray */
  background-color: #fff; /* White */
}

/* Improved contrast */
.high-contrast-text {
  color: #000; /* Black */
  background-color: #fff; /* White */
}

Why contrast is useful:

1. Enhanced readability: High contrast makes the text legible to users with visual impairments and those reading under challenging lighting conditions.
2. Inclusivity: It caters to a wider audience, including users with deteriorating vision and those with temporary or situational impairments.
3. Legal compliance: Many regions have regulations requiring accessible web content, and sufficient contrast is a common requirement.

Tools like the WebAIM Contrast Checker can help you evaluate your color choices, ensuring they meet accessibility standards like WCAG. By ensuring sufficient contrast, you not only make your website more accessible but also improve the overall user experience.

Make All Functionality Keyboard Accessible

Ensuring that all functionalities on a website are accessible via keyboard is essential for users who cannot use a mouse due to physical disabilities, temporary injuries, or personal preference. This includes navigating menus, activating buttons and links, filling out forms, and using interactive widgets.

How to make content keyboard accessible

Consider a dropdown menu on a website. Typically, users hover over the menu with a mouse to view the options.

To make this keyboard-accessible, you need to ensure that users can navigate to the menu using the Tab key and expand the menu using the Enter or Space key.

<ul>
  <li tabindex="0">Menu Item 1
    <ul class="dropdown-content">
      <li tabindex="0">Sub Item 1</li>
      <li tabindex="0">Sub Item 2</li>
    </ul>
  </li>
  <li tabindex="0">Menu Item 2</li>
</ul>

document.querySelectorAll('li[tabindex="0"]').forEach(item => {
  item.addEventListener('keypress', function(e) {
    if (e.key === 'Enter' || e.key === ' ') {
      // Code to toggle dropdown
    }
  });
});

Why keyboard navigation is useful:

1. Accessibility for all: Keyboard accessibility ensures that users with motor disabilities or those who prefer keyboard navigation can use the website effectively.
2. Enhanced usability: Keyboard shortcuts can speed up navigation, offering an enhanced experience even for users who can use a mouse.
3. Compliance with accessibility standards: Adhering to standards like WCAG and ADA (Americans with Disabilities Act) often requires keyboard accessibility.

In practice, keyboard accessibility may involve more than just basic navigation. It also includes managing focus, creating keyboard shortcuts for complex actions, and ensuring custom widgets are keyboard-friendly. By prioritizing keyboard accessibility, you make your website more inclusive and user-friendly.

Provide Alt Text for Images

Alt text (alternative text) is a concise description of an image's content and function. It's crucial for visually impaired users who rely on screen readers to understand image content. Alt text ensures that even if users can't see the images on a web page, their purpose and message can still be conveyed.

How to add alt text to images

Suppose your website has an image of a company logo. The alt text should describe the logo, not just state "logo". For instance, alt="FreeCodeCamp's campfire Logo".

<img src="freecodecamp-logo.png" alt="FreeCodeCamp's campfire Logo">

For purely decorative images that don't add informational content, use an empty alt attribute (alt="") to indicate that they can be skipped by screen readers.

Why alt text is useful:

1. Accessibility Compliance: Providing alt text is a fundamental aspect of web accessibility, required under WCAG guidelines.
2. SEO Benefits: Alt text improves SEO by providing better image context/descriptions, helping search engines index an image properly.
3. Fallback Content: If an image fails to load, the alt text will be displayed, helping all users understand what was supposed to be there.

Properly implemented alt text makes your website more accessible and inclusive, ensuring that all users, regardless of their ability to see, have access to the information conveyed by images. It's a simple yet impactful practice that enhances the overall user experience.

Use ARIA (Accessible Rich Internet Applications) Roles When Necessary

ARIA roles and attributes enhance the accessibility of web content, particularly for dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. ARIA helps make web content and web applications more accessible to people with disabilities, especially when HTML can't accomplish it alone.

How to implement ARIA roles and attributes

Consider a web application with a dynamic content update section, such as a live news feed. Standard HTML alone may not be able to convey the dynamic nature of this content to screen readers.

By using ARIA roles, you can make it clear to assistive technologies that this section of the page is a live region and its updates are important. For instance:

<div aria-live="polite" aria-atomic="true">
  <!-- Dynamic content here, like live news updates -->
</div>

In this example, aria-live="polite" indicates that updates to this region should be announced by screen readers, but not interrupt the current task, while aria-atomic="true" ensures that the entire region is read as a whole, not just the updated part.

Why ARIA is useful:

1. Enhanced screen reader experience: ARIA roles provide screen reader users with a more comprehensive understanding of what's happening on the page, particularly for dynamic and complex content.
2. Greater interactivity: ARIA can make web applications more interactive and usable for people with disabilities, facilitating operations that standard HTML can't handle.
3. Custom widget accessibility: For custom widgets that lack semantic HTML equivalents, ARIA roles can define the widget's function, making it accessible.

While ARIA is powerful, it's important to use it only when necessary. Native HTML elements should be the first choice as they inherently carry semantic meaning and accessibility features. ARIA should be used as a supplement to enhance accessibility when HTML's semantics don't suffice.

Ensure Forms are Accessible

Accessible forms are vital for users with disabilities to interact with a site, input data, and utilize services. Ensuring that form elements are accessible means they can be easily navigated, understood, and filled out by everyone, including those using screen readers or keyboard navigation.

How to make forms accessible

Imagine a simple contact form with fields for name, email, and a message. For each form element, use a <label> tag to provide a clear description. Ensure that each <label> is associated with its respective form control using the for attribute, which matches the id of the input element. This is crucial for screen reader users to understand what each field represents.

<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">

  <label for="message">Message:</label>
  <textarea id="message" name="message"></textarea>

  <button type="submit">Submit</button>
</form>

Why accessible forms are useful:

1. Clarity and context: Labels provide context to users, especially those using screen readers, about what type of information is expected in each field.
2. Error handling: Accessible forms should also handle errors clearly, informing users about what went wrong and how to fix it. This can include real-time validation feedback and error messages that are announced by screen readers.
3. Keyboard navigation: All form controls should be navigable using the keyboard, allowing users who can't use a mouse to interact fully with the form.

Accessible forms not only comply with accessibility standards but also enhance the overall user experience, making your website more inclusive and user-friendly.

Caption and Transcribe Audio and Video

Providing captions for video content and transcriptions for audio is crucial for accessibility. Captions and transcriptions ensure that deaf or hard-of-hearing users, as well as those who prefer reading to listening, can access audio and video content.

How to make audio and video content accessible

For a video on your website, include closed captioning that accurately reflects the spoken content and other auditory cues. You can use HTML5's <track> element to specify caption files. Similarly, for audio content like podcasts or interviews, provide a text transcription.

<video controls>
  <source src="video.mp4" type="video/mp4">
  <track src="captions_en.vtt" kind="captions" srclang="en" label="English">
</video>

In this example, a WebVTT (.vtt) file is used for captions. Ensure the captions are synchronized with the audio and include descriptions of relevant non-speech audio.

Why captions and transcriptions are useful

1. Accessibility for hearing impaired: Captions and transcriptions are essential for users who are deaf or hard of hearing, enabling them to access content that would otherwise be inaccessible.
2. Enhanced comprehension: They also benefit users who are not fluent in the language of the video or have difficulty understanding the speech.
3. Flexible viewing: Captions allow content to be consumed in sound-sensitive environments, like workplaces or libraries.

Remember to regularly check the accuracy and readability of your captions and transcriptions. Well-implemented captions and transcriptions not only make your audio and video content accessible but also enhance the overall engagement and reach of your content.

Design Consistent, Predictable Navigation

Designing a website with consistent and predictable navigation is key to accessibility. It allows users, especially those with cognitive disabilities, to learn the navigation pattern quickly, enhancing their ability to find information and navigate your site effectively.

How to design effective navigation

Consider a website with a top navigation menu. The menu items should be in a logical order and remain consistent across all pages. Avoid changing the order of menu items or their location on different pages.

<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About Us</a></li>
    <li><a href="/services">Services</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
</nav>

In this example, the navigation structure is simple and straightforward. It's important to maintain this structure and order consistently throughout the website.

Why good navigation is useful:

1. Ease of use: A consistent navigation structure helps users understand and remember how to interact with your website, reducing confusion and frustration.
2. Improved orientation: Users can better orient themselves and understand their current location within the website.
3. Support for assistive technologies: Consistent navigation is easier for screen readers and other assistive technologies to interpret, providing a smoother browsing experience for users relying on these tools.

By ensuring that your website's navigation is consistent and predictable, you enhance the usability for all users, making your website more accessible and user-friendly.

Automation Tools for Accessibility Testing

Incorporating automation tools into the accessibility testing process can significantly enhance efficiency and coverage. These tools can swiftly identify areas of non-compliance, allowing for prompt rectifications.

Below are some key tools with link to their websites if you want to explore more:

1. Axe Accessibility Checker

Axe is a versatile browser extension and testing tool available for Chrome, Firefox, and Edge. It provides reliable and detailed issue reporting, making it ideal for quick checks and in-depth analysis.

2. WAVE (Web Accessibility Evaluation Tool)

WAVE, offered as a browser extension, visually represents potential accessibility problems on web pages, helping to pinpoint issues with color contrast, alt text, and ARIA roles.

3. Google Lighthouse

Integrated into Google Chrome's Developer Tools, Lighthouse features an accessibility audit tool that highlights issues and provides actionable recommendations.

4. Tenon.io

Tenon.io is a comprehensive web-based tool for detailed accessibility testing. It can be integrated into development workflows for automated testing during the build process.

5. JAWS Inspect

JAWS Inspect translates screen reader outputs into a visual format, aiding in the testing of screen reader compatibility and navigability.

6. Color Contrast Analyzer

This tool assists in evaluating the contrast between text and its background, ensuring readability for users with visual impairments.

7. Accessibility Insights

Developed by Microsoft, Accessibility Insights offers a suite of tools, including a web tool for Chrome and Edge, to guide manual testing alongside automated checks.

8. Pa11y

Pa11y is a command-line tool that runs automated accessibility tests on web pages, customizable for integration into development processes.

By leveraging these tools, developers and designers can ensure their websites meet accessibility standards, providing an inclusive experience for all users. Regular use, combined with manual testing and user feedback, creates a comprehensive approach to maintaining and enhancing web accessibility.

Embrace Accessibility as a Cornerstone of Web Development

In conclusion, the integration of web accessibility best practices is not just a matter of compliance but a commitment to inclusivity and universal design. The digital world is for everyone, and ensuring that web content is accessible to all, including those with disabilities, is a fundamental responsibility of web developers and designers.

Utilizing tools like Axe, WAVE, Google Lighthouse, and others, combined with manual testing and adherence to guidelines like WCAG, can significantly improve the accessibility of web content. By doing so, we open up our digital spaces to a wider audience, enhance user experience, and foster an environment of inclusivity.

Accessible web design benefits everyone, not just those with disabilities. It leads to cleaner code, better SEO, and a more flexible and resilient website. As the web continues to evolve, prioritizing accessibility will be crucial in creating a more connected and inclusive world. Remember, when we design for accessibility, we improve the web for everyone.

In this article, you'll learn what accessibility means, and why it's important to make accessibility a part of your regular workflow. I'll also give you practical tips with examples to make your websites more accessible.

Let's explore the key parts of web accessibility together and help you make a website that includes everyone.

What is Web Accessibility?

Web accessibility refers to the practice of designing and developing websites, applications, and digital content in a way that ensures people with disabilities can perceive, understand, navigate, and interact with them effectively.

Principles of Web Accessibility

To effectively enhance the accessibility of your websites and apps, you'll want to follow these fundamental principles outlined by the Web Content Accessibility Guidelines (WCAG):

Is it Perceivable?

Content should be displayed in a manner that all users can understand, regardless of their sensory abilities. Here are some ways you can make your content more perceivable:

First, you can provide captions for audio and video materials. Adding captions to your website or application allows those with hearing disabilities to understand the information being shared, and make the content more accessible to everyone.

You can see an example of adding captions to a video in the image below:

Image of a video illustrating the use of captions.

Next, make sure you use proper color contrast for text and background elements.

Colors are an important part of a website, and we can describe them in terms of hue, lightness, and saturation.

There are several categories of colors which include warm colors, cool colors, and neutral colors

Warm Colors: Warm colors include red, orange, and yellow, and variations of
those three colors. These are the colors of fire, fall leaves, sunsets, and sunrises, and are generally energizing, passionate, and positive.

Cool Colors: Cool colors include green, blue, and purple, are often more
subdued than warm colors. They are the colors of night, water, of nature, and are usually calming, relaxing, and somewhat reserved.

Neutral Colors: Neutral colors often serve as the backdrop in design. They’re
commonly combined with brighter accent colors. But they can also be used on their own in designs and can create very sophisticated layouts. Neutral colors include black, white, gray, cream, and beige.

Examples of colors that will make good contrast are white and blue, purple and white, yellow and white, light purple and black, green and white, black and white, and so on – basically any colors that are different enough from each other to create that contrast.

Examples of colors that will make a bad contrast are gray and white, brown and orange, red and purple, and so on.

Here is an example that shows good color contrast that's easy to read:

Image illustrating good contrast using a dark blue background with white text

And here's an image with poor color contrast that's hard to read:

Image Illustrating bad contrast using a white background with light grey text

Also, it's a good idea to include descriptive alternative text (alt text) for images, explaining what they depict and their purpose.

So for example, when you want to add an image to your website, you can add alt text to it explaining what it depicts.

Here is a markup description of how to add alt text to an image:

    <img src="Dog.png" alt="Image of a dog">

Here is an example that shows an image of two (2) dogs:

Image of two dogs

And here's an example of an image that illustrates the use of alt text:

Image of dog with alt text displayed

You should also describe your icon buttons.

Icons can be easily understood most of the time. It's widely recognized that an x symbol, like this ❌, typically closes a window, a check mark ✅ signifies completion, a forward arrow ▶ signifies send (or play), and a plus sign ➕ represents addition.

But this is clear only for individuals with visual capabilities. For people who aren't able to see the buttons, you'll need to provide a description so they know what that button does.

Let's take a look at this HTML and CSS code that shows how to make buttons access:

<!DOCTYPE html>

Here's the result of the code implemented above:

Is it Operable?

Users should be able to navigate and interact with the interface quickly. Consider the following factors:

First, make sure you use clear and consistent headings.

This is what clear and consistent headings look like:

I am a Title

I am a Subtitle

This is heading 3

This is Heading 4

This is Heading 5

This is heading 6

As you can see, these headings go from largest to smallest in order. We have an H1 heading first, followed by H2, H3, and so on.

Here are some headings that don't follow the proper hierarchy:

This is heading 6

This is Heading 5

This is Heading 4

This is heading 3

I am a Subtitle

I am a Title

In this example, the headings go in reverse order, starting from H6 and moving up through H5, H4, and so on.

Just remember to use proper heading hierarchy – don't use an H2 and then jump straight to H4 for a subheading, for example, as this is visually jarring and doesn't convey the proper importance or hierarchy of the text.

Here's why heading hierarchy is important:

• A clear heading hierarchy helps readers easily navigate and understand the content of a document.
• Heading hierarchy is crucial for accessibility, as it helps screen readers and assistive technologies interpret the structure of the content. This is important for individuals with visual impairments who rely on such tools to access information.
• A well-organized heading hierarchy implement a logical flow of information, ensuring that topics are presented in a coherent order.

Also, refrain from using elements that might trigger physical discomfort, like bright flashing lights.

And make sure you think about keyboard accessibility so users can navigate and communicate using the keyboard, and not exclusively using a mouse.

Is it Understandable?

Content and functionality should be presented clearly and understandably. Consider the following factors:

• Organize content using headings, subheadings, and bullet points to enhance readability.
• Provide instructions and error messages that are easy to understand.
• Use simple and concise language, avoid complex terms.

Is it Robust?

Websites should be built using robust and widely supported technologies to enable compatibility across devices and assistive technologies.

You'll want to maximize compatibility with current and future user agents, including assistive technologies.

Here are some of the ways you can maximize compatibility with current and future agents, including assistive tools:

• Use HTML5 semantic elements like <header>, <nav>, <main>, and <footer> to enhance the document's structure.
• Ensure that your JavaScript code is efficient and doesn't block the rendering process.
• Utilize browser developer tools and online testing services to identify and fix compatibility issues.
• Conduct usability testing with a diverse group of users, including those who rely on assistive technologies, to gather feedback and make improvements.
• Optimize your website for fast loading times and low data usage using techniques like caching and tools like CDNs to reduce latency. This benefits both accessibility and user experience.
• Document your code and accessibility features for future maintainers.
• Test website compatibility across various browsers. Testing website compatibility involves ensuring that your website functions correctly and looks good on a variety of devices, browsers, and assistive technologies.

Here are the steps you can follow to test website compatibility effectively:

1. Device Testing: Test your website on various devices, such as desktop computers, laptops, tablets, and smartphones. This includes both iOS and Android devices.
2. Browser Testing: Check your website's performance and appearance on multiple browsers, including but not limited to Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge.
3. User Testing: Conduct usability testing with real users. Ask them to use your website on different devices and browsers and collect feedback on compatibility issues.
4. Performance Testing: Assess website loading times, and optimize for speed using tools like Google PageSpeed Insights, GTmetrix, or Lighthouse. Check for compatibility with slow internet connections.

Conclusion

Understanding web accessibility can enhance the user experience by creating a smooth and seamless interaction with websites and web applications.

Implementing these tips can improve the overall user-friendliness and navigability of your app. It'll help create a more enjoyable experience for all users, and will also allow people with disabilities to perceive, understand, navigate, and interact with your sites effectively.

Ensuring good accessibility is a fundamental responsibility for developers. It can help their applications provide an equitable experience for all users.

But it can be easy to go down a rabbit hole when learning about accessibility best practices.

Fortunately, there are many resources available that teach you how to build accessible websites and apps. In this article, I'll discuss the three websites I frequently go to when I have questions about accessibility: W3C WCAG, WebAIM, and a11yprojects.

Let's look at each one and how you can use them to create more accessible projects.

W3C WCAG

First up, there's W3C WCAG. As stated in the Web Content Accessibility Guidelines (WCAG) website, WCAG provides, "strategies, standards, resources to make the Web accessible to people with disabilities".

The guidelines listed on this website provide comprehensive frameworks for developers to make the web pages universally accessible.

WCAG helps developers craft digital spaces that are usable, perceivable, operable, and robust.

One great section of W3C is the Easy Checks – A First Review of Web Accessibility. In this section, developers can easily learn accessibility rules when it comes to page titles, images, text, and interactions. Easy Checks section is a great place to start navigating W3C.

How to Use W3C WCAG:

• Visit the W3C WCAG website and explore the guidelines and success criteria relevant to your project.

• Study the techniques and documents for the technologies you're using.

• Check the conformance requirements to set accessibility goals for your website or app.

To learn more about these standards and how to make a website accessible, you can come to W3C and study criteria needed to be considered accessible. W3C WCAG is one of the best websites to go to learn about accessibility rules.

WebAIM

On WebAIM's website, they state that they, "empower individuals and organizations to create and deliver accessible content".

WAVE is a accessibility evaluation tool. One tool WAVE offers is its Browser Extension. After downloading the WAVE browser extension, you can inspect your pages and log accessibility issues with the page. Then you can easily figure out how to fix these issues.

The WAVE extension is available on FireFox and Chrome and makes it so simple for your to recognize common accessibility issues. You can find instructions on how to download the WAVE extension on the WAVE's extensions tab.

After downloading the WAVE extension, you can go to your extensions and run it. Finding accessibility issues is as quick as clicking a button. For example, after downloading WAVE, I ran the extension on the New York Times homepage and was alerted to the accessibility issues the website had.

Screenshot of New York Times Homepage with WAVE extension pointing accessibility errors

In the screenshot above, you can see The New York Times homepage with the WAVE extension running. On the left side of the screenshot, you can see WAVE's summary tab pointing out 1 accessibility issue in the homepage with 120 errors. This is WAVE's summary tab, which gives developers a overview of accessibility issues in the page.

Screenshot of New York Times Homepage with WAVE extension pointing accessibility errors

WAVE goes in depth and explains the summary tab even further. Clicking on the details section of the extension lists the accessibility errors in greater details, which you can see in the screenshot above.

The one error that was in the summary page is explained further in the details section. WAVE points out that the accessibility error was a linked image missing alternative text. The 120+ warning are also listed in much more detail, which point out that there are 8 long alternative texts, 1 missing first level heading, 4 redundant link and much more.

The details tab is a great way to find out the accessibility issues your page might have and give you a starting point to fix the accessibility issues.

How to Use WebAIM:

• Install the WAVE browser extension, then run it on your web pages to identify and address accessibility issues.

• Explore WebAIM's website for additional resources, articles, and training materials.

a11yproject

a11yproject, pronounced "a-eleven-y-project" (with "11" representing the omitted letters in the word accessibility) "is a community-driven effort to make digital accessibility easier".

This website displays articles that are all about accessibility. The articles are written by developers and approved by the a11yproject team.

Some recent articles published on a11yprojects include, What is Semantic HTML? and The power of ChatGPT as a cognitive accessibility assistive technology for Traumatic Brain Injury survivors. There are many more interesting topics around accessibility as well.

a11yprojects are divided into different categories, which range from quick tips, background, myths, quick tests and so much more. Readers can go to a11yprojects and filter to a article category they want to see.

a11yproject articles are written by developers that are passionate about accessibility and have a lot of knowledge to share with others. You can go on a11yprojects website to read about latest news about accessibility. The website covers all aspects of accessibility, but mainly focuses on web accessibility.

How to Use a11yproject:

• Visit the a11yproject website to read articles about accessibility best practices and the latest news in the field.

• Engage with the accessibility community by participating in discussions and contributing your knowledge.

Conclusion

There are so many resources available online for developers to learn about the latest news on accessibility. There are also many communities of developers that are passionate about accessibility.

W3C WCAG, WebAIM and a11yprojects are just few online resources available for developers to conduct accessibility research. By going to these three websites, developers can learn the latest news on accessibility and study acceptable accessibility criteria.

In this article, you will learn:

• What accessibility means
• Some myths surrounding accessibility
• How to make your work more accessible
• Some practical accessibility examples

Let's get started!

What is Accessibility?

There are so many definitions of accessibility on the web. But to me, accessibility in digital/web design simply means designing to make content usable for people with disabilities.

Working with accessibility in mind involves designing websites, applications, and digital interfaces that can be navigated by individuals with visual, hearing, motor, or cognitive impairments.

Some Myths Surrounding Accessibility

Like every topic under the sun, lots of people have different opinions about accessibility. Some might be true, some might be false.

Below, I'll share some popular misconceptions about accessibility.

Myth: people with disabilities don't use my platform

You might be designing for a governmental or corporate platform and think that people with disabilities will not use your platform.

This is an incorrect notion to have. There are different forms of disability, including temporary and permanent disabilities. You have no control over who might use your platform at any time or what they might need.

Myth: accessibility is only for people with disabilities

While accessibility measures are crucial for individuals with disabilities, they also benefit a wide range of people, including the elderly, those with temporary disabilities, individuals with situational limitations, and even people without apparent disabilities.

Accessibility best practices make websites and apps easier for everyone to use in various ways.

Myth: accessibility is all about adding ALT text

Alt (alternative) text is an assistive technology which is a valuable tool. But you shouldn't only use alt text as a substitute for general/wider accessibility best practiceds.

Assistive technologies work best when used in conjunction with accessible designs and content.

Myth: you should build accessible sites just so you don't get in trouble with the law

Although accessibility is a legal and ethical requirement, you shouldn't build it into your designs because of that reason alone.

You should build accessible websites and apps because accessibility helps anyone who comes to your platform interact with it well.

Why is Accessibility Important?

Accessibility is important for a number of reasons. They include:

• Improved Usability: Accessibility improves the usability of a website or application. Features like clear navigation, intuitive design, and so on benefit all users. They also contribute to user satisfaction, usability and overall engagement with products and services.
• Broad User Base: When your platform is accessible, it increases your user base, as people from different backgrounds and situations can use your platform. This expands the reach and customer base of your product.
• Enhanced User Experience: Incorporating accessibility in your designs will enhance the experience of your users (disabled or not), making it easier to interact with your platform.
• Equal Rights & Inclusion: Accessibility promotes inclusivity and prevents discrimination based on disabilities. Everyone deserves to have equal access to opportunities, information, and social services.
• Legal & Ethical Requirements: Legally and ethically, accessibility is a requirement for different domains and platforms. Adhering to these legal requirements ensures compliance and helps your client avoid potential legal issues.

How to Make Your Designs More Accessible

Understanding Accessibility Guidelines

Familiarize yourself with accessibility standards such as the Web Content Accessibility Guidelines(WCAG). These guidelines provide comprehensive recommendations for designing accessible digital content.

Use Sufficient Color Contrast

Opt for color combinations that are accessible for individuals with color blindness or low vision. Use tools to check the color contrast ratio and ensure that text is easily distinguishable from the background.

Here's an example of creating sufficient color contrast:

Color contrast example

In the example above, in the first sentence, the highlighted word (link) does not contrast well with the rest of the sentence. Compare with the second sentence where "link", is perfectly contrasting and has an underline, to create more emphasis.

It's more likely that the second sentence is accessible for individuals with color blindness or low vision.

Create Inclusive Forms

Design forms that are user-friendly. Include clear labels, instructions and, error messages. Make sure to enable users navigate and complete the form without relying solely on a mouse.

Here's an example of creating an inclusive form:

User-friendly form example

The first form has some issues:

• It does not have any header (to indicate what the form is for).
• It shows an error field without explaining what it indicates.
• The form does not specify the number of characters the password should have, all of which are very helpful to the user(s).

All these were corrected in the second form, where:

• A header was added indicating that the form is for "Course Registration".
• The error field specifically explains what's wrong – the user entered an invalid email address.
• The number of password characters as required by the platform was stated.

Implement Responsive Design

Some designers design for desktop versions only, not considering accessibility. But it's much more helpful to make your design responsive.

Ensuring that your designs are adaptable to different screen sizes and resolutions accommodates individuals who use various devices. This is a great way to make your designs more accessible.

Here's an example of implementing responsive design:

Responsive Design example

Above is an example of a product description page of a website. The first image on the left shows the desktop version only. In the second image, the design has been made more accessible – you can see the mobile responsive version as well.

Designing for different screen sizes shows that your design accommodates individuals who use various devices, as stated earlier.

Provide Feedback and Error Handling

Making sure your designs provide adequate feedback accompanied by the next step to take, gives a great user experience. Error notifications can completely discourage a user if not handled correctly. As such, adequate feedback is necessary to make your design accessible.

These are few ways of making your designs accessible, amongst others. You can make an accessibility checklist to help remind yourself of accessibility when designing. To help further, check out accessibilitychecklist.org to find out.

Here's an example of how to provide feedback and handle errors:

Error handling example

In the example above, the first 404 page tells the user what error occurred, and what might be the cause – but does not suggest a way of fixing the error. Meanwhile, the second 404 page explains the error that occurred and provides a way of fixing it – "Go to homepage".

Conclusion

Accessibility is important to customer retention and the growth of a business. As a UI/UX/Web designer, it's your responsibility to incorporate accessibility into your product and give your users an awesome experience. Remember, your user is the priority.

ARIA is extremely important for building accessible web applications. But it's very easy to misuse ARIA and make the website less accessible.

This article will demonstrate five common ARIA mistakes and how to fix them.

Don't Use Unnecessary ARIA Labels

The first rule of ARIA is that you should not use ARIA unless you have to. HTML elements already have accessibility built in, and adding unnecessary ARIA labels can break accessibility.

For that reason, it's much better to use HTML elements, instead of constructing code with ARIA labels.

Example of misusing ARIA labels:

⛔ BAD: Below is a button element with aria-label:

<button aria-label="Send">Send</button>

✅ GOOD: Below is a button element:

<button>Send</button>

In the examples above, I am creating a button element. In the first code snippet, there is a aria-label with the label, “send”. HTML’s button element already has accessibility built into it. It is not necessary to add an aria-label so it's much better to remove the label.

The button element will read the text inside it already. We do not need to add the aria-label to describe it.

Takeaway: Don’t add unnecessary ARIA labels if you can use accessible HTML elements instead.

Don't Use the Wrong ARIA Attributes

There are pre-defined ARIA states and properties defined by the ARIA working group, which is part of World Wide Web Consortium.

Developers should use the states and properties available – you cannot create your own in your code. You can find the list of properties and states on W3's Website.

Example of using incorrect ARIA attributes:

⛔ BAD

<span aria-donotshow="true">Don’t show this</span>

✅ GOOD

<span aria-hidden="true">Don’t show this</span>

This means that a new property, like aria-donotshow, is not correct. aria-donotshow is not a property in the W3 website so you shouldn't use it.

Takeaway: Don’t create your own ARIA attributes. You can only use the ones defined by the ARIA working group.

Know When to Use aria-labelledby

Another common mistake is when developers use aria-label to describe content inside the DOM.

All interactive elements need an accessible name. If we want to add an accessible name to an element where the name needs some content from elsewhere in the DOM, we should use aria-labelledby. If there is no content that can be referred to to create an accessible name, then we can use aria-label.

Example of when to use aria-labelledby:

⛔ BAD

<div aria-label="Related Content">                
    <span>Related Content</span>        
</div>

✅ GOOD

<div aria-labelledby="nav-title">                
    <span id='nav-title'>Related Content</span>        
</div>

In the example above, the first code snippet uses aria-label and associates it with the text, “Related content”. But the span inside the text already has the correct content we want a screen reader to read.

Instead of using aria-label in this example, we should reference the span content by adding aria-labelledby that is associated with the id of the content we want to reference.

Takeaway: If you want to reference content from inside the DOM, use aria-labelledby with corresponding id.

Know When to Use aria-describedby

Sometimes, we need to give more information to an element. For example, we might want to tell the user that the button they will press will open a new tab.

This information is important because the user needs to know where they are when navigating websites.

For these types of scenarios, we can use aria-describedby to give additional information.

Example:

⛔ BAD

<button aria-label="Close" aria-label="Opens in a new tab">    
Show related        
</button>

✅ GOOD

<button aria-label="Close" aria-describedby="description">            Show related        
</button>        
<div id="description">Opens in a new tab</div>

In the first example above, what engineers expect the screen reader to announce is: “button, Show related, opens in a new tab”.

But the screen reader does not do that. Instead, it says,“button, opens in a new tab”. The screen reader does not read the content inside, because aria-label always overrides the text content of the HTML5 element it has been applied to.

The second code snipped shows the correct way to use aria-describedby. The screen reader will read, “button, Show related, opens in a new tab”.

That information tells the user that the button is to show related content and if they press that button, it will navigate them to another tab.

Takeaway: Use aria-describedby to add additional information to elements.

Don't Use ARIA Child Roles Without Parent Roles

There are some ARIA attributes that require a child/parent relationship. This means that you cannot use the ARIA child attribute without wrapping it around its parent ARIA attribute.

It’s easy to forget the child/parent relationship and build code that only uses the parent attribute without the child, or to build code that only uses child attribute without its parent.

If you forget the child/parent relationship, the code becomes more inaccessible, which defeats the purpose of ARIA.

Example:

⛔ BAD:

role="listbox" is a parent property. The ul list below does not have role=option which is its child property.

<div role="listbox">
    <ul>
        <li></li>
    </ul>
</div>

✅ GOOD:

role="listbox" is a parent property. The ul list below has role=option which is its child property.

<div role="listbox">
    <ul>
        <li option="option"></li>
    </ul>
</div>

In the code example above, the first code has a code snippet that has role=listbox which is a parent element. listbox needs children inside which is option. We cannot use listbox on its own to build accessible web sites.

Takeaway: Always use child/parent properties together.

Summary

ARIA is a set of attributes and roles defined by WAI to make the web more accessible to people with disabilities. Although it's necessary to create an accessible web, it is very easy to misuse ARIA and make websites less accessible instead.

Try to avoid these five most common ARIA mistakes:

1. Don’t unnecessarily use aria-label. Built-in HTML semantics are always better.

2. Don’t create your own aria attribute. Only use the ones defined by ARIA.

3. Use aria-labelledby with an id when you have content that wraps divs and you want to group sections.

4. Use aria-describedby when you have sections that need more descriptions.

5. Do not use a child ARIA without a predefined parent ARIA.

ARIA was created to make websites more accessible to people with disabilities. If we avoid common mistakes, we will make sure our websites are accessible.

Think about the last site you built, or your favorite site. Are you confident that anyone can use your site and perform the critical actions it requires? Have you considered folks with motor disabilities, visual disabilities, cognitive disabilities, and auditory disabilities?

Accessibility is often left as an after-thought. When it is time to ship a feature, we do an accessibility test and find out that our site wasn't accessible and do a hacky fix.

Making a site accessible is a huge undertaking. But if we keep accessibility in mind from the get-go, it makes it much easier to build an accessible web app.

In this post, I will go over 5 things you can keep in mind WHILE building your app so you don't have to do a hacky slap together at the end.

5 Things to Remember for Good Accessibility

1. Semantinc HTML
2. Tabindex
3. Aria attributes
4. Role
5. Keyboard navigation and screen readers

In short, S.T.A.R.K.

If you need help remembering this, think of Tony Stark.

Let's go through each of these to understand how to use them in your web apps.

What is Semantic HTML?

Using semantic HTML is important for accessibility. This is because assistive technologies such as screen readers are able to interpret what's on the page by parsing the HTML of the page. They enable users to take actions based on the elements.

For example, if a screen reader encounters a button, it signals to the user that they should click on it.

Let's consider some use-cases of what can happen when you don't use semantic HTML:

Creating buttons by using div instead of button:

divs are container elements, so when a screen reader encounters a div, it automatically thinks it is a presentational element.

When a screen reader user encounters a div that has content or children within it, the screen reader announces role="group" and the user will completely miss that the div is interactive. So make sure you use the proper semantic element for its purpose. You get accessibility for free.

Using CSS to fake headings instead of using h1-6 tags:

Heading tags such as <h1> and <h2> let an assitive technology know that this is important text, and the screen reader will announce "Heading".

When you use CSS to make a heading instead of using correct semantics, the significance of the text is lost to a screen reader.

So just make sure to use semantic HTML whenever possible.

What is Tabindex?

Adding a tabindex makes interactive elements keyboard-navigable. When you add tabindex to an element, a user is able to navigate to it using only their keyboard and/or assitive technologies.

1. You use a tabindex of 0 to set focus to an element in the default tabbing order,
2. You use a tabindex of -1 to programmatically focus an element using JavaScript.
3. Do not assign a value of > 1 to tabindex.

A word of caution though - you should only add tabindex to interactive elements. It is not a good practie to add tabindex to elements such as div.

Instead of adding tabindex in that case, use a semantic element, such as a button since semantic elements already are tabbable and do not need an additional tabindex value.

What are ARIA attributes?

Aria attributes such as aria-checked, aria-label give additional information to assistive technologies.

Aria attributes are a set of HTML attributes that you use to provide additional information about the purpose and state of elements on a web page. These attributes are especially beneficial to assistive technologies to provide more context and better navigation for users.

Some common aria-attributes include:

1. aria-label: used to provide a label or name for an element.
2. aria-hidden: used to indicate that an element should be hidden from assistive technologies. This can be useful for elements that are used for layout purposes but are not relevant to the content of the page.
3. aria-describedby: used to associate an element with a description, which helps to provide context of an element.
4. aria-live: used to indicate that an element's content may change dynamically, and that assistive technologies should pay attention to changes in the element's content.

You can use these attributes in combination with each other and with standard HTML attributes to create more accessible and user-friendly web content.

What is the aria-role attribute?

You use the aria-role attribute to define the purpose of an HTML element and provide its semantic meaning.

For example, if you are building a grid component with the help of CSS and divs, you can use role="grid" to let assistive technologies know about the semantics of the component.

Some common aria-roles include:

1. button: used to indicate that an element should be treated as a button.
2. alert: used to indicate that an element is an alertbox.
3. presentation: used to indicate that an element is only presentational.

It is important to exercise caution with aria-role. Remember to not overdo it.

How to handle keyboard navigation and screen readers

Many users with motor disabilities rely on their keyboard and assitive technologies to navigate the web. So it's critical that every component be navigable using a keyboard and screen reader.

You can test keyboard accessibility by navigating a site using only your keyboard. Here are some common keys:

1. tab key to navigate to different sections of the site.
2. spacebar to select elements, such as a checkbox.
3. enter to press buttons.

While testing keyboard navigation, make sure you think about the following:

1. Focus remains visible: Ensure that you can clearly see which element is being focused on the page. Focus should always remain visible.
2. Tab order: When tabbing through sections, the order of tabbing should follow the natural flow and logical structure of the website. It should not jump back and forth between sections.
3. Keyboard traps: Ensure that when navigating with the keyboard, the focus doesn't get trapped on an element. For example, this could happen when a modal is opened, or the focus is navigated to a widget, such as calendar or emoji picker. Ensure that when you select an element in the widget, you are able to navigate back to the site.

Wrapping Up

Overall, testing for accessibility during development is an important part of the process that can help to create more usable and accessible software for all users. Testing for accessibility early helps to provide a great user experience for everyone.

In the next article, I will talk about the various accessibility tools and how to debug an accessibility issue. You can sign up to get it in your inbox here.

Until then, enjoy your holidays!

Feliz Navidad.

This means that as developers, our focus on making websites and applications accessible helps more people use these resources.

In this article, I'll point out barriers to web accessibility, discuss the Web Content Accessibility Guidelines (WCAG), and share a basic checklist that all developers can use when building their websites and applications.

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” – Tim Berners-Lee, W3C Director and inventor of the World Wide Web.

Image credit: Interactive Schools

What is Web Accessibility?

A person is said to be disabled when they’re faced with a condition – permanent or temporary – that makes it difficult or impossible for them to achieve a desired task.

In effect, web accessibility involves removing all barriers that prevent any users from accessing the web equally.

What are the Barriers to Accessibility?

The barriers to accessibility include visual, auditory, cognitive and motor.

Visual barriers constitute conditions which make it difficult for people to view images, videos, and gifs. These conditions can include low vision, colour blindness, or even total vision loss.

Auditory barriers constitute conditions which make it difficult or impossible for people to consume audio content.

Those who have difficulty concentrating, learning or remembering new things are faced with cognitive barriers.

And people who have partial or total loss of function in a body part and find it difficult to navigate websites using devices such as a mouse experience motor barriers.

To resolve these barriers of web or digital accessibility, the Web Accessibility Initiative (WAI) of World Wide Consortium (W3C) created the Web Content Accessibility Guidelines (WCAG).

What are Web Content Accessibility Guidelines?

They are globally accepted standards that guide developers and organisations in building an accessible web.

Image credit: Site Improve

Most of the barriers to web accessibility faced by people with disabilities can be put into four categories. The WCAG addresses each category to ensure accessibility is achieved.

Perceivable: It requires that users can identify content and interface elements using their senses. Most users rely primarily on visual senses, while others rely on sound.

Operable: It requires that users can use controls, buttons, navigation, and other interactive elements by themselves. It takes into consideration that disabled users will use assistive technology like voice recognition, keyboards, screen readers, and so on.

Understandable: It requires that users can comprehend the content and learn and remember how to use your site. The site should have a consistent format, predictable design and usage patterns, as well as an appropriate tone.

Robust: It requires that users of varying abilities and conditions can reliably interpret and interact with content using a technology or device of their choice.

Web Accessibility Checklist

As developers, these are a few of the things to look out for when building websites or application in order to ensure that people of varying abilities can access them equally.

How to make images accessible

All images should have descriptive sentence-like alt texts instead of just a word or clause. For example, the image below should have an alt text as shown in the code beneath it.

_Photo by [Unsplash](https://unsplash.com/@hybridstorytellers?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Hybrid Storytellers on <a href="https://unsplash.com/t/food-drink?utm_source=unsplash&utm_medium=referral&utmcontent=creditCopyText)

<img alt="a right hand removing a slice from a whole pizza" src="https://unsplash.com/photos/XYyUxXw_oQw"/>

The code above shows a sentence-like, descriptive alternative text for the image. The goal of the alt text should be to describe the image in such a way that people using screen readers feel like they can visualize or imagine exactly what image is being described.

Image Alt text output

The next level of accessibility as seen in the above image, is to write alt texts so that users who may be encountering connectivity issues have an idea of the image before they see it.

How to make links accessible

Links should be descriptive and suggestive, and you should label all links with exactly what they do.

Avoid embedding your links in vague texts such as ‘here’. For instance, if we wanted to refer to my most recent article, for the sake of users who rely on screen readers, this is how to do it.

<p>
Check out my most recent article on <a href="https://www.freecodecamp.org/news/web-layouts-use-css-grid-and-flex-to-create-responsive-webpages/">Web Layouts – How to Use CSS Grid and Flex to Create a Responsive Web Page</a>
</p>

In the code above, the link tag is wrapped around the whole title of the article instead of simply making the link text a vague 'here'. This way, everyone who sees, reads, or hears it knows exactly what resource will be found when the link is clicked.

Link output image

When screen readers get to a link that is as descriptive as what we have in the image above, it makes it very easy for visually impaired users to know what the link does and, in effect, decide whether or not to visit it.

How to make forms accessible

When creating web forms, you should consider users with visual or motor limitations. Make it easy for users who can't use the mouse to navigate your form with the keyboard and users relying on screen readers to know the exact information needed for each input.

Ensure that your forms are accessible by using <label> or aria-label to communicate the purpose of an input or what information it requires to screen readers.

<fieldset> tags tell the form that groups of inputs belong together and <legend> tags act as labels for groups of inputs. These become especially necessary when dealing with questions that involve checkboxes or radio buttons.

<fieldset class="first-section">
      <legend>Contact Details</legend>
      <label for="name">Name</label>
      <input type="text" id="name" name="name" autofocus placeholder="Ophy Boamah" autocomplete="on" required> <br><br>
      <label for="email">Email</label>
      <input type="email" id="email" placeholder="ob2@hotmail.com"> <br><br>
      <label for="tel">Phone</label>
      <input type="tel" id="tel" placeholder="+233 200001212"> <br><br>
</fieldset>

In the code above, I implement all the form best practices I mentioned. The fieldset tag creates an initial "first-section" group. The legend tag contains text that provides a description for the group of elements. Finally, the label tag identifies each of the inputs and their purpose.

Accessible form output

The image above is the output of the code. To learn more about creating modern and accessible forms, check out my previous article on How To Create and Validate Modern Web Forms With HTML5.

Video and audio accessibility

All videos should have subtitles and captions. Similarly, all audio should have transcripts, so that people with hearing challenges can still follow along and understand.

 <video id="video" controls preload="metadata">
     <source src="assets/samplevideo.mp4" type="video/mp4" />
     <track
     label="English"
     kind="subtitles"
     srclang="en"
     src="assets/samplevideo-en.srt"
     default />
 </video>

The code above shows a video element that introduces the track tag for adding subtitles so that users who are not able to hear the accompanying audio can read to follow along.

How to select colours for accessibility

When selecting colours for your websites, consider people who are colour-blind and those who have issues with sight.

When we use colours with poor contrast, it makes it difficult for users to read or navigate content on a web page. This means that we must always ensure that even in bad lighting conditions, our foreground and background colours have enough contrast between them for button, links, images, icons, texts and so on.

If you're unsure whether two colours complement each other in an accessible way, check using this online colour checker tool.

Use a color checker tool to check color contrast

You can also add this Web Accessibility Checker Chrome Extension to your browser for onsite accessibility checks.

How to make transitions and animations accessible

Use transitions and animations sparingly and only when extremely necessary in order not to trigger some users.

There are those who get dizzy or experience seizures when they encounter elements that move rapidly. Provide a way for such users to pause, hide, or stop the animation by making those controls available.

How to create accessible page structure and navigation

Use the appropriate HTML tags to semantically structure websites. Your site should be easy to navigate especially with assistive technology.

Page titles should be descriptive so users can easily differentiate between tabs.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta http-equiv="X-UA-Compatible" content="IE=edge" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Web Accessibility Site | Checklist for Developers</title>
</head>
<body>
  <header>
  <nav>
    <ul>
      <li>Home</li>
      <li>About</li>
      <li>Contact</li>
    </ul>
  </nav>
  </header>
  <main>
    <section>
      <div>
        <h1>
          Welcome to Web Accessibility
        </h1>
        <p>
          This is semantic structuring with HTML tag
        </p>
      </div>
    </section>
  </main>
  <footer>
    <a href="https://codehemaa.com">My website</a>
  </footer>
</body>
</html>

The code above shows a web page with a descriptive title. I've used the right semantic tags to properly structure the page by distinguishing the header from the main body and footer.

I've also properly labelled sections, divs, and headings. This helps screen recorders to properly spell out exactly what element and content is present on the page.

Conclusion

If the inventor of the web stated emphatically “access by everyone regardless of disability is an essential aspect” of the web, then as developers we must strive to achieve just that. Plus, it's just the right thing to do.

You should consider accessibility even before you start to build your sites – not done after as damage control. Going forward, we ought to strive for inclusion by contributing to build a more a11y-conscious and a11y-friendly web.

Thanks for reading 👋🏾. I hope you found it helpful.

During the website development process, you want to make sure that the end user has the best user experience. And that includes people with disabilities or those who faces challenges when using a website.

Unfortunately, there are still websites that don't use accessibility best practices. But you can make sure yours does.

If you keep a few things in mind during the web development process, you can improve the user experience for all users, including differently abled users.
Below are some helpful tips you can use to improve website accessibility.

Add Alt Text to Images

You might have heard about the importance of adding alt text on image tags in HTML5. So how do you use them? Do you provide alt text for every image on your webpage?

Image alt text makes it easier for people with visionary disabilities to understand the content of a webpage. But you should include the alt text only for informational images that aid in the understanding of the content.

Decorative images should have empty alt text. This tells screen readers that the information provided by the image is not important and might in fact detract from the user experience.

Informational images are images that convey important information related to the content. You should be able to describe what they show in a few words of alt text.

Let's suppose we run a fitness blog and are working on creating an article about how to do a workout at home and we use the following image in our article.

_Photo by [Unsplash](https://unsplash.com/ja/@jonathanborba?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Jonathan Borba on <a href="https://unsplash.com/s/photos/workout?utm_source=unsplash&utm_medium=referral&utmcontent=creditCopyText)

This image is supposed to convey a message to the blog readers on things you need for a crunch exercise. The alt text for this image could be something like this:

<img src="crunch_exercise.png" alt="You must have a good quality exercise mat and workout clothing to avoid back injuries and skin allergies">

The alt text we provided for our image clearly tells visually impaired users the message our image conveys.

Decorative images, on the other hand, serve the sole purpose of decoration on the webpage – maybe they just break up the content or complement general descriptions in the text.

Images used as icons are a great example of decorative images. The Airbnb homepage has a navigation bar with multiple icons (like the one in the red circle) indicating different types of living spaces available at Airbnb. The icons used in the navigation bar are for decoration purposes and we can leave their alt text empty.

Airbnb homepage

<!-- Example of decorative image -->
<img src="decorative_img.png" alt="">

Maintain Heading Hierarchy

If you don't use headings in the correct hierarchy (from

– the biggest – to

– the smallest), screen readers might assume there's some content missing.

Because of this, it is best to use

for the main title only,

for headings that come after the title, h3 for subheadings, and so on.

Consider the example below: we have a webpage with a few headings.

is used for the document title,

for the second level document heading,

for subheadings and

for mini headlines (headings that come after

).

Heading hierarchy example

Below is the code for this web page. Notice the different heading tags in it:

<h1>Facts about dogs</h1>
<img src="dog.png" alt="a cute dog resting under the sun">
<h2>What makes a dog the best pet?</h2>
<p>Dogs are everyone's favorite and there are numerous science backed reasons behind it mentioned below</p>
<h3>Dogs can sense a lie</h3>
<p>Yup! You read it right! Dogs are smart enough to tell when a praise is sincere. They have a pretty sharp mind.</p>
<h3>Dogs have a great sense of smell</h3>
<p>Dogs have a sense of small that's 40x better than ours and this quality plays an important role in building a stronger bond between a human and a dog. The reasons to it are given below</p>
<h4>1. They can smell a stanger sneaking into your garage</h4>
<p>Dogs can spot a stranger because of their strong sense of smell and save you from theft.</p>
<h4>2. They can tell you whenever you forget to put meat in the fridge after a  grocery run</h4>
<p>Dogs might make you give them a half of the meat you bought from the supermarket but they can also help you save the remaining half. Thanks to their sense of smell!</p>

Use the Aria Property or Label Tag for Input Fields

Aria labels or tags tell screen readers what type of information an input field expects. Without them, screen readers would not know the purpose of an input field, which would provide a bad user experience to visually disabled users.

<!-- Aria label example -->
<input type="text" placeholder="Enter your name" aria-label="Enter your name">

<!-- Label tag example -->
<label>Full Name: <input type="text" placeholder="Enter your name"></label>

Example one uses the aria property for screen readers to read what the user is expected to enter in the name input field.

Example two uses the tag with text Full Name which is readable by screen readers.

Provide Keyword Functionality

Not all users can use a pointing device (mouse) yet a lot of websites do not provide keyboard functionality to users. This discourages users who only use the keyboard from returning to your website.

One simple example of this is adding a click event listener to the submit button of a form instead of making use of the onsubmit event (which requires a user to click to submit a form). Have a look at the example below:

<!-- Example one -->
<form>
    <label>Full name: <input type="text" value=""></label>
    <label>Email: <input type="email" value=""></label>
    <button onclick="handleSubmit>Submit</button>
</form>

<!-- Example two -->
<form>
    <label>Full name: <input type="text" value=""></label>
    <label>Email: <input type="email" value=""></label>
    <button>Submit</button>
</form>

Example one uses a click event listener on the submit button. This means that pressing the enter key on a keyboard would not submit the form.

Example two uses the onsubmit event and assigns a JavaScript function to that event. This way a click or an enter button both run the handleSubmit function.

Use an Accessible Color Palette

Bad color contrasts ruin the overall experience for people without disabilities as well as for those with disabilities. So it's important to get the contrast and complementary colors correct when designing your site.

There are tools like contrast checker that help you understand whether your colors contrast enough to be properly visible. Accessible color contrast helps disabled people distinguish between elements on a web page. See below the examples of good and bad color combinations.

Example of good and bad color combination

The first box has a dark blue background which makes the white easier to read. On the other hand, the second box has a green background with pink text that is not easy to read and causes eye strain.

Provide Alternatives for Audio and Video Content

Users who cannot hear or see well might find it difficult to access the audio and video content of a website.

To offer them a better experience, provide transcripts for any audio you use, and add easy-to-read captions on your video content.

Make Sure the Content is Easy to Understand

Easy to understand content is free of unexplained jargon and technical phrases.

Suppose you run an analytics firm and are an expert in the field of data science. But your users might include current or potential clients and job seekers. These people might not have enough technical knowledge to understand content stuffed with jargon.

We are a team of analytics experts who are masters at aggregating data from all the available warehouses, detecting anomalies, performing batch processing on high volumes of data, and applying robust algorithms to solve your business needs.

The above text is full of analytics jargon that not everyone can understand. This makes you lose your visitors – as why would they invest in you if they can't understand what you do?

Check out the below simplified version of the same text that uses more approachable terms everyone can understand:

We are a team of experts who specialize in collecting data from all the available sources, identifying errors in that data, handling high volumes of data in less time with greater accuracy, and making predictions to solve your business needs.

Make sure that your content delivers its purpose in language that everyone can easily understand.

Conclusion

Accessible websites are crucial for a good user experience. An accessible website can not only grab new users but it can also encourage old users return over and over again.

There is a lot more you can do when it comes to website accessibility. But with these tips and tricks, you can improve your site or app's UX significantly.

I hope these tips help you offer a better user experience in your upcoming projects.

Develop accessible websites and make the internet a better place for everyone!

Interested in connecting on LinkedIn? Hit me up at Tooba Jamal

This isn't always easy, as the range of user accessibility needs can complicate things even further.

Thankfully, various guidelines exist for designing and building more accessible websites and web applications. This article will look at the seemingly mundane, lesser-known, and often overlooked web accessibility feature: the "skip to main content" link.

Because they are invisible by default, many users navigating a website using the usual point-and-click method won't even notice skip-to-main-content links. But these links are critical, as they make navigating complex and large websites simpler for keyboard-only and some screen reader users.

In the section below, we shall have a detailed look at "skip to main content" links and why you should consider implementing them in your website or web application.

What are "Skip to Main Content" Links?

Most websites usually come with navigation menus to make navigation easier. But although they make your website or web application navigable for the point-and-click users, navigation menus can also cause a poor user experience for keyboard-only and some screen reader users.

It is not uncommon for a typical website to have a navigation menu with up to ten menu items at the top of each web page. So a keyboard-only user will needlessly tab through all the navigation links before accessing the main content on pages they visit.

Some screen reader users may undergo a similar experience by traversing all the menu items before reaching the main content.

This creates a negative experience for your users. Adding skip-to-content links can make navigating such complex sites easier and less laborious for keyboard-only and some screen reader users.

A "skip to content" link is an ordinary link, usually before the main navigation menu at the top, linking to the main content on the web page. Since a point-and-click user doesn't need it, a "skip to main content link" is usually hidden and made visible when it is in focus.

It helps keyboard-only and screen reader users skip to the main content instead of traversing all the menu items. And this greatly improves their browsing experience.

The image below shows the skip-to-main-content link for the a11y project. As mentioned above, the skip-to-main-content link is visible only after being focused on.

To test it, navigate to a11yproject.com and hit the Tab key. The skip-to-main-content link immediately becomes visible. After that, you can hit the Enter key to skip the navigation menu.

Skip to main content link on a11y project website

In the next section, we shall implement a simple skip-to-main-content link.

How to Add a Skip to Main Content Link to Your Site

Now that we know what "skip to main content" links are, let's look at how to implement them and some best practices when using them.

As already mentioned in the introduction, skip-to-main-content links are ordinary links.

But again, they are usually not visible to an ordinary point-and-click user. You can change the visibility of the skip-to-main-content link for the keyboard user when it is in focus.

The code below shows the markup for a typical navigation menu. A real-world application may be more complex with nested menu items in addition to the top-level menu items. But I have kept it simple in the example below.

  <body>
    <a href="#main" class="skip-to-main-content-link">Skip to main content</a>
    <nav>
      <ul>
        <li>
          <a href="/">Home</a>
        </li>
        <li>
          <a href="/about.html">About</a>
        </li>
        <li>
          <a href="/blog.html">Blog</a>
        </li>
        <li>
          <a href="/contact.html">Contact</a>
        </li>
        <li>
          <a href="/portfolio.html">Portfolio</a>
        </li>
      </ul>
    </nav>
    <main id="main">
      <h1>Your sweet heading</h1>

      <!-- Page content goes here! -->
    </main>
  </body>

The first element of the <body> tag in the above example is the skip-to-main-content link. Its href attribute points to the main element via its id attribute. Clicking or pressing the Enter key when the skip-to-main-content link is in focus will scroll the main content into view in the viewport.

As pointed out in the previous section, the skip-to-main-content link is primarily for keyboard-only and some screen reader users. So we need to apply some styling to hide it from view when out of focus and display it when it receives focus.

So we select it using the given class and apply the styling below. You can hide and display the skip link with different styling. It doesn't have to be the same code as below.

.skip-to-main-content-link {
  position: absolute;
  left: -9999px;
  z-index: 999;
  padding: 1em;
  background-color: black;
  color: white;
  opacity: 0;
}
.skip-to-main-content-link:focus {
  left: 50%;
  transform: translateX(-50%);
  opacity: 1;
}

You can also apply transition animation to your skip-to-main-content link, though I haven't included it in the example above.

Good Practices When Adding a Skip to Main Content Link

Though skip-to-main-content links are easy to implement, there are some potential problems that can easily slip by you.

Follow what I consider good practices below when implementing skip-to-main-content links. I have picked them up from the WCAG techniques.

• If the skip to main content link is for skipping the main navigation menu at the top of a web page, it should be the first focusable element on the web page.

• The text of the skip link should describe the intent. The text "Skip to main content" will usually suffice.

• It is a requirement that the skip-to-content link is either always visible or visible when in focus. Since our skip-to-content link is for keyboard-only and some screen reader users, you can hide it and make it visible as we did in the example above.

• The focus should shift to the main content after activating the skip link.

It is worth pointing out that using skip links is not only limited to navigation menus. You can also implement links to help users skip focusable elements that are difficult or laborious to navigate with the keyboard.

Conclusion

A navigation menu is a handy feature for navigating to different sections or pages of a website. And although it's meant to provide a better user experience, a navigation menu can become an accessibility obstacle for some users who only use the keyboard or who use a screen reader.

This is why it's a good idea to add skip-to-main-content links on each page. When users need to traverse the navigation menu items, they can use that link to bypass the navigation menu.

The skip-to-main-content link is an ordinary link that's invisible to the point-and-click user. It is visible to screen reader users and when in focus. Clicking it will shift focus to the main content on the web page.

Hopefully, this article has given you insights on skip-to-main-content links and how to implement them in your website or web application.

Accessibility is a journey. Every step you take in the right direction makes your site or web application more accessible. Implementing skip-to-main-content links is one such step. Take that step and make the web more accessible if you haven't. By doing so, you are enriching the digital experience for your clients.

When we evaluate whether or not website is accessible, we look to see if software meets WCAG 2 standards.

Accessibility should not be an after thought, but rather a major part of the development process. Still, sadly these days there are many websites with accessibility errors.

WCAG's audit shows that many accessibility errors fall into just six areas/categories.

96.7% of all errors detected fall into these six categories. Addressing just these few types of issues would significantly improve accessibility across the web. – WebAIM

If we tackle these six problems, we can make sure more websites are accessible for people who use various of assistive technologies.

Let's look at each of these common accessibility problems in more detail.

Update Low Contrast Text

In the code example above, we can see an example of one background/foreground color combo that meets WCAG standards and one that doesn't.

The low color contrast is the one with blue background and gray text. It's really hard to differentiate the background and foreground colors visually and the color combination does not meet WCAG standards. The foreground text blends into the background.

In the second example, the foreground is whitish color and it's easy to read the text. This color combination meets WCAG standard, and the text stands out on its own and is easy to read.

If the text color is hard to differentiate from the background it's in, we have a low contrast accessibility error. Over the last three years, by far the biggest accessibility error is low contrast text. More than 80% of websites have this accessibility error.

You can fix low contrast accessibility errors by simply auditing your website and changing the color of the text or the background. You can run a lighthouse test to see if color contrast is an issue on your website.

You can also check if the background/foreground color combo meets WCAG standards in the following link: https://webaim.org/resources/contrastchecker/.

Add Missing Alternative Text for Images

In 2021, it was reported that 60.6% of all home page images were missing alternative text.

It's important to add alternative text to images because you need to describe the content of the page to those who cannot see the content. Visually impaired users will use a screen reader, which will read the content of the page back to them.

For example, if we have an image of a basket of Belgium fries, we can add an alternative tag to that image with a simple alt attribute:

<img src="example.png" alt="basket of fries"/>

With one attribute, alt, we are able to make the image accessible for screen reader users. When a screen reader user tabs over to the image, it will indicate to them that they are focused on an image and that image is a "basket of fries".

If we didn't have an alt attribute, then the screen reader user wouldn't have known that the image they were focusing on was a basket of fries.

It's also important to note that an alt attribute is not enough for 100% accessible images. We also need to make sure that the alt tag is descriptive and lets the user know what the image looks like.

A bad example of an alt tag would be if it's not descriptive enough. Say we have the same image of the basket of fries and we add alt tag to the image like so:

<img src="example.png" alt="image"/>

In the example above, we would meet accessibility standards by adding the alt tag, but the alt tag is not helpful or descriptive enough for screen reader users. When a screen reader user focuses on this image, it will say, "image, image", which doesn't let the user know what this image is at all.

It's very important to add descriptive alternative tag to images on the page.

Add Missing Form Input Labels

About half of the websites were missing form input labels in 2021. A form label is an HTML element used in forms to describe what the the various fields in the form are for.

If you have any type of form on the page, whether it's checkbox, radio button or dropdown, you must have a <label> associated with this form.

A common error for missing form input is for search forms. Often search forms on a page usually have only a magnifying glass image to indicate to visual users that they can search with that form, but no label to indicate search. But if we don't add a label to this form, screen reader users will not know what the form is when they focus on it.

We can fix this accessibility error by adding a screen reader label.

HTML example:

<label for="searchLabel" class="sr-only">Search</label>
<input type="text" name="search" id="searchLabel>
<input type="submit" value="Search">

CSS example:

.sr-only{
   position:absolute;
   left:-10000px;
   top:auto;
   width:1px;
   height:1px;
   overflow:hidden;
}

In the example above, we added a label "Search" to the form with the help of CSS. When a user focuses on this particular form, the screen reader will read, "Search", to them. The class sr-only in this form will only make this element readable when on a screen reader.

Fix Empty Links

Links are used to navigate the user to a new page or view. A link is focusable by keyboard and can be triggered by the enter key.

Similar to the missing form label error, another accessibility error is empty links. About half of the websites had empty links in 2021.

For example, if we use the Facebook logo to indicate to sighted users that the link is to go to Facebook, but we don't add any label for screen reader users, then we will get an empty link accessibility error.

If we don't add text for screen readers, then screen reader users will not know that they are focused on a Facebook logo.

A good example of adding a label to a link is below:

<a href="/facebook-page">
   <i aria-hidden="true"></i>
   <span class="sr-only">Facebook</span>
</a>

CSS correspondent:

.sr-only{
   position:absolute;
   left:-10000px;
   top:auto;
   width:1px;
   height:1px;
   overflow:hidden;
}

In the example above, we used a Facebook logo to indicate that this is a Facebook link. We also added "Facebook" text that will be read when users focus on it using a screen reader.

Add Missing Document Language

For the last three years, between 28% to 33% of homepages have been missing a document language on their page. This is one of the less common accessibility problems but it is still an accessibility error we should pay attention to and fix.

We can add the language to the HTML tag like so:

<html lang="en">
...
</html>

The example above indicates that the page is in English. We can use other codes to indicate other languages.

It's important to indicate the language of the page because screen readers use the document language to know how to pronounce the words. Document language is also good for SEO.

Fix Empty Buttons

Buttons are used to do things on a page, for example submitting a form or show/hide things. A button is focusable and can be triggered by the space key.

Similar to empty links, we need to make sure that buttons have text for screen readers to read when on focus.

The solution for fixing empty buttons is similar to fixing empty links, which is to make sure text label is present on buttons.

If an image is used inside button, we can add an alt tag to the image. This will ensure that when a user uses a screen reader, the image alt tag is read. Here's an example of how to do this below:

<button type="submit">
   <img src="/search.svg" alt="Search"/>
</button>

Similarly to an image, if you use an SVG inside a button, you can add a title inside the SVG. Here's an example of how to do this below:

<button type="submit">
   <svg id="search" role="img" aria-describedby="search" viewBox="0 0 16 16.9">
      <title id="search">Search</title>
      <path d="M14, 2L8690, 89.1,13,6.5G87"></path>
   </svg>
</button>

We need to make sure that buttons are not empty and that screen readers read what the button is to the user.

Conclusion

Accessibility should never be an afterthought, but rather a large part of the development process. Most accessibility errors come from six categories and if we fix them, we will make our websites more accessible to everyone.

Accessibility fixes should not be difficult and should only require basic HTML and CSS knowledge.

If we pay more attention to accessibility, we will open our websites to a wider audience and also make sure our code is good and meets standards. Accessibility not only helps everyone use websites but also improves the foundation of our code.