The context-switch tax
Most accessibility auditing happens too late. You build a feature, deploy it to a staging environment, and then run a Lighthouse report or open a browser extension. You find six contrast issues and a missing ARIA label.
Now you have to go back to your IDE. You search for the line of code. You guess at a better color. You save. You wait for the hot reload. You re-run the audit.
This loop is slow. It treats accessibility as a final check instead of part of the design process. When the audit tool is separate from the editing tool, accessibility becomes a chore.
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
A logical heading structure is vital for screen reader navigation. Kerf visualizes your heading levels from H1 through H6. If you skip from an H2 to an H4, Kerf flags the break. You can change the tag directly in the editor without hunting through HTML templates.
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 are actually there.
5. Focus order
If a user can't navigate your site with a keyboard, the site is broken. Kerf walks the tab order of your page 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 between Kerf and a browser-based auditor is the "Save" button. When you find an issue in Kerf, you fix it with the visual tools, and Kerf writes the fix directly to your source files. No copying and pasting from DevTools back to your editor.
Accessibility isn't a test you pass at the end of the week. It's a set of decisions you make while you're actually building.