Open standards

DNSSEC

Testtoegankelijkheid and WCAG Toolkit: complies. The domains are signed, and a resolver that validates DNSSEC accepts the answers.

wcagtoolkit.eu: explain. This domain has no website of its own. Both addresses redirect with a 308 to https://wcagtoolkit.com/, and that domain is signed. No content is served from wcagtoolkit.eu.

Portal: does not comply. The portal is a subdomain of properaccess.nl, and that domain is not signed. Turning on DNSSEC affects the whole domain, including the Proper Access website and email. That is outside this round and is planned for week 48 of 2026.

HTTPS and HSTS

Both: comply. A visit over HTTP is redirected to HTTPS. Every response over HTTPS carries Strict-Transport-Security: max-age=31536000; includeSubDomains: your browser opens the site only over HTTPS for a year, subdomains included.

TLS

Both: comply. The servers speak TLS 1.2 and TLS 1.3 and refuse older versions. According to the website test at internet.nl the connection is sufficiently secure. A CAA record, which states which party may issue certificates, is missing. Internet.nl recommends it, but it does not count towards the score. Our DNS provider Strato does not offer this record. All certificates for the site come from Let's Encrypt.

IPv6 and IPv4

Both: comply. All domains can be reached over IPv4 and IPv6.

security.txt

Both: comply. /.well-known/security.txt tells you how to report a vulnerability, following RFC 9116. The file points to our vulnerability disclosure policy. You get a response within 5 working days.

OpenAPI

Testtoegankelijkheid and WCAG Toolkit: complies for /api/licentie/token. At this route the Radar extension exchanges a licence key for a proof. It is the only route that can be called from any origin. There is a description in OpenAPI 3.1, and a test checks that the description stays equal to the code.

Explain for the other 15 routes. They are the back end of forms on our own site, of sign-in, and of account management with a session on our site. One route is called by Mollie after a payment, and Mollie sets that contract. None of these routes exchanges data with another organisation.

Portal: explain. The three connections under /api/ only link Proper Access systems, each with its own token.

REST API design rules

Both: explain. The rules apply to an API you open up to others, and we do not. Among other things they ask for a version number in the path, such as /v1/. Changing the path of the licence route breaks every extension that is already installed. If a paid scan API is added, it will follow the rules from the start.

ISO 8601 for date and time

Testtoegankelijkheid and WCAG Toolkit: complies. Dates in the structured data, the sitemap, security.txt and <time datetime> are in ISO 8601.

Explain for one field. In the response of /api/licentie/token, expiresAt is a Unix time in seconds. It is the expiry time from the signed proof, in the same way as in a JWT (RFC 7519). Converting it breaks the extensions that are already installed. The field graceUntil in the same response is ISO 8601.

Portal: complies. Times are in ISO 8601 with a time zone. A date in another format returns a clear error message (422).

UTF-8

Both: comply. HTML, text files and the Radar scripts are served with charset=utf-8 in the header. JSON is always UTF-8 under RFC 8259. The email we send is UTF-8 as well.

URI

Both: comply. Every page has one fixed address. Alias domains, HTTP and old addresses redirect to it with a 308. No path contains a session id.

JSON

Both: comply. The API routes respond with application/json and valid JSON, also on an error.

HTML

Testtoegankelijkheid and WCAG Toolkit: complies. We ran 34 pages through the Nu Html Checker: the public pages on both domains, the sign-in screen and the error page. Also the portal after sign-in, the Radar panel and the saved Radar report. No page had an error. In the portal after sign-in the checker gives two messages about the ALTCHA widget, which writes its own markup in the browser.

Portal: complies. 98 pages measured: the public ones and every page per role.

CSS

Both: comply. The validator reports properties it does not know: @property and margin-trim on the site, paint-order in the portal. That is valid CSS from newer specifications. The validator found no error in our code.

SVG

Both: comply. The illustrations, logos and icons gave no messages.

Digitoegankelijk (EN 301 549 with WCAG 2.1)

Testtoegankelijkheid and WCAG Toolkit: complies. An auditor from Proper Access evaluated wcagtoolkit.com and WCAG Radar in August 2026 following WCAG-EM, against WCAG 2.2 level A and AA. That includes the WCAG 2.1 criteria EN 301 549 refers to. The audit produced 23 findings. At the retest on 22 August 2026 none were open. A retest checks the findings from the audit again and is not a second full audit. testtoegankelijkheid.nl runs the same code with Dutch texts. The report: retest wcagtoolkit.com, August 2026. See also the accessibility statement.

You can choose another party for the audit. We will then send along the sample we already prepared following WCAG-EM.

Portal: partly tested. We tested 97 pages automatically with axe-core 4.10.3, with the rules for WCAG 2.0, 2.1 and 2.2 level A and AA, at 1280 and at 320 pixels wide. axe-core found no errors.

An automated test finds part of the errors. Keyboard, focus and zoom have not been tested in the portal yet. That is why we do not say the portal meets WCAG. That takes a manual audit.