View Full Executive Developer By page
Accessibility statement
Export EARL CSV Issues
Skip to report
Accessibility audit report

Digital accessibility audit

Prepared for Riverside Books (sample) · riversidebooks.example

10 July 20265 key page templates + 2 flows testedJoe Gullo
EAA WCAG 2.2 AA EN 301 549
Overall score 74 / 100 Close — a few blockers to clear
How to read this Critical — blocks people now Serious Moderate Minor Dotted terms open the glossary
Executive summary

What I found, in plain language

Riverside Books is well-built and most of your pages are already in good shape — clear headings, a working keyboard path, and a readable layout. Five issues, though, stop some people from getting through checkout and finding books.

The most urgent: the add-to-cart and quantity controls have no name a screen reader can read, so a blind customer can't tell what they do. Fix that first — it directly blocks a sale. The rest are quick, well-understood fixes your developer can clear in a day or two.

Score by principle

WCAG groups every requirement under four principles — content must be Perceivable, Operable, Understandable and Robust.

Perceivable 68% · 2 issues
Operable 71% · 1 issue
Understandable 82% · 1 issue
Robust 60% · 1 issue
Scope

Pages tested

The pages covered by this audit.

Conformance target: WCAG 2.2 Level AA

Tested with (accessibility support baseline)

  • Chrome 127 · NVDA 2024.2 · Windows 11
  • Safari 17 · VoiceOver · macOS 14
  • Chrome (Android) · TalkBack 14 · Android 14

How the sample was chosen: A representative sample chosen per WCAG-EM Step 3: the key entry pages plus the complete purchase process, selected to cover each distinct page type (home, listing, product detail, cart/checkout, contact form) and the interactive components they share (navigation, search, forms, add-to-cart).

Where to start

Fix these first

The highest-impact issues, quickest wins first. Clear these and your score climbs the fastest.

  1. Critical
    Cart buttons have no accessible name Cart & checkout
    Effort: low
  2. Serious
    Navigation and footer text is too low-contrast Site-wide / all pages
    Effort: low
  3. Serious
    Contact and checkout fields have no labels Contact
    Effort: medium
  4. Moderate
    Book cover images have no text alternative Browse books
    Effort: low
  5. Moderate
    No visible focus indicator when tabbing Site-wide / all pages
    Effort: low

Findings & fixes

Grouped by page, most affected first.

Cart & checkout 1

Critical A-01

Cart buttons have no accessible name

WCAG 4.1.2 · A
In plain terms

The Add to cart, + and − controls are icon-only buttons with no text a screen reader can announce. A blind customer using a screen reader hears only "button, button, button" and can't tell which one adds the book or changes the quantity — so they can't complete a purchase.

Screen reader users; voice-control users who say a control's name
The fix 
- <button class="add"><svg aria-hidden="true">…</svg></button>
+ <button class="add" aria-label="Add The Lighthouse to cart">
+   <svg aria-hidden="true">…</svg>
+ </button>
Impact: high Effort: low

Site-wide / all pages 2

Serious A-02

Navigation and footer text is too low-contrast

WCAG 1.4.3 · AA
In plain terms

The gray menu and footer links sit at about 2.9:1 against white — below the 4.5:1 minimum. People with low vision, or anyone on a phone in sunlight, struggle to read them.

Low-vision users; anyone in bright light
The fix 
- color: #9aa4b2; /* 2.9:1 */
+ color: #4b5563; /* 7.0:1 — passes AA */
Impact: medium Effort: low
Moderate A-05

No visible focus indicator when tabbing

WCAG 2.4.7 · AA
In plain terms

A custom stylesheet removes the browser's focus outline (outline: none) without adding one back. Keyboard users can't see which link or button they're on, so they get lost moving through the page.

Keyboard-only users; people with motor disabilities
The fix 
- :focus { outline: none; }
+ :focus-visible { outline: 3px solid #294557; outline-offset: 2px; }
Impact: medium Effort: low

Contact 1

Serious A-03

Contact and checkout fields have no labels

WCAG 3.3.2 · A
In plain terms

Several inputs use only placeholder text as their label. Placeholders vanish once you start typing, and most screen readers don't treat them as a real label — so people don't know what to enter, and can't check what they've typed.

Screen reader users; people with memory or attention difficulties
The fix 
- <input type="email" placeholder="Email">
+ <label for="email">Email</label>
+ <input id="email" type="email" autocomplete="email">
Impact: high Effort: medium

Browse books 1

Moderate A-04

Book cover images have no text alternative

WCAG 1.1.1 · A
In plain terms

Cover images on the browse and detail pages have empty alt text. A screen reader skips them, so a blind shopper browsing by cover gets an unlabeled list of "image, image, image".

Screen reader users
The fix 
- <img src="lighthouse.jpg" alt="">
+ <img src="lighthouse.jpg" alt="The Lighthouse by V. Marsh — cover">
Impact: low Effort: low
Credit where it's due

What's already working well

15 of 20 checks passed · 75%

Screen readers & content

  • The page is organized so people can jump between sections
  • Content is read aloud in a sensible order
  • Links make sense on their own (not just “click here”)

Stage 3 · Forms and interactive parts

  • Errors are explained in words, not just color
  • Error messages say how to fix the problem
  • Updates like “added to cart” are read aloud to screen-reader users

Stage 4 · Using the site with a keyboard

  • Everything can be used with a keyboard alone
  • Keyboard users never get stuck in one place
  • Pressing Tab moves through the page in a logical order
  • A “skip to content” link lets people jump past the menu
  • Buttons and links are big enough to tap easily

Color, media & display

  • The page states which language it's written in
  • Buttons, icons and form outlines are easy to see
  • The page still works zoomed in or on a narrow phone
  • The cookie / consent banner can be used by keyboard and screen reader
Method

How this audit was conducted

This audit followed my standard 10-working-day method, evaluated against WCAG 2.2 Level AA using the W3C WCAG-EM methodology: a defined scope, a representative page sample, and a pass/fail outcome for each success criterion. 70 of 72 checks applied to this site's scope; the remaining checks cover features this site doesn't have.

See my full audit methodology →

Stage 1 · Getting started & first scan

  • Held the kickoff call and agreed the work in writing Pass
  • Agreed which pages to test Pass
  • Agreed the accessibility standard to test against Pass
  • Agreed the test environment — the browsers, assistive technology and operating systems the site will be checked with Pass
  • Ran automated checks across the sample pages Pass
  • Reviewed the automated results by hand and removed false alarms Pass

Stage 2 · Testing with screen readers

Stage 3 · Forms and interactive parts

Stage 4 · Using the site with a keyboard

Stage 5 · Video, language, color and cookie banner

Stage 6 · Matching to the standard & your statement

  • Matched every issue to the official accessibility rule it breaks Pass
  • Rated each issue by how much it affects people Pass
  • Wrote a clear fix for every issue Pass
  • Drafted your accessibility statement, ready to publish Pass

Stage 7 · Wrap-up & handover

  • Put the report together and checked it over Pass
  • Booked the wrap-up call with your team Pass
  • Handed over the report and accessibility statement Pass

Want an audit like this for your site?

This is a sample. Book a free 15-minute EAA check and I'll walk you through what a real audit of your site would cover, and which tier it falls into.

Book a free 15-minute EAA check