Most engineering organizations measure what they intend to reward, whether they mean to or not. Velocity, feature output, code review turnaround, uptime, these show up explicitly in performance review criteria at most companies with any kind of structured review process, because leadership has decided, at some point, that these things matter enough to formally track and reward. Accessibility, at the overwhelming majority of organizations, appears nowhere in that list. It exists as an occasional callout during a project retro, or a line item in a design system's documentation nobody is evaluated against, but it is almost never a criterion someone's actual compensation, promotion, or standing on the team is measured by.
This absence is not neutral. In any organization with limited engineering time and a review process that explicitly rewards certain behaviors, work that is not measured is, in practice, deprioritized relative to work that is, regardless of how much any individual engineer personally cares about it. An engineer who spends an extra day making a component genuinely accessible, testing it with a keyboard and a screen reader rather than just shipping the visual design, is spending that day on something their manager will likely never mention in a review, while a peer who shipped one more feature in that same day gets measured, recognized, and rewarded for it directly. Over enough review cycles, that asymmetry shapes behavior more reliably than any all-hands announcement about accessibility mattering to the company.
The Underlying Mechanic: Performance review criteria function as an organization's most concrete, individually-felt statement of what actually matters, more than any stated value or company-wide initiative, because it is the one mechanism tied directly to an individual's compensation and career progression.
Why Good Intentions Alone Do Not Close This Gap
Most engineering leaders who are asked directly will say accessibility matters to their organization, and most mean it sincerely. The gap is not sincerity, it is mechanism. A stated value with no corresponding measurement mechanism competes for attention against every measured priority on a team's plate, and consistently loses that competition, not because anyone decided accessibility does not matter, but because humans and teams reliably optimize for what gets tracked and rewarded over what gets occasionally mentioned. This is the same underlying dynamic covered in our piece on why 'we'll fix it later' is how the lawsuit starts: accessibility work sitting in a backlog with no forcing mechanism attached to it predictably loses to work that does have one, again and again, until an external event, a complaint, an audit, a lawsuit, forces a reckoning that a measurement system could have prevented far earlier and at much lower cost.
What a Real Accessibility Review Criterion Looks Like
The mistake most organizations make when first attempting this is writing a vague, unmeasurable line like "considers accessibility" into a review template, which changes little because it cannot be evaluated consistently or fairly across different reviewers. A criterion that actually functions needs to be as concrete as the other criteria it sits alongside: did the engineer's shipped work pass the team's defined accessibility testing bar before merge, did they flag and either fix or properly escalate accessibility issues found in code review, did they proactively test new interactive components with a keyboard rather than only visually, are there recurring, specific, attributable accessibility regressions traceable to their work. These are measurable in the same concrete way code quality or collaboration already are at most companies, once a team has actually defined what its accessibility testing bar is in the first place.
Where This Should Sit in a Review, and Where It Should Not
Accessibility does not need its own entirely separate review category to be effective, and for most teams, folding it explicitly into existing code quality and craftsmanship criteria, rather than treating it as a bolt-on extra, more accurately reflects that it is a core quality dimension, not a separate specialty concern only relevant to specialists. What matters more than where exactly it sits structurally is that it is explicit, specific, and consistently applied, rather than left as an unwritten expectation that different managers weigh completely differently depending on their own personal familiarity with the topic.
The Signal This Sends Beyond the Review Itself
Adding a concrete accessibility criterion to performance reviews does more than change individual incentives, though that alone is meaningful. It changes what gets discussed in planning, since work that will be measured tends to get scoped and estimated for properly rather than squeezed in as unpaid overtime at the end of a sprint. It changes what gets asked about in interviews, connecting directly to the screening approach covered in our piece on the interview question that filters out fake accessibility experience, since a team that measures this in reviews has a much stronger reason to actually verify it during hiring. And it changes what senior engineers model for junior ones, since review criteria shape what senior team members visibly prioritize and mentor toward.
If your organization has stated accessibility as a value but has no corresponding line in how individual performance is actually evaluated, that gap is worth closing directly, not with a company-wide announcement, but with a specific, measurable criterion built into the review process your engineers already take seriously. Our team can help define what a realistic, measurable accessibility bar looks like for your specific product and team size. Reach us at experts@wcag.world for a conversation about what that looks like in practice, or review the W3C's planning and management guidance for how organizations are encouraged to build accessibility into ongoing process rather than one-off projects.
A practical review loop
Start with the task a person needs to complete, not with the score produced by a single automated scan. Write down the entry point, the expected focus order, the announcement a screen reader should receive, and the recovery path when something goes wrong. Then repeat that task with a keyboard and at least one assistive technology setup. This turns a vague accessibility concern into an observable acceptance test.
The useful evidence is specific. Capture the URL, the control label, the keystrokes, the browser state, and the expected result. Separate a defect from a design choice, and separate both from a limitation in the test environment. Give the product owner a short reproduction and a clear severity rationale. A developer can fix a named interaction. Nobody can reliably fix a general instruction to make a page more accessible.
Finally, put the check into the delivery process. Add the scenario to a pull request checklist, retest it after JavaScript changes, and keep a small set of representative pages available for regression testing. That routine protects the people who depend on the workflow and gives the team a defensible record of what was tested, when it was tested, and what happened.
For the next review, use these related resources: accessibility specialist fastest growing job, how to put accessibility on your resume, the referenced standard.
For the next review, use these related resources: request the relevant WCAG review.