By role · Developers
What Developers Own, and Where to Start
Most of an audit lands on your desk. In our own reports, about half of it was decided before the ticket ever reached you.
You build from a design that already exists. Your job is making the markup say what the design meant.
Accessibility gets handed to developers as though all of it were implementation, and in our own reports about half of it is not. The designer chose the contrast, the target size, the wording of the error message and the shape of the heading hierarchy. If any of those miss the standard, the fix belongs upstream. Agree it with the designer and change it once, rather than improvising a repair only you know about. What is yours is narrower and carries more weight. When the markup you ship describes the design accurately, most of accessibility happens by itself. When it does not, you are the point where it breaks.
The half that is yours is mostly free. Reach for the element that already means the thing. A real button, a real heading, a real landmark. You get keyboard operation, focus behaviour, state reported to the platform and a sensible announcement, without writing a line for any of it. That is not a shortcut, it is what the standard expects. Its own note on the name, role and value rule says that standard HTML controls already satisfy it when you use them the way the spec describes.
What you own
- Semantic HTML that describes the content accurately. Real buttons, real headings, real lists, real landmarks, real tables, and the search element for a search region, which browsers have supported widely since October 2023.
- Keyboard operation, and where focus goes. A native dialog opened with showModal() already moves focus in, holds it there, makes the background inert, handles Escape and hands focus back on close. That leaves you choosing where focus lands first, giving the dialog an accessible name, and making sure what is inside it behaves.
- An accessible name on every control, so a screen reader has something to call it and voice control has something to say to it.
- Native HTML first, ARIA second. Reach for a role only where no element does the job, because a role renames a thing in the accessibility tree and changes nothing else, so it never makes Enter work. ARIA states are a different matter and belong on native elements all the time: aria-pressed on a real button is the documented way to say a toggle is on.
- Live regions for the changes that qualify as status messages, and the right kind for the job. A role of status is meant to be announced whole, so somebody hears "3 items in cart" rather than just "3". Not every environment treats it that way by default, so add aria-atomic when you need the whole phrase guaranteed.
What is not yours
Contrast ratios, target sizes, error message wording and heading hierarchy are usually settled in the design file, before the ticket reached you. If they miss the standard, send them back and agree the fix there. Do not invent your own sizing, wording or hierarchy on the way past, because a fix you improvise is a fix nobody else on the team knows exists. Teams that combine the two roles just do both halves deliberately.
Where to start, in order
- The developer's checklist31 checks sized for a pull request, ordered so the ones that catch the most come first.
- Keyboard accessibilityThe highest-yield test you can run on your own work. Ten minutes with the mouse unplugged reaches a whole class of failures no scanner has a rule for.
- ARIA explainedMostly about when not to reach for it, because bad ARIA breaks more than it repairs.
- Accessible formsHow to label a control so it announces, how to announce an error once rather than twice, and what WCAG 2.2 changed about authentication.
- Link vs. buttonThe small choice that breaks keyboard and voice control. Neither axe-core 4.13 nor any live ACT rule has a test for it, so it reaches you or it reaches nobody.
- Screen reader testingSix commands and a thirty-minute plan. Half an hour of this changes how you write markup for good.
- All 432 fix guides, by subjectThe full reference, filed by what each technique does instead of by W3C's identifiers.
The mistakes we see most from this role
Not a criticism. These are the failures that recur across audits, and knowing them is most of avoiding them.
- Removing the focus outline without replacing it, which strands everybody working by keyboard, switch or voice.
- Firing an action from a div with a click handler instead of a button, which loses keyboard operation and tells a screen reader nothing about what the thing is.
- Writing an aria-label that does not contain the visible text, which breaks the spoken command a voice control user has to say out loud.
- Rebuilding a modal out of divs and then rebuilding focus behaviour by hand, when a native dialog opened with showModal() already does all of it.
- Trapping focus inside something that is not a modal dialog. A non-modal panel can hold a tab sequence as long as there is a way out of it without closing it, and the failure is when there is not one.
- Copying a widget straight out of the ARIA Authoring Practices Guide, where every example carries a note saying it is not written for production.
- Letting a status message pass silently. A result count, a save confirmation or an error that appears without moving the reader has to be exposed as one, though plenty of other updates on a page are not status messages at all.
- Using positive tabindex values, which pulls the tab order out of document order and strands whole sections of the page.
Tools you will use
Other roles
Find out what your site actually needs.
The free scan checks 10 pages in a real browser against all 90 supported automated rules, keeps its 27 best-practice checks separate from WCAG findings, and names the rule behind every finding.