The sort combobox within the Search modal does not have an accessible name. Without a programmatically associated label, assistive technology users cannot determine the purpose of the field, making it difficult to understand how to interact with or use the control.

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)

Global sort button (Shop handcrafted Tables)

<select class="ais-SortBy-select">
  <option value="ogt_posts_product">Sort</option>
  <option value="ogt_posts_product_price_asc">Price (asc)</option>
  <option value="ogt_posts_product_price_desc">Price (desc)</option>
</select>

When the user activates the “Search” button in the header section, a modal dialog appears. Within this modal dialog, the sort combobox is missing accessible name.

As a result, screen reader users may not be able to identify or understand the purpose of the combobox due to the missing accessible name, making it difficult to interact with or use the field effectively.

Remediation

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

Method 1

  1. Associate a visible <label> element with the combobox to provide a clear, programmatic accessible name.

Method 2

  1. If a visible label cannot be added due to design constraints, provide an accessible name using aria-label.

Resources

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

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

When an upload field includes important instructions such as what file to provide, accepted file types, and size limits, that information must be available to assistive technology users at the time the field is encountered. If users are moved directly into the upload control without the section title or instructions being announced, they may not understand what document is required or what constraints apply. This creates a significant barrier to successful form completion.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 3.3.2: Labels or Instructions (A)

WCAG 1.3.1: Info and Relationships (A)

WCAG 4.1.2: Name, Role, Value (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 Upload Receipt and UPC steps, the user is automatically taken into the upload field after advancing, but the section heading is not announced.
  • Important instructions such as uploading an image of the full receipt, showing the store name, purchase date, and total amount, are not clearly conveyed at the moment the field is encountered.
  • Accepted file types (JPG, PNG, PDF) and maximum size (20MB) are visually present, but may not be programmatically associated with the upload control in a way that is reliably announced.

Remediation

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

Method 1

  1. Ensure the upload control has a clear accessible name and that all critical instructions are programmatically associated with it using semantic labeling and descriptive relationships such as aria-describedby.
  2. Include the required contextual details in the associated instructions, including what to upload, accepted formats, and file size limits.

Method 2

  1. Ensure the newly active step heading is announced before the upload control receives focus, so users understand they are now in the receipt upload step.
  2. Preserve a logical reading order so the instructional text is encountered naturally before or with the upload field, rather than requiring users to backtrack to discover what is needed.

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

The embedded product video hides important controls until certain states or mouse interactions occur. As a result, keyboard users may not be able to reliably find, reach, or operate pause, play, or settings controls in a predictable way. This creates an inconsistent and potentially unusable video experience.

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)

Example(s)

Single products with videos (Provincial Industrial Flooring Top 4 Seat Swing Table)

The product video player hides key controls until playback or mouse interaction occurs. In testing, pause/play and settings controls were not consistently reachable by keyboard unless the player first changed state, and one settings control appeared visually obstructed by the progress bar.

Remediation

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

Method 1

  1. Ensure all essential video controls are keyboard reachable at all times they are needed, without requiring hover or mouse movement first.
  2. Do not hide core controls such as play/pause or settings in a way that prevents keyboard access.

Method 2

  1. Make controls visible at all times.
  2. Ensure controls are keyboard accessible.

Resources

Gallery controls remove or suppress the default keyboard focus indicator without consistently replacing it with a visible alternative. This makes it difficult for keyboard users to tell which gallery control is currently focused, especially when navigating thumbnails, arrows, fullscreen controls, and video controls.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 2.4.7: Focus Visible (AA)

Example(s)

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

.iconic-woothumbs-all-images-wrap a:focus,
.iconic-woothumbs-all-images-wrap button:focus {
	outline: 0 !important;
}

Additional plugin styles also remove focus from gallery arrows, thumbnail controls, fullscreen controls, and modal elements.

Remediation

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

Method 1

  1. Remove outline: 0 and similar focus suppression rules unless an equally visible replacement is provided.
  2. Apply a consistent visible focus style to all gallery controls, including thumbnails, arrows, video controls, fullscreen controls, and modal buttons.
  3. Test the gallery using only a keyboard to confirm focus remains visible throughout all gallery states.

Resources

When a user changes the current gallery image, the visual display updates but the change is not clearly communicated to assistive technologies. As a result, screen reader users may not know that the main product image has changed, which image is now being shown, or where they are within the image set.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

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 gallery visually updates the main image and toggles classes such as slick-current or iconic-woothumbs-thumbnails__slide--active, but this change is not clearly announced to assistive technologies in a meaningful way.

Remediation

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

Method 1

  1. Programmatically expose the currently displayed image using a clear selected/current state on the active thumbnail and ensure the main image update is reflected in a way assistive technologies can detect.
  2. Provide image position and context, such as “Image 3 of 12”, where appropriate and useful.
  3. Ensure gallery updates are communicated in a predictable, accessible pattern rather than relying only on visual styling and class changes.

Resources

Interactive controls that perform in-page actions (such as launching modals, triggering share dialogs, or advancing image galleries) are implemented as anchor (<a>) elements instead of <button> elements. These controls do not navigate to a new resource and instead execute JavaScript behavior on the current page. Using links for button functionality creates semantic inconsistency and may result in incorrect expectations for assistive technology users.

User impacts

Follow the links for additional information on user impairments:

WCAG violation(s)

WCAG 4.1.2: Name, Role, Value (A)

Example(s)

Single product pages (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.
A screenshot of a product description with 3 buttons outlined: Share, Make an Offer, and Ask a Question. These buttons use link tags but launch a modal.

Since the highlighted functions trigger an event (as opposed to taking the user somewhere), they should be a button.

Remediation

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

Method 1

  1. Replace the <a> tags with <button> tags

Remediation methods to avoid

  • Do not use <a role="button">. The <button> tag exists for this purpose and forcing unnatural behaviors is bad practice.

Resources