A registration form can accept valid details and still prevent someone from booking a place. A keyboard user might never reach the submit button. A screen-reader user might hear that a field is invalid without learning which field needs attention. A scan can help find defects, but a clean report does not establish that people can complete the task.
Accessibility testing evaluates web content and interactions for barriers affecting people with disabilities. It combines checks against defined requirements with human assessment of how information, controls, and feedback work together. The useful result is evidence about specific barriers and tested behavior, with a clear account of what remains unexamined.
The Web Content Accessibility Guidelines, or WCAG, provide testable success criteria organized around four principles: perceivable, operable, understandable, and robust. For a web application, these principles concern whether people can obtain its information, operate its functions, understand its behavior, and use it with relevant technologies, including assistive technologies.
Specify the WCAG version and conformance level before assessing the page. WCAG 2.2 is a published W3C Recommendation. Its levels are A, AA, and AAA; Level AA includes all Level A and Level AA success criteria. A target of WCAG 2.2 AA therefore does not mean checking only criteria labeled AA. Choose the applicable target from your organization's requirements rather than assuming every project has the same obligations.
Conformance has a broader scope than a short test session. WCAG includes requirements for full pages and complete processes, as well as accessibility-supported uses of technology and non-interference. If registration continues through verification and confirmation pages, assessing the first form alone cannot establish conformance for the complete process.
Describe a limited assessment accordingly: name the pages, states, methods, and criteria examined. Avoid turning “no failures in this scan” into “WCAG compliant.” Technical findings also do not, by themselves, establish compliance with every applicable law.
Automated accessibility testing applies implemented rules to the content the tool examines. It is useful for repeatable detection of problems those rules can identify. Depending on the tool and configuration, that can include missing form labels, missing image alternatives, and certain contrast failures. Different tools support different rules and scopes, so document what yours evaluated.
Some findings need investigation, and some requirements need human evaluation from the start. W3C WAI cautions that tools cannot check all accessibility aspects automatically and can produce false or misleading results. There is no useful universal percentage to apply to every tool, page, and definition of coverage.
Accessibility Insights for Web provides a concrete model. Its Assessment documentation separates automated requirements, assisted requirements where the tool helps identify or evaluate instances, and manual requirements where it supplies instructions for a person. Its current assessment targets WCAG 2.2 AA. That classification helps allocate work; it does not remove the evaluator's responsibility to complete the checks and record credible results.
Image alternatives illustrate the division. A tool can detect that an image lacks an alt attribute. Deciding whether existing alternative text communicates the image's purpose requires context. A decorative illustration may need an empty alternative, while an image acting as a button needs a meaningful account of its action. The presence of text such as “image” does not establish that an informative diagram is accessible.
Keep automatic findings, items awaiting judgment, and completed human decisions distinguishable. A report with no automatic failures can still contain substantial unfinished work.
Consider a fictional workshop registration page with a session selector, contact fields, a terms dialog, a timetable image, and a submission message. The following assessment and observations are illustrative, not results from an executed accessibility test or a customer implementation. Assume the team's chosen target is WCAG 2.2 AA.
Define the task as choosing a session, reviewing the terms, correcting an invalid email address, and submitting the registration. Include the initial form, the open dialog, the validation-error state, and the success state. Those states expose different information and controls even if the browser address never changes.
Record the application build, browser and operating system versions, viewport, test data, and relevant settings. For assistive-technology checks, also record the technology, version, and configuration. Use approved test data rather than real attendee details. Confirm that the environment allows keyboard navigation as intended before interpreting an unreachable control as a product defect.
Start with the initial form and preserve the tool's rule identifiers, affected elements, and original observations. In this fictional example, suppose the scan reports that the email field has no associated label. Confirm the affected element and examine its intended name rather than assuming that nearby visible text is programmatically associated with the field.
Next, deliberately reach the error and dialog states and run the appropriate checks again. Do not assume a scanner automatically opens overlays, submits forms, or discovers every authenticated path. A report on the untouched form may say nothing about controls inserted after a failed submission.
Keep the report tied to the state and build examined. If a result needs manual review, retain that uncertainty until someone evaluates it. Suppressing a rule because its output is inconvenient would hide the question rather than answer it.
Put the pointer aside and follow the registration task using the keyboard. Tab and Shift+Tab normally move between focusable controls; composite widgets may use arrow keys within the component. Check the expected interaction pattern instead of requiring every internal item to be a separate Tab stop.
Evaluate whether the sequence is understandable, whether focus is visible, and whether each needed action can be performed. In this scenario, suppose an automatically displayed sticky banner entirely covers the submit control when it receives focus. The control exists and is reachable, but the person cannot see the current interaction point. That observation supports investigation against WCAG 2.2's Focus Not Obscured (Minimum), a Level AA criterion concerning focused components entirely hidden by author-created content. Partial obscuring and user-opened content require more careful interpretation of the criterion's conditions.
The terms dialog needs a separate interaction check. The WAI-ARIA modal dialog pattern moves focus inside when the dialog opens, keeps its Tab sequence inside while open, supports Escape to close, and normally returns focus to the invoking control. A different return location can be appropriate when the workflow changes or the invoker no longer exists.
Intentional focus containment in an open modal is different from an inescapable keyboard trap. Check that the user can dismiss the dialog and continue registration. These pattern-based expectations help evaluate this example; they are not a substitute for assessing the applicable WCAG criteria.
A screen-reader review should follow the task, not merely listen to the page from beginning to end. Check whether headings help orientation, fields expose meaningful names, and the terms dialog can be understood and operated. Use someone competent with the chosen screen reader so unfamiliar commands do not become mistaken product findings.
Submit an invalid email value and examine the feedback. WCAG's Error Identification criterion requires automatically detected input errors to identify the affected item and describe the error in text. A red border alone cannot provide that description. Whether the message gives a helpful correction is another question; error identification and error suggestion are distinct requirements.
Now suppose successful submission adds “Registration received” without moving focus or navigating to another page. Evaluate whether that status is available to assistive technology. WCAG's Status Messages criterion addresses status information that does not involve a change of context. A focus-taking dialog is a different situation. Avoid turning every content update into an interrupting alert.
Review the timetable image in context as well. If it contains session times absent from the surrounding text, an alternative reading only “timetable” may identify the image without supplying its information. A human reviewer must decide what equivalent information the page needs. Separately enlarge text and inspect whether labels, instructions, and controls remain readable and usable. These visual checks answer questions that a successful keyboard journey alone cannot settle.
Keep observations separate from the decision made about them. The following fictional records show how the same page can produce different kinds of evidence. They do not represent a complete WCAG assessment.
Review Method | Illustrative Observation | Recorded Decision | Follow-Up |
|---|---|---|---|
Automated check with confirmation | Email control lacks an associated label | Confirmed barrier after inspecting the control's exposed name | Correct the association and repeat the scan and task check |
Keyboard and visual review | Automatic sticky banner entirely hides the focused submit control | Failed focused-component visibility check in the tested state | Fix overlap and retest the affected viewport and task |
Screen-reader task review | Non-focus submission status is not announced in the tested configuration | Investigate programmatic status exposure and confirm the applicable criterion | Correct the implementation, then repeat with recorded technology settings |
Contextual content review | Timetable alternative names the image but omits its unique session information | Human judgment: equivalent information is missing | Supply the information accessibly and review it in context |
For the keyboard finding, write a reproducible record rather than “focus broken.” Identify the page state and viewport, then describe the steps: reach the final form control, advance to Submit, and observe its position relative to the automatic banner. State the expected behavior: the focused component must not be entirely hidden by that author-created content.
Record the actual observation that supports the decision, with a screenshot or short recording where appropriate. The reviewer should explain why this is an obstruction of the focused component rather than merely an unattractive focus indicator. A developer can then reproduce the same state, and a second reviewer can evaluate the reasoning.
A useful execution record also identifies:
Keep the reusable specification separate from the result on a particular build. Updating the expected dialog behavior should not rewrite what an earlier attempt checked. For teams keeping these records in Jira, the test case template and worked manual examples provide a practical record structure. Using that structure does not imply that Jira itself performs accessibility scans or supplies a dedicated test-run model without additional configuration or an app.
After a fix, repeat the affected check on the identified new build with the relevant starting state. For the banner defect, confirm both that the control is visible and that the person can continue submitting the form. Preserve the original failure alongside the new attempt. A clean scan on the repaired page cannot replace the manual check that originally exposed the obstruction.
Use outcomes that reflect the available evidence. “Not tested” means no result exists. “Blocked” describes a check that could not be completed because a prerequisite failed. An item awaiting human judgment remains unresolved. Define these labels in your own reporting process instead of treating every absence of a failure as a pass.
Prioritize confirmed barriers by their effect on users and important tasks. WCAG levels are not severity rankings: a failure's impact also depends on its frequency, context, and whether people have a usable alternative. Assign an owner and make unresolved release risks explicit rather than hiding them in an aggregate score.
Include disabled people in evaluation where appropriate to the product and task. Their experience can reveal usability barriers that criteria-based checks alone miss. Combine that involvement with standards evaluation, and avoid generalizing from one participant or one browser and screen-reader combination to everyone with a disability. Report the scope and limitations of both kinds of assessment.
Choose one important journey in the next release and define its target, states, and expected behavior. Use automation for the rules it can evaluate, then assign the remaining keyboard, assistive-technology, visual, and contextual checks to people able to judge them.
The release reviewer needs a traceable answer to a practical question: which barriers were confirmed, which were retested successfully, and which questions remain open? A bounded result with clear human reasoning supports that decision better than an unexplained accessibility score.
A confirmed flaky test can block unrelated changes without providing a dependable release signal. Removing that obstruction is reasonable only if someone still sees…
A green automated test history can help a developer identify a safe-looking change while leaving a QA lead unable to answer a different question:…
A sprint can contain carefully estimated testing work and still overload the only person who can perform it. The missing input may be a…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
