RampCheck

Accessibility audit

www.w3.org · 15 September 2026 · 6 pages tested

Sample report: a real scan of the W3C’s deliberately inaccessible demonstration website (w3.org/WAI/demos/bad). Your report has the same structure, for your own site.

Result

5/100

Critical risk

10 distinct issues found across 354 elements.

Estimated remediation effort: 5 developer-days

What this audit does and does not cover

This is an automated audit. Automated testing reliably detects roughly 30–40% of WCAG success criteria — the machine-checkable ones such as missing alternative text, colour contrast, form labelling and ARIA validity.

It cannot judge whether alternative text is meaningful, whether focus order is logical, whether a page works with a real screen reader, or whether content is understandable. Those require manual testing with assistive technology.

A high score is not a certificate of conformance, and this document is not legal advice. It is an engineering work list: everything it reports is a genuine, reproducible defect worth fixing, and fixing these is a necessary — not sufficient — step toward EN 301 549 / WCAG 2.2 AA conformance.

Start here: 4 quick wins

High-consequence problems with a low fix cost. These give the largest reduction in risk per hour spent.

  1. Images have no text alternative Blocker < 1h
    155 elements on 5 pages · likely a single template fix
  2. Links have no discernible text Blocker < 1h
    26 elements on 5 pages · likely a single template fix
  3. Select menus have no accessible name Blocker < 1h
    6 elements on 5 pages · likely a single template fix
  4. The page does not declare its language Serious < 1h
    5 elements on 5 pages · likely a single template fix

Findings, in priority order

Ranked by consequence to users, how much of the site is affected, and how many elements are involved.

1 Images have no text alternative

Blocker Quick win · < 1h Site-wide template issue WCAG A

155 elements affected on 5 pages · 1.1.1 Non-text Content

Who this affects

Blind and low-vision visitors using a screen reader, and anyone on a slow connection where images fail to load.

Why it matters

The screen reader announces nothing, or reads out the raw filename. If the image is a product photo, a logo or a button, that information is simply gone. This is the most cited issue in accessibility complaints because it is trivially detectable by regulators.

How to fix it

Add an alt attribute to every <img>. Describe the purpose, not the picture: alt="Add to basket", not alt="shopping cart icon". If an image is purely decorative, use alt="" (empty, not missing) so assistive tech skips it.

Examples found

  • /WAI/demos/bad/before/home.html img[src$="border_left_top.gif"]
    <img src="./img/border_left_top.gif" width="10px" height="10px">
  • /WAI/demos/bad/before/home.html img[src$="border_top.gif"]
    <img src="./img/border_top.gif" height="10px">
  • /WAI/demos/bad/before/home.html img[src$="border_right_top.gif"]
    <img src="./img/border_right_top.gif" width="10px" height="10px">
  • /WAI/demos/bad/before/home.html img[src$="border_left.gif"]
    <img src="./img/border_left.gif" width="10px">

Technical reference: https://dequeuniversity.com/rules/axe/4.13/image-alt?application=axeAPI

2 Links have no discernible text

Blocker Quick win · < 1h Site-wide template issue WCAG A

26 elements affected on 5 pages · 2.4.4 Link Purpose (In Context), 4.1.2 Name, Role, Value

Who this affects

Screen reader users, who navigate by pulling up a list of all links on a page.

Why it matters

An unlabelled link is announced as just "link", so that list becomes unusable. Icon-only social links and image links inside cards are the usual cause.

How to fix it

Give the link real text, or an aria-label when the visual design must stay icon-only. Avoid "click here" and "read more" repeated across a page, as they are meaningless out of context.

Examples found

  • /WAI/demos/bad/before/home.html #home > a[onfocus="blur();"]
    <a href="javascript:location.href='home.html';" onfocus="blur();"><img name="nav_home" src="./img/nav_home.gif" width="88" height="27" hspace="15" border="0px"></a>
  • /WAI/demos/bad/before/home.html #news > a[onfocus="blur();"]
    <a href="javascript:location.href='news.html';" onfocus="blur();"><img src="./img/nav_news.gif" name="nav_news" width="90" height="21" hspace="12" border="0px"></a>
  • /WAI/demos/bad/before/home.html #tickets > a[onfocus="blur();"]
    <a href="javascript:location.href='tickets.html';" onfocus="blur();"><img name="nav_facts" src="./img/nav_facts.gif" width="105" height="23" hspace="9" border="0px"></a>
  • /WAI/demos/bad/before/home.html #survey > a[onfocus="blur();"]
    <a href="javascript:location.href='survey.html';" onfocus="blur();"><img src="./img/nav_survey.gif" name="nav_survey" width="107" height="32" hspace="8" border="0px"></a>

Technical reference: https://dequeuniversity.com/rules/axe/4.13/link-name?application=axeAPI

3 Select menus have no accessible name

Blocker Quick win · < 1h Site-wide template issue WCAG A

6 elements affected on 5 pages · 4.1.2 Name, Role, Value

Who this affects

Screen reader users filling in dropdowns such as country, size or quantity.

Why it matters

The user hears the options but never learns what the dropdown is for, which commonly breaks checkout and booking flows.

How to fix it

Associate a <label> with the <select>, or add aria-label.

Examples found

  • /WAI/demos/bad/before/home.html select
    <select onchange="location.href = this.value;">
  • /WAI/demos/bad/before/annotated/home.html select
    <select onchange="location.href = this.value;">
  • /WAI/demos/bad/before/news.html select
    <select onchange="location.href = this.value;">
  • /WAI/demos/bad/before/tickets.html select
    <select onchange="location.href = this.value;">

Technical reference: https://dequeuniversity.com/rules/axe/4.13/select-name?application=axeAPI

4 Form fields have no associated label

Blocker Moderate · 1–4h WCAG A

11 elements affected on 1 page · 4.1.2 Name, Role, Value

Who this affects

Screen reader users, voice-control users, and people with cognitive differences who rely on persistent labels.

Why it matters

Without a programmatic label the user hears "edit text, blank" and has no idea what to type. Placeholder text is not a substitute: it disappears the moment typing starts, and usually fails contrast too. Unlabelled checkout and contact fields are a direct revenue loss.

How to fix it

Use <label for="id"> bound to the input id, or wrap the input in the label. Keep the visible label; do not rely on placeholder alone.

Examples found

  • /WAI/demos/bad/before/survey.html input[value="1"]
    <input class="align" type="radio" name="res" value="1">
  • /WAI/demos/bad/before/survey.html input[value="2"]
    <input class="align" type="radio" name="res" value="2">
  • /WAI/demos/bad/before/survey.html input[value="3"]
    <input class="align" type="radio" name="res" value="3">
  • /WAI/demos/bad/before/survey.html input[value="4"]
    <input class="align" type="radio" name="res" value="4">

Technical reference: https://dequeuniversity.com/rules/axe/4.13/label?application=axeAPI

5 The page does not declare its language

Serious Quick win · < 1h Site-wide template issue WCAG A

5 elements affected on 5 pages · 3.1.1 Language of Page

Who this affects

Screen reader users, especially in multilingual countries.

Why it matters

Without a language declaration the screen reader guesses, often reading Dutch or German content with an English voice, which is close to unintelligible. A one-line fix and a very visible failure in an audit.

How to fix it

Set <html lang="nl"> (or the correct code) on every page, including error pages.

Examples found

  • /WAI/demos/bad/before/home.html html
    <html>
  • /WAI/demos/bad/before/annotated/home.html html
    <html>
  • /WAI/demos/bad/before/news.html html
    <html>
  • /WAI/demos/bad/before/tickets.html html
    <html>

Technical reference: https://dequeuniversity.com/rules/axe/4.13/html-has-lang?application=axeAPI

6 Text does not have enough contrast against its background

Serious Moderate · 1–4h WCAG AA

12 elements affected on 3 pages · 1.4.3 Contrast (Minimum)

Who this affects

The largest affected group by far: everyone with low vision, colour vision deficiency, or age-related sight loss. Also anyone reading on a phone in daylight.

Why it matters

Around 1 in 12 men has some colour vision deficiency, and contrast is the most common failure on the entire web. It is also the easiest thing for a complainant to demonstrate with a screenshot. Light-grey placeholder text and pale brand colours on white are the usual culprits.

How to fix it

Body text needs a contrast ratio of at least 4.5:1 against its background; large text (18pt+, or 14pt+ bold) needs 3:1. Usually this means darkening one brand colour in your CSS variables, which fixes every instance at once.

Examples found

  • /WAI/demos/bad/before/home.html tr[height="25px"]:nth-child(2) > td[bgcolor="#A9B8BF"][width="150px"] > font[color="#41545D"][size="2"] > b
    <b>Free Penguins</b>
  • /WAI/demos/bad/before/home.html tr[height="25px"]:nth-child(7) > td[bgcolor="#A9B8BF"][width="150px"] > font[color="#41545D"][size="2"] > b
    <b>More City Parks</b>
  • /WAI/demos/bad/before/annotated/home.html tr[height="25px"]:nth-child(2) > td[bgcolor="#A9B8BF"][width="150px"] > font[color="#41545D"][size="2"] > b
    <b>Free Penguins</b>
  • /WAI/demos/bad/before/annotated/home.html tr[height="25px"]:nth-child(7) > td[bgcolor="#A9B8BF"][width="150px"] > font[color="#41545D"][size="2"] > b
    <b>More City Parks</b>

Technical reference: https://dequeuniversity.com/rules/axe/4.13/color-contrast?application=axeAPI

7 Content sits outside any landmark region

Moderate Moderate · 1–4h Site-wide template issue Best practice

115 elements affected on 6 pages

Who this affects

Screen reader users navigating by region.

Why it matters

Orphaned content is hard to find when navigating structurally, and suggests the page is built from generic divs rather than semantic HTML.

How to fix it

Use <header>, <nav>, <main>, <footer> and <aside> so all content falls inside a landmark.

Examples found

  • /WAI/demos/bad/before/home.html #logos
    <p id="logos"><a href="https://www.w3.org/" title="W3C Home"><img alt="W3C logo" src="../img/w3c.png" height="48" width="72"></a><a href="https://www.w3.org/WAI/" title="WAI Home"><img alt="Web Accessibility Initiative (WAI) logo" src="../img/wai.png" height="48"></a></p>
  • /WAI/demos/bad/before/home.html h1
    <h1><span class="subhead">Inaccessible Home Page</span><span class="hidden"> -</span> Before and After Demonstration</h1>
  • /WAI/demos/bad/before/home.html .subline
    <p class="subline">Improving a Web site using Web Content Accessibility Guidelines (WCAG) 2.0</p>
  • /WAI/demos/bad/before/home.html #mnav
    <div id="mnav" class="inaccessible">

Technical reference: https://dequeuniversity.com/rules/axe/4.13/region?application=axeAPI

8 Touch targets are too small

Moderate Moderate · 1–4h WCAG AA

17 elements affected on 6 pages · 2.5.8 Target Size (Minimum)

Who this affects

Users with motor impairments or tremor, and anyone using a phone one-handed.

Why it matters

Small or tightly packed controls cause mis-taps. Added in WCAG 2.2, so many sites that passed against 2.1 now fail.

How to fix it

Make interactive targets at least 24x24 CSS pixels, or leave equivalent spacing around them.

Examples found

  • /WAI/demos/bad/before/home.html .inaccessible > .report[href$="home.html"]
    <a href="./reports/home.html" class="report"><span class="hidden">Inaccessible Home Page </span> Report</a>
  • /WAI/demos/bad/before/home.html .accessible > .report[href$="home.html"]
    <a href="../after/reports/home.html" class="report"><span class="hidden">Accessible Home Page </span> Report</a>
  • /WAI/demos/bad/before/reports/home.html .inaccessible > .page[href$="home.html"]
    <a href="../home.html" class="page"><span class="hidden">Inaccessible </span>Home Page</a>
  • /WAI/demos/bad/before/reports/home.html .accessible > .page[href$="home.html"]
    <a href="../../after/home.html" class="page"><span class="hidden">Accessible </span>Home Page</a>

Technical reference: https://dequeuniversity.com/rules/axe/4.13/target-size?application=axeAPI

9 The page has no main landmark

Moderate Quick win · < 1h Site-wide template issue Best practice

6 elements affected on 6 pages

Who this affects

Screen reader users who jump straight to the main content region.

Why it matters

Without a <main> element, users must tab through the entire header and navigation on every single page.

How to fix it

Wrap the primary content of each page in a single <main> element.

Examples found

  • /WAI/demos/bad/before/home.html html
    <html>
  • /WAI/demos/bad/before/reports/home.html html
    <html lang="en">
  • /WAI/demos/bad/before/annotated/home.html html
    <html>
  • /WAI/demos/bad/before/news.html html
    <html>

Technical reference: https://dequeuniversity.com/rules/axe/4.13/landmark-one-main?application=axeAPI

10 Table header cells are empty

Moderate Quick win · < 1h Best practice

1 element affected on 1 page

Who this affects

Screen reader users reading tables.

Why it matters

An empty header gives the cells in that column or row no context when they are read out.

How to fix it

Give every <th> meaningful text. If the cell is purely decorative, make it a <td> instead.

Examples found

  • /WAI/demos/bad/before/tickets.html th
    <th style="padding-bottom:10px;"><img src="./img/headline_ticket_prices.gif" border="0"></th>

Technical reference: https://dequeuniversity.com/rules/axe/4.13/empty-table-header?application=axeAPI

Pages tested

Pages included in this audit and the number of distinct issue types found on each
PageTitleIssue types
/WAI/demos/bad/before/home.html Welcome to CityLights! [Inaccessible Home Page] 8
/WAI/demos/bad/before/reports/home.html Inaccessible Home Page Report 3
/WAI/demos/bad/before/annotated/home.html Welcome to CityLights! [Annotated Inaccessible Home Page] 8
/WAI/demos/bad/before/news.html Welcome to CityLights! [Inaccessible News Page] 7
/WAI/demos/bad/before/tickets.html Welcome to CityLights! [Inaccessible Tickets Page] 9
/WAI/demos/bad/before/survey.html Welcome to CityLights! [Inaccessible Survey Page] 8

Draft accessibility statement

The European Accessibility Act requires businesses providing covered services to publish information on how their service meets the accessibility requirements. Below is a draft built from your results. Complete the parts in [square brackets], review it, and publish it on your website, for example linked from the footer.

This draft is not legal advice. An automated audit alone cannot demonstrate full conformance, so the draft never claims it.

Accessibility statement

[Company name] is committed to making www.w3.org accessible in accordance with the European Accessibility Act (Directive (EU) 2019/882) as implemented in [country].

1. Description of the service

[Describe your service in plain words, for example: “On this website, consumers can choose, order and pay for products.”]

2. How the service works

[Describe the main steps a customer takes, for example: product search, basket, checkout, payment, customer account, contact.]

3. How the service meets the accessibility requirements

We follow the harmonised European standard EN 301 549, which is based on the Web Content Accessibility Guidelines (WCAG) at conformance level AA.

Compliance status: this website is partially compliant. An automated test of 6 pages on 15 September 2026 found the following barriers, which we are working to remove by [date]:

  • Images have no text alternative (WCAG 1.1.1)
  • Links have no discernible text (WCAG 2.4.4, 4.1.2)
  • Select menus have no accessible name (WCAG 4.1.2)
  • Form fields have no associated label (WCAG 4.1.2)
  • The page does not declare its language (WCAG 3.1.1)
  • Text does not have enough contrast against its background (WCAG 1.4.3)
  • Touch targets are too small (WCAG 2.5.8)

[Add the measures you have already taken, for example keyboard operability, text alternatives, sufficient contrast.]

4. Feedback and contact

Have you found a barrier on our website? Please tell us: [email address], [phone number].

5. Market surveillance authority

[Name and address of the competent market surveillance authority in your country.]

Prepared on 15 September 2026. [Last reviewed on …]

Method

Each page was loaded in a real Chromium browser at 1366×900, allowed to finish client-side rendering, and tested with axe-core, the open-source engine used by most professional accessibility tooling. Rules were run for WCAG 2.0, 2.1 and 2.2 at levels A and AA — the levels referenced by EN 301 549, the harmonised European standard underpinning the European Accessibility Act.

Findings are deduplicated across pages: an element repeated in a shared header or footer is reported once, with the number of pages it affects, rather than once per page. Issues marked site-wide appear at the same location on most tested pages and can usually be resolved with a single change to a shared template or component.

Scan reference: 2026-09-15T14:13:12.899Z · 6 of 18 discovered URLs tested · robots.txt directives respected.