Accessibility issue detail

Review one page-level accessibility audit result, including its status, score, source Lighthouse audit ID, explanation, impact, and suggested checks.

The Accessibility issue detail page explains one accessibility audit result for one scanned page.

You usually reach this page by opening Page results, choosing Accessibility checks, and selecting one row from the checks table.

This page is more focused than the main Accessibility checks table. It shows the selected audit, the page result, the Lighthouse audit ID, and Siteimp's explanation of what the issue means.

What this page is for

Use this page when you want to understand one accessibility result without reading the full Lighthouse report.

It helps answer:

what did this audit check?
did this page pass, fail, require manual review, or return another status?
what Lighthouse audit produced the result?
what does this issue usually affect?
what should a reviewer or developer check next?

This page is evidence, not certification. Automated accessibility checks are useful, but they do not prove that a page is fully accessible.

Page score

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

This score reflects Lighthouse's overall accessibility model. It may include more than the specific audit shown on this detail page.

Audit status

The Audit status card shows Siteimp's interpreted status for this audit result.

Common statuses include:

Pass: Lighthouse reported the audit as passing.
Fail: Lighthouse reported the audit as failing.
Partial: Lighthouse reported a non-binary result.
Manual: the audit requires human judgment.
Info: the audit is informational.
N/A: the audit was not applicable on this page.
Unknown: Siteimp could not map the result clearly.

Manual, informational, and N/A results are not the same as failures.

Audit score

The Audit score card shows the score for this specific audit when Lighthouse provides one.

Some audits do not provide a score. In those cases, Siteimp shows an empty value.

Audit ID

The Audit ID card shows the source Lighthouse audit identifier.

This is useful when creating developer tickets, comparing results against Lighthouse output, or searching technical references.

Result table

The Result table repeats the selected audit in a compact row.

It shows:

the friendly Siteimp audit title
a short description
the interpreted status
the audit score
the source Lighthouse audit ID

What this means

The What this means section explains the audit in plain language.

It is written for practical review and handoff. It avoids relying on raw Lighthouse wording so the app can keep a stable support experience even when Lighthouse versions change.

What to check

The What to check section lists practical review steps.

These are not guaranteed fixes. They are starting points for inspection, debugging, and developer handoff.

Failed to load page accessibility issue

If Siteimp shows Failed to load page accessibility issue, the app could not load the selected issue detail.

Return to the page's Accessibility checks table and open the row again.

If the problem continues, contact technical support and include:

the scan number
the page URL
the audit key or audit ID
the error text shown in the app

No page accessibility issue is available

If Siteimp shows No page accessibility issue is available, the route may not match a valid audit for that page.

Return to the page's Accessibility checks table and choose an available audit row.

Audit reference

The sections below provide anchor targets for each supported accessibility audit. The HelpDrawer can route individual audit pages to this shared support file and land on the relevant section.

Access keys are unique

Audit key: accesskeys
Lighthouse audit ID: accesskeys
Likely scope: page_content

Summary

Keyboard access keys should not conflict with each other.

What this means

Access keys let people trigger controls or links from the keyboard. If two elements use the same access key, keyboard users may not know which control will activate.

Why it matters

Duplicate access keys can make keyboard navigation unpredictable.

What to check

Look for repeated accesskey attributes.
Remove access keys unless they are clearly needed.
Make sure any remaining access keys are unique on the page.

How to use this result in Siteimp

Open the affected page, compare the status and audit score with the guidance above, then use the page content, template, component, or styling layer suggested by the likely scope as the starting point for review.

ARIA attributes match their roles

Audit key: aria_allowed_attr
Lighthouse audit ID: aria-allowed-attr
Likely scope: shared_template_or_component

Summary

ARIA attributes should only be used where they are valid for the element or role.

What this means

ARIA can improve accessibility when it matches the element’s purpose. When an ARIA attribute is used on an incompatible role, assistive technology may ignore it or announce the element incorrectly.

Why it matters

Invalid ARIA can make controls harder to understand for screen reader users.

What to check

Review the element using the ARIA attribute.
Confirm the attribute is allowed for that role.
Prefer native HTML controls when possible.

How to use this result in Siteimp

ARIA roles are used on compatible elements

Audit key: aria_allowed_role
Lighthouse audit ID: aria-allowed-role
Likely scope: shared_template_or_component

Summary

ARIA roles should fit the element they are applied to.

What this means

A role changes how an element is exposed to assistive technology. If the role does not fit the underlying element, users may receive confusing or incomplete information.

Why it matters

Screen reader users may hear the wrong type of control or miss expected behavior.

What to check

Check whether the role is needed.
Use a native HTML element if one exists.
Confirm the role is allowed for the element.

How to use this result in Siteimp

Command elements have accessible names

Audit key: aria_command_name
Lighthouse audit ID: aria-command-name
Likely scope: shared_template_or_component

Summary

Buttons, links, and menu items need names that assistive technology can announce.

What this means

Interactive elements need accessible names so people using screen readers or voice control know what each control does.

Why it matters

Unnamed controls can leave users guessing what action a button or link performs.

What to check

Check buttons, links, and menu items.
Add visible text where possible.
Use aria-label only when visible text is not practical.

How to use this result in Siteimp

Conditional ARIA attributes are used correctly

Audit key: aria_conditional_attr
Lighthouse audit ID: aria-conditional-attr
Likely scope: shared_template_or_component

Summary

Some ARIA attributes are only valid in specific role or state combinations.

What this means

ARIA attributes often depend on the element’s role or current state. Using them outside the required conditions can create confusing accessibility information.

Why it matters

Assistive technology may announce inaccurate state or relationship information.

What to check

Review the role on the affected element.
Check whether the ARIA attribute requires another role or state.
Remove attributes that do not apply.

How to use this result in Siteimp

Deprecated ARIA roles are not used

Audit key: aria_deprecated_role
Lighthouse audit ID: aria-deprecated-role
Likely scope: shared_template_or_component

Summary

ARIA roles that are no longer recommended should be replaced.

What this means

Deprecated roles may still appear in old examples or older components. Replacing them helps keep accessibility behavior aligned with current platform expectations.

Why it matters

Old roles may be poorly supported or confusing in newer assistive technology.

What to check

Find the deprecated role.
Replace it with the current recommended role.
Use native HTML where possible.

How to use this result in Siteimp

Dialogs have accessible names

Audit key: aria_dialog_name
Lighthouse audit ID: aria-dialog-name
Likely scope: shared_template_or_component

Summary

Dialog and alert dialog regions need names that describe their purpose.

What this means

When a dialog opens, screen reader users need to know what the dialog is for. An accessible name usually comes from a heading or label connected to the dialog.

Why it matters

Users may enter a dialog without knowing what task or message it contains.

What to check

Check dialog components.
Connect the dialog to a visible heading with aria-labelledby.
Use aria-label only when there is no visible heading.

How to use this result in Siteimp

The page body is not hidden from assistive technology

Audit key: aria_hidden_body
Lighthouse audit ID: aria-hidden-body
Likely scope: shared_template_or_component

Summary

The document body should not be marked aria-hidden.

What this means

Putting aria-hidden on the body can hide the entire page from screen readers and other assistive technology.

Why it matters

Assistive technology users may be unable to access the page content.

What to check

Search for aria-hidden on the body element.
Remove it from the body.
Apply hiding only to specific decorative or inactive regions when appropriate.

How to use this result in Siteimp

Hidden regions do not contain focusable elements

Audit key: aria_hidden_focus
Lighthouse audit ID: aria-hidden-focus
Likely scope: shared_template_or_component

Summary

Elements hidden from assistive technology should not contain controls that can still receive focus.

What this means

If a focusable control is inside an aria-hidden region, keyboard users may reach something that screen readers cannot describe.

Why it matters

Keyboard and screen reader users can get confusing or silent focus stops.

What to check

Inspect hidden menus, drawers, modals, and panels.
Prevent hidden controls from receiving focus.
Remove aria-hidden when content is active.

How to use this result in Siteimp

ARIA input fields have accessible names

Audit key: aria_input_field_name
Lighthouse audit ID: aria-input-field-name
Likely scope: shared_template_or_component

Summary

ARIA input widgets need labels or names.

What this means

Custom input widgets need accessible names so assistive technology can announce what value or choice the user is editing.

Why it matters

Users may not know what information an input is asking for.

What to check

Check custom ARIA inputs.
Connect each input to visible label text.
Prefer native input elements when possible.

How to use this result in Siteimp

ARIA meter elements have accessible names

Audit key: aria_meter_name
Lighthouse audit ID: aria-meter-name
Likely scope: shared_template_or_component

Summary

Meter widgets need names that explain what is being measured.

What this means

A meter communicates a value within a known range. Without a name, users may hear a number but not understand what the number represents.

Why it matters

Assistive technology users may miss the meaning of a meter value.

What to check

Find ARIA meter widgets.
Add visible labels or aria-labelledby.
Make sure the measured value is clear.

How to use this result in Siteimp

Progress bars have accessible names

Audit key: aria_progressbar_name
Lighthouse audit ID: aria-progressbar-name
Likely scope: shared_template_or_component

Summary

Progress indicators need names that describe the task being tracked.

What this means

A progress bar should tell users what process is progressing, not only the percentage or value.

Why it matters

Users may not understand what a progress indicator refers to.

What to check

Review progress components.
Add a visible label or aria-labelledby.
Make sure progress updates are meaningful.

How to use this result in Siteimp

Elements do not use prohibited ARIA attributes

Audit key: aria_prohibited_attr
Lighthouse audit ID: aria-prohibited-attr
Likely scope: shared_template_or_component

Summary

Some ARIA attributes are not allowed on certain roles.

What this means

When an attribute is prohibited for a role, it can create conflicting information for assistive technology.

Why it matters

Users may hear incorrect state or behavior information.

What to check

Check the role and attribute combination.
Remove prohibited attributes.
Use a more appropriate role or native element.

How to use this result in Siteimp

ARIA roles include required attributes

Audit key: aria_required_attr
Lighthouse audit ID: aria-required-attr
Likely scope: shared_template_or_component

Summary

Some ARIA roles require supporting attributes to work correctly.

What this means

Certain roles need extra ARIA attributes to describe their state, value, or relationship. Without those attributes, the role may be incomplete.

Why it matters

Assistive technology may announce an incomplete or confusing widget.

What to check

Find the role on the affected element.
Add the required ARIA attributes.
Consider replacing the custom widget with native HTML.

How to use this result in Siteimp

ARIA containers include required child roles

Audit key: aria_required_children
Lighthouse audit ID: aria-required-children
Likely scope: shared_template_or_component

Summary

Some ARIA roles require specific child roles.

What this means

Composite widgets such as menus, lists, and tab groups rely on expected child roles so assistive technology can understand their structure.

Why it matters

Users may not be able to understand or navigate the widget correctly.

What to check

Inspect the widget structure.
Confirm required child roles are present.
Use established component patterns for menus, tabs, and lists.

How to use this result in Siteimp

ARIA roles are inside required parent roles

Audit key: aria_required_parent
Lighthouse audit ID: aria-required-parent
Likely scope: shared_template_or_component

Summary

Some ARIA child roles must appear inside a matching parent role.

What this means

ARIA roles often work as structured groups. A child role outside its expected parent can lose meaning for assistive technology.

Why it matters

Screen reader navigation may not describe the structure correctly.

What to check

Find the affected role.
Confirm it is inside the required parent role.
Review component markup for missing wrapper elements.

How to use this result in Siteimp

ARIA role values are valid

Audit key: aria_roles
Lighthouse audit ID: aria-roles
Likely scope: shared_template_or_component

Summary

ARIA role names should be spelled correctly and recognized.

What this means

Invalid role values are ignored by browsers and assistive technology. That can leave a custom element without the semantics it was intended to have.

Why it matters

Users may not hear the correct role or control type.

What to check

Check spelling of role values.
Remove invalid roles.
Use native HTML elements when possible.

How to use this result in Siteimp

Text roles do not contain focusable descendants

Audit key: aria_text
Lighthouse audit ID: aria-text
Likely scope: shared_template_or_component

Summary

Elements exposed as text should not contain interactive controls.

What this means

The text role changes how content is exposed to assistive technology. Focusable controls inside text-like regions can become confusing or inaccessible.

Why it matters

Users may encounter controls that are not announced as usable controls.

What to check

Inspect elements with role text.
Move interactive elements outside text-only regions.
Remove role text unless it is truly needed.

How to use this result in Siteimp

ARIA toggle fields have accessible names

Audit key: aria_toggle_field_name
Lighthouse audit ID: aria-toggle-field-name
Likely scope: shared_template_or_component

Summary

Toggle controls need names that explain what they turn on or off.

What this means

Switches, checkboxes, and other toggle controls need accessible names so users know what state they are changing.

Why it matters

Users may know a toggle exists but not what it controls.

What to check

Check custom toggle controls.
Connect controls to visible labels.
Prefer native checkbox or button patterns where possible.

How to use this result in Siteimp

Tooltips have accessible names

Audit key: aria_tooltip_name
Lighthouse audit ID: aria-tooltip-name
Likely scope: shared_template_or_component

Summary

Tooltip elements should have text that assistive technology can expose.

What this means

A tooltip exists to provide additional information. If it has no accessible text, assistive technology users may not receive that information.

Why it matters

Important helper text may be unavailable to screen reader users.

What to check

Check tooltip components.
Make sure tooltip text is present in accessible content.
Avoid putting essential instructions only in hover-only tooltips.

How to use this result in Siteimp

Tree items have accessible names

Audit key: aria_treeitem_name
Lighthouse audit ID: aria-treeitem-name
Likely scope: shared_template_or_component

Summary

Tree view items need names that describe each item.

What this means

Tree widgets rely on each item having a clear name so users can navigate the hierarchy and understand each selectable item.

Why it matters

Screen reader users may not know what tree item is focused or selected.

What to check

Review tree components.
Ensure each tree item has visible or accessible text.
Check expanded and collapsed states.

How to use this result in Siteimp

ARIA attributes are valid

Audit key: aria_valid_attr
Lighthouse audit ID: aria-valid-attr
Likely scope: shared_template_or_component

Summary

ARIA attribute names should be recognized and spelled correctly.

What this means

Misspelled or invalid ARIA attributes are ignored. That can make accessibility fixes look present in code while not actually working.

Why it matters

Assistive technology may not receive the intended label, state, or relationship.

What to check

Check spelling of aria attributes.
Remove invalid attributes.
Use browser and linting tools to catch mistakes earlier.

How to use this result in Siteimp

ARIA attribute values are valid

Audit key: aria_valid_attr_value
Lighthouse audit ID: aria-valid-attr-value
Likely scope: shared_template_or_component

Summary

ARIA attributes should use values allowed by their specification.

What this means

Many ARIA attributes only accept specific values. Invalid values can be ignored or interpreted incorrectly.

Why it matters

Users may hear incorrect state or relationship information.

What to check

Review the affected ARIA value.
Confirm the value is allowed.
Use true, false, mixed, IDs, or tokens only where appropriate.

How to use this result in Siteimp

Buttons have accessible names

Audit key: buttons_have_accessible_names
Lighthouse audit ID: button-name
Likely scope: shared_template_or_component

Summary

Every button needs a name that describes its action.

What this means

Buttons are action controls. A visible icon alone may not provide a name to screen readers, so users may hear only “button” without knowing what it does.

Why it matters

Screen reader and voice control users may not be able to identify or use the button.

What to check

Check icon-only buttons.
Add visible text when possible.
Use aria-label for icon-only controls.

How to use this result in Siteimp

The page provides a way to bypass repeated content

Audit key: bypass
Lighthouse audit ID: bypass
Likely scope: shared_template_or_component

Summary

Pages should help keyboard users move past repeated navigation.

What this means

Repeated headers, menus, and sidebars can slow keyboard and screen reader users. Skip links, headings, and landmarks give users faster ways to reach the main content.

Why it matters

Users may need to tab through the same navigation on every page.

What to check

Add or review skip links.
Make sure the page has a main landmark.
Use meaningful headings to structure content.

How to use this result in Siteimp

Text has sufficient color contrast

Audit key: color_contrast
Lighthouse audit ID: color-contrast
Likely scope: shared_css_or_theme

Summary

Text should be readable against its background.

What this means

Low contrast text can be difficult to read for people with low vision, color vision differences, aging eyes, or poor display conditions.

Why it matters

Users may struggle to read text, labels, links, and controls.

What to check

Review theme colors and design tokens.
Check button, link, muted text, and card styles.
Increase contrast while preserving visual hierarchy.

How to use this result in Siteimp

Custom controls have labels

Audit key: custom_controls_labels
Lighthouse audit ID: custom-controls-labels
Likely scope: shared_template_or_component

Summary

Custom interactive controls need names that describe their purpose.

What this means

Custom controls do not automatically inherit the accessibility behavior of native HTML controls. Labels help assistive technology users understand what each control does.

Why it matters

Users may encounter controls that are announced without enough context.

What to check

Review custom components.
Prefer native controls when possible.
Add labels through visible text or ARIA relationships.

How to use this result in Siteimp

Custom controls expose appropriate roles

Audit key: custom_controls_roles
Lighthouse audit ID: custom-controls-roles
Likely scope: shared_template_or_component

Summary

Custom controls need roles that describe what kind of control they are.

What this means

When a non-native element behaves like a button, tab, switch, or menu item, assistive technology needs the correct role to understand it.

Why it matters

Users may not know how to interact with a custom control.

What to check

Prefer native HTML controls.
Add roles only when needed.
Verify keyboard behavior matches the role.

How to use this result in Siteimp

Definition lists use valid structure

Audit key: definition_list
Lighthouse audit ID: definition-list
Likely scope: page_content

Summary

Definition lists should contain properly grouped terms and descriptions.

What this means

Definition list markup communicates relationships between terms and descriptions. Invalid structure can make those relationships unclear.

Why it matters

Assistive technology may not present term-description relationships correctly.

What to check

Review dl, dt, and dd markup.
Keep terms and descriptions properly grouped.
Use regular lists when the content is not a definition list.

How to use this result in Siteimp

Definition list items are inside definition lists

Audit key: dlitem
Lighthouse audit ID: dlitem
Likely scope: page_content

Summary

Definition terms and descriptions should be wrapped in a definition list.

What this means

The dt and dd elements only have their intended meaning when used inside a dl element.

Why it matters

Users may miss the relationship between terms and descriptions.

What to check

Find standalone dt or dd elements.
Wrap them in a dl element.
Use different markup if the content is not a definition list.

How to use this result in Siteimp

The page has a document title

Audit key: document_title
Lighthouse audit ID: document-title
Likely scope: shared_template_or_component

Summary

Each page needs a title that identifies it.

What this means

The document title is often the first thing announced by screen readers and appears in browser tabs, bookmarks, and search results.

Why it matters

Users may have trouble identifying where they are, especially with multiple tabs open.

What to check

Check the title element.
Make titles unique and descriptive.
Confirm templates generate page-specific titles.

How to use this result in Siteimp

ARIA IDs are unique

Audit key: duplicate_id_aria
Lighthouse audit ID: duplicate-id-aria
Likely scope: shared_template_or_component

Summary

IDs referenced by ARIA should not be duplicated.

What this means

ARIA relationships often point to elements by ID. If an ID appears more than once, assistive technology may connect to the wrong element.

Why it matters

Labels, descriptions, and relationships may be announced incorrectly.

What to check

Search for duplicate IDs.
Check reusable components rendered multiple times.
Generate unique IDs for repeated components.

How to use this result in Siteimp

Headings contain text

Audit key: empty_heading
Lighthouse audit ID: empty-heading
Likely scope: page_content

Summary

Heading elements should not be empty.

What this means

Headings help users understand page structure. Empty headings create confusing stops in screen reader heading navigation.

Why it matters

Users navigating by headings may encounter blank or meaningless sections.

What to check

Find empty h1-h6 elements.
Remove unused headings.
Add meaningful heading text where needed.

How to use this result in Siteimp

Keyboard focus is not accidentally trapped

Audit key: focus_traps
Lighthouse audit ID: focus-traps
Likely scope: shared_template_or_component

Summary

Keyboard users should be able to move into and out of interactive regions.

What this means

Some components, especially modals and menus, manage focus intentionally. Focus should not become stuck unless the active interaction requires it and provides a clear exit.

Why it matters

Keyboard users may be unable to continue using the page.

What to check

Test modals, menus, drawers, and widgets with the keyboard.
Confirm Escape or close controls work.
Return focus to a sensible place when closing UI.

How to use this result in Siteimp

Interactive controls are keyboard focusable

Audit key: focusable_controls
Lighthouse audit ID: focusable-controls
Likely scope: shared_template_or_component

Summary

People should be able to reach interactive controls with the keyboard.

What this means

Controls that respond to clicks should usually be reachable and usable without a mouse.

Why it matters

Keyboard users may be unable to activate important actions.

What to check

Tab through the page.
Find clickable elements that cannot receive focus.
Use buttons and links instead of clickable divs.

How to use this result in Siteimp

Form fields have labels

Audit key: form_elements_have_labels
Lighthouse audit ID: label
Likely scope: shared_template_or_component

Summary

Each form field needs a clear label.

What this means

Labels tell users what information a field expects. Placeholders alone are not a reliable substitute for labels.

Why it matters

Screen reader users may not know what to enter in a field.

What to check

Check inputs, selects, and textareas.
Use label elements connected with for/id.
Keep labels visible when possible.

How to use this result in Siteimp

Form fields do not have conflicting labels

Audit key: form_field_multiple_labels
Lighthouse audit ID: form-field-multiple-labels
Likely scope: shared_template_or_component

Summary

Each form field should have one clear label relationship.

What this means

Multiple labels can create confusing or repeated announcements, especially when labels conflict.

Why it matters

Users may hear unclear or duplicated field instructions.

What to check

Review label relationships.
Avoid multiple label elements for one field.
Use descriptions for helper text instead of extra labels.

How to use this result in Siteimp

Frames have titles

Audit key: frame_title
Lighthouse audit ID: frame-title
Likely scope: page_content

Summary

Embedded frames should describe their content.

What this means

Frame titles help assistive technology users understand what embedded content contains before entering it.

Why it matters

Users may not know what an iframe contains or whether they should interact with it.

What to check

Check iframe elements.
Add concise title attributes.
Use titles that describe the embedded content or task.

How to use this result in Siteimp

Headings follow a logical order

Audit key: heading_order
Lighthouse audit ID: heading-order
Likely scope: page_content

Summary

Heading levels should create a clear outline.

What this means

Headings help users scan and navigate the page. Skipped or confusing heading levels can make the page structure harder to understand.

Why it matters

Screen reader users and keyboard users may have trouble understanding page organization.

What to check

Review the page heading outline.
Avoid jumping from h1 to h4 without a reason.
Choose headings for structure, not visual size.

How to use this result in Siteimp

The page declares a language

Audit key: html_has_lang
Lighthouse audit ID: html-has-lang
Likely scope: shared_template_or_component

Summary

The html element should identify the page language.

What this means

Language metadata helps screen readers choose the correct pronunciation rules.

Why it matters

Text may be pronounced incorrectly by assistive technology.

What to check

Check the lang attribute on html.
Set the primary page language.
Use language changes for mixed-language content when needed.

How to use this result in Siteimp

The page language value is valid

Audit key: html_lang_valid
Lighthouse audit ID: html-lang-valid
Likely scope: shared_template_or_component

Summary

The html lang value should use a recognized language code.

What this means

A valid language code helps browsers and assistive technology apply the correct language behavior.

Why it matters

Screen readers may use the wrong pronunciation rules.

What to check

Check the lang value.
Use standard language codes such as en or fr-CA.
Fix template defaults if the value is generated.

How to use this result in Siteimp

HTML and XML language values agree

Audit key: html_xml_lang_mismatch
Lighthouse audit ID: html-xml-lang-mismatch
Likely scope: shared_template_or_component

Summary

When both language attributes are present, they should identify the same base language.

What this means

Conflicting language metadata can create inconsistent behavior across tools.

Why it matters

Assistive technology may choose the wrong language behavior.

What to check

Check lang and xml:lang.
Remove xml:lang if it is not needed.
Make both values consistent when both are present.

How to use this result in Siteimp

Identical links have the same purpose

Audit key: identical_links_same_purpose
Lighthouse audit ID: identical-links-same-purpose
Likely scope: page_content

Summary

Links with the same accessible name should lead to the same kind of destination.

What this means

When repeated link text points to different destinations, users navigating by links may not know which one they need.

Why it matters

Screen reader users may have trouble choosing the correct link from a list.

What to check

Review repeated link text.
Make ambiguous links more specific.
Avoid many different destinations named only “Read more”.

How to use this result in Siteimp

Image alt text is not redundant

Audit key: image_redundant_alt
Lighthouse audit ID: image-redundant-alt
Likely scope: page_content

Summary

Alt text should not repeat nearby text unnecessarily.

What this means

If alt text repeats adjacent text, screen reader users may hear the same content twice.

Why it matters

Repeated announcements can make pages slower and more tiring to navigate.

What to check

Compare alt text with nearby captions and labels.
Use empty alt text for decorative images.
Keep informative alt text concise.

How to use this result in Siteimp

Images have alt text

Audit key: images_have_alt_text
Lighthouse audit ID: image-alt
Likely scope: page_content

Summary

Images should provide text alternatives when they convey information.

What this means

Alt text gives people who cannot see an image access to its meaning. Decorative images can use empty alt text.

Why it matters

Users may miss important visual information.

What to check

Find images without alt attributes.
Add meaningful alt text for informative images.
Use empty alt text for decorative images.

How to use this result in Siteimp

Input buttons have discernible text

Audit key: input_button_name
Lighthouse audit ID: input-button-name
Likely scope: shared_template_or_component

Summary

Input buttons need names that describe their action.

What this means

Input-based buttons should expose clear action text to assistive technology.

Why it matters

Users may not know what action a form button performs.

What to check

Check input buttons.
Add value text where appropriate.
Use button elements for richer button content.

How to use this result in Siteimp

Image submit buttons have alt text

Audit key: input_image_alt
Lighthouse audit ID: input-image-alt
Likely scope: page_content

Summary

Image inputs need text alternatives.

What this means

An input of type image acts as a submit button. Its alt text tells users what submitting will do.

Why it matters

Screen reader users may not understand the image button’s purpose.

What to check

Find input type image elements.
Add alt text that describes the action.
Consider replacing image inputs with regular buttons.

How to use this result in Siteimp

Interactive elements communicate their purpose and state

Audit key: interactive_element_affordance
Lighthouse audit ID: interactive-element-affordance
Likely scope: shared_css_or_theme

Summary

Controls should look and behave like controls.

What this means

People need to recognize what can be interacted with and what state it is currently in. Visual, keyboard, and assistive technology cues should work together.

Why it matters

Users may miss controls or misunderstand their current state.

What to check

Review custom controls.
Check hover, focus, active, selected, and disabled states.
Avoid relying on color alone.

How to use this result in Siteimp

Visible labels match accessible names

Audit key: label_content_name_mismatch
Lighthouse audit ID: label-content-name-mismatch
Likely scope: shared_template_or_component

Summary

A control’s accessible name should include its visible label.

What this means

Voice control users often speak the visible label to activate a control. If the accessible name does not match, voice commands may fail.

Why it matters

Voice control and screen reader users may have trouble finding or activating controls.

What to check

Compare visible labels with aria-label values.
Avoid overriding visible text with unrelated labels.
Make accessible names include the visible text.

How to use this result in Siteimp

The page has one main landmark

Audit key: landmark_one_main
Lighthouse audit ID: landmark-one-main
Likely scope: shared_template_or_component

Summary

Each page should identify its main content area.

What this means

The main landmark helps assistive technology users jump directly to the central content of the page.

Why it matters

Users may have a harder time bypassing repeated navigation and finding the page’s primary content.

What to check

Check for a main element or role main.
Avoid multiple main landmarks.
Make sure the main landmark wraps the primary content.

How to use this result in Siteimp

Links are distinguishable without relying only on color

Audit key: link_in_text_block
Lighthouse audit ID: link-in-text-block
Likely scope: shared_css_or_theme

Summary

Text links should be recognizable even when color is not enough.

What this means

Links inside paragraphs should have a visual cue beyond color, such as an underline, so users can identify them reliably.

Why it matters

Users with low vision or color vision differences may miss links.

What to check

Review paragraph link styling.
Add underlines or another non-color cue.
Check hover and focus states.

How to use this result in Siteimp

Links have accessible names

Audit key: link_name
Lighthouse audit ID: link-name
Likely scope: shared_template_or_component

Summary

Every link should have text that identifies its destination or purpose.

What this means

Screen reader users can navigate by links. Empty or unnamed links make that list confusing.

Why it matters

Users may not know where a link goes or whether it is worth following.

What to check

Check icon-only and image-only links.
Add meaningful link text.
Avoid empty anchor elements.

How to use this result in Siteimp

Links are crawlable

Audit key: links_are_crawlable
Lighthouse audit ID: crawlable-anchors
Likely scope: shared_template_or_component

Summary

Links should use href values that browsers and tools can follow.

What this means

Standard links help browsers, crawlers, assistive technology, and users understand navigation.

Why it matters

Non-standard links can make navigation less reliable for users and tools.

What to check

Check anchor elements.
Use real href values for navigation.
Use buttons for actions that do not navigate.

How to use this result in Siteimp

Links have descriptive text

Audit key: links_have_descriptive_text
Lighthouse audit ID: link-text
Likely scope: page_content

Summary

Link text should make sense without relying heavily on surrounding content.

What this means

Descriptive links help users decide where to go, especially when navigating a list of links.

Why it matters

Generic text like “click here” or “read more” can be difficult to use out of context.

What to check

Review generic link text.
Include the destination or action in the link text.
Make repeated links distinguishable.

How to use this result in Siteimp

Lists use valid list structure

Audit key: list
Lighthouse audit ID: list
Likely scope: shared_template_or_component

Summary

List containers should contain list items.

What this means

Proper list markup helps assistive technology announce the number of items and support list navigation.

Why it matters

Users may not understand grouped content as a list.

What to check

Check ul, ol, and menu elements.
Make sure direct children are list items where required.
Use non-list markup for layout-only groups.

How to use this result in Siteimp

List items are inside lists

Audit key: listitem
Lighthouse audit ID: listitem
Likely scope: shared_template_or_component

Summary

List item elements should be contained by a list.

What this means

An li element only has its intended meaning inside ul, ol, or menu.

Why it matters

Assistive technology may not announce list structure correctly.

What to check

Find li elements outside lists.
Wrap list items in ul, ol, or menu.
Use different elements for non-list layouts.

How to use this result in Siteimp

Keyboard tab order is logical

Audit key: logical_tab_order
Lighthouse audit ID: logical-tab-order
Likely scope: shared_template_or_component

Summary

Keyboard focus should move through the page in an understandable order.

What this means

People using a keyboard rely on focus moving in a predictable sequence that matches the page’s structure and task flow.

Why it matters

Users may get lost or miss controls if focus jumps around unexpectedly.

What to check

Tab through the page manually.
Avoid positive tabindex values.
Check modals, menus, and custom layouts.

How to use this result in Siteimp

Focus moves appropriately when content changes

Audit key: managed_focus
Lighthouse audit ID: managed-focus
Likely scope: shared_template_or_component

Summary

Dynamic interfaces should move focus when it helps users stay oriented.

What this means

When modals open, routes change, or important content appears, keyboard and screen reader users may need focus to move to the new context.

Why it matters

Users may not realize that new content appeared or where to continue.

What to check

Test modals, drawers, route changes, and alerts.
Move focus to new interactive contexts when appropriate.
Return focus after closing temporary UI.

How to use this result in Siteimp

The page does not use automatic meta refresh

Audit key: meta_refresh
Lighthouse audit ID: meta-refresh
Likely scope: shared_template_or_component

Summary

Pages should not unexpectedly refresh or redirect using meta refresh.

What this means

Automatic refreshes can disorient users and interrupt reading, keyboard navigation, or assistive technology output.

Why it matters

Users may lose their place or be moved unexpectedly.

What to check

Search for meta refresh tags.
Use server redirects for permanent navigation changes.
Avoid automatic refresh unless users control it.

How to use this result in Siteimp

The viewport allows zooming

Audit key: meta_viewport
Lighthouse audit ID: meta-viewport
Likely scope: shared_template_or_component

Summary

Users should be able to zoom the page on mobile devices.

What this means

People with low vision often zoom pages to read comfortably. Viewport settings should not block scaling.

Why it matters

Mobile users may be unable to enlarge text and controls.

What to check

Review the viewport meta tag.
Avoid user-scalable=no.
Avoid maximum-scale values that restrict zoom.

How to use this result in Siteimp

Object elements have alternate text

Audit key: object_alt
Lighthouse audit ID: object-alt
Likely scope: page_content

Summary

Embedded object content should provide a text alternative.

What this means

Object elements can embed media or documents. A text alternative helps users understand the content if it is not accessible or cannot load.

Why it matters

Users may miss embedded content or its purpose.

What to check

Check object elements.
Add fallback text inside the object element.
Use accessible embed alternatives where possible.

How to use this result in Siteimp

Offscreen content is hidden when appropriate

Audit key: offscreen_content_hidden
Lighthouse audit ID: offscreen-content-hidden
Likely scope: shared_template_or_component

Summary

Content moved offscreen should not confuse assistive technology users.

What this means

Offscreen menus, drawers, or panels can remain available to screen readers even when sighted users cannot see them. Hidden inactive content should be managed carefully.

Why it matters

Users may navigate into content that appears unavailable or inactive.

What to check

Review hidden menus and drawers.
Use hidden, inert, or aria-hidden carefully.
Make active content visible and inactive content unreachable.

How to use this result in Siteimp

Select fields have accessible names

Audit key: select_name
Lighthouse audit ID: select-name
Likely scope: shared_template_or_component

Summary

Select controls need labels that describe the choice being made.

What this means

A select control lets users choose from options. Its label explains what those options represent.

Why it matters

Users may not know what they are selecting.

What to check

Check select elements.
Connect each select to a label.
Avoid relying only on placeholder options.

How to use this result in Siteimp

Skip links are focusable

Audit key: skip_link
Lighthouse audit ID: skip-link
Likely scope: shared_template_or_component

Summary

Skip links should become available when keyboard users tab to them.

What this means

Skip links help keyboard users bypass repeated navigation. They need to receive focus and point to a valid target.

Why it matters

Keyboard users may have to move through repeated menus on every page.

What to check

Tab from the top of the page.
Make sure the skip link appears on focus.
Confirm the skip link target exists and receives focus.

How to use this result in Siteimp

Positive tabindex values are not used

Audit key: tabindex
Lighthouse audit ID: tabindex
Likely scope: shared_template_or_component

Summary

Tab order should usually follow the document order.

What this means

Positive tabindex values create a custom focus order that can become confusing and difficult to maintain.

Why it matters

Keyboard users may experience focus jumps that do not match the visual layout.

What to check

Search for tabindex values greater than zero.
Remove positive tabindex values.
Use natural DOM order and tabindex=0 only when needed.

How to use this result in Siteimp

Tables do not use duplicate names

Audit key: table_duplicate_name
Lighthouse audit ID: table-duplicate-name
Likely scope: page_content

Summary

Table captions and summary information should not conflict or repeat awkwardly.

What this means

Tables need clear names and descriptions. Duplicate or conflicting table labels can make data tables harder to understand.

Why it matters

Screen reader users may hear confusing table descriptions.

What to check

Review table captions and summary attributes.
Avoid repeating the same information in multiple naming locations.
Use captions for visible table titles.

How to use this result in Siteimp

Tables use real captions

Audit key: table_fake_caption
Lighthouse audit ID: table-fake-caption
Likely scope: page_content

Summary

Table captions should use the caption element.

What this means

A visual heading inside a table is not the same as a semantic caption. Real captions help assistive technology identify the table.

Why it matters

Users may not hear the table’s title or purpose when navigating data.

What to check

Check tables with visual caption rows.
Use the caption element.
Keep captions concise and descriptive.

How to use this result in Siteimp

Touch targets have enough size and spacing

Audit key: target_size
Lighthouse audit ID: target-size
Likely scope: shared_css_or_theme

Summary

Interactive targets should be large enough to activate accurately.

What this means

Small or tightly packed targets can be difficult to use on touch screens or for people with motor impairments.

Why it matters

Users may tap the wrong control or struggle to activate controls.

What to check

Review buttons, links, and icon controls.
Increase spacing around small targets.
Check mobile layouts carefully.

How to use this result in Siteimp

Large table cells are associated with headers

Audit key: td_has_header
Lighthouse audit ID: td-has-header
Likely scope: page_content

Summary

Complex data tables should connect data cells to headers.

What this means

Header relationships help screen reader users understand what each data cell means in larger tables.

Why it matters

Users may hear table values without enough row or column context.

What to check

Review large or complex tables.
Use th elements for headers.
Add scope or headers attributes when needed.

How to use this result in Siteimp

Table header references are valid

Audit key: td_headers_attr
Lighthouse audit ID: td-headers-attr
Likely scope: page_content

Summary

Cells using headers attributes should point to valid table headers.

What this means

The headers attribute connects a data cell to specific header cells. Broken references make those relationships unreliable.

Why it matters

Screen reader users may not get the right context for table data.

What to check

Check headers attributes on table cells.
Make sure referenced IDs exist in the same table.
Use simpler table structure when possible.

How to use this result in Siteimp

Table headers describe data cells

Audit key: th_has_data_cells
Lighthouse audit ID: th-has-data-cells
Likely scope: page_content

Summary

Table header cells should be connected to actual data.

What this means

Headers help users understand table data. A header without related data can make the table structure confusing.

Why it matters

Assistive technology users may hear misleading or unnecessary table structure.

What to check

Review th elements.
Confirm headers line up with data cells.
Remove unused header cells.

How to use this result in Siteimp

Landmarks support page navigation

Audit key: use_landmarks
Lighthouse audit ID: use-landmarks
Likely scope: shared_template_or_component

Summary

Landmark elements help users move around major page regions.

What this means

Landmarks such as header, nav, main, aside, and footer give assistive technology users shortcuts to major sections.

Why it matters

Users may have to move through the page more slowly without region navigation.

What to check

Review major layout regions.
Use semantic HTML landmarks.
Avoid too many repeated landmarks without labels.

How to use this result in Siteimp

Language attributes use valid values

Audit key: valid_lang
Lighthouse audit ID: valid-lang
Likely scope: page_content

Summary

Language attributes should use recognized language codes.

What this means

Valid language codes help assistive technology pronounce text correctly when content changes language.

Why it matters

Screen readers may pronounce words with the wrong language rules.

What to check

Check lang attributes throughout the page.
Use standard language codes.
Apply language changes only where content actually changes language.

How to use this result in Siteimp

Videos include captions

Audit key: video_caption
Lighthouse audit ID: video-caption
Likely scope: page_content

Summary

Videos should provide captions when they contain spoken content.

What this means

Captions make spoken audio available to people who are deaf, hard of hearing, watching without sound, or processing audio in difficult environments.

Why it matters

Users may miss spoken information in video content.

What to check

Check video elements.
Add caption tracks for spoken content.
Make sure captions are synchronized and accurate.

How to use this result in Siteimp

Visual order follows DOM order

Audit key: visual_order_follows_dom
Lighthouse audit ID: visual-order-follows-dom
Likely scope: shared_css_or_theme

Summary

The visual layout should match the order users encounter with keyboard and assistive technology.

What this means

CSS can visually rearrange content. If the visual order differs from DOM order, keyboard and screen reader users may experience the page in a different sequence.

Why it matters

Users may get confused when focus or reading order does not match the visible layout.

What to check

Compare visual order with keyboard order.
Review flexbox and grid ordering.
Avoid using CSS order to change meaningful reading sequence.