Auditing after the fact
The common workflow is to build a page, deploy it to staging, and then run Lighthouse or a browser extension against it. The report comes back with six contrast issues and a missing ARIA label — identified on the rendered page, not in your files.
Each fix then means finding the right line in the editor, guessing at a better color, saving, reloading, and re-running the report to see whether the number went from six to five. The round trip is long enough that in practice the audit runs once, near the end, instead of continuously.
Accessibility in the flow
Kerf puts the audit directly inside the visual editor. When you click an element to edit its styles, you see its accessibility status immediately. You don't "run" a report — the feedback is part of inspection.
Kerf Pro runs five checks that target the most common WCAG failures.
1. Color contrast
Kerf calculates the contrast ratio between text and its background. If you edit a button and the text color doesn't meet WCAG AA, Kerf flags it. Adjust the hex code and the contrast number updates with the change.
2. Alt text and labeling
Every image and functional element needs a label. Kerf scans for missing alt attributes on images and missing accessible names on icon-only buttons. It highlights these
elements in the layers panel so the gaps are obvious.
3. Heading hierarchy
Screen reader users navigate by heading levels. Kerf visualizes your headings from H1 through H6, and if you skip from an H2 to an H4, it flags the break. You can change the tag directly in the editor rather than tracking it down in a template.
4. Landmarks and semantics
Modern pages rely on landmarks — <nav>, <main>, <section>. Kerf checks whether your page structure follows landmark best
practices, so the regions a screen reader navigates by are present.
5. Focus order
Keyboard users move through a page in tab order. Kerf walks the tab order and flags focusable elements that sit outside the reading flow, along with interactive elements that have no visible focus state.
Fix in place
The difference from a browser-based auditor is what happens after the finding. When Kerf flags an issue, you fix it with the same visual tools you're already editing with, and the fix is written to your source files — there's nothing to copy back from DevTools.