Checked 8/31/2026 · https://a11yglass.com
No critical barriers in the checked HTML · 1 point to follow up.
How is the score formed? (100 starting points)
| {n} CSS rule{nPlural} with possibly too low text contrast | -7 |
| Result | 93 / 100 |
Perceivable
{n} CSS rule{nPlural} with possibly too low text contrast
Required: 4.5:1 (normal) or 3:1 (large text). With an “assumed page background” the actual background could not be determined reliably — check in the browser if in doubt. Found among others: {examples}
.grade
This is what you should do: Darken the text colour or lighten the background until the relevant minimum value is reached. Never use colour as the only distinguishing feature.
Already handled correctly
- A skip link to the content exists
- A <main> landmark exists
Next steps
- {n} CSS rule{nPlural} with possibly too low text contrast. Darken the text colour or lighten the background until the relevant minimum value is reached. Never use colour as the only distinguishing feature.
Weekly re-scan, JS-rendered, email on new barriers — coming soon.
Create an accessibility statement →
Method & limits
On 8/31/2026 the HTML that a11yglass.com delivers on a first visit without login was checked, plus up to four linked CSS files from the same domain. Checked: colour contrast (from CSS), text alternatives, form labelling, names of controls, heading structure, page title and page language, zoom lock, duplicate ids, positive tabindex values, landmarks.
Not checked: anything that arises via JavaScript, keyboard operability, visible focus, focus order, screen-reader announcement, content behind login, subpages. The automated test finds roughly 20–35% of WCAG breaches — the rest needs a manual check. A snapshot, not a legal decision.
Overlay widgets (accessibility buttons that switch contrast or font size) do not make a site conformant — the barriers found have to be fixed in the source code. Why overlays don't help