The Scan accessibility issue detail page expands one accessibility audit across the entire scan.

Instead of inspecting one page in isolation, this view helps identify repeated patterns, shared failures, component problems, template issues, and recurring accessibility risks across a website.

This page is designed for operational review, debugging, prioritization, handoff, and remediation planning.

What this page is for

Use this page to answer questions like:

  • how many pages were affected by this audit?
  • how many pages failed this accessibility check?
  • is this isolated or site-wide?
  • does the issue appear to come from shared templates or repeated content?
  • which pages should be reviewed first?
  • should this be assigned to development, design, content, or QA?

The scan-wide accessibility issue detail page turns repeated Lighthouse results into actionable investigation evidence.

Affected pages

The Affected pages card shows how many URLs in the scan included this audit result.

Large affected counts often indicate:

  • shared templates
  • repeated UI components
  • common content patterns
  • inherited design system problems

Smaller counts may indicate isolated page-level problems.

Failed

The Failed card shows how many pages failed the audit.

Failed audits should generally be prioritized before manual or informational results.

A scan with many repeated failures may indicate a structural accessibility issue rather than isolated authoring mistakes.

Manual

The Manual card shows how many pages require human review.

Manual audits are not necessarily failures. Lighthouse is indicating that the result cannot be fully determined automatically.

These often require:

  • keyboard testing
  • screen reader testing
  • interaction testing
  • visual verification
  • workflow validation

Likely scope

The Likely scope card estimates where investigation should begin.

Examples include:

  • page content
  • shared component
  • template
  • navigation
  • forms
  • theme or CSS
  • mixed

This is intended as operational guidance, not a guaranteed root cause.

Result table

The Result section summarizes the selected accessibility audit.

This includes:

  • audit name
  • audit status
  • Lighthouse score
  • audit ID

The same audit may appear differently across different pages in the scan.

For example:

  • one page may pass
  • another may fail
  • another may require manual review

What this means

The What this means section explains the accessibility concern in operational language.

Siteimp intentionally reframes Lighthouse accessibility output into support and investigation language that is easier to use during debugging, support, QA, and handoff workflows.

What to check

The What to check section provides practical investigation guidance.

These recommendations are intended to help teams review:

  • templates
  • repeated components
  • design systems
  • content patterns
  • keyboard behavior
  • semantic structure
  • assistive technology compatibility

Accessibility work often requires real browser testing and human review.

Affected pages table

The affected pages table lists URLs where this accessibility audit appeared in the scan.

Use this table to:

  • identify repeated patterns
  • prioritize fixes
  • compare affected pages
  • open page-level issue details
  • determine whether the issue is isolated or systemic

Scan-wide versus page-level issue pages

This page shows one accessibility audit across many pages.

The page-level accessibility issue detail page shows one audit on one specific page.

Use the scan-wide page to identify patterns and operational scope.

Use the page-level page to inspect implementation details on a single URL.

Failed to load accessibility issue

If Siteimp shows Failed to load accessibility issue, the application could not load the selected scan-wide accessibility issue.

Return to the Scan accessibility page and reopen the issue.

If the problem continues, collect:

  • the scan number
  • the audit key
  • the error message shown in the application

Then contact technical support.

No accessibility issue is available

If Siteimp shows No accessibility issue is available, the requested audit may not exist for the current scan.

Return to the Scan accessibility page and open an available issue.


Accessibility audit reference

The sections below provide stable anchor targets for scan-wide accessibility audit support.

HelpDrawer routes individual accessibility issue pages into this shared support document using audit anchors.


Heading order

Audit key: heading_order
Lighthouse audit ID: heading-order
Likely scope: page content, template

Summary

Heading levels should form a logical document outline.

What this means across a scan

Repeated heading-order failures often indicate inconsistent content structure, template misuse, or visual styling being used instead of semantic heading levels.

Why it matters

Screen reader users often navigate pages using headings. Poor heading structure can make pages difficult to understand and navigate.

What to check

  • skipped heading levels
  • repeated H1 elements
  • headings used for styling only
  • template-generated heading problems
  • CMS content inconsistencies

How to use this scan-wide result

If many pages fail this audit, investigate shared templates or editorial patterns before fixing pages individually.


Color contrast

Audit key: color_contrast
Lighthouse audit ID: color-contrast
Likely scope: theme, shared CSS

Summary

Foreground and background colors should meet accessibility contrast requirements.

What this means across a scan

Repeated contrast failures often indicate design system or theme-level color problems.

Why it matters

Low contrast can make content difficult or impossible to read for many users, especially users with low vision.

What to check

  • button text contrast
  • muted text colors
  • disabled state styling
  • hover state readability
  • dark mode themes
  • custom component styling

How to use this scan-wide result

If failures appear across many pages, review shared design tokens, component styles, and theme variables before editing individual pages.


Images have alt text

Audit key: images_have_alt_text
Lighthouse audit ID: image-alt
Likely scope: content, CMS workflow

Summary

Images should provide meaningful alternative text when appropriate.

What this means across a scan

Repeated missing alt text often indicates workflow or CMS authoring issues.

Why it matters

Screen reader users rely on alternative text to understand image content and purpose.

What to check

  • missing alt attributes
  • decorative images
  • repeated stock image patterns
  • CMS media workflows
  • image component defaults

How to use this scan-wide result

If many pages are affected, review editorial processes and image component defaults before fixing images individually.


Links have discernible names

Audit key: link_name
Lighthouse audit ID: link-name
Likely scope: components, navigation

Summary

Links should clearly communicate their purpose.

What this means across a scan

Repeated failures often indicate icon-only links, empty links, or navigation component problems.

Why it matters

Users navigating with assistive technologies need meaningful link names to understand navigation targets.

What to check

  • icon-only buttons
  • empty anchor tags
  • navigation components
  • repeated footer links
  • social media icon links

How to use this scan-wide result

If failures repeat across many pages, inspect shared navigation or component systems first.


Form elements have labels

Audit key: form_elements_have_labels
Lighthouse audit ID: label
Likely scope: forms, shared components

Summary

Form controls should have associated labels.

What this means across a scan

Repeated failures often indicate reusable form component problems or incomplete form templates.

Why it matters

Labels help users understand what information is expected in a form field.

What to check

  • missing label elements
  • placeholder-only fields
  • hidden labels
  • reusable form component patterns
  • modal and dialog forms

How to use this scan-wide result

If failures appear across many pages, prioritize investigation of shared form components before page-level fixes.