The salary schedule is provided as a PDF that is not accessible to screen reader users, and no equivalent accessible alternative is provided. Users who cannot access the PDF’s content do not have another reliable way to obtain the same information.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 1.1.1: Non-text Content (A)

WCAG 1.3.1: Info and Relationships (A)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

Human Resource – Salary Schedule

The Salary Schedule PDF is very problematic and is being provided without an accessible alternative.

Remediation

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

Method

  1. Provide an accessible version of the salary schedule, preferably as an HTML table. If a PDF remains available, remediate the PDF so its reading order, tags, table structure, and text output are correct.

When the share modal opens, keyboard focus is not moved into the modal and is not contained within it. Users must continue tabbing through the underlying page before reaching modal content, and focus can move outside the modal while it is open. This prevents the modal from behaving like a true dialog and makes the interaction difficult or confusing for keyboard and screen reader users.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.1.1: Keyboard (A)

WCAG 2.4.3: Focus Order (A)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

A screenshot of a social media "Share" modal depicting several social media options.

The share window visually appears as a modal overlay, but the markup does not expose a true dialog pattern or focus-management behavior.

Remediation

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

Method

  1. Move focus into the dialog, preferably to the close button or dialog heading.
  2. Trap focus within the modal while it is open.
  3. Allow Escape to close the modal.
  4. Return focus to the button that opened the modal after it closes.
  5. Prevent users from navigating to background page content while the modal is active.

Resources

The share modal’s close control is built with a non-interactive <div> instead of a native button. Because the control is not keyboard accessible and the modal does not close with Escape, keyboard-only users may be unable to dismiss the modal once it opens.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.1.1: Keyboard (A)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

A screenshot of a social media "Share" modal depicting several social media options. The modal "close" button is outlined.

The close control is a <div> containing an SVG and does not provide native keyboard behavior.

Remediation

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

Method

  1. Replace the close <div> with a native <button> element and provide a clear accessible name.

Resources

Filter controls are implemented using non-semantic <div> elements instead of native form controls or buttons. Because these controls are not keyboard accessible, users relying on keyboard navigation cannot filter or refine resource listings.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.1.1: Keyboard (A)

WCAG 1.3.1: Info and Relationships (A)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

Resource Center

<div class="facetwp-bb-module facet-wrap">
    <h3 class="facetwp-facet-title">View Resources by Type</h3>
    <div class="facetwp-facet facetwp-facet-resource_type facetwp-type-radio" data-name="resource_type" data-type="radio">
        <div class="facetwp-radio checked" data-value="" data-rocket-lazy-bg-631eaaac-d0ed-4a0a-9dc6-905709e3e2dd="loaded" data-rocket-lazy-bg-f8788009-9e53-496c-abb5-5b4957cc530c="loaded">Any</div>
        <div class="facetwp-radio" data-value="case_study" data-rocket-lazy-bg-631eaaac-d0ed-4a0a-9dc6-905709e3e2dd="loaded"><span class="facetwp-display-value">Case Studies</span><span class="facetwp-counter">(28)</span></div>
        <div class="facetwp-radio" data-value="post" data-rocket-lazy-bg-631eaaac-d0ed-4a0a-9dc6-905709e3e2dd="loaded"><span class="facetwp-display-value">Posts</span><span class="facetwp-counter">(12)</span></div>
        <div class="facetwp-radio" data-value="podcast" data-rocket-lazy-bg-631eaaac-d0ed-4a0a-9dc6-905709e3e2dd="loaded"><span class="facetwp-display-value">Podcasts</span><span class="facetwp-counter">(6)</span></div>
        <div class="facetwp-radio" data-value="webinar" data-rocket-lazy-bg-631eaaac-d0ed-4a0a-9dc6-905709e3e2dd="loaded"><span class="facetwp-display-value">Webinars</span><span class="facetwp-counter">(3)</span></div>
    </div>
</div>

Non-native UI elements are being used to wrap the options with no keyboard support.

Remediation

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

Method

  1. Implement filters using native radio buttons, checkboxes, or buttons
  2. Expose clear names, roles, and states to assistive technologies

Remediation methods to avoid

  • Do not use non-native UI elements for interactive elements
.ac-remediations p.remediations-into strong { background-color: #00703C; color: #ffffff; display: inline-block; border-radius: 80px; padding: 4px 8px; line-height: 1; } .ac-remediations { background-color: #ffffff; padding: 1em; border-radius: 10px; box-shadow: 0 0 20px 0 rgba(0, 0, 0, .2); margin: 2em 0; } .ac-remediations h3 { font-size: 1.25rem; font-weight: 700; }

Resources

Range sliders within the filter modal cannot be reliably operated using a keyboard and do not provide appropriate accessible names. As a result, keyboard and screen reader users may be unable to identify what each slider controls or adjust its value, preventing them from using important filtering functionality.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 1.3.1: Info and Relationships (A)

WCAG 2.1.1: Keyboard (A)

WCAG 4.1.2: Name, Role, Value (A)

WCAG 1.3.1: Info and Relationships (A)

Example(s)

Global shop filter (Shop Handcraft Tables)

A screenshot of a product filter. Each category is a collapsed accordion with the except of "Price" which contains a min/max slider that allows mouse users to drag dots in order to set a price range between $0 and $125,000 USD.

When the user activates the “Search” button in the header section, a modal dialog appears. Within this modal dialog, when the user activates the “Filters” button, another modal opens. In this modal, when the user expands the “Price”, “Length”, “Width” and so on buttons under the “Filters” text, the sliders within those buttons are not operable using a keyboard and are missing accessible names.

This makes it difficult for keyboard and screen reader users to access and adjust the slider values.

Remediation

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

Method 1

  1. have a clear accessible name that identifies whether it controls the minimum or maximum value
  2. support full keyboard operation using expected keys such as:
    • Left/Right Arrow or Down/Up Arrow to decrease/increase
    • Home to move to the minimum allowed value
    • End to move to the maximum allowed value
    • optional Page Up/Page Down for larger increments
  3. expose updated values programmatically through:
    • aria-valuenow
    • aria-valuemin
    • aria-valuemax
    • and, where helpful, aria-valuetext such as “Minimum price $150” or “Maximum price $9,768”
  4. provide a programmatic relationship to the visible filter label, such as Price
  5. clearly indicate which thumb currently has focus
  6. avoid trapping keyboard users or requiring a mouse to reposition the handles

Method 2

  1. Replace the custom dual-handle slider with separate Minimum and Maximum form fields that use native semantic inputs and labels.

Method 3

  1. Provide both interfaces: keep the visual range slider for users who prefer it, but also include accessible Min and Max inputs that stay synchronized with the slider.

Remediation methods to avoid

  • Avoid use non-UI elements that were not intended to be used as UI elements (for example, div and span and then using JS to make them UI elements)

Resources

The “Add to Wishlist” control does not programmatically communicate its current state (whether the item has been added or not). While the visible text may change, assistive technology users are not reliably informed of the control’s status, making it difficult to determine whether the action has been applied.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

“Add to Wishlist” on single products (Provincial Industrial Flooring Top 4 Seat Swing Table)

The control visually toggles between “Add to Wishlist” and “Remove from Wishlist”, but does not expose a programmatic state such as pressed/selected, making it unclear to assistive technology users whether the item is currently saved.

Remediation

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

Method

  1. Use aria-pressed="true/false" to convey the button state to screen readers
  2. Even better: Also implement an aria-live announcement for additional confirmation (“[item] added/removed from wishlist”
.ac-remediations p.remediations-into strong { background-color: #00703C; color: #ffffff; display: inline-block; border-radius: 80px; padding: 4px 8px; line-height: 1; } .ac-remediations { background-color: #ffffff; padding: 1em; border-radius: 10px; box-shadow: 0 0 20px 0 rgba(0, 0, 0, .2); margin: 2em 0; } .ac-remediations h3 { font-size: 1.25rem; font-weight: 700; }

Resources

The image gallery can be opened with a mouse, but keyboard users cannot activate the gallery images to open the lightbox. This prevents keyboard-only and screen reader users from accessing the enlarged gallery view and any additional image navigation available within it. Although the lightbox itself is more usable once opened, the entry point to that experience is not keyboard operable.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.1.1: Keyboard (A)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

Modula Best Grid Galleries (Antique Store Grand Ave. Los Angeles)

Because the lightbox can only be opened by mouse interaction, keyboard users are blocked from accessing the expanded gallery experience.

Remediation

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

Method 1 – recommended

  1. Use a native interactive element with built-in keyboard support, such as a <button>, and ensure it responds to standard keyboard activation.

Method 2 – if this gallery plugin must be used

  1. Ensure it responds to both Enter and Space
  2. Ensure the keyboard behavior matches the mouse behavior
  3. Verify the control remains focusable and operable without requiring pointer interaction

Remediation methods to avoid

  • Avoid using <a> to trigger actions
.ac-remediations p.remediations-into strong { background-color: #00703C; color: #ffffff; display: inline-block; border-radius: 80px; padding: 4px 8px; line-height: 1; } .ac-remediations { background-color: #ffffff; padding: 1em; border-radius: 10px; box-shadow: 0 0 20px 0 rgba(0, 0, 0, .2); margin: 2em 0; } .ac-remediations h3 { font-size: 1.25rem; font-weight: 700; }

Resources

The “Add to Wishlist” control on product pages is not fully operable using a keyboard. Although it is visually presented as a button, it is implemented using a non-semantic element that does not reliably support keyboard interaction. This prevents keyboard-only and assistive technology users from adding or removing items from their wishlist.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.1.1: Keyboard (A)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

Single products (1920s American Victor Model VV-50 Portable Phonograph)

Remediation

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

Method

  1. Replace non-semantic interactive elements with native <button> elements to ensure built-in keyboard support and accessibility.

Remediation methods to avoid

  • Do not use <a> to trigger an event
  • Using JavaScript to force non-native elements to do a job they weren’t programmed to have or have supports they wouldn’t normally have will still have potential to cause breakage or conflict
.ac-remediations p.remediations-into strong { background-color: #00703C; color: #ffffff; display: inline-block; border-radius: 80px; padding: 4px 8px; line-height: 1; } .ac-remediations { background-color: #ffffff; padding: 1em; border-radius: 10px; box-shadow: 0 0 20px 0 rgba(0, 0, 0, .2); margin: 2em 0; } .ac-remediations h3 { font-size: 1.25rem; font-weight: 700; }

Resources

Interactive controls within the wishlist modal are not fully operable using a keyboard. Users who rely on keyboard navigation may be unable to activate key functionality such as closing the modal or removing items from the wishlist, preventing them from completing core tasks.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.1.1: Keyboard (A)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

A screenshot of a Wishlist drawer modal expanded with the "Delete item" and "Close modal" buttons outlined.

These controls are implemented using <a> elements with role="button" but do not reliably respond to keyboard activation (e.g., Enter/Space), making them non-functional for keyboard users.

Remediation

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

Method

  1. Replace non-semantic interactive elements with native <button> elements to ensure built-in keyboard support and accessibility.

Remediation methods to avoid

  • Do not use <a> to trigger an event
  • Using JavaScript to force non-native elements to do a job they weren’t programmed to have or have supports they wouldn’t normally have will still have potential to cause breakage or conflict
.ac-remediations p.remediations-into strong { background-color: #00703C; color: #ffffff; display: inline-block; border-radius: 80px; padding: 4px 8px; line-height: 1; } .ac-remediations { background-color: #ffffff; padding: 1em; border-radius: 10px; box-shadow: 0 0 20px 0 rgba(0, 0, 0, .2); margin: 2em 0; } .ac-remediations h3 { font-size: 1.25rem; font-weight: 700; }

Resources

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