Fictional Full Audit — Northmere Outfitters

£595 service example · 1 October 2026 · bounded technical accessibility review

1. Result and priorities

Seven distinct findings were confirmed within the agreed demonstration: three High and four Moderate. Fix keyboard access to Add to basket, readable checkout errors and visible focus on the checkout link first. Then address the disappearing email cue, product image alternative, low-contrast delivery note and small quantity controls. The local basket is pre-seeded so checkout can still be inspected; this does not make the inaccessible product action acceptable.

Severity is our prioritisation of the demonstrated user impact, not the automated tool’s severity label and not a legal finding. High means a key action or orientation/recovery step is blocked or substantially impaired. Moderate means a material information or input barrier that should be corrected but has a narrower impact in this fixture. No Critical issue is asserted. Multiple affected nodes, viewports or criteria in one underlying defect are not counted as separate findings.

2. What was tested

The sample uses the same invented Northmere Outfitters scenario as the £195 Scope Report: a UK clothing seller serving consumers in Great Britain and Germany, with 16 persons employed, €3.2 million turnover and €2.6 million balance-sheet total. These are fictional assumptions, not verified business facts. This technical report makes no further legal determination.

3. Automated results and interpretation

There were 24 saved axe runs: six original templates at each of two widths (12), followed by the six corrected templates at each width (12). Each original set detected three distinct rule types: color-contrast on the delivery note, image-alt on the product image and target-size on two cart buttons. That is four violating nodes per original viewport set, not four different findings and not a count of every barrier on the site. The other four findings were established through browser interaction and inspection rather than an axe violation.

The 12 fixed-template scans reported zero violations for the selected rules. The cart color-contrast incomplete result for the minus glyph persisted in both widths. It remains a review item, not a pass or an eighth confirmed failure. Absence of axe violations cannot clear keyboard operation, error understanding, visible labels, focus appearance or all WCAG requirements.

4. Findings, reproduction and remedies

F01 — Add to basket is skipped by keyboard navigation

High · 2.1.1 Keyboard — Level A. On product.html, Add to basket is a bare div with a pointer click handler. With the Size selector focused, an actual CUA Tab moved directly to View basket. Shift+Tab returned to Size. The Add control was skipped in both directions. A separate pointer click updated the local status to “Added one demo jacket to the basket.” No equivalent keyboard add action was found in the bounded product page.

1. Open product.html and focus Size.
2. Press Tab: focus goes to View basket rather than Add to basket. Press Shift+Tab: it returns to Size.
3. Compare with a pointer click on Add to basket: the status updates. Do not infer a successful order; this is a local demonstration.

Impact and fix. A keyboard user cannot perform the product-page add action. Use a native button with a suitable name and preserve the status update. Avoid repairing only appearance or adding a pointer-only role. Retest recorded: in fixed/product.html, Tab from Size focused Add to basket and Enter updated the same local status. Evidence: manual.json entries P01/P04 and P01-fixed; product-desktop.jpg. Criterion guidance.

F02 — Email purpose disappears when a value is entered

Moderate · 3.3.2 Labels or Instructions — Level A. The checkout email input has zero associated labels and uses the placeholder “Demo email” as its sole visible purpose cue. After typing, the placeholder disappears and the occupied field has no persistent visible label. This can make reviewing or correcting an entered value harder. The placeholder can supply an accessible name in this browser; no absence-of-accessible-name failure is asserted.

1. Open checkout.html and observe the email placeholder.
2. Enter an invented value and compare the populated field with its initial state: its only visible purpose cue disappears.
3. Inspect the label association: the email input’s labels collection has length zero.

Fix and retest. Add a persistent visible label associated with the email input; retain autocomplete and use separate hint text if a format example is helpful. In fixed/checkout.html the email input had one associated label and the visible label remained available independently of the value. Evidence: manual.json P02/P03 and P02/P03-fixed. Criterion guidance.

F03 — Form errors have red borders but no explanation

High · 3.3.1 Error Identification — Level A; 1.4.1 Use of Color — Level A. Submitting the empty checkout highlighted four fields with red borders: name, email, address and postcode. The errors region remained empty and the review screen stayed hidden. No field had aria-invalid or an associated error description. Submitting a malformed email with the other fields filled highlighted only email, again without explanatory text. Color was the sole error cue.

1. Open checkout.html and activate the local review button with the four text fields empty.
2. Observe the four red borders and absence of a readable error explanation.
3. Fill the other fields with invented values, supply a malformed email and activate review again. The email is highlighted but its error is still not explained.

Impact and fix. A customer who cannot distinguish the border color, or cannot infer what needs correction, lacks actionable recovery information. Provide a text error identifying each field and explaining the problem. Programmatically associate it with the input, expose invalid state, preserve entered values and give a practical way to reach errors. An error summary is a proposed solution, not a mandatory implementation dictated by these criteria.

Retest recorded: fixed empty submission displayed “Check 4 fields” with four named text errors, corresponding aria-invalid=true and aria-describedby links; focus moved to the error summary. The email message gives an example format. Original checkout observation: valid invented inputs in original checkout.html reached a local review heading; Edit returned focus to the name field. This occurred before the fixed empty-state retest and is not a fixed valid-state retest. Fixed malformed-email recovery was not separately recorded in manual.json and is not claimed here. Evidence: manual.json P02/P03, P02/P03-fixed and checkout-review; checkout-empty.jpg. Error identification; Use of color.

F04 — Meaningful product image has no text alternative

Moderate · 1.1.1 Non-text Content — Level A. The product page visibly shows a navy jacket with a hood and front pockets, at a rendered 400×360.20 CSS pixels. This product-detail image conveys information beyond a decorative flourish. Its alt attribute was absent and no alternative naming attribute was present. Axe detected the same image-alt violation at both widths. The report does not predict or claim what a screen reader spoke.

1. Open product.html and inspect the jacket image in context.
2. Inspect the image’s alternative-text attributes; alt is missing.
3. Compare the visible product detail with the text alternative available from the image: none is supplied.

Fix and retest. Provide a concise alternative describing useful product information and ensure the wider product description carries essential details. Empty alt would be appropriate only if the image were truly redundant or decorative in its context. The fixed image was visibly inspected and its alt read as “Navy hooded jacket with two zipped pockets and a front zip”. Fixed scans no longer reported image-alt. This supports the local repair; no screen-reader announcement is claimed. Evidence: manual.json original and fixed-product observations; both original scan files; axe-fixed.json; product-desktop.jpg. Criterion guidance.

F05 — Delivery note is too faint

Moderate · 1.4.3 Contrast (Minimum) — Level AA. Collection.html’s delivery note renders as #999999 text on #ffffff at 16px, font weight 400. Relative luminance gives approximately 2.849:1; axe reports 2.84:1. This normal-size text requires 4.5:1. The text is not a logo, disabled control or decorative image, so those exceptions do not apply.

1. Open collection.html and inspect the delivery note.
2. Read its computed foreground, background, font size and weight.
3. Calculate the luminance ratio for #999999 on white and compare with the normal-text threshold.

Fix and retest. Use a darker foreground meeting at least 4.5:1 on the actual background and check all note states. Do not treat a larger screenshot or browser zoom as a contrast repair. The fixed note remained 16px, weight 400, with foreground rgb(25,50,60), equivalent to #19323c. Its paragraph background was transparent over a white body. Fixed scans no longer reported the delivery-note color-contrast violation. Evidence: manual.json original and fixed-collection measurements; color-contrast nodes in both original scan files; axe-fixed.json; collection-contrast.jpg. Criterion guidance.

F06 — Quantity controls are undersized and too close

Moderate · 2.5.8 Target Size (Minimum) — Level AA. The cart’s decrease and increase buttons each measured 16×16 CSS pixels. Their horizontal gap is 2px and horizontal centre-to-centre distance is 18px; a 24px-diameter circle centred on each overlaps the other circle. Both nodes were flagged by axe at both widths.

Exception check. These are standalone authored quantity buttons, not inline sentence links or unmodified user-agent controls. No equivalent adequately sized quantity control is present on this page, and no essential-size or legal-layout reason is asserted. The spacing exception does not apply because the circles intersect. The fact that the buttons can be operated with a keyboard does not satisfy the pointer-target requirement.

1. Open cart.html and measure the decrease/increase bounding rectangles.
2. Compare 16×16 against the 24×24 CSS-pixel minimum, then assess the spacing exception using centred 24px circles.
3. Check for an equivalent same-page quantity control and the other exceptions before recording the failure.

Fix and retest. Increase the clickable area and preserve clear labels. Fixed controls measured approximately 48.16×50.39 CSS pixels and no target-size violation appeared in fixed scans. Retest pointer activation and adjacent layout after changes. Evidence: manual.json P06/P07 and P06/P07-fixed; both original scans and axe-fixed.json. Criterion and exceptions.

F07 — Checkout link has no visible focus indicator

High · 2.4.7 Focus Visible — Level AA. In cart.html, after a pointer action on Increase, an actual CUA Tab moved focus to Continue to checkout. It was the active element, but its computed outline style was none and box-shadow was none; the focused screenshot showed no visible focus indicator. This concerns keyboard orientation on a key onward action, not whether clicking the link works.

1. Open cart.html, activate Increase and then press Tab.
2. Confirm that Continue to checkout is focused and inspect its rendered appearance.
3. Compare with the fixed reference’s visible indicator; do not infer focus visibility solely from document.activeElement.

Fix and retest. Preserve a visible keyboard-focus style on every interactive state; do not suppress the outline without a replacement. In fixed/cart.html, the same link had a solid 3px orange outline with 4px offset and a visible focused screenshot. No claim about a different, untested device’s focus rendering is made. Evidence: manual.json P06/P07 and P06/P07-fixed; cart-focused.jpg and cart-fixed-focus.jpg. Criterion guidance.

Selected captured browser states

5. Other checks and unresolved coverage

6. Developer action and acceptance plan

1. Repair F01 with a native product-action button; repeat actual Tab, Shift+Tab and Enter checks from Size and verify the status update.
2. Repair F03 with readable field errors and associations; repeat empty, malformed, corrected and resubmitted forms. Preserve values and confirm recovery focus.
3. Repair F07 by restoring visible keyboard focus; inspect the rendered indicator on the onward checkout link and other controls.
4. Repair F02, F04, F05 and F06 in the shared components: persistent labels, useful image alternatives, measured color pairs and pointer target areas.
5. Repeat automation and the same browser interaction reproduction steps at agreed widths. Resolve incomplete results with documented judgement; do not silently turn them into passes.
6. For a production commission, extend the agreed review to its actual payment, identity, supplier, language and assistive-technology requirements using safe test access. Record what remains outside scope.

The corrected reference illustrates repairs; it does not eliminate the need to verify a client implementation. No remediation time or fee beyond the published audit offer is inferred from this synthetic example. Implementation, production deployment, legal advice, screen-reader sessions and ongoing monitoring are not included unless explicitly agreed.

7. Evidence, sources and service limits

The evidence set consists of three JSON scan collections, manual.json and five fixture screenshots. Files were captured through a supported CUA in-app browser session; the saved results and source were inspected. The frozen fixture manifest contains 21 file hashes and 613,362 bytes. Browser test evidence and the local fixture are retained with this demonstration; no account or customer payload is included. Report-specific hashes and the review receipt are retained separately rather than implying a history of client work.

Primary technical sources were accessed on 1 October 2026: the WCAG 2.2 Recommendation and the W3C Understanding pages linked for each finding. Understanding documents explain criteria but are informative; the Recommendation supplies the normative requirements. Official axe-core source describes the tool; version 4.13.0 was obtained from its public package and the package integrity verified. No paid access, production call or browser-profile change was required.

The £595 Full Audit offers technical review of agreed named pages/templates, journeys, states and viewports with confirmed WCAG 2.2 Level A/AA findings, impact, reproduction and remediation guidance. Exact scope, access and delivery are agreed before payment. “Full” names that service; it does not mean every URL, every combination, every browser or certification. This sample deliberately uses a bounded representative fixture and discloses its incomplete coverage.

The £195 Scope Report answers the preceding applicability and prioritisation question for one named public website/checkout; its published promise is three working days after complete inputs. It is not this technical audit. Neither service promises a legal outcome, certification, prevented claims or conversion improvement. A real report must record the testing environment, tools and checks performed, including any untested coverage.

8. Appendix — handover and tender summary

Fictional one-page handover/tender summary · 1 October 2026. Northmere Outfitters is invented. This summary can accompany the example report; it is not a real customer reference, tender assurance or certificate.

Review boundary. Six local representative templates: home, about, collection, product, cart and checkout. Original and corrected references were scanned at 1280×720 and 320×720 CSS pixels using axe-core 4.13.0: 24 scans. Recorded browser interaction checks through supported browser control (CUA) covered product keyboard/pointer comparison, image context, labels, empty and malformed inputs, original local valid review/Edit, quantity targets and visible focus. User agent reported Chromium 154.0.0.0 on Mac Intel; full build/OS version were not established.

Result. Seven original-fixture findings: three High (F01 keyboard add action, F03 readable/color-independent errors, F07 visible checkout-link focus) and four Moderate (F02 persistent email label, F04 image alternative, F05 note contrast, F06 quantity targets). These counts describe underlying defects, not all site barriers. See the full report for exact WCAG levels, exceptions, reproduction and evidence.

Action. Repair the three High purchase/recovery/orientation barriers first, then the four Moderate issues. Repeat the same reproduction steps at agreed widths; retain original evidence and attach the new release/version. The fixed reference had zero selected-rule violations, with recorded repairs for the seven issues. A minus-glyph contrast incomplete persists. Original valid review/Edit is not proof of a fixed valid-state retest.

Limits. No screen reader, disabled-user evaluation, physical mobile, other browser, actual 400% zoom or text-spacing override was tested. No authentication, payment, order, receipt, production availability or exhaustive all-criteria conformance was tested. Fixed malformed-email and valid-review states were not separately retained. Neither this summary nor the repair reference establishes production conformance or a legal outcome.

Production handover needed. The real client supplies its production URL/release, agreed templates/states, component owners, developer and retest owner, safe payment/access boundary, additional required browsers/assistive technologies, contact route and delivery date. A change is closed only with matching retest evidence. The £595 Full Audit covers agreed technical work; the £195 Scope Report separately addresses applicability and next actions, with its own three-working-day complete-intake promise.

9. Appendix — draft accessibility statement

Draft subject and assessment

Northmere Outfitters is an invented clothing retailer. This draft relates only to the local demonstration’s home, about, collection, product, basket and checkout templates, as reviewed on 1 October 2026. Testing used axe-core 4.13.0 at 1280×720 and 320×720 CSS pixels and recorded browser interaction checks in an in-app Chromium surface whose user agent reported version 154.0.0.0. No screen reader was run.

Known barriers in the reviewed original version

• F01 — Add to basket cannot be reached through the tested Tab sequence.
• F02 — Email entry relies on a placeholder that disappears after input, leaving no persistent visible label.
• F03 — Empty or malformed checkout input is identified with red borders but no readable error explanation.
• F04 — A meaningful product image has no text alternative.
• F05 — Delivery-note contrast is below the normal-text threshold.
• F06 — The two quantity buttons are too small and close together for the minimum target-size/spacing requirement.
• F07 — The focused Continue to checkout link has no visible indicator in the tested original version.

These are seven underlying issues, prioritised as three High and four Moderate in the accompanying report. The separate corrected reference demonstrates repairs and had no selected-rule violations in its scans. A cart minus-glyph contrast incomplete still needs judgement. This reference does not prove that any production version has been repaired or that all requirements are met.

Assessment limits and improvement work

The review did not include screen readers, disabled-user testing, physical mobile devices, other browsers, actual 400% browser zoom, text-spacing overrides, production payment/authentication, a real order or a complete criterion-by-criterion conformance assessment. Valid local review/Edit were checked on the original checkout; fixed valid-review and malformed-email states were not separately retained. Planned work is to correct the documented barriers, retest the same actions, resolve incomplete results and agree additional coverage before making any broader statement. No remediation dates are invented.

Feedback and support route

There is no functional public feedback or alternative-purchase service for this fictional business. A real publisher must supply and test an accessible contact route, identify who receives accessibility reports, explain the information customers should provide and state how assistance is handled. Do not copy an invented contact address, promise a response time or suggest that the local demo can take an order.

Before adapting this draft for a real website

1. Confirm the legal operator, real website URL, actual reviewed release/date, markets and agreed coverage.
2. Replace local findings with the real assessment and retest status, including unresolved barriers and genuinely scheduled improvements.
3. Add a verified accessible feedback/support route and any alternative formats or assistance actually offered.
4. Confirm which service-information and statement requirements apply with appropriate advice; this draft is not a statutory checklist or legal sign-off.
5. Approve truthful wording, record the preparation/review date and keep the statement updated when the service changes.