KresciaPARTNERS
Method
What we actually run, and what we actually change
Written for the developer who will read our diff. Every claim on this page is something you can check in your own repository within an hour.
The audit: a machine pass and a human pass
An automated pass tells you a great deal and settles nothing. Engines are excellent at the countable — missing alternatives, empty labels, contrast ratios — and blind to the rest: whether the focus order makes sense, whether an error message is announced, whether a custom dropdown can be operated at all. No engine reports on those, and no vendor who claims otherwise has measured them.
So we run both, in this order. The machine gives us the inventory. The keyboard and the screen reader tell us which parts of that inventory actually stop somebody from buying.
axe-core, across every template in scope
The same rule set that ships in axe DevTools. Run on each template, not just the home page — most sites fail hardest on product and checkout.
Keyboard only, then a screen reader
Tab through the paths that carry money: navigation, search, product, cart, checkout, contact. Then the same paths with NVDA, listening to what gets announced.
Issue, location, and the line to change
Every finding is tied to a file and a selector. If we can’t point at the line, it doesn’t go in the report.
The recurring six
Six families cover most of what we find
Themes are shared, so their defects are shared too. On a Shopify or WordPress build, the same handful of patterns comes back site after site — which is why we quote by template rather than by hour: the fix list for one Dawn storefront looks a great deal like the fix list for the next one.
Images with no alternative
Announced as the file name. Decorative images need an empty alt so they’re skipped; meaningful ones need a sentence somebody actually wrote.
Icon buttons with no name
Announced as “button.” Cart, search, menu, and close are the usual four — and the cart one is the expensive one.
Form fields with no label
A placeholder is not a label: it disappears on focus and isn’t reliably announced. Newsletter and search fields are the classic offenders.
Focus you can’t see
outline: none with nothing put back. A keyboard
user is then navigating an invisible cursor.
Headings used for size
An h4 chosen because it looked right. Screen
reader users navigate by heading, so the outline is the table of contents.
Contrast below the line
Gray-on-gray secondary text and light text on a brand color. Usually fixed in the token, once, for the whole site.
What a fix looks like
Three real examples, in the form you’ll receive them: the line as it ships, and the line as we hand it back. Nothing is rewritten around it — we change what needs changing and leave the rest of your build alone.
The icon carries no information once the button has a name, so it’s marked
aria-hidden — otherwise the same control gets
announced twice.
The deliverable
What the report contains — and what it never contains
It’s written to be forwarded. Your client should be able to read the first page without knowing what WCAG stands for, and your developer should be able to work from the rest without asking us anything.
Counts before and after, by category and by template · every issue with its file, selector and severity · the exact change made · the screen-reader behavior for the worst three · the date and version of every measurement.
The words “compliant,” “certified,” or “protected” · a score presented as a legal position · an opinion on anyone’s risk · a recommendation to install an overlay.
Where automated numbers stop being useful
A scan that returns zero errors does not mean a site is usable. It means the countable things are handled. A page can pass every automated rule and still be impossible to check out on, because the form errors aren’t announced or the modal traps focus. We say this in the report, every time, on purpose: an agency that forwards a “zero issues” claim to its client is exposed the day somebody actually tests with a screen reader.