The Accessibility checks page provides a focused accessibility evidence view for one page inside a scan.

Siteimp derives these checks from Lighthouse accessibility audits, then reshapes them into a compact operational workflow designed for review, debugging, support, and handoff to developers or content teams.

This page intentionally avoids dumping the full Lighthouse JSON payload into the interface. Instead, it presents curated accessibility evidence in a form that is easier to scan, filter, explain, and act on.

Accessibility is treated as practical operational evidence here, not just a score.

What this page is for

The Accessibility checks page helps answer questions like:

  • what accessibility score did Lighthouse report for this page?
  • which accessibility-related audits were collected?
  • which audits failed?
  • which audits require manual review?
  • which audits were not applicable?
  • which checks should be reviewed first?
  • which Lighthouse audit produced this row?
  • which accessibility issue should be opened next?

This page is designed to support both quick scanning and deeper investigation.

Accessibility score

The Accessibility score card shows the Lighthouse accessibility score for the page.

The score is reported as a whole number out of 100.

Important: the score reflects the complete Lighthouse accessibility scoring model, not only the curated rows displayed in Siteimp.

That means:

  • Siteimp may show a relatively small number of curated checks
  • the Lighthouse accessibility score may still include additional weighting and audits behind the scenes

Use the score as orientation, then use the table and issue flows as evidence.

Overview cards

The overview section summarizes the current page accessibility state.

Accessibility score

The Lighthouse accessibility score for the page.

Checks

The number of curated accessibility checks displayed by Siteimp.

Pass

The number of checks that passed.

Fail

The number of checks that failed.

These cards help identify whether the page likely requires deeper review before you even inspect the table.

Filtering accessibility checks

The page now includes accessibility filtering controls similar to the Images workflow.

You can filter the table by status to reduce noise and focus on the audits that matter most.

Common filters include:

  • Pass
  • Fail
  • Manual
  • N/A
  • Partial
  • Unknown

This makes large accessibility result sets easier to work through systematically.

For example:

  • use Fail to focus only on actionable issues
  • use Manual to review audits requiring human judgment
  • use N/A to confirm whether checks simply did not apply to the page

The filter system is especially useful when reviewing larger scans or accessibility-heavy workflows.

Clickable accessibility rows

Accessibility rows are now fully clickable.

Selecting a row opens a dedicated accessibility issue detail view for that audit.

This creates a much cleaner workflow than forcing users to manually cross-reference audit IDs or scan long tables repeatedly.

The accessibility flow now behaves more like the rest of Siteimp:

  • summary view
  • evidence list
  • focused issue detail
  • affected pages
  • operational guidance

This keeps navigation consistent across the application.

Checks table

The Checks table contains the curated accessibility rows Siteimp derived from Lighthouse.

Check

The human-readable accessibility audit name.

Examples include:

  • headings follow a logical order
  • images have alt text
  • buttons have accessible names
  • form elements have labels
  • links have descriptive text

Status

The interpreted accessibility state for the audit.

Possible values include:

  • Pass
  • Fail
  • Manual
  • Partial
  • N/A
  • Unknown

Score

The Lighthouse audit score when available.

Not every audit produces a meaningful numeric score.

Audit id

The original Lighthouse audit identifier.

This is useful when connecting Siteimp evidence back to Lighthouse documentation, debugging notes, or developer work.

Accessibility issue drilldown pages

Selecting a row opens a dedicated accessibility issue detail page.

These pages provide a deeper operational view of one accessibility audit across the scan.

Issue detail pages can include:

  • affected page counts
  • pass/fail/manual summaries
  • practical explanations
  • likely scope
  • impact descriptions
  • what to check
  • affected pages tables
  • related evidence

This creates a much more actionable accessibility workflow than a raw Lighthouse export.

Manual checks

Some Lighthouse accessibility audits require human judgment.

These audits appear with a Manual status.

Examples include:

  • whether controls communicate purpose clearly
  • whether focus behavior feels predictable
  • whether navigation is understandable
  • whether custom controls behave accessibly

Manual does not mean the page failed.

It means automated tooling alone cannot fully verify the result.

Why accessibility still requires human review

Automated accessibility auditing is extremely useful, but incomplete.

A page can score highly and still create serious usability problems for real users.

Automated tooling cannot fully determine:

  • whether content is understandable
  • whether navigation feels intuitive
  • whether keyboard interaction is comfortable
  • whether screen reader output is usable in context
  • whether dynamic UI behavior is confusing
  • whether workflows are mentally exhausting

Siteimp treats accessibility evidence as operational visibility, not certification.

Common investigation patterns

Failed heading order audits

Review the page heading structure.

Look for:

  • skipped heading levels
  • decorative headings used for sizing
  • multiple unrelated h1 elements
  • deeply nested heading jumps

The Heading outline page is often useful here.

Failed alt text audits

Review images that may require meaningful alt text.

Check whether:

  • informative images have descriptive alt text
  • decorative images use empty alt text correctly
  • repeated alt text became redundant
  • screenshots or diagrams are explained properly

The Images workflow is often the fastest next step.

Failed label audits

Inspect form controls and interactive elements.

Check for:

  • missing labels
  • placeholder-only inputs
  • unlabeled buttons
  • icon-only controls
  • incorrect aria-label usage

Manual keyboard audits

Test the page directly using the keyboard.

Verify:

  • focus visibility
  • tab order
  • focus trapping
  • modal behavior
  • keyboard reachability

Accessibility page not found

If Siteimp shows Accessibility page not found, the route did not include a valid scan and page combination.

Return to the Page results view and reopen Accessibility checks from the page detail workflow.

Failed to load page accessibility

If Siteimp shows Failed to load page accessibility, the application could not load accessibility-derived data for this page.

Return to the Page results view and try again.

If the issue continues:

  • rerun the scan
  • confirm Lighthouse completed successfully
  • verify the page could be fetched normally
  • contact technical support if the problem persists

Include:

  • the scan number
  • the affected page URL
  • the exact error text shown in the app

Why this page may appear mostly empty

Some pages naturally produce very few accessibility-derived rows.

This can happen when:

  • the page is extremely small
  • Lighthouse could not fully audit the page
  • the page contains very little interactive content
  • accessibility-derived evidence was unavailable for the scan

An empty or minimal table does not automatically mean the page is fully accessible.