Most accessibility consultants give you a spreadsheet. Hundreds of rows. WCAG criterion references, impact ratings, vague descriptions like “ensure keyboard operability.” Then they leave and you are supposed to figure it out.
I work differently. I go into the codebase, fix the issues, and open pull requests your team can review and merge. The deliverable is working accessible code, not another document for the backlog.
What hands-on accessibility engineering looks like
When I work directly in a codebase I am looking at your actual component implementations, not a theoretical checklist. Common things I fix:
Focus management. I write the focus trap logic for your modal. I add the route change focus handler to your Next.js or SvelteKit app. I implement the skip link that actually targets the right container.
ARIA patterns. I refactor the custom dropdown that uses div elements with onClick handlers into a proper combobox or listbox pattern with keyboard support, aria-expanded, aria-activedescendant, and all the rest. Not by telling you it needs doing. By doing it.
Form error handling. I wire aria-describedby between your error messages and their inputs. I fix the validation flow so errors are announced when they appear, not when the page loads. I rewrite the generic “Please correct the errors above” message into something a screen reader user can act on.
Semantic structure. I replace presentational div nesting with the right HTML elements. I add the heading hierarchy your design implies but your markup does not. I mark up your data tables with th, scope, and caption rather than a grid of divs with CSS columns.
Colour contrast. I identify the failing tokens in your design system, find the closest accessible values that still feel on-brand, and update the variables. Not a recommendation. The actual fix.
I speak developer
I know what a pull request looks like. I know when to use a utility component versus a CSS class. I know the difference between a React controlled component and an uncontrolled one, and why it matters for accessibility. I know what your ESLint rule is probably missing and what eslint-plugin-jsx-a11y covers and what it does not.
When I raise an issue with a developer I give them the code fix, not a citation from the WCAG spec. If I am explaining why something needs to change, I explain it in terms of what the browser accessibility tree does with the current markup and what it does with the fixed markup. That is the conversation that gets things merged.
When this approach works best
This model suits teams that:
- Have an accessibility backlog and no time or knowledge to work through it
- Are preparing for a product launch and need issues resolved, not listed
- Are building a component library and want accessibility baked in rather than retrofitted
- Have received an audit report from someone else and need help implementing the fixes