Every release team eventually faces the same question: do we ship with digital accessibility blockers, or do we hold the release?
The wrong answer costs you either way. If you block every Web Content Accessibility Guidelines (WCAG) violation, you stall delivery over issues that barely affect users. If you ignore severity, you ship a product that locks people out of checkout, login, or the application they came to submit.
I use a simpler test. Digital accessibility blockers are issues that prevent a person with a disability from completing a critical task, understanding essential information, or operating a core feature.
A WCAG Violation Is Not Automatically a Digital Accessibility Blocker
Conformance and user impact measure different things. A product can carry a WCAG failure that never stops anyone from finishing a task. Meanwhile, one narrow technical defect, such as an unlabeled “Submit” button, can stop someone from buying a product or applying for a job.
So I treat task completion and user impact as the primary release gate. WCAG, EN 301 549 (PDF), and Section 508 give me the compliance framework behind that decision, but they can’t make the call alone.
Accessibility Severity Levels and Release Decisions
| Severity | Release Treatment |
|---|---|
| Blocker | Prevents a person with a disability from completing a critical task or accessing essential functionality. Must fix before release. |
| Critical | Major barrier to important functionality, with limited or poor workaround. Normally fix before release. |
| Major | Significant accessibility problem, but the user can still accomplish the task through a reasonable path. Fix before or immediately after release. |
| Moderate | Creates friction or reduces usability but does not prevent meaningful access. Track and remediate. |
| Minor | Low-impact conformance or usability issue. Backlog. |
The One Question That Settles Most Debates
For every issue your team finds, ask:
Can a person with a disability independently complete the same critical task as other users?
- If yes: the release can proceed with this issue, but needs to be prioritized immediately afterwards.
- If no: the issue is considered a blocker and needs to be remediated before the release conproceed.
Teams should catch most of these issues during planning and design. Even mature testing programs let defects slip through, so your release process must stop them at the final gate.
Digital Accessibility Blockers checklist
Use this list before you approve a release.
1. Keyboard and alternative input
- A user cannot complete a critical workflow using only a keyboard.
- Interactive controls cannot receive keyboard focus.
- Keyboard focus is invisible or extremely difficult to see.
- Focus becomes trapped in a component or modal.
- Keyboard focus moves unexpectedly or skips important controls.
- A user cannot close a modal, dialog, menu, or other overlay using the keyboard.
- A custom control has no usable keyboard interaction.
- Functionality depends exclusively on mouse movement, hover, drag, or touch.
- Drag-and-drop functionality has no accessible alternative.
- Touch targets for critical functionality are too small or difficult to operate.
- A user using switch access, voice control, or another alternative input method cannot operate a critical function.
2. Screen reader access
- Critical content is completely unavailable to screen readers.
- Important controls have no accessible name.
- Controls are announced with the wrong role or purpose.
- Form fields cannot be identified or understood.
- Critical status changes are not communicated to assistive technology.
- Error messages are not announced or associated with the relevant field.
- Dynamic content updates without providing an accessible announcement.
- Reading order does not correspond to the intended information or interaction order.
- Hidden or irrelevant content is exposed to assistive technology in a way that interferes with use.
- Screen reader users cannot determine whether an operation succeeded or failed.
- Essential information is conveyed visually but not programmatically.
3. Forms and transactions
- A user cannot complete a critical form with a screen reader.
- Form fields lack meaningful labels.
- Required fields are not programmatically identified.
- Instructions or constraints are not associated with their fields.
- Validation errors cannot be identified or understood.
- Users lose entered information when an error occurs.
- CAPTCHA or bot protection prevents users with disabilities from completing the workflow.
- Authentication requires an inaccessible interaction.
- A critical transaction cannot be completed without inaccessible verification.
- Time limits prevent users from completing a transaction and there is no accessible way to extend them.
4. Visual presentation
- Critical text does not meet applicable contrast requirements.
- Information is communicated through color alone.
- Interactive states cannot be distinguished visually.
- Focus indicators are missing or effectively invisible.
- Text or controls become unusable when text is enlarged.
- Content overlaps, disappears, or becomes inaccessible when zoomed.
- Responsive layouts create inaccessible horizontal scrolling for essential content.
- Icons or graphical controls have no accessible alternative.
- Important information disappears when users apply operating-system accessibility settings.
5. Content and structure
- Headings do not provide a meaningful structure for critical content.
- Lists, tables, or other semantic structures are incorrectly implemented.
- Page titles are missing or misleading.
- Links do not communicate their purpose.
- Images containing meaningful information lack appropriate alternatives.
- Decorative images are unnecessarily exposed to assistive technology.
- Instructions depend on visual characteristics such as “click the green button.”
- Content changes meaning or becomes unusable when presented in a different orientation or viewport.
- Language changes are not programmatically identified where needed.
6. Multimedia
- Required video content has no captions.
- Captions are materially inaccurate or incomplete.
- Audio-only essential information has no equivalent alternative.
- Video containing essential visual information has no appropriate audio description or equivalent.
- Media controls cannot be operated with a keyboard or assistive technology.
- Automatically playing media interferes with assistive technology or critical functionality.
7. Custom components
Pay particular attention to:
- Dialogs and modals
- Menus
- Comboboxes
- Autocomplete fields
- Tabs
- Accordions
- Carousels
- Date pickers
- Sliders
- Tooltips
- Toast notifications
- Dropdowns
- Data grids
- Drag-and-drop interfaces
- Rich-text editors
For each component, verify that users can discover it, operate it, understand its state, and recover from errors using keyboard and assistive technology.
8. Error recovery
This is an especially important release criterion.
- Users cannot determine what went wrong.
- Errors are presented only visually.
- Errors are not associated with the relevant control.
- Users cannot determine how to correct the problem.
- Correctly entered information is unnecessarily discarded.
- A failed operation leaves the interface in an unusable state.
- Success/failure is communicated visually but not to assistive technology.
9. Critical business workflows
Regardless of individual WCAG criteria, treat these as blockers when a disability prevents completion of a core product task, such as:
- Account creation
- Authentication/login
- Password reset
- Search
- Navigation
- Purchasing
- Checkout
- Payment
- Booking
- Application submission
- Document upload
- Messaging
- Content creation
- Saving/submitting work
- Customer support
- Account management
- Cancellation or modification of a service
10. Mobile accessibility
For native mobile applications, add:
- Critical functionality cannot be completed using VoiceOver or TalkBack.
- Controls have missing, incorrect, or ambiguous accessibility labels.
- Accessibility focus does not follow the intended interaction order.
- Custom gestures have no accessible alternative.
- Critical functionality depends on multi-finger or complex gestures.
- Dynamic content changes are not announced.
- System text-size settings cause content or functionality to become inaccessible.
- Orientation changes cause loss of content or functionality.
- Controls are difficult to activate with touch or assistive input.
- Authentication or security workflows do not work with mobile assistive technology.
Make the Release Gate a Habit
Your team will get the most from a blocker checklist when it applies the checklist consistently, not just on launch day. Build these checks into your definition of done, train QA and product owners to ask the task-completion question, and give your accessibility specialists the authority to call a blocker.
Accessibility doesn’t tax your delivery for the sake of compliance. It decides whether every customer can use what you ship. When you gate releases on user impact, you protect those customers, and you protect your roadmap from fixes that cost far more after launch.
Most of the original was already active, so the changes were small. The main passive constructions were “works best when your team applies it” (reworked so the team is the clear actor throughout) and “is a compliance tax on delivery” (a linking-verb construction I recast with a stronger action verb). I also changed “apply the task-completion question” to “ask the task-completion question,” which reads more naturally.