Elysia Tools
Navigation
Workflow Playbook
Review a page or UI component for structural, reading-order, screenshot-contrast, and color-vision risks, then turn automated findings into a human-reviewed release record.
Hubs
A useful pre-publish audit starts with a reproducible page state rather than a single casual visit. Record the URL or fixture, build identifier, viewport, authentication state, and interactive states such as menus, dialogs, validation errors, and empty results. Screenshots make visual findings comparable, but they do not replace the HTML and behavior that produced them.
Run the structure checker first so obvious labels, alternative text, headings, and landmarks are visible. Follow it with the reading-order simulation and compare the announced sequence with the task a person must complete. A machine can report a suspicious order; a reviewer must decide whether the order is understandable and still test the page with keyboard and appropriate assistive technology.
Use pair checks for known foreground and background values, palette checks for reusable design tokens, and the heatmap for regions that are difficult to enumerate. Color-vision simulations are useful for finding interfaces that communicate only through hue. Retain the actual color values and screenshots, and add non-color cues such as text, icons, patterns, or state labels where the design needs them.
The report should make automated observations easy to trace to a page location and should record retest results. The human review then covers keyboard operation, focus visibility, zoom, reflow, content meaning, and exceptions. Finish with a clear fix, retest, defer, or block decision. This workflow organizes evidence; it does not certify legal compliance or guarantee an issue-free experience for every person.
Workflow playbook
Render the page at the agreed viewports and states, then save screenshots with the build identifier. Include menus, dialogs, errors, and other states that could change focus order, text, or contrast instead of auditing only the landing view.
Submit the representative URL, HTML, or design image to the accessibility checker. Triage missing labels, alternative text, heading and landmark problems, and other detected WCAG risks, while preserving the input and exact finding locations for later comparison.
Send the same page or markup through the screen-reader simulation to examine the sequence of headings, landmarks, controls, labels, and status messages. Compare the exposed sequence with the intended task and mark where a human must test a real screen reader or keyboard.
Use the screenshot heatmap to locate weak-contrast regions, check important pairs or tokens with the contrast tools, and run color-vision simulations to see whether status, emphasis, or controls become indistinguishable. Treat simulated views as risk signals, not user research or a final verdict.
Use the accessibility checker for URL or markup findings, use Website Screenshot when layout and viewport evidence must be repeatable, and keep both inputs when client-side rendering changes the delivered interface.
Treat the checker output as an automated issue list, then use Screen Reader Simulation Tester to inspect headings, landmarks, labels, and reading order. A human still confirms whether the sequence makes sense for the task.
Use a contrast checker for a known foreground/background pair, a palette checker for design tokens, and the heatmap plus color-vision tools for screenshot regions and color-confusion risks. None of these alone proves that the whole interface is compliant.
Use palette and color-token checks where the page is governed by a design system, extract colors from key imagery when needed, and generate a severity-grouped report. A named reviewer then checks keyboard operation, focus visibility, zoom and reflow, content meaning, and exceptions before recording fix, retest, defer, or block.