Comparing automated and manual findings

Scan an event-registration page, verify the reported results, and use a short manual review to find what automation misses.

Difficulty:: beginner
Estimated time:: 20 minutes

Objectives

Run a reproducible automated check against a defined page state.
Verify and classify each reported target instead of copying tool output directly.
Perform a short keyboard and content review after the automated scan.
Compare detected and missed issues and document evidence for both.

Instructions

Use the Testing with automated tools method to review the event-registration page. Start the exercise from the Exercise workspace.

Record the checker, route, viewport, theme, configuration, and initial UI state.
Run an automated accessibility check and preserve its results.
Locate every reported target in the rendered page and classify it as confirmed, needs review, false or not applicable, or a tooling error.
For confirmed findings, record the rule or message, target, evidence, user impact, and remediation direction.
Complete session selection and registration using only a keyboard, then review the purpose of repeated links.
Find five accessibility problems in total and compare which were reported automatically with which required human review.

Exact tool wording and severity can differ. Return to this page whenever you need a hint or are ready to review the solution, and avoid opening the Solution until you have compared the automated and manual results.

Exercise workspace

Event registration automated testing exercise

Start exercise

The exercise opens on a separate page. Return to this page whenever you need a hint, or when you are ready to continue and review the solution.

You can open the exercise in a new tab if you want to keep these instructions and hints available.

Hints

Inspect each reported target in the rendered page and confirm the issue in context before recording it.
Complete the session-selection and registration task using only a keyboard after the scan.
Compare controls and repeated links that look similar and ask whether their purpose is distinguishable without visual context.

Solution

The fixture contains three findings expected from common automated rules and two that require human review.

Automated — the email field has no accessible label

A visible Email address prompt appears before the input, but it is a paragraph rather than a programmatically associated label. A checker should report the unnamed form field. Confirm the target in context, then associate a visible label with the input using matching for and id values or another appropriate naming method.

Automated — the remove button has no accessible name

The saved-session button contains only a symbol hidden from the accessibility tree, leaving the button unnamed. A checker should identify the button-name failure. Give the button a concise name that includes the action and, when needed, the affected session.

Automated — the registration helper has insufficient contrast

The helper text has approximately 2 to 1 contrast against its background in both themes. A checker should report the affected text and measured pair. Use a foreground color that meets the applicable text-contrast requirement in every supported theme.

Manual — session selection is pointer-only

Choose this session responds to a pointer click and changes state, but it is not a native control, cannot receive keyboard focus, and has no keyboard activation. An automated scan does not establish that the intended interaction works. Use a native button or implement equivalent semantics, focusability, state, and keyboard operation.

Manual — Read more links do not distinguish their destinations

Both links expose the same Read more name while leading to different session details, and the allowed surrounding context does not make the destination clear. Tool output varies for contextual link-purpose judgments. Use link text that identifies the relevant session or provide an equally clear accessible name consistent with the visible purpose.