Accessibility

How we approach accessibility.

We target WCAG 2.1 level AA on this site and for client work. We learned to build this way on government and university work, where accessibility is part of the acceptance criteria.

Last updated: July 19, 2026

What that means in practice

Semantic, keyboard-first markup. Proper headings, landmarks (header, main, footer), and lists, so screen readers and keyboard users get a structure they can move through.
Visible focus. Interactive controls show a clear focus state so keyboard users can follow where they are on the page.
Labeled forms. Inputs have labels, grouped fields use fieldsets and legends, and decorative marks are hidden from assistive tech.
Respects reduced motion. If your system asks for reduced motion, the site honors it. Animations are gated behind that preference, and content shows without JavaScript.
Readable contrast & type. Color pairings target the WCAG AA contrast ratio, and text scales with your browser settings.

How we prove it

Every page clears five separate checks before it ships.

It runs as a gate, so this site cannot be published with a failure in any of them. Five engines because the first three passed a page that still had two AA failures, and the fifth exists because the first four judge CSS, which cannot see a photograph sitting behind the words.

A harness plants deliberate failures and confirms that each of the five goes red.

axe-core: WCAG 2.1 A + AA rules; clean
HTML_CodeSniffer: an independent implementation, via pa11y; clean
a11y-dom: ours: keyboard reachability and focus contrast; clean
a11y-contrast: ours: contrast measured from rendered pixels, not from CSS; clean
Lighthouse: accessibility score floor; pass

Standard: WCAG 2.1 AA and Section 508, as on the university and government work where we learned to build to them.

Check it on this site.

Three places to confirm this on our own site.

The entity graph: View source on any page here. The JSON-LD blocks describe the studio, the founder, the site, and the services, linked to each other by @id instead of repeated. On an article you also get its BlogPosting; on the FAQ, the questions.
The dateline matches the markup: The date printed on an article and the datePublished in its JSON-LD come from one field, so the two match.
A file written for machines: llms.txt, a plain-text map of this site.

Read our llms.txt. Two of the five engines above are ones we wrote ourselves, because the off-the-shelf checkers do not test keyboard behavior or contrast measured from rendered pixels.

Why we don't use accessibility overlays

You'll see tools that promise instant compliance from a single line of script: an accessibility “overlay” or widget that sits on top of a finished site. We don't use them, and we'd steer you away from them. Disabled users and accessibility experts have publicly warned against overlays, because a script that rewrites the page as it loads can get in the way of the screen readers people already rely on.

We fix the source of the problem. An overlay is a script that tries to patch your site while it loads. We change the actual code or CMS so the fix can be tested at the source and maintained with the rest of the site.
Automated tools only reach so far. Roughly a third of the WCAG checkpoints can be verified by software. The rest takes keyboard and screen-reader testing and human judgment.
Other benefits. The same work that opens your site to disabled visitors also reads better to search engines, widens your audience, and lowers your legal risk.

Where we know we fall short

We do not claim perfection. We test against automated checks and by keyboard, but automated tools miss things and we're a small shop. Third-party content we embed (maps, video, forms) can carry its own gaps. If you hit a barrier, tell us and we will fix it.

Found a barrier? Tell us.

Email hello@plantpoweredpixels.com with the page and what got in your way. We prioritize accessibility reports and usually reply within a couple of business days.