An accessibility code review is not a WCAG audit of a live website. It is a review of your frontend code — your React components, your Svelte or Vue templates, your HTML patterns, your CSS focus styles — before or after it ships, with findings written at the code level so your developers can act on them immediately.
If you are a developer or engineering lead who wants expert eyes on your UI implementation rather than a usability report, this is the engagement.
What an accessibility code review covers
Component architecture. I look at how your interactive components are structured. Custom dropdowns, modals, tabs, accordions, tooltips, autocompletes — all of these have established ARIA patterns. I check whether your implementation follows the pattern, deviates from it intentionally, or deviates from it accidentally.
Keyboard interaction models. Each interactive widget type has a defined keyboard model. Tabs use arrow keys to move between panels. Comboboxes use arrow keys to navigate suggestions and Enter to select. Modals trap focus inside and return focus on close. I check the keyboard model against expected behaviour and identify where it falls short.
ARIA usage. Misused ARIA is worse than no ARIA. aria-label overriding visible text creates divergence between what sighted and screen reader users see. role="button" on a non-focusable element without tabindex="0" creates a button nobody can reach by keyboard. aria-hidden="true" on a container that includes focusable elements hides them visually but not from keyboard navigation. I find these patterns and fix them.
Focus style implementation. Many codebases suppress focus styles globally with :focus { outline: none } and then partially reintroduce them. I check that every interactive element has a visible focus style in every state, that focus styles meet WCAG 2.2 minimum requirements, and that they are not accidentally removed by CSS specificity.
CSS and computed accessibility tree. Some accessibility failures only appear when CSS is applied. Content that is visually hidden but not correctly hidden from assistive technology. Elements positioned off-screen that remain in tab order. I check the rendered output, not just the HTML.
Automated tool configuration. If your codebase uses eslint-plugin-jsx-a11y, axe-core in tests, or similar, I check the configuration for common gaps and suggest rule additions that would have caught the issues I found.
What the output looks like
The output is a code-level findings document. Each finding includes:
- The file and component where the issue exists
- The specific code causing the problem (quoted directly from the source)
- The WCAG criterion it fails
- The fix, written as the corrected code or the specific attribute change needed
No vague recommendations. No generic WCAG criterion descriptions without context. The findings read like a senior developer’s code review comments.
Who this is for
This engagement suits teams who:
- Have built something and want it checked before it ships or before a formal audit
- Have received WCAG audit findings and want help understanding the code-level root causes
- Are building a component library and want specialist review of interactive patterns
- Have automated tooling in place but know it does not catch everything