Six findings in detail
A-01: Size options cannot be selected with the keyboard
- Severity
- High
- Page
- Product page
- WCAG conformance level
- A
- WCAG success criterion
- 2.1.1
ScreenshotAn annotated screenshot of this issue is added here in a real report, based on the client's website.
Issue description
Interactive controls must be operable with a keyboard alone. Custom controls built from non-interactive elements are invisible to the keyboard unless they are given the right role and behavior. When a required choice, such as a product size, cannot be made without a mouse, the whole purchase is blocked.
Steps to reproduce
- Open any product page in a desktop browser.
- Press Tab repeatedly, starting from the product title.
- Observe that focus moves from the image gallery straight to the Add to cart button. The size options (S, M, L and XL) are never reached.
- Press Enter or Space while the size area is visible: no size is selected.
Actual behavior
The size options (S, M, L and XL) are styled div elements with mouse click handlers only. They are not in the tab order, and pressing Enter or Space has no effect. As a result, people who navigate with a keyboard, a switch device or voice control cannot choose a size and cannot complete a purchase.
Expected behavior / remediation
All options of a product should be selectable with the keyboard and announced with their name, role and state.
- Use native radio buttons grouped in a
fieldset with a legend, instead of styled div elements. - Style the radio buttons with CSS so the visual design stays the same.
<fieldset>
<legend>Size</legend>
<input type="radio" id="size-s" name="size" value="S">
<label for="size-s">S</label>
<input type="radio" id="size-m" name="size" value="M">
<label for="size-m">M</label>
</fieldset>
Comments
Affects people using keyboards, switch devices, voice control and screen readers. To confirm the fix, tab to the group and choose with the arrow keys. A screen reader should announce "Size, M, radio button, 2 of 4, selected".
A-02: Cart confirmation message is not announced
- Severity
- High
- Page
- Product page, cart
- WCAG conformance level
- AA
- WCAG success criterion
- 4.1.3
ScreenshotAn annotated screenshot of this issue is added here in a real report, based on the client's website.
Issue description
When a page changes after an action, such as an item being added to a cart, people who cannot see the change need it announced. Status messages should be exposed programmatically so assistive technologies can announce them without moving focus.
Steps to reproduce
- Turn on a screen reader (NVDA on Windows or VoiceOver on macOS).
- On a product page, choose a size and activate Add to cart.
- Observe that the cart count and the on-screen notice change, but the screen reader announces nothing.
Actual behavior
After "Add to cart" is activated, the cart count changes and a notice reading "Linen overshirt added to cart" appears on screen, but the notice is inserted into the page without a status role. As a result, screen reader users receive no confirmation and cannot tell whether the item was added.
Expected behavior / remediation
Status messages should be announced by assistive technologies without moving keyboard focus.
- Add an empty container with
role="status" to the page when it loads. - Write the confirmation text into that container after the item is added. The container must already exist, or many screen readers will not announce the text.
<div id="cart-status" role="status"></div>
<script>
document.getElementById("cart-status").textContent =
"Linen overshirt added to cart. Your cart has 2 items.";
</script>
Comments
Affects people using screen readers. To confirm the fix, turn on NVDA or VoiceOver, add an item and listen for the message.
A-05: Checkout errors are not linked to their form fields
- Severity
- High
- Page
- Checkout
- WCAG conformance level
- A
- WCAG success criterion
- 3.3.1, 1.3.1
ScreenshotAn annotated screenshot of this issue is added here in a real report, based on the client's website.
Issue description
Form errors must be identified in text and connected to the field they belong to, so that people using assistive technologies know that an error occurred, where it is and how to fix it.
Steps to reproduce
- Add an item to the cart and go to checkout.
- Leave the Email field empty and activate Continue to shipping.
- Observe the red message under the field. A screen reader announces nothing, and focus stays on the button.
Actual behavior
When the email field is left empty, a red message appears under it, but the message is not connected to the field and focus stays on the button. As a result, screen reader users are not told that an error occurred or which field it relates to.
Expected behavior / remediation
Errors should be identified in text, connected to the field they belong to, and announced to assistive technologies.
- Add
aria-invalid="true" to each field in error. - Connect the error message to its field with
aria-describedby. - Move focus to an error summary at the top of the form that links to each problem.
<label for="email">Email</label>
<input id="email" type="email"
aria-invalid="true"
aria-describedby="email-error">
<p id="email-error">
Enter your email address, for example name@example.com.
</p>
Comments
Affects people using screen readers and people with cognitive or learning disabilities. To confirm the fix, submit the empty form. Focus should move to the summary, and each field should be announced as invalid with its message.
A-08: Current page is not identified in the navigation
- Severity
- Medium
- Page
- All pages
- WCAG conformance level
- A
- WCAG success criterion
- 4.1.2
ScreenshotAn annotated screenshot of this issue is added here in a real report, based on the client's website.
Issue description
Navigation should tell people using assistive technologies which page they are on. A visual highlight alone is not available to people who cannot see it.
Steps to reproduce
- Open the Shop page.
- Inspect the Shop link in the main navigation.
- Observe that it is styled in bold but has no aria-current attribute, and that a screen reader does not announce it as the current page.
Actual behavior
The link for the current page is shown in bold, but no attribute identifies it as current. As a result, screen reader users are not told which page they are on.
Expected behavior / remediation
The current state of the active link should be defined programmatically and announced.
- Add
aria-current="page" to the link of the current page. - Make sure the attribute moves to the right link on every page.
<a href="/shop/" aria-current="page">Shop</a>
Comments
Affects people using screen readers. To confirm the fix, tab to the link and listen for "current page".
A-10: Active slide is not identified in the carousel indicators
- Severity
- Medium
- Page
- Home page
- WCAG conformance level
- A
- WCAG success criterion
- 4.1.2
ScreenshotAn annotated screenshot of this issue is added here in a real report, based on the client's website.
Issue description
Carousel controls must have accessible names, and the currently active slide must be identifiable by people who cannot see the visual indicator.
Steps to reproduce
- Open the home page and tab to the carousel indicators.
- With a screen reader running, move through the five dots.
- Observe that each is announced as "button", with no name and no indication of which slide is active.
Actual behavior
The five round indicators under the homepage carousel are button elements with no text. The active slide is shown only by a filled dot. As a result, screen reader users hear "button" five times and cannot tell which slide is active.
Expected behavior / remediation
Each indicator should have an accessible name, and the active one should be identified programmatically.
- Give each button a name, such as
aria-label="Go to slide 2 of 5". - Add
aria-current="true" to the active indicator, and update it when the slide changes.
<button type="button" aria-label="Go to slide 1 of 5" aria-current="true"></button>
<button type="button" aria-label="Go to slide 2 of 5"></button>
Comments
Affects people using screen readers. Note: aria-selected is only valid on elements with the tab, option, row or gridcell role, so it should not be added to plain buttons. If the indicators follow the tabs pattern, use role="tablist", role="tab" and aria-selected instead.
A-12: Redundant alternative text on product images
- Severity
- Low
- Page
- Collection page
- WCAG conformance level
- Best practice
- WCAG success criterion
- 1.1.1 (related)
ScreenshotAn annotated screenshot of this issue is added here in a real report, based on the client's website.
Issue description
Images that only repeat adjacent text add noise for screen reader users. Decorative or redundant images should be hidden from assistive technologies by giving them an empty alt attribute.
Steps to reproduce
- Open a collection page and listen to a product card with a screen reader.
- Observe that the product name is read twice: once from the image alt text and once from the link text.
Actual behavior
Each product image has alt text that repeats the product name shown in the adjacent visible link (for example alt="Linen overshirt" beside the link "Linen overshirt"). As a result, screen reader users hear the same name twice.
Expected behavior / remediation
Images that only repeat adjacent text should be ignored by assistive technologies.
- Set the alt attribute to an empty string on images that repeat adjacent text.
- Alternatively, place the image and the text inside the same link.
<a href="/shop/linen-overshirt/">
<img src="overshirt.jpg" alt="">
Linen overshirt
</a>
Comments
A small annoyance rather than a barrier. To confirm the fix, listen to a product card with a screen reader and check that the name is read once.