Estimating Accessibility Effort

Estimate each issue

For each issue, produce:

Effort definitions

Factors that increase effort

• Shared components: A fix to a shared component is small in code but high in risk — it affects every consumer. Testing effort scales with usage count.
• Missing patterns: If the codebase has no existing pattern for the fix (e.g., no focus management utilities, no live region conventions), the first fix includes establishing the pattern. Subsequent similar fixes are smaller.
• Test coverage: If the fix needs new tests (it usually does), include test authoring in the estimate. Accessibility tests often require Playwright for integration-level assertions, not just unit tests.
• Multi-theme: Contrast fixes need verification in every supported theme. Double the verification effort for each additional theme.
• Third-party components: Fixes inside third-party component internals may require forking, wrapping, or replacing the component rather than a simple attribute change.
• Dynamic content: Issues involving dynamic state (live regions, focus management after async operations, error announcements) are harder than static markup fixes because they require understanding the component's lifecycle.

Factors that decrease effort

• Component library handles it: If the project uses a headless UI library that already implements the ARIA pattern, the fix may be as simple as passing the correct props.
• Pattern already exists: If the codebase already has a focus management utility, a live region component, or an error handling convention, applying it to a new location is faster.
• Single occurrence: An issue that appears in one place with no shared component implications.

Batch estimation

When estimating a set of issues (e.g., a full audit report), also provide:

Summary table

Dependency graph

If issues depend on each other, note the order. Common patterns:

• "Establish focus management utility (L)" must come before "Add focus return to all modals (S each)"
• "Add aria-describedby error association" depends on "Implement error message components"
• "Fix landmark structure" should come before "Add skip link" (the skip link needs a target)

Quick wins

Highlight issues that are XS or S effort with Critical or Serious severity. These deliver the most accessibility improvement per unit of effort and are good candidates for immediate action.

Report format

## Accessibility Effort Estimate - [scope]

### Individual Estimates

| Issue | WCAG | Severity | Scope | Effort | Rationale |
| ----- | ---- | -------- | ----- | ------ | --------- |
| ...   | ...  | ...      | ...   | ...    | ...       |

### Summary

| Effort | Count |
| ------ | ----- |
| XS     | n     |
| S      | n     |
| M      | n     |
| L      | n     |
| XL     | n     |

### Dependencies

- [issue A] must be completed before [issue B] because [reason]

### Quick Wins

- [issue] (XS/S effort, Critical/Serious severity) - [what to do]

Gotchas

• Do not estimate without reading the code. An issue that sounds simple ("add keyboard support") might be trivial (the component library already handles it) or enormous (the widget is entirely custom with mouse-only interactions). The code determines the estimate, not the issue title.
• Estimates are not commitments. T-shirt sizes communicate relative effort, not hours or days. The same "M" fix takes different wall-clock time depending on developer familiarity, test infrastructure, and review process. Frame estimates as relative sizing, not delivery promises.
• First-of-kind fixes are larger than they appear. The first focus management fix, the first live region, the first keyboard navigation pattern — each establishes a convention that subsequent fixes can follow. Estimate the first instance higher and note that follow-on instances will be smaller.
• Test effort is part of the fix. An accessibility fix without corresponding tests will regress. Include test authoring in every estimate, especially for dynamic behaviour (focus management, ARIA state changes, error announcements).
• Shared component fixes need integration testing. Changing a shared <Button> or <Dialog> component to fix an accessibility issue affects every page that uses it. The code change may be small, but the testing surface is the entire usage footprint.
• Some issues are cheaper to fix together. Adding aria-describedby to 10 form fields is not 10x the effort of doing one — it is 1x to establish the pattern plus 10x a trivial application. Group related issues when estimating batches.
• Replacing a component is sometimes cheaper than fixing it. If a custom widget has fundamental accessibility problems (no ARIA pattern, no keyboard model, no focus management), switching to an accessible component library may be less total effort than retrofitting accessibility onto the custom implementation.