UI Feature Guide

Actual top-level sections and related workflows

The shipped extension panel currently exposes these review sections: Scan Results, Broken Links, Metadata Check, Language, Keyboard & Focus Order, Interaction Checks, Headings, Browser Preferences QA, Page Review Overlays, Alt Text Analysis, Manual Checks, and Screen Reader Review. The panel opens one section at a time, so inactive sections are hidden while the active section owns the available content area.

A11Y Workspace / Dashboard is still part of the product, but it opens as a separate local extension page behind Open Workspace rather than as a first-row injected panel tab. Ask A11Y Cat, filters, exports, theme, handoff actions, and local-data controls also sit outside the top-level section row.

On first toolbar launch, the extension runs the base page scan and pre-populates Scan Results, Metadata Check, Broken Links, Headings, Language, and Alt Text Analysis for the current page state. Section buttons rerun their own checks when you need fresh evidence.

View current panel overview screenshotView workspace comparison screenshot

How to use this guide

1. 1

   Match the guide to the visible surface you are using

   Each section below maps to a real panel section, page-side helper, or linked workspace area so reviewers can move from the UI they see to the right documentation without translating internal module names first.

2. 2

   Use the technical notes when traceability matters

   The guide names the shipped browser APIs, local libraries, and evidence types so engineers, release reviewers, and auditors can connect the public documentation back to the actual runtime model.

3. 3

   Keep the evidence boundary explicit

   Confirmed, review, advisory, limitation, diagnostic, and workflow output do not mean the same thing. Read the evidence class before turning any result into a defect, release claim, or accessibility statement.

Result classification quick reference

Libraries and browser APIs behind the interface

A11Y Workspace / Dashboard

The workspace is a local extension page opened through Open Workspace. It is not injected into the reviewed page and it is not one of the first-row panel sections. This is where deeper overview, issue-log, comparison, report-builder, diagnostics, and saved-scan workflows live when the small panel is not enough.

1. 1

   Open the workspace after you have a scan worth comparing or handing off

   Use it when you need more than a quick panel review, especially for issue logs, previous-scan comparison, report building, or diagnostics.

2. 2

   Use the overview and issue log as local review navigation, not as a second scan engine

   The workspace reflects the latest saved extension snapshot and local workflow state for the current scope. It helps reviewers move through the evidence already captured.

3. 3

   Compare like-for-like states

   Use the same route, auth state, viewport, and interaction state when comparing previous and current runs. Otherwise the delta may describe a different page state rather than a real regression.

4. 4

   Treat the workspace as local review support, not as a page-level proof surface

   It helps organise evidence, exports, and history, but it still depends on the underlying captured run and does not replace fresh testing on the live page state.

View workspace comparison screenshotRead previous scan and history guideRead exports and local data guide

Scan Results

Scan Results is the main automated review surface. It groups confirmed issues, review items, advisory output, limitations, and diagnostics for the current rendered page state and gives reviewers the direct path to selectors, issue details, highlight actions, exports, and QA handoff controls.

1. 1

   Run the scan on the page state you actually want to review

   The extension uses temporary activeTab access and packaged local script injection for that live page state only. Route changes, auth changes, and dynamic states can change the result set.

2. 2

   Review confirmed issues first, then check what moved into review-only buckets

   High-confidence scanner evidence stays separate from work that still needs human judgement so obvious defects are not buried under ambiguous items.

3. 3

   Use selectors, snippets, filters, and detail views to move from triage to remediation

   Issue details expose rule IDs, selectors, supporting snippets, severity, evidence provenance, and issue actions such as inspect, highlight, selector copy, or QA report inclusion.

4. 4

   Route unresolved review work into Manual Checks, Screen Reader Review, or the relevant feature-specific section

   Scan Results is the hub, not the end of the workflow. Ambiguous evidence still needs a reviewer decision before it becomes a real defect or release claim.

View current Scan Results screenshotView confirmed issues sectionView highlight action

Manual Checks

Manual Checks holds structured review workflow material that the automated scan cannot close out safely. It exists so incomplete or context-dependent evidence does not get flattened into a false pass/fail claim.

1. 1

   Open Manual Checks after Scan Results or a tool routes work there

   Use it when the extension has enough evidence to guide the reviewer but not enough to prove the outcome deterministically.

2. 2

   Read the structured guidance cards before deciding defect status

   Manual checks explain what to inspect next, which selectors or snippets matter, and which parts of the user journey still need direct confirmation.

3. 3

   Record the outcome in your QA workflow, not in the tool alone

   The section organises work and can support exports or highlights, but the actual pass/fail decision still belongs to the reviewer and their release process.

View manual review screenshot

Screen Reader Review

Screen Reader Review is a structured review aid, not a replacement for NVDA, JAWS, VoiceOver, TalkBack, Narrator, keyboard-only testing, or real user-task testing.

1. 1

   Open the aid after you understand the page structure and main findings

   Use it once the automated scan, manual checks, and structural evidence have given you enough context to plan a real assistive-technology check.

2. 2

   Review expected reading order and capture notes

   Use the guided surface to organise what you expect to hear or reach in the user journey, then record observations and follow-up work.

3. 3

   Compare with real assistive-technology behaviour

   Use the target browser and assistive-technology combination for the release decision. Differences found there outrank the virtual aid.

View current Screen Reader Review screenshot

Keyboard & Focus Order

Keyboard & Focus Order is the page-level focus evidence section. It builds a focusable inventory, runs a bounded programmatic focus-order capture for the current page state, separates confirmed findings from review-only findings, and keeps extension-owned UI plus page-side focus badges out of the captured evidence set.

1. 1

   Run Capture focus order on the page state you want to review

   This creates a bounded focus sequence for the current page state. It is not the same as the real debugger-dispatched Tab traversal that lives in Interaction Checks.

2. 2

   Review the summary and finding cards before opening the full sequence

   Confirmed findings are limited to states the capture can actually prove, such as positive tabindex, focusable aria-hidden content, or a fully obscured focused target.

3. 3

   Use Show focus badges only after a capture exists

   The numbered page-side badges help visual inspection, but they are excluded from the focus inventory so they do not contaminate the captured evidence.

4. 4

   Export or report the bounded evidence only when it helps the review record

   Technical details can export focus evidence, add the section to the QA report, or include full focus-order detail when the extra traceability is useful.

Interaction Checks

Interaction Checks is the bounded keyboard-interaction evidence section. It combines real trusted-key traversal where available, safe widget audits, workflow traces, saved run history, and previous-run comparison so QA can capture repeatable interaction evidence without pretending the tool crawled every user task.

1. 1

   Choose the right submode before you run it

   Use Tab traversal for ordered keyboard-path evidence, Widget audits for safe Enter/Space/Escape state checks, Workflow runner for bounded flows such as dialog open/tab/Escape, and History & comparison when regression tracking matters.

2. 2

   Set the run condition and scope explicitly

   You can change traversal preset depth, audit one selected safe widget or a bounded top-3 batch, and rerun under the current page state or a mobile simulated viewport condition.

3. 3

   Review keyboard path, key-state details, and boundary notes together

   Watch for focus loss, hidden focus, positive tabindex, unnamed focused controls, early loops, state-unchanged warnings, missing Escape restore, focus-return gaps, or labelled DOM/scripted fallback evidence.

4. 4

   Use saved-run history and export only when the bounded evidence is useful

   Interaction evidence JSON and QA report inclusion help when QA needs repeatable proof of a regression or a stable handoff record for a known page state.

Headings

The Headings surface helps reviewers inspect semantic structure, visible H1 use, skipped levels, ARIA headings, hidden headings, and heading-like visual text that does not map cleanly to markup.

1. 1

   Open Headings when structure and navigation matter

   Use it for long pages, dashboards, documentation, and flows where screen-reader or keyboard users depend on a sensible outline.

2. 2

   Review semantic order and visible hierarchy together

   Check whether the heading sequence supports the content and whether the visual hierarchy suggests a conflicting structure.

3. 3

   Confirm whether the finding is structural or contextual

   Some pages intentionally break a simplistic outline pattern, so reviewers still need content and layout context before filing every heading warning as a defect.

View current Headings screenshot

Language

The Language tab covers text-quality checks that are useful in accessibility review but need careful interpretation because they can be language-, project-, or content-dependent. In the current public documentation set, that surface includes both language mismatch review and local spelling review.

View current Language screenshotView spelling review screenshot

Alt Text Analysis

Alt Text Analysis separates missing or clearly broken image alternatives from context-dependent cases such as decorative images, linked images, SVG or icon patterns, complex graphics, and background-image situations that need reviewer judgement.

1. 1

   Open Alt Text Analysis when the page uses meaningful imagery

   This surface is most useful on content-heavy pages, product cards, dashboards, and marketing pages where images carry information.

2. 2

   Check image role and context before judging the text alternative

   Review whether the image is informative, functional, decorative, redundant, or complex before deciding what a good alternative should be.

3. 3

   Use the classification, then validate with content context

   Confirmed missing alternatives are strong remediation candidates, but usefulness and quality of alt text still need human content judgement.

View current Alt Text Analysis screenshot

Metadata Check

Metadata Check reviews document-level information such as title, description, canonical URL, Open Graph, Twitter card, and structured data. It helps reviewers catch page-quality and orientation problems that matter to users and downstream sharing surfaces.

1. 1

   Open Metadata Check after the scan

   Use it when you want page-level naming and preview information, not just DOM-level accessibility findings.

2. 2

   Review missing, malformed, or conflicting fields

   Look for missing titles or descriptions, broken canonical values, weak preview metadata, or mismatches between page title and the visible H1.

3. 3

   Decide whether the output is accessibility-critical or quality guidance

   Metadata can affect orientation, findability, and assistive context, but it is often advisory rather than a direct WCAG conformance result.

View current Metadata Check screenshot

Broken Links

Broken Links focuses on supported link-status evidence and is most useful when navigation reliability or dead-end paths matter to the user journey.

1. 1

   Open Broken Links when navigation reliability matters

   Use it to review same-origin links and supported request-status evidence from the browser context.

2. 2

   Check whether the evidence is complete

   Cross-origin, authenticated, blocked, timeout, or rate-limited states can produce limitations or incomplete evidence instead of a confirmed broken-link result.

3. 3

   Confirm real user impact before filing a defect

   Some broken-link evidence is advisory or environment-dependent, so reviewers should confirm whether the failure is reproducible in the target environment.

View current Broken Links screenshot

Browser Preferences QA

Browser Preferences QA is the utility-evidence surface for preference-state review. It owns the utility selection, expected-vs-found summary, tester observations, release evidence gates, and local exports. Page-side badges, outlines, helper status, collapse, and reset behaviour are documented under Page Review Overlays.

1. 1

   Choose the utility or preset that matches the review question

   Use the section for reduced motion, dark mode, high contrast, forced colours, text spacing, focus-review support, and related preference-state evidence for the current tab.

2. 2

   Apply the utility and review expected versus found

   The section is designed to keep the tester grounded in what the utility was supposed to show, what the page actually did, and whether the mismatch is only a heuristic review signal or something stronger.

3. 3

   Save observations and complete release evidence gates where relevant

   The documented gates include tester observation, reset cleanup, browser-level evidence where required, and real forced-colours or assistive-technology proof when the selected utility scope depends on them.

4. 4

   Reset all before continuing

   Reset removes the active preview classes and helper state from the page without reloading it, reducing the risk of carrying review conditions into the next check accidentally.

View current Browser Preferences QA screenshot

Page Review Overlays

Page Review Overlays is the page-side visual review companion. It controls the injected helper, active overlay status, page badges, outlines, review summaries, collapse, and reset behaviour for the active tab without mixing that page-side presentation layer into Browser Preferences QA utility evidence.

1. 1

   Open the helper when you need page-side review context

   The helper uses the dedicated root a11y-cat-browser-preference-qa-root and a11y-cat- prefixed classes so the extension can stress the page visually without counting its own helper as page content.

2. 2

   Choose the overlay mode that matches the review task

   Available overlay categories cover reduced motion, dark mode review, high contrast review, forced colours review, text spacing review, focus review, hidden focusable review, headings, landmarks, links, buttons, forms, and ARIA-state review.

3. 3

   Inspect badges and summaries, then confirm with real user methods

   The overlays help reviewers see where the likely issues are, but the result remains review/heuristic evidence until it is confirmed with manual keyboard, browser, forced-colours, or assistive-technology testing where relevant.

4. 4

   Reset page controls before moving on

   Reset clears the active helper state, overlay classes, and review badges so the next test starts clean.

View related page-review controls screenshotView page highlight action

History, exports, diagnostics, and support workflows

These features support traceability, handoff, and support. Accessibility review is iterative: you need to compare scans, preserve notes, export authorised evidence, and explain coverage limits without overstating what the tool proved.

View previous-scan comparison workflowView CSV export actionView JSON export actionView diagnostics detailsView scan limitations

Shared review controls across the panel

Several important features are not a dedicated first-row section, but they still shape how reviewers work and how accessible evidence moves into handoff, export, or local follow-up workflows.

View severity filtersView issue detailsView highlight actionView handoff dialogView panel resize controlsView theme settingsView clear-data controls