Images across the site use alternative text in inconsistent and unhelpful ways, including repeating the product name, reusing filenames, or providing other text that does not meaningfully describe the image itself. This prevents screen reader users from understanding the image content and may also reduce the search value of image metadata.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 1.1.1: Non-text Content (A)

Example(s)

Throughout the site, images use alt text such as repeated product names, generic labels like “Video” (see product image galleries with videos), or file names. In blog content, visible captions may duplicate the alt text exactly rather than providing complementary information.

Remediation

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

Method 1

  1. Write alt text to describe the image itself and its purpose in context, not just the page topic, product title, or file name.
    • No: Unique Tables - Q288043
    • Yes: Rustic industrial swing table with four suspended seats and a weathered wood top
  2. For product galleries, describe what is unique about each image where the image adds distinct information, such as angle, detail, material, finish, damage, or ornamentation.
  3. Use empty alt text (alt="") for decorative images that do not add meaning, rather than filling the attribute with filenames or repeated labels.
  4. Treat alt text as both an accessibility and content quality feature. Helpful alt text improves the experience for screen reader users and can also support image indexing and search relevance when it accurately reflects the image content.

Remediation methods to avoid

  • Do not mark all images decorative. Images are selected for a reason and their value should be conveyed to a user who may not be able to see it.
  • Avoid using AI-generated alt text. It is frequently inaccurate and doesn’t convey the right details. Search engines index alt text so accuracy allows users to find items on your site that fit their queries.
  • Do not use keyword soup as alt text. This isn’t helpful for users and search engines are punishing this.
.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 product gallery thumbnails are interactive, but they are not exposed to assistive technologies as clear controls with a meaningful name, role, and selected state. Screen reader users may encounter a series of images or generic controls without being told that they can be used to change the main product image or which one is currently active.

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)

Single product image galleries (Provincial Industrial Flooring Top 4 Seat Swing Table)

A screenshot of a product gallery with one large image and a carousel of clickable thumbnail images to click to enlarge. The thumbnails are outlined.

The product gallery uses custom thumbnail elements such as .iconic-woothumbs-thumbnails__slide with click behavior added by JavaScript, but they are not exposed as semantic controls such as buttons and do not programmatically communicate which thumbnail is selected.

Remediation

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

Method 1

  1. Use native interactive elements such as button for each thumbnail and provide a meaningful accessible name, such as the image description or image number.
  2. Programmatically expose the current state using an appropriate state such as aria-current="true" or aria-selected="true" within a valid widget pattern.
  3. Ensure the thumbnail structure communicates both purpose and relationship to the main gallery image so assistive technology users can understand that activating a thumbnail changes the primary image.

Remediation methods to avoid

  • Do not use <a> tags.
  • Avoid using <div> tags or other non-UI elements and forcing them to be UI elements with scripts.
.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

Pagination arrows and gallery navigation controls are implemented as <a> elements containing only SVG icons and no accessible text alternative. Because these controls lack an accessible name, assistive technologies cannot determine their purpose. Users navigating by screen reader or voice control will encounter unlabeled links, making navigation confusing or impossible.

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)

Single product image galleries (Vintage Concentric Bronze Passage Door Knob Set)

A screenshot of a product image gallery. The enlarge images icon, the next image icon, and the scroll through images icon are all outlined.

Archives and catalogues with pagination (Handcrafted Tables, page 2)

A screenshot of pagination with a Previous chevron, 1, 2, 3, an ellipses, 5, and a Next chevron.

Remediation

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

Method 1

  1. Add visible or visually hidden text

Method 2

  1. Add an aria-label attribute to the a / button

Remediation methods to avoid

  • Do not use a title attribute without one of the aforementioned methods. A title will only reliably benefit sighted mouse-users.
.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 skip navigation link, designed to allow users to bypass repetitive navigation, is present but hidden from screen reader users. This means that users relying on screen readers are unable to quickly skip over the header and go straight to the main content, significantly slowing down navigation.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.4.1: Bypass Blocks (A)

WCAG 2.4.7: Focus Visible (AA)

Remediation

Ensure that the skip navigation link is visible and focusable for all users.

Users must be informed when a link will take them to a different website or open in a new browser tab/window. This helps prevent disorientation, unexpected navigation changes, and loss of context. Providing both visual indicators (such as an external-link icon) and accessible text cues (such as “external link” or “opens in a new tab”) ensures that all users—sighted, low-vision, and screen reader users—can anticipate the behavior of the link.

Without clear indicators, users may inadvertently leave the current site, lose their place, or become confused when new tabs or windows appear unexpectedly. This affects all users but is especially disruptive for those who use assistive technology or have cognitive disabilities.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 3.2.1: On Focus (A)

WCAG 3.2.2: On Input (A)

WCAG 2.4.4: Link Purpose (A)

Example(s)

Careers

A screenshot of an external link that says "Apple Online Now"

Footer:

A screenshot of an external link in the footer that says "Transparency in Coverage".

Homepage

A screenshot of the "Shop Colt Merchandise" call to action and the external link that says "Shop Now".

These are all sample of external links with no external link indication.

Testing conditions

  • Chrome

Remediation

Users should know what will happen when they activate a link, especially if it will take them away from the original site.

A fully comprehensive example of an external link is:

<a href="https://shop.colt.com/" target="_blank" rel="noopener noreferrer">
    Shop now
    <i class="fa-solid fa-arrow-up-right-from-square" aria-hidden="true" title="external link, opens in a new tab"></i>
    <span class="sr-only"> (external link, opens in a new tab)</span>
</a>
  • The icon provides a visible indication a link will take them off-site
  • The icon having an aria-hidden="true" attribute hides duplicate information from a screen reader
  • The title attribute on the icon provides the information to sighted mouse users.
  • The screen reader text provide critical information to screen reader users.

External links should be formatted as the example provided.

Important note: Whether or not a link should open in a new tab is a hotly contested subject within the accessibility community. However, what is universally agreed upon is all external links should function the same (as in not having some open in the same tab and some opening a new tab) and what is going to happen should be conveyed to users (as in, “external link, opens in a new tab” or “external link, opens in the same tab”).

The site has multiple menus intended for different viewpoints. Unfortunately, these menus are only hidden with display: none making them still available in the DOM and for users who navigate with CSS disabled. The presence of all three menus creates id conflicts and present high risks for confusion. It can also create conflicts for bypassing landmarks and prevents some users from navigating effeciently.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 4.1.1 – Parsing

WCAG 1.3.1: Info and Relationships (A)

WCAG 2.4.1: Bypass Blocks (A)

Example(s)

A screenshot of all 3 Colt headers full styled.
A screenshot of all 3 Colt headers with CSS disabled presenting identical information.

The site includes three navigation menus (one each for desktop, tablet, and mobile). Although only one is meant to appear at a time based on viewport width, all three remain in the DOM at all times and are hidden using display: none. As a result, each menu contains list items with the same IDs. This creates multiple conflicting landmarks, broken relationships, and invalid HTML. If CSS is disabled, all three menus become visible simultaneously, exposing the duplication further.

This issue is made Critical by presenting multiple search fields and duplicate landmarks.

Testing conditions

  • Chrome/NVDA

Steps to reproduce

  1. Use an add-on, developer tools, or assistive tech to disabling styling
  2. View all three menus that are present

Remediation

Method 1 (recommended)

Remove duplicate menus and use CSS and JavaScript to restyle and reposition a single menus based on breakpoints.

Method 2

Only load one menu into the DOM at a time depending on the break points. Do not use display: none.

Split from 2564-070: Keyboard focus not restricted in modal dialog.

When a modal dialog opens, keyboard focus must be trapped inside the modal until it is closed. This ensures users navigating by keyboard or assistive technology do not accidentally move to underlying page content that is visually hidden but still present in the DOM. If focus is not properly managed, users can become disoriented, encounter inaccessible hidden controls, or lose track of their place in the interaction.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.4.3: Focus Order (A)

WCAG 2.1.1: Keyboard (A)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

Global, all “Favorites” modals (Baked Honey BBQ Chicken Bites)

A screenshot of a "Sign up to favorite" modal with Name, Email, and Password forms. It's highlighted to indicate it does not trap keyboard focus.

When users select to “favorite” a post, a sign up/sign in modal appears. Keyboard users can tab out of the modal into the obscured page content. After the modal is closed, hidden fields remain focusable, leaving invisible controls in the tab order.

Global, all “Search” modals (Home)

A screenshot of a search overlay with a "Sign In" button, a search input, a "Recently Viewed" section with several posts, and a "Related" section with several posts visible.

When users expand the search modal powered by Slickstream. Once a keyboard user has tabbed through the end of the search suggestions offered in the modal, it tabs though the hidden “Favorites” modal, and then restarts at the top of the page.

Testing conditions

  • Chrome/JAWS
  • Chrome/NVDA

Steps to reproduce

  1. Using a screen reader or keyboard, activate the “Add to favorites” or “menu” button
  2. Observe a dialog appears.
  3. Navigate through the dialog content pressing Tab or Shift + Tab keys and observe that the background content receives focus.
  4. Listen that the background content is announced as well while navigating with virtual cursor (up and down arrow keys)

Remediation

  • Implement a focus trap so focus stays within the modal or flyout menu while open.
  • Place initial focus on a logical element when the modal/menu opens (eg, heading, first link, or close button).
  • Ensure focus returns to the trigger element when the modal/menu closes.

Split from 2564-002: Focus not visible.

When users navigate with a keyboard, interactive elements (such as links, buttons, or form fields) do not show a clear visual focus indicator. Without a visible focus state, users cannot tell which element is active, making navigation difficult or impossible.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.4.7: Focus Visible (AA)

Example(s)

Global

Video: https://go.screenpal.com/watch/cTXYFPnqoJL

Testing conditions

  • Chrome
  • FireFox

Steps to reproduce

  1. Go to any of the mentioned page
  2. Begin navigating via keyboard
  3. Note when you get “lost”, as in no longer know where you are on the page due to a lack of focus indication

Remediation

While samples are attached, there are very few places on the site with focus indication. A global focus indication with sufficient focus should be implemented.

This issue arises from the omission of proper heading markup for text that visually appears to serve as headings, leading to potential confusion in content structure. The lack of appropriate HTML heading tags for text that indicates section titles or key content divisions can disrupt the logical hierarchy expected by assistive technologies. This misstep may cause screen readers to fail in presenting a clear content structure, making it challenging for users to navigate and understand the page’s organization effectively.

User impacts

Follow the links for additional information on user impairments:

WCAG violation

WCAG 1.3.1: Info and Relationships (A)

Examples

Global issue, (Strawberry Cake)

A screenshot highlighting the names of the commentors for the page.

This screenshot demonstrates that the text, such as commentors’ names, under the “Reader Comments and Reviews” section, is not marked up using HTML heading tags.

Testing conditions

  • Chrome/JAWS
  • MAC/Voiceover

Steps to reproduce

  1. Inspect the mentioned text in the main content area.
  2. Observe that the text is not marked-up using HTML heading.

Remediation

Apply appropriate HTML heading tags to all text that visually serves as a heading to ensure a clear and logical content structure. Regularly audit and update the page’s semantics to align with accessibility standards, enhancing the experience for screen reader users by providing accurate navigation cues.

Forms must clearly communicate when errors occur so users know what went wrong and how to fix it. Without textual error messages, users may not realize that input is invalid or missing. This creates barriers for screen reader users, people with cognitive disabilities, and anyone unfamiliar with the form. WCAG requires that errors be identified in text and programmatically associated with the relevant input field.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 3.3.1: Error Identification (A)

WCAG 3.3.3: Error Suggestion (AA)

WCAG 4.1.3: Status Messages (AA)

Example(s)

Global, ALL “Sign up for our Newsletter” forms (Home)

In the form under the section “Enter your email below, and we’ll send the link straight to your inbox…”, submitting the form with empty or invalid data does not produce a textual error message. Users cannot tell which field failed validation or how to correct the error.

Testing conditions

  • Chrome/JAWS
  • FireFox/NVDA
  • MAC/Voiceover

Steps to reproduce

  1. Submit any form empty or with invalid data.
  2. Observe that the error is identified via a red color rectangular box only (and only in cases of invalid data).

Remediation

  • Display clear, textual error messages whenever a field fails validation (eg, “Invalid email: email addresses must contain ‘@'”).
  • Programmatically associate error messages with the input field using aria-describedby or similar.
  • Ensure error messages are announced by screen readers (eg, by placing them inside a role="alert" container).