Adopting some a11y adjustments
Stefan Johansson 3 min read
We have rolled out a small set of accessibility tweaks to the site, and we wanted to take a moment to explain what changed, why it matters, and what we are signing up to going forward.
What is a11y, anyway?
“a11y” is shorthand for accessibility — the eleven letters between the a and the y. It is the practice of designing and building software so that as many people as possible can use it well, regardless of how they read, navigate, or interact with the web.
That includes people using screen readers, keyboard-only navigation, high-contrast or zoomed displays, voice control, switch devices, or simply reading on a phone in bright sunlight. Good accessibility is not a niche concern — it is what makes a site feel solid and considered for everyone.
What is WCAG?
The Web Content Accessibility Guidelines (WCAG) are the internationally recognized standard for web accessibility, published by the W3C. They are organized around four principles: content should be perceivable, operable, understandable, and robust.
WCAG defines three conformance levels — A, AA, and AAA. Level AA is the practical bar that most public websites and many regulatory frameworks aim for, and it is the level we target here.
What we changed
In the most recent update we focused on links inside body text. Previously, paragraph links were distinguished from surrounding text only by color, and only picked up an underline on hover. That fails WCAG 1.4.1 (Use of Color), because anyone who cannot reliably perceive the color difference has no way to tell a link from regular prose.
The fix was straightforward: links inside text now carry an underline by default, not just on hover. Navigation in the site header and footer still appears without underlines, because those are clearly identifiable link groups rather than links embedded in sentences — the rule applies where it should and steps aside where it would only add noise.
We also keep dedicated high-contrast light and dark themes that thicken the underline and adjust link colors further, for readers who need stronger visual differentiation.
Our commitment
We run automated accessibility checks (using axe-core, against WCAG 2.0 and 2.1 levels A and AA) as part of our end-to-end test suite, so regressions are caught before they ship. Automated checks cannot catch everything, but they keep us honest about the obvious problems: contrast, alt text, heading order, form labels, and the link issue described above.
Beyond the automation, we are committing to:
- Designing with keyboard navigation and screen readers in mind from the start, not as an afterthought.
- Maintaining sufficient color contrast across every theme we ship.
- Writing meaningful alt text and link text — never “click here”.
- Preserving a logical heading structure so the document outline makes sense without styling.
- Listening when readers tell us something is hard to use, and treating those reports as bugs.
Accessibility is a moving target, and we will not always get it right on the first pass. But it is a goal we take seriously, because the whole point of publishing openly is for the work to actually reach people. If you run into something on the site that is awkward, broken, or unreadable for you, please let us know.