The browser page title (<title>) and the main on-page heading (<h1>) are inconsistent and do not clearly represent the same content. When these two elements use different terminology or levels of specificity, it can make it difficult for users to confirm they are on the correct page or to understand the page’s purpose.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.4.2: Page Titled (A)

WCAG 2.4.6: Headings and Labels (AA)

WCAG 3.2.4: Consistent Identification (AA)

Example(s)

Many pages are like this and can many navigation difficult.

Remediation

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

Method

  1. Synchronize the title attribute with the h1. Ensure the URL is also consistent.
  2. Avoid using vague or abbreviated titles when the on-page heading is more descriptive
  3. Ensure both elements accurately reflect the page’s purpose and content
  4. Maintain consistency across the site to support navigation and orientation

Empty heading elements are present on the page, including instances where headings are used as structural wrappers without containing meaningful text. Headings are intended to provide a clear outline of page content, and empty headings create gaps in that structure, reducing the reliability of navigation for assistive technologies.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 1.3.1: Info and Relationships (A)

WCAG 2.4.6: Headings and Labels (AA)

Example(s)

Pages with form embeds with an empty .widgettitle heading:

Pages with miscellaneous empty headings

Remediation

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

Method 1

  1. Remove empty heading elements that do not convey information
  2. If a heading is needed for structure, provide clear, descriptive text that reflects the content it introduces

Resources

A same-page “jump link” references an anchor that does not exist on the page. When users activate the link, focus and navigation do not move to the expected section, resulting in a broken navigation experience and loss of context.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.4.4: Link Purpose (A)

WCAG 1.3.1: Info and Relationships (A)

WCAG 2.4.1: Bypass Blocks (A)

Example(s)

Extended Business Office

<a href="#denial" target="_self" class="fl-button fl-button-icon-animation">
    <span class="fl-button-text">Denials Management</span>
    <i class="fl-button-icon fl-button-icon-after ua-icon ua-icon-chevron-right2" aria-hidden="true"></i>
</a>

The target container:

<div id="insurance-follow-up" class="fl-row fl-row-full-width fl-row-bg-none fl-node-61y0eiofbasl fl-row-default-height fl-row-align-center two-col-icon-wrapper" data-node="61y0eiofbasl">
    ...
</div>

Remediation

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

Method 1

  1. Update the link href to match the existing target ID

Method 2

  1. Update the target element’s id to match the link

Text within the cookie policy is rendered at an extremely small size, making it difficult to read for many users. Small text increases visual strain and can become unreadable, particularly for users with low vision or when viewed on smaller screens.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 1.4.4: Resize text (AA)

Example(s)

Global (cookie policy)

  • The current text size is approximately 8.75px (#303030 on #ffffff).
  • While the contrast ratio is acceptable, the extremely small font size significantly reduces readability.
  • Small text often compounds other accessibility issues, especially on mobile devices and high-resolution displays.

Remediation

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

Method

  1. Increase the base font size of the cookie policy content to a readable default (generally at least 16px for body text). Ensure text scales appropriately when users zoom the page up to 200% without loss of content or functionality.

Resources

The mega menu uses presentational roles on submenu list containers even though those containers organize related navigation links into grouped sections. This removes meaningful structural information and prevents assistive technologies from conveying the hierarchy and relationships between menu categories and their links.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 1.3.1: Info and Relationships (A)

Example(s)

Global (main menu)

Each submenu container looks as such:

<ul class="mega-sub-menu" style="--columns:12" role="presentation">
    ...
</ul>

Remediation

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

Method

  1. Remove role="presentation" from submenu <ul>

Resources

A video presented in Spanish is labeled with an English title. When the visible title does not reflect the language of the content, users may not understand what to expect before interacting with the media.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 3.1.2: Language of Parts (AA)

WCAG 2.4.4: Link Purpose (In Context) (A)

Example(s)

Point and Pay Online Payments

A screenshot of a list of 3 helpful videos. The second items says "Watch: How to Create an Account and Set Up Recurring Payments (Spanish)".

“Watch: How to Create an Account and Set Up Recurring Payments (Spanish)” is in English despite intending to appeal to Spanish speakers.

Remediation

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

Method

  1. Change “Watch: How to Create an Account and Set Up Recurring Payments (Spanish)” to its Spanish counterpart (eg, “Mire: Cómo crear una cuenta y configurar pagos recurrentes (Español)” — not translated by someone who speaks Spanish)
  2. Ensure its language tag is updated to es

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

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

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

Resources

When a confirmation or review step is revealed, users should be able to encounter the review content in a logical reading order before reaching the final confirmation controls. If focus is moved directly to a checkbox or action near the end of the section, users may miss important review information that appears earlier in the expanded content. This creates a disconnect between the visual reading order and the assistive technology experience, increasing the risk of submitting incorrect information.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 1.3.2: Meaningful Sequence (A)

WCAG 2.4.3: Focus Order (A)

WCAG 3.2.2: On Input (A)

Example(s)

Rebates (1911 Rebate)

A screenshot of a form with 5 expandable sections. The fifth and final section is expanded depicting an "Order Confirmation" table listing out the information the user input throughout the form for review. After the table are two checkboxes for consenting to Terms and Conditions and consenting to sign up for the newsletter.
  • In the Confirm Submission step, the section includes review tables showing previously entered information.
  • When the section expands, focus is moved immediately to the Terms and Conditions checkbox rather than to the beginning of the newly revealed content.
  • A screen reader user must manually backtrack to discover that review information exists before the checkboxes and submit button.

Remediation

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

Method

  1. When the confirmation step is expanded, place focus at the beginning of the newly revealed section or on a semantic section heading so users encounter the review content in order before reaching the checkboxes and final submit action. Ensure the reading and focus order match the intended task flow.

Resources