Adam Tibi

Accessibility

I built this site to conform to the W3C Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA.

Date of claim
Guidelines
Web Content Accessibility Guidelines (WCAG) 2.2
Conformance level
Level AA
Pages covered
All pages on adamtibi.com.
Technologies relied upon

HTML and CSS. I use JavaScript in a few places to improve the experience, but the site does not depend on it. With JavaScript switched off, every page still reads and anything JavaScript would have enhanced falls back to plain HTML. JavaScript is therefore not relied upon for conformance.

Tested manually

Automated tools can check roughly thirty of the fifty-five success criteria that apply at Level AA. The rest need human judgment. A tool can tell me that an image has alt text, for example, but it cannot reliably tell me whether that alt text is actually useful. The same applies to things such as whether a heading describes what follows or whether a focus indicator is obvious enough to see.

So I checked those myself using the following.

Tested automatically

I also have automated accessibility tests running against the built site before anything is published. If one of these tests fails, the release fails with it rather than producing a warning for me to look at later.

  • axe-core is the main accessibility scanner I use. It runs against every page in both light and dark themes at 320, 768 and 1500 pixels wide. I also enable the WCAG 2.2 rules that axe ships with but leaves switched off by default.
  • Playwright drives that matrix, twelve combinations in total. It also runs tests I wrote specifically for things a scanner cannot reliably check, including the skip link, focus visibility, focus not being obscured, reflow, text spacing and consistent help.
  • pa11y-ci makes a second independent pass over every page using both axe and HTML_CodeSniffer. I use this because I don’t want the whole accessibility check to depend on one scanning engine.
  • Nu Html Checker validates the HTML and CSS of every built page. Invalid markup may look perfectly fine in a browser while giving assistive technology something very different to work with.
  • Lighthouse CI runs as another check, and its accessibility category has to score 100.
  • lychee checks every internal link and anchor target. This also catches broken skip links and links to sections that no longer exist.
  • I wrote a contrast audit specifically for this site to cover non-text contrast, including the contrast used by the footer accessibility badge.
  • I also wrote a content lint that requires alt text and a caption on every image and rejects link text that would mean nothing when read out of context.

I have tested this site manually, NVDA included, but there is an obvious problem with me being the tester: I already know the content.

Knowing what a page says is not the same as meeting it cold, and that makes me a poor test subject.

So if you find an accessibility problem here, or anything else that does not work for you, please tell me on LinkedIn. I would rather hear about it than not.