How should accessibility defects be prioritized during testing?

• A. Defects blocking users with assistive tech or major navigation barriers, especially for essential tasks.
• B. Defects that involve only cosmetic UI color changes.
• C. Defects discovered last during testing.
• D. All defects treated the same regardless of impact.

Answer: (A)

Prioritize accessibility defects by the real impact they have on users, focusing first on blockers for assistive technologies and on barriers that prevent completing essential tasks. When a defect prevents someone from using a product with a screen reader, keyboard, or other assistive tools, or when it blocks a core workflow like logging in, submitting a form, or paying for something, it directly stops meaningful use and must be addressed first.

Think of why these blockers matter: they disable core capabilities and exclude a portion of users from achieving goals with the product. For example, missing or mislabeled form fields can leave a screen reader user uncertain about what to input, and poor focus management can trap keyboard users in a page. In contrast, issues that are purely cosmetic—such as color refinements that don’t affect readability or navigation—do not prevent use and are lower priority unless they actually impede accessibility.

Defects found later in testing shouldn’t automatically take lower priority if they create a critical accessibility barrier, but the most urgent work is still to remove barriers that block essential tasks. Overall, fix the high-impact accessibility problems first, and treat other issues as lower priority unless they directly affect accessibility or core workflows.