Skip to content
Let's Talk

Paper Crane / accessibility

We build for the people using screen readers, keyboards, and assistive tech, then test, document the results, and stand behind what we ship.

( Scroll to explore ↓ )

Note

An accessible site reaches more people and lowers your risk

More than a quarter of Canadians, roughly 8 million people, live with a disability. Build for them and you widen your audience, cut your legal exposure, and ship a better product.

Detail

Accessibility that survives launch day

We build on a component system where accessibility is solved once, inside each component, then reused across every page. Your team can add pages and edit content later without quietly breaking things. WCAG 2.2 AA is our default on scoped builds, and every one is backed by a real audit.

What we check for

Keyboard operation

Every menu, form, and control works without a mouse, in a logical order, with focus you can always see.

Screen readers

We test with NVDA so the page makes sense read aloud, not just seen on screen.

Colour and contrast

Text and interface elements meet contrast targets, and colour is never the only thing carrying meaning.

Zoom and reflow

Content stays usable at 200 percent zoom and on small screens, with nothing cut off or overlapping.

Forms and errors

Labels, hints, and error messages that assistive tech can read and that people can act on.

Motion and animation

Movement respects reduced-motion settings, so animation never gets in the way or causes discomfort.

Detail

Tested by tools and by hand

axe-core through Playwright and Lighthouse run during the build, catching regressions early. Then comes the manual work: keyboard, screen reader, contrast, zoom and reflow, and forms. Every scoped build ends with a dated audit report mapped to WCAG 2.2, which also feeds a VPAT when a client needs one for procurement.

What you walk away with

Accessibility is part of the build, and it keeps working after we hand over the keys.

An accessible build

Built to WCAG 2.2 AA from the components up, not retrofitted at the end.

A public accessibility statement

Plain-language copy for your footer that tells visitors what to expect and how to reach you.

A VPAT on request

A conformance report your procurement and enterprise buyers can review, backed by a real audit.

Ongoing fixes

If someone reports a barrier, we handle it under your support retainer.

Questions we get asked

Which standard do you build to?

WCAG 2.2 Level AA, the current version of the international guidelines and the one most laws point to. It includes everything in the earlier 2.0 and 2.1 versions.

Do you actually test, or just claim it?

We test. Automated checks run in the build, and we do keyboard, screen reader, contrast, zoom, and forms testing by hand. Every scoped build gets a dated audit report you can keep.

What is a VPAT, and do we need one?

Filled in, a VPAT is an Accessibility Conformance Report. Procurement teams and enterprise buyers ask for it during RFPs. If your buyers request one, we produce it from your audit. If nobody is asking, you probably do not need it yet.

Will our existing site pass?

Maybe, maybe not. We can audit what you have, tell you honestly where it stands, and hand you a prioritized list of what to fix.

Does accessible cost more?

Building it in from the start keeps the added cost modest. Fixing an inaccessible site after launch is where the real expense shows up.

Get in touch

Let's build it right

Send us your site or web app. We'll show you where it stands against WCAG 2.2 AA today, and what it takes to close the gaps.

Start a conversation →