Check designs, components, code and releases

Define the task and interaction states

Before design or build work starts, record the task the visitor must complete, affected pages, user groups, content type and every state of the interaction. Include empty, error, success, expanded, modal and responsive states where relevant. Confirm what content meaning must remain available and which team owns the labels, instructions and alternative text. Check the design against the current shared pattern before introducing a new component.

During design review, inspect reading order, headings and labels, keyboard sequence, focus visibility, error and status messaging, contrast, zoom and reflow. Identify any motion or gesture that needs an alternate interaction. Give design feedback while changes remain inexpensive. For background on specific patterns, use the existing guides for forms, tables and page structure.

Check the implemented component in realistic content

On a staging or approved test environment, test the actual code with realistic labels, long text, errors, repeated content and small-screen layouts. Run automated checks on changed pages and representative examples of every template that uses a changed component. Record tool name, version, ruleset, URL, date and result. Confirm flagged issues instead of copying scanner labels into the release record without investigation.

Manually complete the intended task with a keyboard, visible focus and increased zoom. Check text resize and reflow at narrow widths. Use an appropriate screen reader for changed controls, names, relationships, status announcements and form results. Test the browser and assistive-technology combinations that the review scope names; mark untested combinations explicitly. An empty component or isolated screenshot is not enough when content changes the layout or meaning.

Document each defect with location, state, steps to reproduce, impact, assigned owner, proposed correction and target date set by the responsible owner. Shared components need a regression check in the representative pages that depend on them.

Record the release decision and verify production

Hold publication until the Reviewer records the scoped checks, recommendation, unresolved issues and authorized decision. Label each untested case. If District policy permits a formal exception, record the authorized decision-maker, rationale, affected users and task, accessible alternative, owner and review date; the checklist itself grants no exception authority.

After deployment, open the public page while signed out and repeat the key task. Confirm the live component, correct document, links, labels and confirmation state. Keep a recovery reference for technical releases. If a production barrier appears, notify the Reviewer, record an issue, and repair or roll back under the approved recovery plan.

See review and publish a website update for the editor handoff.

Use a working record

Complete a record when the activity occurs, download it and retain it in the approved team location.

• Publishing and release acceptance