Sample report

Three findings written up exactly as they appear in a Perceivio audit report: what is wrong, who it stops, how to make it happen again, and how to fix it.

Product
Example Store web checkout (invented)
Standard
WCAG 2.2, Level A and AA
Tested with
Chrome 130 and Firefox 131 on Windows 11, NVDA 2024.4, keyboard only; Safari on iOS 18 with VoiceOver
Shown here
3 sample findings: 1 critical, 1 serious, 1 moderate

Finding PCV-001

Keyboard focus is trapped inside the payment method menu at checkout

Severity
Critical
WCAG criterion
2.1.2 No Keyboard Trap, Level A
Where
Checkout, step 3 of 3, “Payment method” menu
Found in
All tested browsers, with and without a screen reader

What is wrong

Once the payment method menu is opened from the keyboard, there is no keyboard way out of it. Tab and Shift+Tab only cycle between the four payment options, and Escape does nothing. The only way to close the menu is to click outside it with a mouse.

Who it affects

Anyone who cannot use a mouse: keyboard users, screen reader users, switch and voice control users. They cannot reach the “Place order” button, so they cannot complete a purchase at all. This blocks the main task of the site, which is why it is rated critical.

Steps to reproduce

  1. Add any item to the basket and go to /checkout.
  2. Fill in the delivery details and continue to step 3, “Payment”.
  3. Put the mouse aside. Press Tab until focus reaches the “Payment method” button (the first control after the order summary).
  4. Press Enter. The menu opens with four options: Card, UPI, Net banking, Cash on delivery.
  5. Press Tab. Focus moves to Card. Keep pressing Tab: focus goes to UPI, Net banking, Cash on delivery, then back to Card.
  6. Press Escape. The menu stays open and focus does not move.
  7. Press Shift+Tab repeatedly. Focus keeps cycling inside the menu and never reaches the page.

Expected

Escape closes the menu and returns focus to the “Payment method” button. Tab from the last option leaves the menu and moves to the next control, so “Place order” can be reached.

Actual

Focus is held inside the menu. With NVDA running, the options are announced again and again with no way out. The order cannot be placed without a mouse.

How to fix

Remove the script that sends focus from the last option back to the first: a menu should not hold Tab. Close the menu on Escape and return focus to the button that opened it. Keep aria-expanded on the button in step with the menu. A native <select> would avoid the problem entirely.

menu.addEventListener("keydown", (e) => {
  if (e.key === "Escape") {
    closeMenu();
    button.setAttribute("aria-expanded", "false");
    button.focus();
  }
});
// Delete the handler that moves focus from the last option to the first.

Retest: Open. We repeat every step above after your fix ships and mark it passed only when the steps no longer reproduce the issue.

The open payment menu: focus cycles through the four options and never leaves, so “Place order” is out of reach.

Finding PCV-002

Product prices are too faint to read: contrast is 2.8:1

Severity
Serious
WCAG criterion
1.4.3 Contrast (Minimum), Level AA
Where
Product cards on category, search and home pages
Found in
All browsers and devices: it is a colour value in the stylesheet

What is wrong

The price on every product card is set in light grey #8A94A0 on the card’s off-white background #F4F5F7. That pair measures 2.8:1. Prices are 16px regular text, which needs at least 4.5:1.

Who it affects

People with low vision, older shoppers, anyone with colour vision deficiency, and anyone reading a phone outdoors. The price is the piece of information a buyer most needs, and for these users it is hard or impossible to read without zooming in on each card.

Steps to reproduce

  1. Open any category page, for example /category/shoes.
  2. Right-click the price on the first product card (for example “₹2,499”) and choose Inspect.
  3. In the Styles panel, note the text colour #8A94A0 on .product-card and the background #F4F5F7.
  4. Enter both values in a contrast checker, such as the Colour Contrast Analyser or the contrast readout in Chrome DevTools.
  5. Read the result: 2.8:1, below the 4.5:1 required for text of this size.

Expected

Price text reaches at least 4.5:1 against its background, so it can be read at normal size.

Actual

Price text measures 2.8:1. The same grey is used for the “was” price and the delivery note on the card, which fail too.

How to fix

Change the price colour token to #5B6470, which measures 5.5:1 on #F4F5F7 and keeps the same grey family. Because the colour comes from one token, the fix is one line and corrects every card at once.

:root {
  --price-text: #5B6470; /* was #8A94A0: 2.8:1, now 5.5:1 on #F4F5F7 */
}

Retest: Open. We re-measure the price, the “was” price and the delivery note on every card type, in light and dark themes if you have both.

The same product card before and after: price text #8A94A0 at 2.8:1, then #5B6470 at 5.5:1, both on #F4F5F7.

Finding PCV-003

The site footer is not exposed as a landmark to screen readers

Severity
Moderate
WCAG criterion
1.3.1 Info and Relationships, Level A
Where
Site footer, every page
Found in
NVDA with Chrome and Firefox, VoiceOver on iOS

What is wrong

The footer is built from a plain <div class="footer">. It looks like a footer, but nothing in the code says so, so screen readers do not list it as a region the user can jump to.

Who it affects

Screen reader users. The footer holds the contact details, returns policy and help links. To reach them, a screen reader user has to read or tab through the whole page instead of jumping straight there. It slows them down on every page but does not block a task, so it is rated moderate.

Steps to reproduce

  1. Start NVDA and open the home page in Chrome.
  2. Press NVDA+F7 to open the Elements list, then choose “Landmarks”.
  3. Note the landmarks listed: banner, navigation, main. No content information (footer) landmark is listed.
  4. Close the list. Press D repeatedly to move through landmarks. After “main”, NVDA wraps back to the top of the page.
  5. Repeat on a product page and on checkout. The result is the same on every page.

Expected

A “content information” landmark appears in the landmarks list and can be reached with D, taking the user straight to the footer links.

Actual

Only banner, navigation and main are listed. The footer can be reached only by reading through the whole page.

How to fix

Use the <footer> element for the site footer and place it directly inside <body>, outside <main>. In that position browsers expose it as the content information landmark with no extra ARIA.

<!-- Before -->
<div class="footer"> … </div>

<!-- After: a direct child of <body>, after </main> -->
<footer class="footer"> … </footer>

Retest: Open. We check the landmarks list again on the home, product and checkout templates.

The page as a screen reader’s landmarks list sees it: header, navigation and main are found, the footer is not.

What a full report adds

Cover and scope
Pages and screens tested, standard and version, methods, tools and assistive technology versions.
Summary
Counts by severity, the risk in plain words, and the order we suggest fixing things in.
Every finding
Each issue written up in the format shown above, with screenshots and the code location.
Retest
Passed or still open for each issue, after your team ships the fixes.

Get findings like these

One page, tested free, reported like this.