Accessibility
Accessibility on this site.
I take accessibility seriously in my work, which means I am also responsible for it on my own site. This page is the honest version: what I test, what I do not, and what to do if you find a problem.
What I test.
Every page on this site is scanned with a multi-lane audit on each significant change. Open issues are tracked and fixed. Findings from the automated and AI-assisted passes are reviewed by a human (me) before any change ships.
The audit covers, at WCAG 2.1 Level A and AA:
- Image alt text, both presence and quality (SC 1.1.1)
- Programmatic structure, landmarks, and ARIA correctness (SC 1.3.1, 2.4.1, 4.1.2)
- Form field labels and autocomplete (SC 1.3.5, 3.3.2)
- Color contrast for text (SC 1.4.3)
- Text-spacing tolerance (SC 1.4.12)
- Use of color and graphics contrast in forms, charts, and non-decorative graphics, surfaced for human review (SC 1.4.1, 1.4.11)
- Keyboard support where it can be automated (SC 2.1.1)
- Page titles, both presence and descriptiveness across the site (SC 2.4.2)
- Link purpose in context, both presence and meaningfulness (SC 2.4.4)
- Multiple ways to find a page across the site (SC 2.4.5)
- Headings and labels, both empty-heading detection and descriptiveness (SC 2.4.6)
- Page language declaration (SC 3.1.1)
- Consistent identification of the same destination across pages (SC 3.2.4)
- Markup validity (SC 4.1.1)
- Accessible-name quality for non-link controls (SC 4.1.2)
- Whether the skip link actually works: its target exists, it reveals itself on focus, and it comes first in the tab order (SC 2.4.1)
- Focus order, walked by actually pressing Tab and recording where focus lands (SC 2.4.3)
- Focus visibility, confirmed by comparing the rendered pixels focused against unfocused, never by reading the stylesheet (SC 2.4.7)
- Meaningful sequence, surfaced where the observed focus order disagrees with the visual order (SC 1.3.2)
Beyond the WCAG 2.1 AA success criteria, the automated scan also runs axe-core’s best-practice rules. These catch problems that are not strict WCAG failures but still get in a real person’s way: a heading order that skips levels, a page with no landmark regions for screen-reader navigation, and similar gaps. I report these separately and label them “best practice,” not as a success criterion, so you can always tell a conformance requirement from a recommendation.
What I do not test.
- I do not run real assistive-technology user testing. I do not have screen-reader users, voice-control users, or switch users on call. That kind of testing is the only way to confirm a real person can use the site. If you use assistive tech and run into something, please tell me (see below).
- I do not test the site across every browser; the automated scan runs in Chromium via Playwright. The scan is not a substitute for testing in actual assistive-technology software.
- These specific WCAG criteria are out of scope of my automated coverage: Reflow (SC 1.4.10) and Content on Hover or Focus (SC 1.4.13). Viewport-resize behavior and hover and focus popups need a human.
- The keyboard walk sees the page as it loads. Closed menus, modals, and accordions are invisible to it unless the interaction is scripted, and that is the largest gap in the lane.
- Reaching a control is not the same as operating it. Whether Enter activates it, whether Escape closes it, and whether focus returns somewhere sensible afterward are all still manual.
- Keyboard traps (SC 2.1.2) are not tested. A walk would stall inside a trap rather than identify one, so a trap shows up as a truncated run rather than as a finding.
- I do not claim 100% accessibility. Nobody can.
The standard I aim for.
WCAG 2.1 Level AA. A handful of Level AAA items are met where it is reasonable to do so; I do not claim full AAA conformance.
Third-party content.
This site currently does not embed third-party players or widgets. If that changes (a YouTube embed, a calendar embed, anything similar), automated checks will sometimes flag issues inside that third party’s markup that I cannot reach. When that happens, I disclose it on the affected page rather than pretend.
How to report a barrier.
The quickest way is to say hello. Please include the page URL, what you were trying to do, what assistive technology you were using (if any), and what happened. I usually reply within a couple of days. If something is blocking you completely, say so at the top of your note; I treat that as a priority.
Last reviewed.
2026-06-06