Storefront accessibility lab / demonstration
This fictional product page demonstrates six common e-commerce accessibility issues and working remediations. It is a process demonstration, not client work or a certificate of conformance.
Working component
Use Tab and Shift+Tab. Select a size with the arrow keys, add the product to the basket and open delivery information. Focus remains visible and changes are announced to assistive technology.
Issue → fix → retest
Each finding explains user impact, a safe implementation direction and a repeatable acceptance test. “Before” snippets are displayed as text and do not reduce the accessibility of the demo itself.
A row of controls labelled “40, 41, 42” does not tell screen-reader users what those values represent.
<div><button>40</button>…</div><fieldset><legend>EU size</legend>…</fieldset>Retest: the screen reader announces the group name, selected value and number of options.
When purchase is attempted without a size, the user receives a specific message and focus moves to the first option.
alert('Error');error.textContent = message;
firstSize.focus();Retest: activate “Add to basket” without a size and verify focus position.
A role="status" message announces the product, size and basket count without interrupting the user.
cartCount.textContent = count;<p role="status" aria-live="polite">…</p>Retest: after adding the product, the update is announced while focus stays on the button.
The native dialog element limits navigation to the open window. When closed, focus returns to the delivery information button.
<div class="modal">…</div><dialog aria-labelledby="shipping-title">…</dialog>Retest: open the dialog, use Tab and Escape, then verify focus return.
The promotion code has a persistent label, associated error text and an updated aria-invalid state.
Retest: enter an invalid code, then ACCESS10; verify both the message and field state.
The product image receives concise alternative text, so its meaning does not depend on sight alone.
<img src="product.webp"><img src="product.webp" alt="Beige Aster One trainer…">Retest: a screen reader announces the product name and relevant visual characteristics.
Handover example
The final report includes remediation status and retest results. It does not leave the client with a generic list of recommendations.
| Component | Impact | Change | Retest | Status |
|---|---|---|---|---|
| Size variant | Options lack context | fieldset and legend | Keyboard + screen reader | Implemented |
| Purchase validation | Error is not identified | Message and focus movement | Purchase without size | Implemented |
| Basket status | Update is not exposed to AT | role="status" | Announcement after add | Implemented |
| Delivery information | Focus leaves the modal | Native dialog | Tab, Escape, return | Implemented |
| Promotion code | Error lacks field relation | aria-describedby and aria-invalid | Invalid/valid code | Implemented |
| Product image | No text alternative | Concise alt attribute | Screen reader | Implemented |
VOIDLAB AccessOps
The mini-audit identifies priorities within a key customer journey. A technical remediation scope is created only after that evidence is available.