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.

One hidden hurdle for some users is motion sensitivity. It might not be something we think about every day, but it can have a big impact on how people experience the internet.

In this article, I want to shine a light on motion sensitivity. We'll explore what it's like, the conditions it's linked to, and how it can affect someone's ability to enjoy using a website.

My goals for this article are:

1. To get you thinking about creating web experiences that are comfortable and welcoming for everyone.
2. To equip you with practical tips to make that happen. Because an inclusive web is a better web for everyone.

What is Motion Sensitivity?

Motion sensitivity isn't just a technical term – it refers to how we experience the digital world, especially for those whose sensitivities go beyond what meets the eye. So, let's unravel this concept and see why it matters.

According to National Library of Medicine, motion sensitivity refers to a condition where a person experiences symptoms such as dizziness, nausea, and imbalance in response to motion. This can be caused by a variety of factors, including inner ear problems, neurological disorders, and certain medications.

People with motion sensitivity may have difficulty tolerating activities that involve moving, such as riding in cars and even certain motion animations.

Maybe you've taken a long road trip and experienced motion sickness. Or you've visited the cinema to see a 3D movie and, instead of enjoying the experience, you end up with headaches, migraine, dizziness, or nausea. Then you understand how serious motion sensitivity can be.

How Motion Sensitivity Impacts People

For some people, motion effects like parallax scrolling can be annoying, but the effects of motion sensitivity go beyond a mere inconvenience. It can disrupt the digital experience and, more importantly, affect the well-being of those navigating the space.

Some people might feel dizzy, nauseous, or experience headaches or migraines when faced with certain animations or transitions. For them, accessing digital content becomes more than just a click – it's a consideration of their comfort and health.

Insights into Related Disorders

To truly understand motion sensitivity, I believe we need to explore the conditions linked to it, mainly vestibular disorders and visual motion sensitivity.

Vestibular Disorders impact the inner ear and how the brain processes spatial information. For someone with vestibular disorders, simple tasks like maintaining balance or handling motion stimuli can become challenging.

Visual Motion Sensitivity is about heightened sensitivity to visual stimuli, leading to discomfort or adverse reactions to certain types of motion. For someone with visual motion sensitivity, navigating websites with specific animations or scrolling behaviors can be a struggle.

By diving into these facets of motion sensitivity, we lay the groundwork for creating digital spaces that acknowledge and respect diverse user experiences.

So, Why Does this Matter?

Well, I think it is as simple as this: everyone deserves to enjoy the digital world without feeling unwell. Understanding motion sensitivity helps us create websites, games, and apps that are more inclusive and comfortable for everyone, not just folks with superhero vision.

Let's explore why designing with motion sensitivity in mind is not just a best practice but a step towards a more inclusive online world.

How Common is Motion Sensitivity?

Motion sensitivity is more common than you might think. According to this article from Archives of Physiotherapy, it has been reported that 28.4% of the population experience motion sensitivity. Also, according to this article:

Nearly all people are affected with sufficient motion and most people will experience motion sickness at least once in their lifetime. Susceptibility, however, is variable, with about one-third of the population being highly susceptible while most other people are affected under extreme conditions. Women are more easily affected than men.

These statistics underscore the need for web designers and developers to consider motion sensitivity in our creations. They highlight that what might be a visually engaging animation for one user could be an obstacle for another.

How to Identify Motion-Sensitive Triggers in Animations

Animation can enhance engagement and help guide users through the app. But it is vital that we scrutinize the types of animations we incorporate into our designs, particularly when aiming for motion-friendly experiences.

Let's explore these potential triggers and discuss alternatives to ensure a more inclusive design.

Rapid or Flickering Animations

• Trigger Potential: Quick, flickering animations can be disorienting for users with motion sensitivity, leading to discomfort or headaches. Examples of these types of animations include rapidly blinking notifications, flickering banners, or flashing call-to-action buttons.
• Alternative Approach: Opt for smoother transitions like subtle fades or slides, avoiding rapid flickering effects for a more comfortable experience.

Overly Complex Transitions

• Trigger Potential: Elaborate loading animations with intricate patterns, complex slide-in effects, or overly detailed transitions between pages may overwhelm users, causing sensory overload for those with motion sensitivity.
• Alternative Approach: Simplify transitions, focus on clarity and purpose. Strive for elegance in design without unnecessary visual complexity.

Bouncing or Elastic Motions

• Trigger Potential: Animations with bouncing or elastic movements can induce dizziness or nausea in motion-sensitive users. Examples include buttons that bounce upon interaction or elastic-scrolling effects.
• Alternative Approach: Choose more subtle easing functions for animations, providing a smoother and less physically demanding experience.

High-Speed Animations

• Trigger Potential: High-speed carousels, rapid image sliders, or quick-scrolling features may challenge users with motion sensitivity, potentially leading to feelings of discomfort or disorientation.
• Alternative Approach: Allow users to control animation speeds or default to slower, more deliberate transitions for a universally comfortable pace.

Continuous Auto-Scrolling

• Trigger Potential: Auto-scrolling features that move content continuously without user interaction, like automatic slideshows or news tickers, can be unsettling for users with motion sensitivity.
• Alternative Approach: Implement user-initiated scrolling, providing control to the user and avoiding unexpected motion.

Flashing or Intense Color Changes

• Trigger Potential: Flashing animations or sudden, intense color changes can be visually overwhelming and trigger discomfort. Examples include flashing banners, intense color changes on hover, or rapidly changing background colors.
• Alternative Approach: Maintain a consistent color palette and avoid rapid, drastic color shifts. Consider softer transitions for color changes.

Rotational Movements

• Trigger Potential: Rotational animations, such as spinning logos or rotating carousels, may cause dizziness or vertigo for individuals with vestibular disorders or motion sensitivity.
• Alternative Approach: Minimize or eliminate rotational motions, especially in situations where they may not be essential for understanding the content.

By recognizing these potential triggers and adopting alternative approaches, we can create digital experiences that are more considerate and welcoming for users with motion sensitivity.

The goal is not to stop adding animations but to design with empathy, ensuring that motion enhances rather than detracts from the user experience.

How to Use Reduce-Motion Preferences

One significant stride towards motion-friendly web design is utilizing the reduce-motion preferences embedded in operating systems and browsers. This preference provide users with the option to minimize or eliminate unnecessary animations.

By recognizing and respecting these user preferences, we can significantly enhance the accessibility of web applications.

Incorporate Reduced Motion Features

For developers, integrating reduced motion features into web applications involves a combination of coding practices and user interface considerations.

Begin by identifying areas where animations can be toned down or replaced with static alternatives. Implementing conditional checks for reduce-motion preferences in your codebase allows your web application to adapt dynamically, providing a smoother experience for users who opt for reduced motion.

CSS prefers-reduced-motion Media Feature

.animated-element {
  animation: pulse 1s linear infinite both;
}

/* Tone down the animation */
@media (prefers-reduced-motion) {
  .animated-element {
    animation: smooth 4s linear infinite both;
  }
}

JavaScript Reduced Motion Detection

// Check if the user prefers reduced motion using JavaScript

const prefersReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;

// Example of adjusting animation based on reduced motion preference

const animatedElement = document.querySelector('.animated-element');
if (prefersReducedMotion) {
  animatedElement.style.animation = 'smooth 4s linear infinite both';
} else {
  animatedElement.style.animation = 'pulse 1s linear infinite both';
}

Test Your Animation on Chrome

While basic accessibility checks are readily available, Chrome DevTools offers advanced capabilities through its hidden Rendering tool.

One of the options available in the rendering tool is the option to test your animation for when a user enables prefers-reduced-motion. Here's how to leverage it:

• Click the customize (three dots) icon in the DevTools panel
• Select more tools
• Select Rendering option from the list of options

Select Rendering under more tools

• Once enabled, the Rendering tab appears in DevTools.
• Look for the option named "Emulate CSS media feature prefers-reduced-motion."
• Enable this option to preview how your website's animations appear for users who have set their device or browser to reduce motion.

When a user has prefers-reduced-motion enabled, avoid completely removing animations. Aim to provide users with a smoother experience rather than completely excluding them from the interactive experience.

Motion Sensitivity Tips and Best Practices

Let's explore tips and best practices to incorporate into our designs:

1. Subtle Animations: Opt for subtle animations that convey information without being overwhelming. Gentle fades, transitions, and loading effects can enhance the user experience without causing discomfort.
2. Adjustable Speeds: Provide users with the ability to control animation speeds. Implement settings within your application that allow users to customize the speed of transitions, ensuring a comfortable experience for everyone.
3. Clear Navigation Signals: Use motion to guide users intuitively. For instance, employ subtle animations to indicate a change in state or to draw attention to important elements, ensuring that users with motion sensitivity can follow the flow without feeling disoriented.
4. User Testing: Conduct thorough user testing, specifically with individuals who experience motion sensitivity. Gather feedback to refine your design, ensuring that it meets the needs of the diverse user base.
5. Document and Communicate: Clearly document your approach to motion-friendly design in your project documentation. This not only serves as a reference for your team but also communicates your commitment to accessibility to stakeholders and users.

Conclusion

Motion sensitivity isn't a rare exception – it's a shared experience for many people. Our responsibility as web developers is not merely to acknowledge this reality but to actively integrate inclusivity into the DNA of our creations.

By identifying potential triggers and implementing reduced motion features using technologies like prefers-reduced-motion in CSS and JavaScript, we create spaces that accommodate diverse needs without compromising on engagement.

Accessibility is not a trend, it's a fundamental ethos that shapes the future of the internet into one where everyone regardless of their abilities can use the internet with comfort.

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

You can connect with me on LinkedIn or GitHub.

References

• Val Head. Designing Safer Web Animation For Motion Sensitivity (September 08, 2015) https://alistapart.com/article/designing-safer-web-animation-for-motion-sensitivity/
• Chaudhary, S., Saywell, N., Kumar, A., & Taylor, D. (2020). Visual Fixations and Motion Sensitivity: Protocol for an Exploratory Study. JMIR Research Protocols, 9(7). https://doi.org/10.2196/16805
• Albalwi, A.A., Johnson, E.G., Alharbi, A.A. et al. Effects of head motion on postural stability in healthy young adults with chronic motion sensitivity. Arch Physiother10, 6 (2020). https://doi.org/10.1186/s40945-020-00077-9
• Motion sickness. (2024, January 1). In Wikipedia. https://en.wikipedia.org/wiki/Motion_sickness

But when designing this new element, you might forget to consider the accessibility of the component.

Typically, default elements are accessible – and if you plan to replace them with custom designs, you should ensure it works as well as the default.

In this tutorial, I'll show you how to build a custom dropdown with a step by step example.

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.

Here's What We'll Cover:

1. Default Select Features
2. How to Figure Out Which ARIA Attributes Are Required
3. How to Set Up the HTML
4. The CSS
5. The JavaScript
   – Toggle dropdown visibility
   – How to close the dropdown
   – Dropdown keyboard interaction
   – How to fix the option visibility issue
   – How to highlight options on alphanumeric keypress
   – How to enhance screenreader functionality
6. Wrapping Up

Default Select Features

Since the default select attribute is accessible, let's look at some of the features that makes it accessible:

• The select element visibly indicates when it's active or selected, typically through a change in appearance.
• The element opens on click or key press (SPACE, UP, and DOWN Arrow)
• While the dropdown is open, users can move through the available options by pressing the UP or DOWN arrow keys.
• Entering alphanumeric keys when the dropdown is open highlights the option that matches the entered letters. If there's no match, nothing changes.
• Clicking on an option or pressing SPACE or ENTER when an option is highlighted selects that option, updates the select value, and closes the dropdown.
• If the dropdown is open, pressing the ESC key closes it, providing a quick way to cancel the selection or close the dropdown.
• When the select element is focused when using a screen reader, the screen reader announces that it's a select element and provides information about the currently selected value for accessibility.

Using this information, let's build a custom dropdown.

How to Figure Out Which ARIA Attributes Are Required

While some elements' roles and accessible names are obvious, there are some that aren't. Whenever I need to find the appropriate role or ARIA-attibute for a component, I check out the W3 accessible names guide.

In this case, I know the custom dropdown should have a role="options" but I don't know what role to assign the parent elements.

So to start, I locate the option Accessible Name Guidance by Role list. You can see that the Option is pointing to a combobox pattern.

The option in the table is showing a combobox.

The next thing I need to do is to read more on the combobox. According to this MDN page I understand that a combobox is a component that combines an input type element with a dropdown list and allows users to select from a list of options presented in the dropdown.

That sounds exactly like what the select element does. The combobox also needs to have an [aria-expanded](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-expanded) attribute and a connecting popup element which will contain the list of options. According to the MDN page:

The popup element associated with a combobox can be either a listbox, tree, grid, or dialog element.

In this example, we'll be using a listbox element.

The combobox element needs to have an aria-contols and aria-haspopup attributes, the value of these attributes will be the ID of the listbox element.

How to Set Up the HTML

From the information gathered we will need a combobox, listbox, and option to setup our HTML.

In this example, the HTML will look like this:

<form>
  <label for="select">Custom Select box</label>
  <button
     role="combobox"
     id="select"
     value="Select"
     aria-controls="listbox"
     aria-haspopup="listbox"
     tabindex="0"
     aria-expanded="false">
    Select</button>
  <ul role="listbox" id="listbox">
   <li role="option">Option 1</li>
   <li role="option">Option 2</li>
   <li role="option">Option 3</li>
  </ul>
</form>

In the code above, the button has a role="combobox" and according to the MDN combobox article the [aria-expanded](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-expanded) attribute is required when working with a combobox. The aria-controls points to the id of the listbox which is listbox. This associates the listbox with the combobox.

The CSS

You can style the dropdown anyhow you want based on your requirements. Here's a sample style for my component:

.form {
  margin: 1.2rem 0;
  position: relative;
  #announcement {
    opacity: 0;
  }
  label {
    display: block;
    padding: .7rem .8rem;
    width: 65%;
    margin: 0 auto;
    text-align: left;
    font-size: .75rem;
  }
  button,
  ul{
    display: block;
    padding: .7rem .8rem;
    width: 60%;
    margin: 0 auto;
    text-align: left;
    background: white;
    border: 0;
    font-size: 1rem;
  }
  button{
    display: flex;
    justify-content: space-between;
    align-items: center;
    position: relative;

    &::before {
      font-family: "Font Awesome 5 Free";
      content: "\f107";
      vertical-align: middle;
      font-weight: 900;
      position: absolute;
      right: .8rem;
    }

    &:focus-visible {
      outline: 0;
      box-shadow: 0 0 5px 2px rgba(251, 146, 60, 0.7) inset;
    }
  }
  ul {
    color: #3f403b;
    position: absolute;
    left: 0;
    right: 0;
    top: 4.8rem;
    max-height: 10rem;
    overflow-y: auto;
    list-style-type: none;
    padding: 0;
    margin-top: .1rem;
    opacity: 0;
    transform: scale(1,0);
    transform-origin: top left;
    transition: all .3s ease-in;
    pointer-events: none;
    z-index: 2;
    &.active {
      opacity: 1;
      transform: scale(1,1);
      pointer-events: auto;
    }
    li {
      padding: .6rem .5rem;
      border-top: 1px solid #e6e6e6;
      cursor: pointer;
      transition: all .3s ease-in;
      position: relative;
      &::before {
        font-family: "Font Awesome 5 Free";
        content: "\f00c";
        vertical-align: middle;
        font-weight: 900;
        position: absolute;
        right: .8rem;
        opacity: 0;
        transition: opacity .300s ease-out;
      }
      &:hover, &.current {
        background: #e6e6e6;
      }
      &.active {
        box-shadow: 0 0 0 2px rgba(251, 146, 60, 0.7);
      }
      &.active::before {
        opacity: 1;
      }
    }
  }
}

In the code above, I have hidden the listbox element and added an active class that shows it. I have also added a current class that styles the highlighted option and an active class that styles the selected option.

This is how it looks:

The current state and active state of an option

The Javascript

It's easier to break down the features and work on them one at a time, and that's what we'll do here.

Toggle Dropdown Visibility

Clicking the combobox or pressing the Space or Enter keys on the keyboard (when the button is focused) should toggle the dropdown visibility:

const elements = {
  button: document.querySelector('[role="combobox"]'),
  dropdown: document.querySelector('[role="listbox"]'),
}; // I like to group all my elements into one objects 🤓.
let isDropdownOpen = false;

const toggleDropdown = () => {
  elements.dropdown.classList.toggle('active');
  isDropdownOpen = !isDropdownOpen;
  elements.button.setAttribute('aria-expanded', isDropdownOpen.toString()); // update the aria-expanded state
};

const handleKeyPress = (event) => {
   event.preventDefault();
  const { key } = event;
  const openKeys = ['Enter', ' '];

  if (openKeys.includes(key)) {
    toggleDropdown();
  }
};

elements.button.addEventListener('keydown', handleKeyPress);
elements.button.addEventListener('click', toggleDropdown);

In the code above we've created a toggleable dropdown button that responds to both keyboard and mouse interactions. The toggleDropdown function adds an active class to the dropdown.

Closing the Dropdown: Using the Esc Key

Pressing the Esc key or clicking outside the dropdown element should close the dropdown:

// previous code

// update handleKeyPress function 
const handleKeyPress = (event) => {
    event.preventDefault();
  const { key } = event;
  const openKeys = ['Enter', ' '];

  if (!isDropdownOpen && openKeys.includes(key) || (isDropdownOpen && key === 'Escape')) {
    toggleDropdown();

  }
};

const handleDocumentInteraction = (event) => {
  const isClickInsideButton = elements.button.contains(event.target);
  const isClickInsideDropdown = elements.dropdown.contains(event.target);

  if (isClickInsideButton || (!isClickInsideDropdown && isDropdownOpen)){
    toggleDropdown();
  }
};


elements.button.addEventListener('keydown', handleKeyPress);
// elements.button.addEventListener('click', toggleDropdown);
document.addEventListener('click', handleDocumentInteraction);

While it might seem like the handleKeyPress and handleDocumentInteraction functions could be combined for simplicity, we'll keep them separate as these functions will handle more tasks later in the article.

In the code above we have updated the handleKeyPress function to check for Escape and also introduced a handleDocumentInteraction function to close the dropdown if there's a click outside the dropdown element.

Dropdown Keyboard Interaction

Pressing the UP or DOWN arrow keys should open the dropdown. When the dropdown is open, these keys should allow navigation through the options, moving the selection up or down. Also, clicking on an option or pressing the Space or Enter keys while an option is focused should update the button's displayed value. This behavior aims to replicate the interaction of a standard select element.

const elements = {
  button: document.querySelector('[role="combobox"]'),
  dropdown: document.querySelector('[role="listbox"]'),
  options: document.querySelectorAll('[role="option"]'), // add the options elements
};
let isDropdownOpen = false;
let currentOptionIndex = 0;

const toggleDropdown = () => {
  elements.dropdown.classList.toggle('active');
  isDropdownOpen = !isDropdownOpen;
  elements.button.setAttribute('aria-expanded', isDropdownOpen.toString());

  if (isDropdownOpen) {
    focusCurrentOption();
  } else {
    elements.button.focus(); // focus the button when the dropdown is closed just like the select element
  }
};

const focusCurrentOption = () => {
  const currentOption = elements.options[currentOptionIndex];

  currentOption.classList.add('current');
  currentOption.focus();

  elements.options.forEach((option, index) => {
    if (option !== currentOption) {
      option.classList.remove('current');
    }
  });
};

const handleKeyPress = (event) => {
  event.preventDefault();
  const { key } = event;
  const openKeys = ['ArrowDown', 'ArrowUp', 'Enter', ' '];

  if (!isDropdownOpen && openKeys.includes(key)) {
    toggleDropdown();

  } else if (isDropdownOpen) {
    switch (key) {
      case 'Escape':
        toggleDropdown();
        break;
      case 'ArrowDown':
        moveFocusDown();
        break;
      case 'ArrowUp':
        moveFocusUp();
        break;
      case 'Enter':
      case ' ':
        selectCurrentOption();
        break;
      default:
        break;
    }
  }
};

const handleDocumentInteraction = (event) => {
  const isClickInsideButton = elements.button.contains(event.target);
  const isClickInsideDropdown = elements.dropdown.contains(event.target);

  if (isClickInsideButton || (!isClickInsideDropdown && isDropdownOpen)) {
    toggleDropdown();
  }

  // Check if the click is on an option
  const clickedOption = event.target.closest('[role="option"]');
  if (clickedOption) {
    selectOptionByElement(clickedOption);
  }
};


const moveFocusDown = () => {
  if (currentOptionIndex < elements.options.length - 1) {
    currentOptionIndex++;
  } else {
    currentOptionIndex = 0;
  }
  focusCurrentOption();
};

const moveFocusUp = () => {
  if (currentOptionIndex > 0) {
    currentOptionIndex--;
  } else {
    currentOptionIndex = elements.options.length - 1;
  }
  focusCurrentOption();
};

const selectCurrentOption = () => {
  const selectedOption = elements.options[currentOptionIndex];
  selectOptionByElement(selectedOption);
};

const selectOptionByElement = (optionElement) => {
  const optionValue = optionElement.textContent;

  elements.button.textContent = optionValue;
  elements.options.forEach(option => {
    option.classList.remove('active');
    option.setAttribute('aria-selected', 'false');
  });

  optionElement.classList.add('active');
  optionElement.setAttribute('aria-selected', 'true');
};

elements.button.addEventListener('keydown', handleKeyPress);
document.addEventListener('click', handleDocumentInteraction);

In the updated code, we've added keyboard navigation and option selection. Here's the breakdown:

1. The elements object now includes a reference to the option elements with the role "option."
2. The dropdown can also be opened with keys like ArrowDown, ArrowUp, Space or Enter
3. When the dropdown is open, Escape closes the dropdown, ArrowDown moves focus down the options, ArrowUp moves it up, and Enter or Space selects the current option.
4. Clicking an option or using keyboard input selects the option.
5. The selected option is displayed in the button, and the aria-selected state of the option is updated.
6. active class is now added to the selected option

Fixing Option Visibility Issue

This looks good so far – but if you're following along and you test this code, you'll notice an issue: if an option is out of view and the down arrow is pressed the option isn't shown.

To fix this, you can use the scrollIntoView method to ensure that the current option is scrolled into view when it is focused. Add it to the focusCurrentOption like this:

const focusCurrentOption = () => {
  const currentOption = elements.options[currentOptionIndex];

  currentOption.classList.add('current');
  currentOption.focus();

  // Scroll the current option into view
  currentOption.scrollIntoView({
    block: 'nearest',
  });

  elements.options.forEach((option, index) => {
    if (option !== currentOption) {
      option.classList.remove('current');
    }
  });
};

// rest of code

Also when the user selects an option, the dropdown should close, the same way the select element works. Call the toggleDropdown function in the selectOptionByElement function like this:

const selectOptionByElement = (optionElement) => {
  const optionValue = optionElement.textContent;

  elements.button.textContent = optionValue;
  elements.options.forEach(option => {
    option.classList.remove('active');
    option.setAttribute('aria-selected', 'false');
  });

  optionElement.classList.add('active');
  optionElement.setAttribute('aria-selected', 'true');

  toggleDropdown(); // close the dropdown once an option is selected

};

Highlighting Options on Alphanumeric Key Press

Pressing an alphanumeric keys should highlight the option that starts with said character. And if the same character is pressed again then the next option should be highlighted and so on.

let lastTypedChar = '';
let lastMatchingIndex = 0;

// update the handleKeyPress function

const handleKeyPress = (event) => {
  event.preventDefault();
  const { key } = event;
  const openKeys = ['ArrowDown', 'ArrowUp', 'Enter', ' '];

  if (!isDropdownOpen && openKeys.includes(key)) {
    toggleDropdown();

  } else if (isDropdownOpen) {
    switch (key) {
      case 'Escape':
        toggleDropdown();
        break;
      case 'ArrowDown':
        moveFocusDown();
        break;
      case 'ArrowUp':
        moveFocusUp();
        break;
      case 'Enter':
      case ' ':
        selectCurrentOption();
        break;
      default:
        // Handle alphanumeric key presses for mini-search
        handleAlphanumericKeyPress(key);
        break;
    }
  }
};


// previous code

const handleAlphanumericKeyPress = (key) => {
  const typedChar = key.toLowerCase();

  if (lastTypedChar !== typedChar) {
    lastMatchingIndex = 0;
  }

  const matchingOptions = Array.from(elements.options).filter((option) =>
    option.textContent.toLowerCase().startsWith(typedChar)
  );

  if (matchingOptions.length) {
    if (lastMatchingIndex === matchingOptions.length) {
      lastMatchingIndex = 0;
    }
    let value = matchingOptions[lastMatchingIndex]
    const index = Array.from(elements.options).indexOf(value);
    currentOptionIndex = index;
    focusCurrentOption();
    lastMatchingIndex += 1;
  }
  lastTypedChar = typedChar;
};

// rest of the code

Running the code and testing it with both mouse and keyboard inputs should result in the expected behavior.

Enhancing Screen Reader Functionality

The last functionality I'm addressing in this article is the screen reader functionality.

For screen reader users, selecting an option should announce the selected option, Just like the default HTML select element. Update the HTML to have a div that will contain the content to be announced, like this:

<form>
  <label for="select">Custom Select box</label>
  <button
     role="combobox"
     id="select"
     value="Select"
     aria-controls="listbox"
     aria-haspopup="listbox"
     tabindex="0"
     aria-expanded="false">
    Select</button>
  <div id="announcement" aria-live="assertive" role="alert" style="opacity:0;"></div> <!-- The screen reader will announce the content in this element  -->
  <ul role="listbox" id="listbox">
   <li role="option">Option 1</li>
   <li role="option">Option 2</li>
   <li role="option">Option 3</li>
  </ul>
</form>

Then use JavaScript to update the value in the alert:

// previous code
const selectOptionByElement = (optionElement) => {
  const optionValue = optionElement.textContent;

  elements.button.textContent = optionValue;
  elements.options.forEach(option => {
    option.classList.remove('active');
    option.setAttribute('aria-selected', 'false');
  });

  optionElement.classList.add('active');
  optionElement.setAttribute('aria-selected', 'true');

  toggleDropdown();
  announceOption(optionValue); // Announce the selected option
};

const announceOption = (text) => {
  elements.announcement.textContent = text;
  elements.announcement.setAttribute('aria-live', 'assertive');
  setTimeout(() => {
    elements.announcement.textContent = '';
    elements.announcement.setAttribute('aria-live', 'off');
  }, 1000); // Announce and clear after 1 second (adjust as needed)
};

// rest of code

In the code above, I've added an announceOption function. The function is called whenever a user selects an option. The use of the assertive value in the aria-live attribute signals to the screen reader to interrupt its current announcement and promptly announce the updated value.

Now when you test this with a screenreader, the screen reader announces the selected option as expected.

Here's a working example of the custom select on Codepen:

Wrapping Up

There's room for improvement in these features, such as adding multiple select options, autocomplete, and enhancing the overall look. Yet, my intention is for this article to be a helpful guide, encouraging you to keep accessibility in mind when building a component.

If you're looking for a package to use you should consider using React-Select or Vue3-select.

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

You can connect with me on Linkedin or Github

Resources used in this article:

• MDN Combobox roles
• W3 ARIA practices