Fix the cookie cutter, not the cookies.
Every barrier in a design system is copied onto every page that uses it. We help your team stop barriers at the source: in components, in the build pipeline, and in the habits of the people who design, build, write, and test.
One flawed component, copied onto every page
Audits keep finding the same issues because the same components keep producing them. A select menu without a label, a modal without focus management, a color token that fails contrast on white: each is a single defect in the design system, stamped onto every page that uses it.
So we start where the copies come from. A design-system audit tests each component in your library, in Storybook or wherever it lives, against WCAG 2.2 AA with a keyboard and screen readers, in every state and variant. We check the design files too: color tokens, focus styles, target sizes, and the annotations designers hand to developers.
Then we fix or specify fixes at the component level and add tests, so the defect can't return unnoticed. One accessible date picker in the library is worth more than a hundred patched date pickers in production.
Where each check belongs in your pipeline
Automated checks are cheap at every stage. The earlier they run, the cheaper the fix.
| Stage | What we set up | What it catches |
|---|---|---|
| Design | Contrast-checked color tokens, focus and target-size specs, and annotation templates | Contrast failures, missing focus styles, and unnamed controls before any code exists |
| Component | Storybook's accessibility addon and unit tests that run axe-core | Missing names, invalid ARIA, and contrast problems in every component state |
| Pull request | Lint rules such as eslint-plugin-jsx-a11y, and axe-core checks in CI | Common markup errors, blocked at review instead of found in production |
| End to end | Playwright with @axe-core/playwright on critical journeys, plus scripted keyboard paths | Barriers that appear only when components combine: lost focus, trapped dialogs, silent errors |
| Release | A short manual screen-reader pass on changed journeys | Meaning: whether names make sense and announcements arrive when they should |
| Production | Baclion Watch | Regressions from content, configuration, and third-party code |
Automation is a floor, not a ceiling
We put automated tests in your pipeline because they're fast and never get tired. We also tell you plainly what they miss.
In Deque's own 2021 study of its first-time audits, automated axe testing found 57% of issues by volume. That figure comes from the company that makes axe-core, and it counts issues, not WCAG success criteria. In a 2017 test by the UK Government Digital Service, the best of the automated tools it compared found 41% of the barriers planted on a deliberately inaccessible page.
The rest takes people who know what to look for. That's why the pipeline includes a manual step, and why the workshops matter as much as the tooling.
Workshops for each role on your team
Each half-day workshop uses your own product as the course material, for up to 20 people at a time.
Designers
Contrast tokens, focus states, and target sizes, and how to annotate headings, names, and reading order so developers don't have to guess.
Developers
Native elements first, ARIA only when needed, focus management in single-page apps, and live regions, practiced on your own components with a screen reader running.
Content editors
Headings, link text, alt text, tables, and accessible documents, taught inside your CMS and your Word templates.
QA testers
A repeatable manual test script with keyboard, zoom, and screen readers, and how to write a finding a developer can act on.
Product managers
Acceptance criteria, a definition of done, and how to prioritize accessibility findings by who is blocked.
Acceptance criteria your team can paste into tickets
Every team gets a set like this, adapted to its own components.
- Every interactive element can be reached and operated with a keyboard alone, with a visible focus indicator
- Every form field has a programmatic label, and errors are announced and linked to their fields
- Dialogs move focus inside when they open, keep it there, and return it to the trigger when they close
- Status updates such as cart counts and saved messages are announced through a polite live region
- Pointer targets are at least 24 by 24 CSS pixels, or meet one of the criterion's exceptions
- Content reflows without horizontal scrolling at a width of 320 CSS pixels
- Text and interface components meet WCAG 2.2 AA contrast ratios in their default, hover, and focus states
Workshops by the half day
Team workshop
Starting at
$2,200per half day
Role-based training for up to 20 designers, developers, or content editors, built around your own product.
Request a quoteDesign-system audits and CI setup are scoped separately, once we've seen your component library. Workshops run remotely, or in person in Bowling Green, elsewhere in Kentucky, and in the Nashville area.
Questions from engineering and design leads
Will automated tests in CI catch everything?
No, and we'll say so in writing. They catch a useful share of issues early and cheaply; the rest needs manual testing and trained people. We set up both, and Baclion Watch can cover production.
Can you audit our design files as well as our code?
Yes. We review design files for tokens, focus styles, target sizes, and annotations, and the coded components in Storybook or your documentation site. A problem caught in design is the cheapest one to fix.
Do the workshops use generic examples?
No. We build each workshop around your product: your components, your CMS, and your documents. The broken example on screen is one your team will recognize.
Can you work with our design-system team over several months?
Yes. Some teams want a short engagement to set up tooling; others want a developer on our team pairing with theirs through a component-library rebuild. We scope either after a call.
Keep reading
Tell us what your website needs to do.
Send a link and a sentence about your deadline. You will hear back from a person within one business day, usually with a short list of questions and a proposed scope.