01 / DEVELOPMENT
Choose checks that answer real questions
A test should verify behavior that matters to the task. Begin with the main visitor journey and identify the points where a failure would interrupt it. For a content site, those points may include navigation, search, direct child-page requests, readable layouts, and a working contact state. For a working application, they may include input validation, saved state, permissions, and recovery. Let the product's purpose determine the checks rather than adding tests merely because a framework makes them easy to write.
Use different kinds of evidence for different claims. A type check can catch certain code inconsistencies. A production build can show that the application compiles. A route request can show that a page resolves. A browser interaction can show that a control behaves correctly. A screenshot can reveal wrapping and alignment. None of these establishes every other property. A strong review combines the evidence needed for the conclusion and states the limits of what was actually checked.
Prioritize the consequences of failure. A broken primary action, inaccessible navigation, or misleading success message deserves attention before a minor decorative inconsistency. This does not mean visual quality is unimportant. It means the review should distinguish a defect that blocks the visitor from a refinement that improves an already usable experience. A short prioritized list makes repair work more efficient and avoids spending the entire review on whichever issue is easiest to notice.
02 / DEVELOPMENT
Combine automated and manual review
Automated accessibility tools can identify useful problems, including some missing names, invalid relationships, and contrast issues. They cannot establish complete accessibility on their own. Manual checks are needed for reading order, meaningful labels, keyboard behavior, focus visibility, and the practical clarity of a flow. Where assistive-technology testing is available, include it in the relevant journeys. If it is unavailable, report that limitation instead of implying coverage from a different kind of test.
Inspect responsive behavior with real content. Test a narrow screen, a typical mobile width, an intermediate layout, and a desktop composition. Include long headings and paragraphs, not only the shortest examples. Enlarge text and observe whether the content remains usable without clipping or page-wide horizontal scrolling. A layout can pass a few fixed screenshots and still fail when a user changes text size. Responsive quality includes that adaptation.
Test state changes deliberately. Open and close menus, clear search, apply a filter that returns no results, enter invalid data, and interrupt an operation where the environment permits a controlled check. Confirm that the interface describes each result accurately. For a preview form without a delivery service, the important test is that it cannot imply a successful message transmission. The acceptance check should match the actual implementation rather than a feature that has not been configured.
03 / DEVELOPMENT
Keep a repair loop with evidence
Record a defect with the page, viewport or state, observed behavior, expected result, and a proposed repair. Capture evidence when it helps explain the issue. After changing the relevant component, rerun the affected check and inspect related shared behavior. A repair to a global heading style may need more than one page review because it can change several compositions. A narrow content correction usually needs a narrower verification.
Do not repeat every check indefinitely after an unrelated change. Reuse successful evidence while its inputs remain unchanged, and expand the review when a new failure or concern justifies it. If two attempts on the same issue make no progress, investigate the underlying cause. Repeating the same action with no new information consumes time without improving confidence. A useful test process learns from failures and changes approach when the evidence requires it.
Prepare the handoff so another person can reproduce the result. Record the actual commands, tested routes and states, and any blocked checks. When source is packaged, include the files needed for a clean installation and build. Exclude local dependencies, caches, secrets, and unnecessary scratch material. A clean archive test can reveal missing configuration that the working directory silently supplies. Reproducibility turns a one-session result into a usable project.
Report precisely
Say that the tested routes, viewports, and interaction states passed, and identify the tools or limitations relevant to that statement. Do not claim universal compliance or perfect behavior from a finite review. Precise reporting is more useful than a broad assurance because it tells the next person what they can rely on and where additional evidence may be needed.
For confirmed company and product information, visit Developers. Explore the rest of the reading room for more general guidance.