slop auditAccessibility checks before launch work best as a short sequence that follows the main task. Start with the page a visitor receives, use the keyboard and a narrow viewport, and record where the interface becomes hard to see, understand, or use.
This is not a full accessibility audit or a legal compliance review. It is a developer check for common public-page problems while the fix is still close to the code.
Check the page structure
Use one clear page heading and a logical heading hierarchy. A heading should describe the section that follows it, not simply make text larger. Do not skip levels just to achieve a visual size.
The first screen should state what the page is and what to do next. People using a screen reader, a search result, or a tool should not have to guess from a slogan.
Check the HTML and the rendered page together. A heading can be in the HTML but hidden, duplicated, or out of order on screen.
Check labels, names, and errors
Every form control needs an accessible name that still makes sense when read without the surrounding design. A placeholder is not a durable label: it disappears when the user types and often has low contrast.
When the URL is invalid or a scan cannot start, connect the error to the field, announce it to assistive technology, and say what to do. “Invalid input” is less useful than “Enter a public URL beginning with https://.”
The same principle applies to icon-only buttons. Give them a visible tooltip if useful, but always provide an accessible name in the DOM. A close icon, clear field button, menu toggle, and theme control should each announce its purpose.
Follow the keyboard path
Start at the public URL and press Tab. The focus order should follow the reading and task order. Focus should remain visible against both the paper background and darker panels. Opening a menu or dialog should not leave keyboard users behind an overlay or move them to an unrelated part of the page.
Check this sequence:
- Move from the navigation to the main heading and primary action.
- Open every interactive control on the main path.
- Confirm that Escape closes dismissible overlays when appropriate.
- Verify that focus returns to the control that opened an overlay.
- Complete the action without requiring a pointer-only gesture.
If a route changes without a full page load, announce the new page and move focus to the new main content. Otherwise the URL may change while the person still hears the old page.
Test narrow widths and target size
Responsive accessibility is more than avoiding horizontal scroll. Keep the order, spacing, and target sizes usable on a small screen.
Check the primary action, menu, clear controls, links, and form fields at a narrow phone width. Text should not be clipped, controls should not overlap, and a sticky navigation bar should not cover the heading or focused element. Zoom the page to 200 percent if your workflow allows it; layout problems often appear before a desktop screenshot shows them.
Do not fix every collision with another breakpoint. Decide which content matters first, then update the layout.
Review contrast and motion
Muted text can be hard to read. Check body text, helper text, disabled states, focus rings, borders, and text on accent or dark backgrounds. A border that disappears can make a field or focus state hard to see.
Motion should show a state clearly. A scan indicator can show that a request is running, but it should not claim that a stage is complete before the report confirms it. Respect reduced-motion preferences. Use the prefers-reduced-motion implementation and testing guide to adapt CSS and JavaScript movement while keeping content and controls usable.
Know what automation cannot prove
Automated checks can find missing names, obvious overflow, some contrast problems, heading issues, and visible keyboard focus. They cannot decide whether instructions are clear, whether the focus order makes sense, or whether a person can recover from an error.
Use the output for the next review, not as a certificate. A good launch check combines automated checks, a real browser path, and a human review of the main task.
Fix accessibility issues before you share the public URL. Run the route again after the change and keep the before-and-after evidence with the release.