Accessibility statement

What this statement covers

• coverground.eu — this information and marketing site;
• app.coverground.eu — the route builder and the account and billing pages for subscribers;
• public route pages and embeds — the pages visitors use to walk a published route, the overview page on which an organisation shows its routes, the embeddable route cards and the WordPress block;
• documents — the route as a PDF and the invoice PDF.

Internal administration screens are out of scope; they are not publicly reachable.

Which standard we hold to

We hold to WCAG 2.2, level AA, in line with EN 301 549. Coverground is a commercial service in the EU; the European Accessibility Act applies to us as an e-commerce service.

Conformance status

All three surfaces partially conform. On 7 September 2026 we reviewed every public page; what that review found and what is still open is below.

• coverground.eu — a small number of issues, all at level AA and none of them blocking.
• Public route pages — this is where the real work is. Following a route without being able to see is possible, but poorer than with sight, and it is spelled out below.
• The route builder — a small number of known issues, none of which makes a task impossible.

What we do

• Generated routes are step-free by default: no steps, usable with a wheelchair or a pram. Since 7 September 2026 that is enforced — a route cannot be published while no step-free path has been found between its points.
• Nor can a route be published while an image has no text alternative, or a link has no working address. If an author later adds a photo to a route that is already published, it does not pass that gate: such a photo is left out of the route page until it is described, and the author is told about it.
• Alongside the map, the route page puts the whole route in text: the list of route points, the story at each one, and spoken guidance as you walk. What that text does not do is under the limitations below.
• The route builder is keyboard operable: every map action has a keyboard route through the waypoint panel, including placing and moving points through an address search field.
• The interface follows the system settings for forced colors, reduced motion and increased contrast.
• Colour combinations are contrast-checked and the measured values are documented beside the design tokens in the code. The build re-measures part of that on every change; the check does not yet cover every colour pair.
• The interface is available in Dutch and English, with each page's language marked up for assistive software. The changelog exists in English only.
• Accessibility is reviewed before delivery on every interface change, with specialist tooling, as a standing part of our development process.

Known limitations

Public route pages

• The map has no equivalent in text, and distances are straight-line (WCAG 1.1.1, 1.3.1). The spoken guidance gives the straight-line distance to the next point, while the route length at the top is the distance along the path. Stand on the wrong side of a canal and "250 metres to go" is true as the crow flies and not as a walk. The list of points with bearings is not a description of the route itself: no text says which streets you follow. Someone who cannot look at the map is therefore missing information a sighted visitor has.
• Route point names are sometimes spoken in the wrong language (WCAG 3.1.2). Walking an English-language route with a Dutch interface, the point names sit inside a passage marked as Dutch, so a screen reader pronounces them with a Dutch voice.
• The spoken guidance repeats itself, and the "at 3 o'clock" idiom is not always reliable. On arrival the distance just given is sometimes restated, and during a sustained weak GPS signal one sentence repeats. The clock direction is also based on where the top of the phone points; turn the device to read the screen and the direction named changes while you are facing the same way.
• Recovering from denied location access does not work equally well on every device (WCAG 3.3.3). Deny access once you are already on the map and all you get is the fact that it was denied — the instructions for turning it back on are not shown in that case. Where they do appear, they point at a padlock in the address bar; an iPhone has no such icon, and on Android the block is usually in the phone's own settings. If access is withdrawn mid-walk, the page returns to the permission step and you lose your reading position. Following the route without location remains possible throughout.
• The map controls sit at the top of the screen, out of thumb reach while walking. Not a blocker, but awkward — and the button that opens and closes the text panel, the most used on the page, is smaller than the others.
• On narrow screens an element you jump to with the keyboard can end up behind the fixed bar at the bottom (WCAG 2.4.11). At an enlarged default font there is also a screen width at which the button for collapsing the panel is visible but does nothing (WCAG 4.1.2).
• Two links to the same website can end up with the same name (WCAG 2.4.4). When the author leaves a link label empty we derive a name from the web address alone, so two empty labels pointing at one site produce two identical links.

The embeddable route card

• At 200% text size the card is clipped (WCAG 1.4.4, 1.4.12). The frame's height is fixed and its content cannot scroll inside it, so the foot band — holding the card's only control — is the first thing to go.
• Several cards on one page share a name (WCAG 4.1.2), which makes them indistinguishable in a list of frames.

The route builder

• After renaming a waypoint, the list of alternative segments can keep naming the old one (WCAG 4.1.2). Workaround: reload the builder page.
• Smaller issues, recorded and open. A change to the system's reduced-motion setting during a session is missed by one drag animation (reloading applies it); some status messages — the changing route length, and the notice that a route path could not be generated during an import — are not yet passed to screen readers; and when publishing is blocked because an image lacks a description, only the first image is named and the field itself is not marked. None of these prevents completing a task.

This site

• The price switch does not announce what it changes (WCAG 4.1.3). Switching between monthly and yearly on the subscription page changes four prices with no announcement to a screen reader.
• In the changelog the date does not travel with its heading (WCAG 2.4.6). The date sits before the heading it belongs to, so it is missing from a list of headings.
• The link to the changelog from a Dutch page does not say it is in English, and the feed is named differently in two places.

The WordPress block

• Every card carries the same button text (WCAG 2.4.4). With several route cards on one page, every button reads "Follow this route" without naming the route.
• The card's text exists in Dutch and English only (WCAG 3.1.2). On a site in another language the card gets English text, correctly marked up as English but not in that site's language.
• A long route name makes the card clip on a narrow screen, and a focus ring can be cut off at the card's edge (WCAG 1.4.10, 2.4.7).
• The WordPress admin screen is further behind: several issues are open there around focus, duplicate names, and one colour combination that misses our own contrast target. That screen is seen by a site's administrators, not by their visitors.

Documents

• The route PDF carries the interface language rather than the route's (WCAG 3.1.1), and its fixed headings are in English only.
• On an invoice, the subscription's description is in English, even on an otherwise Dutch invoice (WCAG 3.1.2).

The route builder is a complex authoring environment, and the route page is used outdoors, on a phone, in motion. Neither has yet been tested with people who use assistive software daily. That is the largest open item on this list, and until it happens everything above rests on our own research. If you run into something, we want to hear about it — right now that report is the most valuable thing we can get.

Feedback

Email hi@coverground.eu. We answer in English and Dutch, normally within five working days. If something on this platform is not accessible to you, tell us which page and what happened; we treat such reports as defects.

Enforcement

If you believe Coverground treats you unequally on the grounds of disability and we do not resolve it, you can submit a complaint to the College voor de Rechten van de Mens (Netherlands Institute for Human Rights), which assesses complaints under the Dutch Equal Treatment Act on Disability or Chronic Illness (Wgbh/cz). Supervision of the accessibility requirements for e-commerce services under the Dutch implementation of the European Accessibility Act lies with the Netherlands Authority for Consumers and Markets (ACM).

How this statement was prepared

Prepared on 24 August 2026 and updated on 9 September 2026, after a full review of every public page on 7 September. The basis is internal research using specialist tooling: automated checks, contrast measurement, and source code review. It does not yet include testing with people who use assistive software daily, nor screen-reader testing on real devices. Findings are tracked in our internal backlog with WCAG references. We review this statement every six months, or earlier when a release changes one of the covered surfaces.