Accessibility statement for validiscan.com

Validiscan’s website, validiscan.com, aims to meet WCAG 2.2 AA. Automated tests check its pages with axe-core and test keyboard use, reflow, zoom and colour contrast; no person has tested it with a screen reader yet.

Request a free check

Last updated: 20 October 2026

On this page: 7 answers

Which standard does the site aim to meet?

Validiscan’s website aims to meet WCAG 2.2 AA, the standard Validiscan checks online shops against. This statement does not claim that the site fully meets it: automated tests find many kinds of barriers but not all, and the tests that need a person have not been done yet.

Source: Web Content Accessibility Guidelines (WCAG) 2.2, W3C

Details: what this statement claims, and what it covers

Validiscan’s website aims to meet WCAG 2.2 AA: level AA of the Web Content Accessibility Guidelines (WCAG) 2.2. That is the same standard Validiscan checks online shops against.

This statement does not claim that the site fully meets that standard. The automated tests described below find many kinds of barriers, but not all of them, and the tests that need a person have not been done yet.

The statement covers every page of validiscan.com, in each language the site is published in. It does not cover Validiscan’s application (the operator console and the customer portal), which is not in operation yet.

How is the site tested?

Every page of validiscan.com in its site map is tested automatically with axe-core and html-validate. One page of every page type, in every language, is also tested in the dark theme, at phone width, at 320 CSS pixels, with zoom, forced colours, reduced motion and JavaScript off.

Accessibility tests of validiscan.com
Test	What it checks	Pages
axe-core	The axe-core rules tagged wcag2a, wcag2aa, wcag21a, wcag21aa and wcag22aa, run through @axe-core/playwright. The test fails on any violation.	Every page in the site map, light theme, 1440 by 900 CSS pixels. One page of every page type in every language in the light and the dark theme, at 1440 by 900 and at 390 by 844 CSS pixels. The home page of every language also in both themes and at both sizes, with every question opened and the example finding stepped back to an earlier phase.
Keyboard	The header, the phone menu, the language list, the theme menu, the example finding and a disclosure can be reached and operated with the keyboard, with a visible focus indicator. The list below gives the detail.	The styleguide page, which holds the header and menus that every page shares and the parts the pages are built from. The example finding and the phone menu also on the home page; the contact pop-up on the home page and the free check page in every language
Contact form	The pop-up opens from the free-check buttons and from the free check page’s link to ask for a quote, with its title, the right subject and labelled fields; sending it empty shows an error in words under each required field; a complete form shows the confirmation, which takes focus; Escape closes it and returns focus to the link that opened it, or to the Menu button when the link was in the phone menu. axe-core finds no violation with the pop-up open, in the light and the dark theme, and nothing scrolls sideways at 320 CSS pixels or with text enlarged to 200%. Without JavaScript, the footer’s link to the contact form leads to the contact page, whose form is sent and answered with its confirmation.	The home page, the free check page and the contact page in every language. The test that sends the form without JavaScript uses the English pages
Reflow	No sideways scrolling at a width of 320 CSS pixels.	One page of every page type in every language
Zoom	A window of 1280 by 800 pixels at 400% zoom, tested as 320 by 200 CSS pixels: no sideways scrolling, and the main heading is visible. Text enlarged to 200% in a window 1280 pixels wide: no sideways scrolling.	One page of every page type in every language
Forced colours	With forced colours switched on, as in the contrast themes of Windows: the main heading is shown and nothing scrolls sideways.	One page of every page type in every language
Reduced motion	With reduced motion requested, animations and transitions are switched off. The test checks the stamp animation of the example finding on the home page and the styleguide page, and that a disclosure opens without sliding.	One page of every page type in every language
JavaScript off	The main content shows the same text with JavaScript switched off as with it on, apart from the controls that only work with JavaScript.	One page of every page type in every language
Colour contrast	Every pairing of text or interface colour with a background that the design lists, in the light and the dark theme: at least 4.5 to 1 for text, at least 3 to 1 for borders, focus indicators, parts of controls and graphics.	The colour values of both themes
Valid HTML	The HTML of each page against the HTML standard, with html-validate.	Every page
Structure and links	Exactly one main heading, no skipped heading level, the language of the page declared, and no link with a vague text such as “click here” or “read more”.	Every page in the site map
Lighthouse	An accessibility score of 100 in Lighthouse, on its mobile profile.	The home page, the “How it works” page, one platform page, one guide and one reference page

Details: which pages are tested, and where the tests run

Every page in the site map is tested automatically with axe-core and html-validate. One page of every page type, in every language, is also tested in the dark theme, at phone width, at a width of 320 CSS pixels, with zoom, with forced colours, with reduced motion and with JavaScript switched off. Each test fails if it finds a single problem.

The tests run in the Chromium browser against the built site, served locally. A version of validiscan.com is published only after its build has passed them.

What do the keyboard tests check?

The skip link is the first stop of the Tab key and moves focus to the main content.
Every control in the header can be reached with the Tab key and shows a visible focus indicator.
The theme menu opens with the Enter key or the down arrow key, closes with Escape and returns focus to its button. A theme can be chosen with the keyboard, and the choice is kept when the page is loaded again.
The phone menu opens with the Enter key and closes with Escape, and focus returns to its button.
The language list opens with the Enter key, its first link can be reached with the Tab key, and Escape returns focus to its button.
The open phone menu and the open language list close when focus leaves them with the Tab key, so the menu does not cover the element that receives focus next. The phone menu is tested for this on a guide page, at widths of 390 and 800 CSS pixels.
The button that steps the example finding through its lifecycle, on the home page and the styleguide page, can be reached with the Tab key, shows a visible focus indicator and works with the Enter key.
The contact pop-up opens with the Enter key on “Request a free check” in the header or the phone menu, and on the free check page’s link to ask for a quote. It moves focus to its first field, closes with Escape, and returns focus to the link that opened it, or to the Menu button when the link was in the phone menu.
A disclosure opens and closes with the Enter key and with the space bar.

What has not been tested yet?

No person has tested validiscan.com with a screen reader yet, and the site has not been tested with users who have disabilities. A pass through Validiscan’s manual checklist, a scan with its own scanner, and tests in browsers other than Chromium and on real phones and tablets have not been done either.

A test with a screen reader by a person
A test with users who have disabilities
A pass through Validiscan’s own manual checklist of 35 checks
A scan of the site with Validiscan’s own scanner
Browsers other than Chromium, and real phones and tablets

Details: each test not done yet, and when this statement changes

No person has tested validiscan.com with a screen reader yet, and the site has not been tested with users who have disabilities. These have not been done:

a test with a screen reader by a person, for example with NVDA on Windows or VoiceOver on a Mac or an iPhone;
a test with users who have disabilities;
a pass through Validiscan’s own manual checklist of 35 checks, which covers every WCAG 2.2 criterion that no rule tests and some that rules test only in part (the method and standards page describes it);
a scan of the site with Validiscan’s own scanner, which adds its own checks to those of axe-core;
browsers other than Chromium, such as Firefox and Safari, and real phones and tablets. The phone width in the tests is a browser window set to that size.

This statement will be updated after the screen-reader test, with what it found.

Are there known limitations?

Three limitations of validiscan.com are known: examples of Validiscan’s output, which are shown as the software produces them; tables wider than the screen, which scroll sideways inside their own frame; and documents on other websites, which Validiscan cannot change. Automated tests cannot find every barrier, so others may exist.

Examples of Validiscan’s output. The site shows real output of Validiscan’s software, such as the text of a pull request and the code changes of a fix, marked “Example data”. They are shown as the software produces them. Their links are plain text, because they lead into Validiscan’s application, which needs a login. Documents among them, such as the pull request text, are marked with their own language; on the Danish, French and Spanish pages they are in English. The example finding on the home page carries the same label, and its lines of code are shown without the indentation they share.
Wide tables. A table that is wider than the screen scrolls sideways inside its own frame. The frame can be reached with the Tab key and scrolled with the arrow keys. On narrow screens, many tables are shown as stacked rows instead.
Documents on other websites. Some links lead to documents that other organisations publish, such as laws on EUR-Lex or standards published as PDF files. Validiscan cannot change how accessible those documents are.

What automated accessibility testing can and cannot prove

What does the site depend on?

Validiscan’s website depends on HTML and CSS; JavaScript only adds conveniences, such as the theme menu and the contact form in a pop-up. Without JavaScript the pages show the same text, and the contact form still works. The site uses no accessibility overlay or widget.

Without JavaScript, the pages show the same text. Only the theme menu, the button that steps the example finding through its lifecycle on the home page and the styleguide page, “Open all details”, the filters of the reference pages, the note after a click on an email link and the contact pop-up need JavaScript, and they are not shown without it. Without JavaScript the list “On this page” does not mark the answer you are reading, and a table frame or code block that fits its column can still be reached with the Tab key. The contact form also works without JavaScript: the footer’s link to the contact form and the free check page’s link to ask for a quote then lead to the contact page, whose form is sent as an ordinary web form, and the free-check buttons lead to the free check page or open a prepared email.
Light or dark. The site follows the light or dark setting of your device. With JavaScript on, the theme menu in the header can change it for this site.
No cookies, one form. There is no cookie banner to get past. The only form is the contact form: its fields have visible labels, required fields are marked in words, and an error is shown in words under its field.

Details: what JavaScript adds

Validiscan’s website depends on HTML and CSS. JavaScript only adds conveniences: the theme menu; the step-through of the example finding on the home page and the styleguide page; the note that shows the email address after a click on an email link and, where the browser allows it, a button that copies the address; the contact form in a pop-up, which opens from the free-check buttons and from the free check page’s link to ask for a quote, and checks the fields before it sends the message; “Open all details”, the marking of the answer you are reading in the list “On this page”, and the opening of a closed disclosure that holds the section a link leads to; a smooth scroll to a section of the same page, unless reduced motion is requested; the filters of the reference pages; the Tab key passing over a table frame or code block that fits its column; and closing the phone menu and the language list with the Escape key or a click elsewhere on the page, or when focus leaves them. The site uses no accessibility overlay or widget.

How do I report a barrier?

Write to info@validiscan.com, saying which page you were on, what you tried to do and what went wrong; if you use assistive technology, naming it helps, but you do not have to. The email reaches William Quaade Rasmussen, who runs Validiscan and is responsible for validiscan.com. He reads and answers it himself.

Details: what to write, and who reads it

Write to info@validiscan.com. Say which page you were on, what you tried to do and what went wrong. If you use assistive technology, naming it helps, but you do not have to.

The email reaches William Quaade Rasmussen, who runs Validiscan and is responsible for this website. He reads and answers it himself.

When was this statement written?

This statement was first written on 6 October 2026 and last updated on 20 October 2026, after the tests above were run again on that day’s build of the site. It describes the site and its tests as they were on that date.

Sources

One source, checked for this page on 6 October 2026.

W3C 1

Web Content Accessibility Guidelines (WCAG) 2.2 · W3C · 12 December 2024 · checked 6 October 2026

Start with a free check of your shop.

Send your shop’s address. Validiscan scans it and replies with every failure the scan can prove, with the page and the code.

Request a free check

Or write to info@validiscan.com.

What the free check covers, and what it leaves out

You send: your shop’s address
Pages scanned: up to 15
You get: every failure the scan can prove, with the page and the code
On your shop: public pages only; no login, nothing bought, no forms sent
What it is not: a full audit