To assign severity levels to accessibility issues, score each issue against two factors: user impact (how much the issue blocks people using assistive technology) and risk factor (how likely the issue appears in legal claims). Most accessibility platforms let you set severity manually or apply a default rating based on the WCAG success criterion. The result is a prioritized queue where the highest severity items get fixed first.
| Element | What It Means |
|---|---|
| User Impact | How significantly the issue blocks people who rely on assistive technology. |
| Risk Factor | How frequently the issue appears in accessibility-related legal claims. |
| Conformance Level | Whether the criterion sits at WCAG Level A, AA, or AAA. |
| Default vs. Manual | Platforms apply a default severity, then allow reviewers to adjust based on context. |
The Two Factors That Drive Severity
User impact and risk factor are the two scoring inputs most accessibility compliance platforms use. User impact looks at the experience side: does the issue prevent someone from completing a task, or does it create friction without fully blocking them? An unlabeled form field on a checkout page sits higher than the same issue on a rarely visited footer link.
Risk factor looks at the legal side: certain issues appear repeatedly in demand letters and complaints. Missing alternative text, inaccessible forms, and keyboard traps show up far more often than less common criteria. Platforms weight these issues higher because they carry both user and legal consequences.
How Platforms Apply Default Severity
When an audit is imported or an issue is logged, the platform assigns a default severity based on the WCAG success criterion. A Level A violation generally carries higher severity than a Level AA violation, and AAA items sit lower still. The default is a starting point, not a final answer.
Reviewers then adjust severity based on where the issue lives. The same issue on a high-traffic landing page is treated differently than one on an internal admin screen seen by two people a month. Page weight, user flow, and frequency all factor in.
A Practical Severity Scale
Most platforms use a three or four tier scale. The names vary, but the structure is consistent across the industry.
- Critical: Fully blocks a user from completing a core task. Example: keyboard users cannot reach a primary action button.
- High: Significantly degrades the experience but does not fully block it. Example: form errors that screen reader users cannot perceive.
- Medium: Creates friction or confusion without blocking the task. Example: a heading structure that skips levels.
- Low: Minor inconsistency or cosmetic issue with limited functional impact.
Adjusting Severity After Assignment
Severity is not static. As pages get fixed, as new features ship, and as user data comes in, the relative weight of remaining issues shifts. A platform that supports severity editing lets your team reprioritize the backlog without rebuilding it from scratch.
Reviewers often adjust severity after screen reader testing or keyboard testing confirms how an issue behaves in practice. What looks moderate in a code review may turn out to be a complete blocker once it is encountered in an assistive technology session.
Documenting Severity Decisions
Severity ratings hold up better when the reasoning is recorded. Most platforms include a notes or rationale field next to the severity selector. A short line explaining why an issue was rated critical, high, medium, or low gives developers context and gives auditors a record of how prioritization decisions were made.
That record matters when a VPAT, Accessibility Conformance Report, or internal status report references the same issue months later. Consistent severity logic across an audit cycle keeps remediation focused on what affects users and reduces risk most.