bekee gibson

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, UI components, and content on hover (SC 1.4.3, 1.4.11, 1.4.13)
  • Text-spacing tolerance (SC 1.4.12)
  • Use of color in forms and non-decorative graphics, surfaced for human review (SC 1.4.1)
  • 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)

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), Focus Order (SC 2.4.3), and Focus Visible (SC 2.4.7, partially). Viewport-resize behavior, dynamic keyboard sequences, and visual focus confirmation need a human.
  • 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