Evidence first, then the fix, then proof it stayed fixed.
This is how we work: the principles we hold to, the six steps of an engagement, every assistive technology we test with, how we decide what is urgent, and what we do with your data.
Five principles we don't bend
Source code over overlays
We fix the HTML, CSS, and JavaScript your team owns. We never install widgets that paint over a page, because they can't change what the code underneath tells assistive technology.
Evidence for every claim
Each finding records the success criterion, the location, the assistive technology and browser, and what we heard or saw. If we can't show it, we don't report it.
Rank by who is blocked
An unlabeled field in checkout outranks a skipped heading level in the footer, whatever the rule names suggest. We sort by impact on people, then by how often they hit it.
Plain English and code-level detail
Executives get a summary they can act on in five minutes. Developers get the selector, the failing markup, and a pattern to copy.
Fixed stays fixed
Every fix is retested against the original finding, and monitoring catches regressions before your users do.
Six steps, from first look to ongoing watch
Discover
We map your templates, journeys, platforms, third-party scripts, and deadlines, and agree on a sample that represents the whole site.
Test
An automated sweep with axe-core and our own rules, then manual testing of every sampled template and journey against the WCAG 2.2 A and AA criteria, using the assistive technology listed below.
Rank
Each finding gets a severity from the model below, the component it lives in, and an owner, so the backlog sorts itself.
Fix
Our engineers ship fixes as reviewed pull requests or theme changes, or pair with your developers so the knowledge stays in-house.
Verify
We retest each fix with the same assistive technology that found the problem and record the result against the original finding.
Watch
Baclion Watch scans weekly, tracks field performance and script changes, and adds quarterly manual checks so regressions surface early.
How we test with screen readers
We test the screen reader and browser pairings people actually use together, because a screen reader's behavior depends on the browser beneath it.
| Combination | What we test | What it catches |
|---|---|---|
| NVDA with Firefox and Chrome on Windows | Every sampled template and journey in browse and focus modes: landmarks, headings, forms, tables, and live regions | Missing names and roles, silent dynamic updates, and ARIA that contradicts native semantics |
| JAWS with Chrome on Windows | Critical journeys, forms, data tables, and custom widgets | Differences in how ARIA patterns and table headers are interpreted, and widgets that only work in one screen reader |
| VoiceOver with Safari on macOS | Critical journeys, rotor navigation, and dialogs | Focus lost when dialogs open, and gaps in the accessibility tree that only appear in WebKit |
| VoiceOver with Safari on iOS | Mobile layouts, swipe and double-tap gestures, and the rotor | Controls that exist only on hover, unlabeled icon buttons, and gestures with no alternative |
| TalkBack with Chrome on Android | Mobile layouts, explore by touch, and reading controls | Custom controls with no role, focus that jumps around the layout, and content hidden from the accessibility tree |
How we test beyond the screen reader
Most people with disabilities don't use a screen reader. These settings and devices cover much of the rest.
| Setting or device | What we test | What it catches |
|---|---|---|
| Keyboard only | Every interactive element, in order, with no mouse | Keyboard traps, invisible focus, focus order that doesn't match the page, and controls that only respond to clicks |
| Browser zoom at 200% and 400%, reflow at 320 CSS px | Text resizing and reflow on desktop layouts | Clipped or overlapping text, horizontal scrolling, and sticky headers that swallow the viewport |
| Windows contrast themes (forced colors) | Every sampled template in a dark and a light contrast theme | Icons and focus indicators that vanish, buttons with no visible edge, and meaning carried only by background images |
| Speech input with Dragon or Voice Control | Critical journeys completed by voice | Visible labels that don't match the accessible name, and controls that can't be activated by saying their name |
| Switch Access and Switch Control | Critical journeys with single-switch scanning on Android and iOS | Time limits that expire before scanning reaches a control, and targets too small or too close together |
| Reduced motion | Every sampled template with the operating system's reduced-motion setting on | Animation, parallax, and autoplaying video that ignore the setting, and motion with no pause control |
How we decide what's urgent
Severity measures the impact on people, not the WCAG level of the rule. A Level AA failure can be a blocker, and a Level A failure can be minor.
| Severity | Definition | Example |
|---|---|---|
| Blocker | Someone can't complete a core task at all, and there is no workaround. | A delivery-date picker in checkout that traps keyboard focus |
| Serious | The task is possible only with significant effort, guesswork, or help from someone else. | Error messages that appear on screen but are never announced |
| Moderate | The barrier slows people down or causes confusion, but they can still finish. | A sticky header that hides the focused field on a long form |
| Minor | An inconsistency or annoyance that affects comfort more than completion. | A decorative image announced by its file name |
What we do with your data
Testing a website sometimes means seeing what your customers see. We keep that exposure as small as we can.
We sign your NDA on request. We ask for least-privilege access to a staging environment: test accounts, read-only wherever possible, and nothing we don't need. We never use production personal data; we test with synthetic records or accounts your team creates for us.
Findings, screenshots, and recordings live in your issue tracker or in a shared folder you control, so the record of the work stays with you after the engagement ends.
Questions about our method
How much do you rely on automated tools?
We use them on every engagement, and they are useful. In Deque's own 2021 study of first-time audits, automated axe testing found 57% of issues by volume. The rest, including many of the barriers that actually stop people, needs a person with a keyboard and a screen reader. Our article on what automation catches goes deeper.
Why test with several screen readers instead of one?
Screen readers interpret the same code differently, and each runs on a different browser engine. A pattern that works in NVDA with Chrome can fail in VoiceOver with Safari. Testing the main pairings catches those differences before your users do.
What happens if we disagree with a finding?
Tell us. We show the evidence, retest if anything has changed, and adjust the severity or close the finding if we got it wrong. A findings register is more useful when it is accurate than when it is long.
Will you test on our production site?
We prefer staging for anything that writes data, such as forms, checkouts, and account changes. Read-only testing of public pages in production is fine and often more realistic. We agree on the rules before testing starts.
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.