Software QA / Intermediate: integrated product evidence / Lesson 10
Accessibility as observable usability
Evaluate an enrollment form with keyboard navigation, accessible names, error recovery, and readable presentation. Combine automation with manual checks and clearly bound any conformance claim.
On this page
Lesson goals
- Use WCAG criteria as testable references.
- Observe keyboard, focus, names, and errors.
- Explain what automated accessibility checks cannot establish.
Translate access needs into evidence
Accessibility testing asks whether people with different abilities can perceive information, operate controls, understand feedback, and use supported technologies. WCAG supplies published success criteria, but a criterion is not a complete test script. Select the relevant version and target level, define pages and complete processes in scope, and record tested technologies. An enrollment flow includes discovery, entry, validation, confirmation, and recovery. A clean landing page cannot establish that the complete process is accessible. Include people with disabilities in evaluation where feasible, while keeping their experience distinct from a claim about every user.
Worked case: keyboard enrollment
Start at the page top without a mouse. Tab through the form, observe a visible focus indicator, activate controls with their expected keys, and submit an invalid value. Expect a logical focus order and a way to reach and correct the invalid field without becoming trapped. If a modal opens, check entry, operation, closing, and focus return to the initiating control. Record exact steps and the browser/assistive-technology combination. A control that reacts to a mouse click but cannot be reached or named meaningfully is not adequately covered by a mouse-based happy-path test.
Step | Observation required
Tab to enrollment fields | logical order and visible focus
Inspect email field | accessible name identifies purpose
Submit invalid email | text identifies error and correction
Open/close help dialog | usable controls; focus returnsEach observation is evidence for a particular behavior; other criteria still need evaluation.
Check semantics and meaningful feedback
Inspect whether each input has a programmatically associated name, whether headings describe structure, and whether status updates can be perceived without moving focus unnecessarily. A placeholder that disappears during typing is not a dependable substitute for an enduring label. Required fields and errors should not rely on color alone. For an invalid date, useful feedback identifies the affected field and expected format, and preserves other valid entries. Test the correction path, because announcing an error without enabling recovery still leaves a user blocked. Avoid adding ARIA indiscriminately; native semantics often provide simpler, more consistent behavior.
Worked case: contrast and enlargement
For ordinary text, WCAG 2.2 success criterion 1.4.3 uses a minimum contrast ratio of 4.5:1, with a 3:1 threshold for qualifying large text and stated exceptions. Check the actual foreground/background combination, including error text and disabled-looking but active controls. Separately enlarge text and inspect reflow at the relevant conditions: can a learner read the price and submit without clipped content? Passing contrast does not prove zoom usability. Record the measured colors and element state, because hover, focus, and error presentation may use different combinations.
Combine tools with judgment
Automated checks can identify some missing names, invalid structures, and detectable contrast issues. They cannot determine whether alternative text communicates the purpose of an image, whether focus order supports a task, or whether an error message is understandable in context. Use tools as repeatable evidence within a broader evaluation. Report pages, states, criteria, methods, and unresolved findings rather than a blanket “accessible” badge. Recheck after design or content changes, since a translated button label or newly inserted dialog can alter names, layout, reading order, and recovery behavior.
Common errors and fixes
A zero-error scan is called full accessibility
- Why it happens
- The tool’s detectable subset is confused with all criteria.
- How to fix it
- Add manual task, keyboard, and assistive-technology evaluation.
- Prevent it next time
- State method and criterion coverage in reports.
Errors are indicated only in red
- Why it happens
- Visual styling substitutes for meaningful feedback.
- How to fix it
- Add associated text and a usable correction path.
- Prevent it next time
- Test errors without relying on color perception.
Focus disappears when a dialog closes
- Why it happens
- The interaction lacks a deliberate focus lifecycle.
- How to fix it
- Return focus to the initiating control and verify keyboard continuation.
- Prevent it next time
- Include open/close sequences in component acceptance.
Check your understanding
1. An enrollment page passes automated checks. What two manual cases add value?
Show worked solution
Complete enrollment with keyboard only, including an error and correction; then inspect a help dialog’s opening, closing, and focus return with a supported assistive technology. Record task completion and meaningful names. These cases investigate interaction and comprehension beyond a scan’s detectable rules.
2. A label has 4.6:1 contrast but is clipped at enlargement. Is that acceptable evidence?
Show worked solution
It supports the specific ordinary-text contrast check for that state, but clipping is a separate problem requiring investigation against the applicable resize/reflow criteria. Report both observations, preserve the tested viewport and enlargement settings, and retest the task after a layout fix.
Key takeaways
- Evaluate complete tasks and recovery, not only individual controls.
- Bound accessibility claims to evaluated scope, criteria, and methods.