Accessibility

Accessibility built into the work.

We target WCAG 2.1 level AA on this site and make it the baseline for client work. Accessibility is not an add-on. It is part of design, implementation, testing, and maintenance, informed by government and university work where it is part of the acceptance criteria.

Last updated: July 19, 2026

What that means in practice

Semantic, keyboard-first markup. Real headings, landmarks (header, main, footer), and lists, so screen readers and keyboard users get a structure they can move through, not a wall of divs.
Visible focus. Interactive controls show a clear focus state so keyboard users can follow where they are on the page.
Labeled forms. Inputs have real 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 rather than a promise: this site cannot merge 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. We would rather find that here than in a complaint.

An engine that cannot fail looks exactly like an engine that passes, so a harness plants deliberate failures and checks that every one of the five goes red. A check nobody has ever seen fail is not evidence.

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. The bar behind university and government work, which is where we learned to build to it.

The accessible version is the machine-readable one.

The structure that makes a site work for a screen reader is the same structure that makes it legible to a language model. Semantic markup, a real heading order, described images, content that arrives in the HTML instead of being assembled by script after the fact. We build that because of the accessibility standard. Machine readability comes along with it.

That is also why we do not sell you a separate product for it. There is an industry forming around “optimizing” sites for AI answers, and the technical half of that pitch is real work we already do. The rest of it is a glossary page per keyword, a post a day, and seeding reference entries for organizations that do not warrant one. We are not going to do that to your site, and nobody selling it can show you the attribution data to justify it.

Check it on this site, right now.

Everything above is a claim about how we build. Here is where to confirm we do it to our own site before you take our word on yours.

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 they cannot disagree. That is the whole reason to generate markup from the page's own data rather than hand-write a second copy of it.
A file written for machines: llms.txt, the plain-text map of this site a language model can read without parsing markup.

Read our llms.txt. The engines listed further up this page are the other half of it: two of the five are ones we wrote ourselves, because the off-the-shelf checkers do not catch what a keyboard and a rendered pixel catch.

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, not the symptom. 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 real keyboard and screen-reader testing and human judgment, and that's where we spend the time.
Accessibility is value, not a tax. The same work that opens your site to disabled visitors also reads better to search engines, widens your audience, and lowers your legal risk. We build for the upside, not out of fear.

Where we know we fall short

No site is ever “done” on accessibility, and we'd rather be honest than 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, that's a bug to us. Tell us and we'll 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.