Modal dialogs must clearly identify themselves to assistive technologies and contain keyboard focus while open. If a modal is not announced as a dialog and users can tab outside of it, screen reader and keyboard users may not realize that a modal has opened or may continue navigating underlying page content unintentionally. This creates confusion, breaks expected interaction patterns, and can prevent users from fully understanding or completing the task presented in the dialog.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 4.1.2: Name, Role, Value (A)

WCAG 2.1.1: Keyboard (A)

WCAG 2.4.3: Focus Order (A)

WCAG 1.3.1: Info and Relationships (A)

Example(s)

A screenshot of a Terms and Conditions modal.
  • Activating the Terms and Conditions link opens a dialog and moves focus to the heading Terms and Conditions, but the modal is not announced as a dialog to the screen reader user.
  • Keyboard focus is not contained within the modal, allowing users to tab out of it and continue into the underlying page while the dialog remains open.

Remediation

For this issue to be remediated and marked Fixed, all the items below must be addressed.

Method

  1. Ensure the modal is announced as a dialog when it opens and that its accessible name is reliably conveyed to assistive technologies.
  2. Confirm that the dialog container, not just its heading, is exposed correctly and that it is opened using an accessible modal pattern.
  3. Trap keyboard focus within the modal while it is open, return focus to the triggering element when it closes, and prevent interaction with background content until the dialog is dismissed.

Resources

When a multi-step form advances to the next section without a full page reload, users need clear confirmation that the interface has changed and that a new step has been revealed. If the newly expanded section is not announced to assistive technologies, screen reader users may not realize that progression has occurred, what step they are now on, or what content has become available. This makes the form feel unpredictable and difficult to navigate.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 4.1.3: Status Messages (AA)

WCAG 3.2.2: On Input (A)

WCAG 1.3.1: Info and Relationships (A)

Example(s)

Rebates (1911 Rebate)

A screenshot of 5 form sections formatted as accordions. The second section is expanded, depicting form fields and a "Next" button that would expand the third section and collapse the second.
  • In the multi-step rebate form, selecting “Next” expands the following section, but no announcement is made to indicate that a new step has opened.
  • Step headings such as “Upload Receipt” are visually present, but are not announced when the new section becomes active.
  • Focus is moved directly into the next field or control, leaving screen reader users without context about where they are in the form.

Remediation

For this issue to be remediated and marked Fixed, all the items below must be addressed.

Method 1

  1. When a new step is revealed, provide a programmatic announcement that communicates the new section name and, if available, its position in the process. Example: “Step 3 of 5, Upload Receipt.”
  2. Use a polite live region or another reliable status-message pattern so users are informed of the transition without forcing a disruptive focus change.

Method 2

  1. Programmatically move focus to the newly revealed section heading when advancing steps, provided the heading is properly marked up and the focus change does not create additional confusion.
  2. Ensure the heading for each revealed step is exposed semantically so screen reader users receive immediate context before entering the new fields.

Resources

Interactive elements that are hidden from assistive technologies cannot be perceived or accessed by screen reader users. Applying aria-hidden="true" to a link removes it from the accessibility tree while it remains visible and operable for sighted users. This creates a mismatch between visual and non-visual experiences and prevents some users from accessing important functionality.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 4.1.2: Name, Role, Value (A)

WCAG 1.3.1: Info and Relationships (A)

Example(s)

Global, footer (Home)

A screenshot of a link "Colt Optics" with an accessibility tooltip depicting it is marked "hidden".
<a aria-hidden="true" title="external link, opens in a new tab" target="_blank" href="https://coltoptics.com/">
    <span class="elementor-icon-list-text">Colt Optics</span><i class="fas fa-external-link-alt"></i><span class="sr-only"> (external link, opens in a new tab)</span>
</a>

Remediation

For this issue to be remediated and marked Fixed, all the items below must be addressed.

Method 1

  1. Remove the aria-hidden="true" attribute from the <a> element so it is exposed to assistive technologies.

Resources

The form includes a <label> element whose for attribute references a <div> rather than a labelable form control. As a result, the visible “CAPTCHA” label is not programmatically associated with the reCAPTCHA widget.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 1.3.1: Info and Relationships (A)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

SGMA Interest Form


<li id="field_3_4" class="gfield gfield--type-captcha field_sublabel_below gfield--no-description field_description_below field_validation_below gfield_visibility_visible">
    <label class="gfield_label gform-field-label" for="input_3_4">CAPTCHA</label>
    <div id="input_3_4" class="ginput_container ginput_recaptcha gform-initialized" data-sitekey="6LeONYAUAAAAAMcf5o1zy0qfiB4PDUYikA_ZisRO" data-theme="light" data-tabindex="0" data-badge="" data-widget-id="0">
        ...
    </div>
</li>

The target is a div, not a form control.

Remediation

Ensure the CAPTCHA label is programmatically associated with the interactive element. If the widget is rendered inside a container <div>, use appropriate ARIA techniques (such as aria-labelledby) on the rendered iframe or wrapper element to correctly associate the visible label with the CAPTCHA control.

An image is used as the sole content of a link but has an empty alt attribute. As a result, the link does not have an accessible name, and assistive technology users are not informed of its purpose or destination.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.4.4: Link Purpose (A)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

Receive our emails

A screenshot of the Constant Contact logo on a form.

Specifically referring to the Constant Contact branding.

Remediation

Provide meaningful alternative text that describes the purpose of the link rather than the visual appearance of the image.

The reCAPTCHA badge exposes additional content and controls when hovered with a mouse, but the same information is not made available when the component receives keyboard focus. This creates an interaction that depends on pointer hover and prevents keyboard users from accessing the same content.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 1.4.13: Content on Hover or Focus (AA)

WCAG 2.1.1: Keyboard (A)

Example(s)

Pages with forms (Receive our emails)

A screenshot of a reCaptcha that says: "Protected by reCAPTCHA. reCAPTCHA is changing its terms of service. Link take action. Link Privacy. Link Terms."

Remediation

Ensure any content or controls revealed on hover are also revealed on keyboard focus and remain accessible without requiring pointer interaction. If the badge contains expandable information, the same behavior should be triggered consistently for both hover and focus states.

Several inline links are visually indistinguishable from surrounding body text except for a slight color difference. They are not underlined and do not use additional styling such as font weight, border, or other non-color indicators. Users must rely solely on color perception to identify which text is interactive, which reduces discoverability and creates barriers for users who cannot perceive color differences.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 1.4.1: Use of Color (A)

Example(s)

Returns

A screenshot of text. Three links are outlined in red to highlight which text is a link as there is no visual difference.

Surrounding text is #212529 and the link color is #111111 (making a 1.22:1 contrast ratio). Color-reliant link text must have a 3:1 contrast ratio to surrounding text.

Remediation

Give links a distinguishing feature, such as an underline. Alternatively, make the link-color a 3:1 contrast from #212529 (though an element difference is encouraged).

Activating “Continue to payment” opens a payment modal/iframe without moving focus into it or announcing that a modal opened. Users can tab into the footer and only reach the modal later (it appears at the bottom of the DOM). Escape closes only in some focus contexts and there is no confirmation it closed.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.4.3: Focus Order (A)

WCAG 2.4.7: Focus Visible (AA)

WCAG 2.1.1: Keyboard (A)

WCAG 4.1.3: Status Messages (AA)

WCAG 1.3.2: Meaningful Sequence (A)

Example(s)

Checkout

A screenshot of modal consisting of a payments form (hosting input for Card number, expiration date, card code, and a Place Order button).

Remediation

  • On open: move focus to the modal (first heading/field) and announce the dialogue box
  • Trap focus within the modal while open; return focus to the trigger on close
  • Ensure Escape closes the modal regardless of which control inside is focused

The drawer presents top-level categories (“Guns & NFA”) with visible caret indicators, but keyboard users cannot reliably expand/collapse submenus. Tabbing from a parent item moves focus directly into submenu links that are not visible. Pressing Enter on the parent navigates away instead of expanding the submenu.

As a result, sighted keyboard users can end up focused on offscreen/hidden items with no visual indication of where they are, and they cannot discover or operate submenu controls.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.1.1: Keyboard (A)

WCAG 2.4.7: Focus Visible (AA)

WCAG 2.4.3: Focus Order (A)

WCAG 1.3.1: Info and Relationships (A)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

Press Space or Enter will activate the page instead of expanding the submenu (these are usually triggers for buttons like submenu toggles).

Tabbing will still go into the submenu without revealing it.

Remediation

  • Convert submenu toggles (the caret) into real buttons (<button type="button">) with:
    • an accessible name (“Expand Guns & NFA submenu’)
    • aria-expanded="true/false"
    • aria-controls="[submenu-id]"
  • Prevent focus from entering submenu items until the submenu is expanded.
  • Preserve expected keyboard patterns:
    • Enter/Space on the toggle expands/collapses
    • Tab moves through visible interactive elements only
  • Ensure expanded submenu items are visibly revealed before they become focusable.

When users activate the Menu button, focus does not move into the newly opened navigation drawer. Instead, focus continues through the underlying page header controls (logo, cart, etc.), which makes the opened menu feel “not opened” to keyboard and screen reader users and creates disorienting focus order.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.4.3: Focus Order (A)

WCAG 3.2.2: On Input (A)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

In the video, the menu drawer is opened and Tab is pressed again. Instead of going into the menu drawer, focus continues in the background.

Remediation

  • When the Menu button opens the drawer, programmatically move focus to the drawer container or the first interactive element inside it.
  • Ensure the Menu button accurately communicates state with aria-expanded="true/false" and a correct aria-controls relationship to the drawer element.
  • Provide a predictable, reversible open/close pattern