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:
- Vision impairment (external link, opens in a new tab)
- Cognitive impairment (external link, opens in a new tab)
- Motor impairment (external link, opens in a new tab)
- General user experience (external link, opens in a new tab)
WCAG violation(s)
WCAG 2.1.1: Keyboard (A) (external link, opens in a new tab)
WCAG 4.1.2: Name, Role, Value (A) (external link, opens in a new tab)
Example(s)
Modula Best Grid Galleries (Antique Store Grand Ave. Los Angeles (external link, opens in a new tab))

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
- 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
- Ensure it responds to both Enter and Space
- Ensure the keyboard behavior matches the mouse behavior
- Verify the control remains focusable and operable without requiring pointer interaction
Remediation methods to avoid
- Avoid using
<a>to trigger actions
Resources
- Lightbox (external link, opens in a new tab) (Code Accessible)
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:
- Vision impairment (external link, opens in a new tab)
- Cognitive impairment (external link, opens in a new tab)
- Motor impairment (external link, opens in a new tab)
- General user experience (external link, opens in a new tab)
WCAG violation(s)
WCAG 2.1.1: Keyboard (A) (external link, opens in a new tab)
WCAG 4.1.2: Name, Role, Value (A) (external link, opens in a new tab)
Example(s)
Single products (1920s American Victor Model VV-50 Portable Phonograph (external link, opens in a new tab))

Remediation
For this issue to be remediated and marked Fixed, all the items below must be addressed.
Method
- 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:
- Vision impairment (external link, opens in a new tab)
- Cognitive impairment (external link, opens in a new tab)
- Motor impairment (external link, opens in a new tab)
- General user experience (external link, opens in a new tab)
WCAG violation(s)
WCAG 2.1.1: Keyboard (A) (external link, opens in a new tab)
WCAG 4.1.2: Name, Role, Value (A) (external link, opens in a new tab)
Example(s)

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
- 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
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:
- Vision impairment (external link, opens in a new tab)
- Cognitive impairment (external link, opens in a new tab)
- Motor impairment (external link, opens in a new tab)
WCAG violation(s)
WCAG 4.1.2: Name, Role, Value (A) (external link, opens in a new tab)
WCAG 2.1.1: Keyboard (A) (external link, opens in a new tab)
WCAG 2.4.3: Focus Order (A) (external link, opens in a new tab)
WCAG 1.3.1: Info and Relationships (A) (external link, opens in a new tab)
Example(s)

- 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
- Ensure the modal is announced as a dialog when it opens and that its accessible name is reliably conveyed to assistive technologies.
- Confirm that the dialog container, not just its heading, is exposed correctly and that it is opened using an accessible modal pattern.
- 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
- Mastering Accessible Modals with ARIA and Keyboard Navigation (external link, opens in a new tab) (A11y Collective)
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:
- Vision impairment (external link, opens in a new tab)
- Cognitive impairment (external link, opens in a new tab)
- Motor impairment (external link, opens in a new tab)
WCAG violation(s)
WCAG 4.1.2: Name, Role, Value (A) (external link, opens in a new tab)
WCAG 1.3.1: Info and Relationships (A) (external link, opens in a new tab)
Example(s)
Global, footer (Home (external link, opens in a new tab))

<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
- Remove the
aria-hidden="true"attribute from the<a>element so it is exposed to assistive technologies.
Resources
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:
- Vision impairment (external link, opens in a new tab)
- Cognitive impairment (external link, opens in a new tab)
- Motor impairment (external link, opens in a new tab)
- General user experience (external link, opens in a new tab)
WCAG violation(s)
WCAG 1.1.1: Non-text Content (A) (external link, opens in a new tab)
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
- 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
- No:
- 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.
- Use empty alt text (
alt="") for decorative images that do not add meaning, rather than filling the attribute with filenames or repeated labels. - 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
alttext. It is frequently inaccurate and doesn’t convey the right details. Search engines indexalttext so accuracy allows users to find items on your site that fit their queries. - Do not use keyword soup as
alttext. This isn’t helpful for users and search engines are punishing this.
Resources
- The Alt Scene: When and How to Write Alternative Text (external link, opens in a new tab) (Equalize Digital)
- How to write effective product alt text for accessibility (external link, opens in a new tab) (AccessiCart)
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:
- Vision impairment (external link, opens in a new tab)
- Cognitive impairment (external link, opens in a new tab)
- Motor impairment (external link, opens in a new tab)
- General user experience (external link, opens in a new tab)
WCAG violation(s)
WCAG 1.3.1: Info and Relationships (A) (external link, opens in a new tab)
WCAG 4.1.2: Name, Role, Value (A) (external link, opens in a new tab)
Example(s)
Single product image galleries (Provincial Industrial Flooring Top 4 Seat Swing Table (external link, opens in a new tab))

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
- Use native interactive elements such as
buttonfor each thumbnail and provide a meaningful accessible name, such as the image description or image number. - Programmatically expose the current state using an appropriate state such as
aria-current="true"oraria-selected="true"within a valid widget pattern. - 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.
Resources
- How to Test and Improve Carousel Accessibility: A Complete Guide (external link, opens in a new tab) (A11y Collective)
- Carousels Tutorial (external link, opens in a new tab) (W3 School)
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:
- Vision impairment (external link, opens in a new tab)
- Cognitive impairment (external link, opens in a new tab)
- Motor impairment (external link, opens in a new tab)
WCAG violation(s)
WCAG 2.4.4: Link Purpose (A) (external link, opens in a new tab)
WCAG 4.1.2: Name, Role, Value (A) (external link, opens in a new tab)
Example(s)
Single product image galleries (Vintage Concentric Bronze Passage Door Knob Set (external link, opens in a new tab))

Archives and catalogues with pagination (Handcrafted Tables, page 2 (external link, opens in a new tab))

Remediation
For this issue to be remediated and marked Fixed, all the items below must be addressed.
Method 1
- Add visible or visually hidden text
Method 2
- Add an
aria-labelattribute to thea/button
Remediation methods to avoid
- Do not use a
titleattribute without one of the aforementioned methods. Atitlewill only reliably benefit sighted mouse-users.
Resources
The <select> element does not have a properly associated accessible label. Without a programmatically determinable name, assistive technologies cannot reliably identify the purpose of the control. This makes it difficult or impossible for users to understand what the dropdown does when navigating via screen readers, voice control, or other assistive technology.
User impacts
Follow the links for additional information on user impairments:
- Vision impairment (external link, opens in a new tab)
- Cognitive impairment (external link, opens in a new tab)
- Motor impairment (external link, opens in a new tab)
- General user experience (external link, opens in a new tab)
WCAG violation(s)
WCAG 1.3.1: Info and Relationships (A) (external link, opens in a new tab)
WCAG 4.1.2: Name, Role, Value (A) (external link, opens in a new tab)
Example(s)
Blog (external link, opens in a new tab)

Shop pages (external link, opens in a new tab)

Remediation
For this issue to be remediated and marked Fixed, all the items below must be addressed.
Method 1 (recommended) – add a visual label
- Add a visible
labelthat is programmatically associated with the fields using afor/idconnection.
Method 2 – add ARIA label
- Add an
aria-labelattribute to theselectfields (eg,<select aria-label="Sort products">)
Remediation methods to avoid
- Don’t add a label via jQuery; these generally conflict with AJAX scripts commonly run on blogs and store
Resources
- Accessibility Labels (external link, opens in a new tab) (W3)
- Every input needs a label (external link, opens in a new tab) (A11y Collective)
The registration form uses placeholder text inside input fields instead of proper labels. Placeholder text disappears when users start typing and is not reliably announced by assistive technologies. This makes it difficult for users to understand what information is required in each field.
User impacts
Follow the links for additional information on user impairments:
- Vision impairment (external link, opens in a new tab)
- Cognitive impairment (external link, opens in a new tab)
- Motor impairment (external link, opens in a new tab)
- General user experience (external link, opens in a new tab)
WCAG violation(s)
WCAG 1.3.1: Info and Relationships (A) (external link, opens in a new tab)
WCAG 3.3.2: Labels or Instructions (A) (external link, opens in a new tab)
WCAG 4.1.2: Name, Role, Value (A) (external link, opens in a new tab)
Example(s)

<input type="text" placeholder="Name">
<input type="email" placeholder="Email address">
No <label> element exists, programmatically associated or otherwise.
Remediation
For this issue to be remediated and marked Fixed, all the items below must be addressed.
Method 1 – Implement visible labels (recommended)
- Add a
<label>element for each form control. - Ensure the
forattribute of the<label>matches theidof the input. - Keep the label visible on screen (do not rely solely on placeholder text).
- Ensure each
idvalue is unique on the page.
<label for="name">Name</label>
<input type="text" id="name">
<label for="email">Email address</label>
<input type="email" id="email">
Method 2 – Implement an aria-label
- Add a unique
idto each form control. - Add an
aria-labelattribute that clearly describes the field’s purpose. - Ensure the accessible name matches any visible text.
- Do not rely on placeholder text as the accessible name.
<input type="text" id="name" aria-label="Name">
Remediation methods to avoid
- Do not rely solely on
placeholdertext as the label. - Do not hide visible labels with
display: none;(this removes them from assistive technologies). - Do not add
titleattributes as a substitute for labels. They are inconsistently announced. - Do not use vague accessible names like
"field"or"input1". - Do not duplicate IDs across fields when associating labels.