Making Accessibility Visible Part 5: Keyboard Focus and Dialog Behavior

Posted November 03, 2021

AudioEye

Posted November 03, 2021

Part 5 - making accessibility visible - Keyboard Focus

Ready to see AudioEye in action?

Watch Demo

This is the fifth and final part in our Making Accessibility Visible series. The series examines how people who use screen readers navigate online content, and what that experience looks like on accessible versus inaccessible sites. Read the first four installments on our blog: Part 1: Missing Button Labels here, Part 2: Heading Helpfulness here, Part 3: Image Alt Text here, and Part 4: Missing Descriptions here.

In part 5 of the Making Accessibility Visible video series, professional accessibility testers Sarah and Charles use screen readers to explore the content on an e-commerce website in order to join an email list. Charles and Sarah show us what that process looks like on an accessible versus inaccessible version of the same page.

Watch the video to learn about what happens when keyboard focus and dialog behave incorrectly.

Code/Technical Notes From the Video

Task prompt

Task description

Activate the “Join” button. It opens a pop-up with a heading, an email field, and a button, so someone can enter their email address and join the mailing list.

Testers featured

Charles, Sarah

Broken elements

The button “Open dialog” doesn’t work, so the user cannot enter their information to join the email list.

<div class="dialog open-dialog" role="dialog">
      <button class="close-dialog">
        X
      </button>
      <h2 id="dialog-title">
        Join
      </h2>
      <div class="dialog_form">
        <div class="dialog_form_item">
          <label>
            <span class="label_text">
              Email Address
            </span>
            <input type="email">
          </label>
        </div>
        <button type="submit" aria-label="submit" class="submit close-dialog">
          Join
        </button>
      </div>
    </div>

Working elements

When the dialog opens, “Join dialog” is announced and the user can enter their email address to join the mailing list. The dialog can be closed with the ESC key or close button and the focus will return to the Join button, the triggering element.

<div class="dialog" role="dialog" aria-labelledby="dialog-title">
      <button aria-label="close" class="close-dialog">
        X
      </button>
  <h2 id="dialog-title">
    Join
  </h2>
  <div class="dialog_form">
    <div class="dialog_form_item">
      <label>
        <span class="label_text">
          Email Address
        </span>
        <input type="email" autocomplete="email">
      </label>
    </div>
    <button type="submit" class="submit close-dialog">
      Join
    </button>
  </div>
</div>

About Keyboard Focus and Dialog Behavior

For a website to be accessible, it needs to be navigable by keyboard alone — which is how people with screen readers use the internet. Most interactive elements, such as links or pop-ups, are typically indicated visually on a webpage. With a screen reader, you can focus on these elements by using the tab key on a keyboard.

Here are some best practices to make your website keyboard-friendly:

Make sure a screen reader can focus on any interactive elements on a page, such as links, buttons, and forms.
Use high contrast or styling between the focus indicator and other parts of the page.
Structure the code on the website to reflect the correct hierarchy of the content.
If a page element is not interactive, don’t give it focus.
Test if focus is working on both mobile and desktop versions of the webpage.
Follow recommendations in accessibility acts, including WCAG 2.X, ADA, AODA, etc.

Web browsers will usually automatically provide focus indicators, however, it is important to test that they are functioning. You can also build focus indicators into the website code.

For more information, explore the links below.

Additional Resources

Keyboard Accessibility
Read this article to learn the basics of keyboard accessibility and common keystrokes to test for.

Modal Dialog Example
Learn more about modal dialogs and how to make them accessible using Accessible Rich Internet Applications (ARIA).

A Final Note on the Series

All issues covered in the Making Accessibility Visible series, including missing alt text and descriptions and misleading headings, greatly impact whether a blind person can interact with a website. We hope this series has given you a deeper understanding of how screen reader users navigate the internet and what you can do to create an accessible website.

This series wouldn’t have been possible without the valuable feedback and time from our testers — Chris, Leslie, Sarah, and Charles. Our testing community plays a vital role in identifying accessibility issues and improving user experience for people who rely on different assistive technologies to navigate digital content.

Accessibility really doesn’t have to be this hard, scary thing. If you take some steps and do this today, your website will stand out as being exemplary.
- Chris, an Internet Security Professional