Overview

Combine automated checks with manual keyboard and screen reader testing.

A11y Testing Tools (Axe, Lighthouse) makes the interface usable for more people and more devices. The goal is not only passing an automated score, but making names, focus, state, errors, and reading order understandable.

Core Ideas

• For A11y Testing Tools (Axe, Lighthouse), start with the keyboard and visible labels.
• Expose the right name, role, value, and state for interactive controls.
• Use clear error messages and do not rely on color alone.
• Validate with tools, then confirm manually with real interaction.

Step by Step

1. Build the A11y Testing Tools (Axe, Lighthouse) pattern with semantic HTML first.
2. Tab through the interface and confirm focus order.
3. Check labels, descriptions, live messages, and error states.
4. Use an automated tool after manual checks to catch missed details.

Beginner Explanation

A11y Testing Tools (Axe, Lighthouse) combines automated tools with manual checks because no tool can understand every human interaction.

Automated audits catch many missing labels, color contrast problems, duplicate IDs, and invalid ARIA patterns.

Manual testing is still required for keyboard flow, focus behavior, screen reader meaning, content clarity, and task completion.

Before You Start

• Before practicing A11y Testing Tools (Axe, Lighthouse), identify the task a user is trying to complete.
• List the interactive elements and confirm each one has a visible label or clear text.
• Tab through the UI once before changing code so you know the current focus order.
• Check whether information is conveyed only by color, position, motion, or icon shape.
• Keep a notes list for issues found by keyboard testing, screen reader testing, and automated tools separately.

Key Accessibility Concepts

• Keyboard testing catches focus order, hidden traps, missing controls, and broken shortcuts.
• Screen reader testing catches names, roles, states, headings, landmarks, and announcements.
• Automated tools catch repeatable code issues, but they cannot judge every task flow.
• Regression testing should include the most important pages and forms after every UI change.

Plain-English Glossary

• Accessible name: the label announced for a control, link, image, or region.
• Role: the type of element or widget exposed to assistive technology.
• State: current information such as expanded, selected, pressed, invalid, checked, or disabled.
• Focus order: the sequence keyboard users follow when pressing Tab and Shift+Tab.
• Landmark: a page region such as nav, main, header, footer, aside, or form.
• Live region: an area that announces important dynamic updates.
• Alt text: text alternative for an image when the image communicates information.
• Assistive technology: tools such as screen readers, magnifiers, switch devices, voice control, and captions.

What You Will Learn

• Explain the accessibility risk that A11y Testing Tools (Axe, Lighthouse) solves.
• Identify names, roles, states, labels, focus order, and errors in a real interface.
• Update the code editor example without breaking keyboard or screen reader behavior.
• Separate automated-tool findings from manual usability findings.

Where You Use This in Real Projects

You use A11y Testing Tools (Axe, Lighthouse) in login pages, checkout flows, dashboards, menus, dialogs, search forms, media pages, image galleries, article pages, admin panels, and design systems.

Accessibility work is easiest when it is built into components from the start: buttons, links, inputs, alerts, dialogs, tabs, accordions, cards, navigation, and tables.

A beginner should practice small pieces first, then test the full task flow from page load to success or error recovery.

Browser and Assistive Technology Notes

• Different browsers and assistive technologies may announce the same pattern slightly differently, so test the behavior, not only the exact wording.
• Native HTML controls usually provide stronger cross-browser behavior than custom div-based controls.
• Do not hide important text with display: none if assistive technology needs to read it.
• Use visually hidden helper text only when the text is useful for non-visual users and not a substitute for visible instructions.
• Retest after CSS and JavaScript changes because visual updates can accidentally hide labels, focus rings, and error messages.

Code Example

# Manual checks
1. Tab through the page.
2. Check visible focus.
3. Confirm labels are announced.
4. Run Lighthouse or axe.
5. Retest with a screen reader for critical flows.

Another Example

Accessibility test order:
1. Use the page with only the keyboard.
2. Check visible focus on every control.
3. Inspect headings, landmarks, labels, and errors.
4. Run an automated audit.
5. Retest the same task with a screen reader when the flow is important.

More Practice Examples

Example 1: Button with live status

<button id="saveButton" type="button">Save profile</button>
<p id="saveStatus" role="status"></p>

<script>
  const button = document.querySelector('#saveButton');
  const status = document.querySelector('#saveStatus');

  button.addEventListener('click', () => {
    status.textContent = 'Profile saved successfully.';
  });
</script>

• The button has visible text, so it already has an accessible name.
• role="status" announces the result without moving focus.
• The message is useful because it confirms that the action worked.

Example 2: Form field with hint and error

<label for="username">Username</label>
<input id="username" name="username" aria-describedby="usernameHint usernameError" aria-invalid="true">
<p id="usernameHint">Use 4 to 20 letters or numbers.</p>
<p id="usernameError">Username is required.</p>

• The label gives the input its accessible name.
• aria-describedby connects both the hint and current error.
• aria-invalid tells assistive technology the current value needs correction.

Example 3: Visible focus and reduced motion

.action:focus-visible {
  outline: 3px solid #2563eb;
  outline-offset: 3px;
}

@media (prefers-reduced-motion: reduce) {
  .action {
    transition: none;
  }
}

• focus-visible keeps keyboard focus obvious without showing rings for every mouse click.
• outline-offset separates the focus indicator from the element edge.
• The reduced motion query keeps interaction calm for people who request it.

Example Explained

• The A11y Testing Tools (Axe, Lighthouse) example starts with semantic HTML so the browser provides as much accessibility behavior as possible.
• Labels, text, headings, landmarks, and descriptions create the information assistive technology needs.
• ARIA is used only when it adds a missing relationship, state, or announcement.
• Keyboard behavior is part of the feature, not an optional extra.
• The example can be tested by completing a real task, not only by inspecting code.

How to Read This Example

1. Find the interactive elements first: links, buttons, form fields, dialogs, menus, or custom widgets.
2. Name each control out loud and check whether the visible text, label, aria-label, or aria-labelledby provides that name.
3. Check role and state next, such as expanded, invalid, selected, pressed, checked, or hidden.
4. Tab through the example and confirm the focus order follows the visual and logical task order.
5. Change one part of the A11y Testing Tools (Axe, Lighthouse) example, then retest with keyboard and automated checks.

Checklist

• Test with keyboard only before relying on automated tools.
• Use visible labels, focus states, and clear error messages.
• Prefer semantic HTML and add ARIA only when it adds real meaning.

Common Mistakes

• Treating automated audit scores as the whole accessibility test.
• Removing focus outlines without replacing them.
• Using ARIA to patch invalid or non-semantic HTML instead of fixing the HTML.

Do and Don't

• Do: begin A11y Testing Tools (Axe, Lighthouse) with real HTML elements, visible labels, and clear content.
• Do: keep focus indicators visible and test every interactive element with the keyboard.
• Do: connect helper text, errors, and dynamic status messages programmatically.
• Don't: use ARIA to hide invalid markup or avoid native controls.
• Don't: depend only on color, icon shape, placeholder text, animation, or mouse hover.

Practice Challenge

Test the A11y Testing Tools (Axe, Lighthouse) pattern using only Tab, Shift+Tab, Enter, Space, and Escape, then check whether names and states are announced clearly.

Try These Changes

• Remove the visible label from one control, run the editor, then restore the label and compare the result.
• Add a validation error and connect it with aria-describedby and aria-invalid.
• Use only Tab, Shift+Tab, Enter, Space, and Escape to complete the example task.
• Change a button or link color and check whether the focus, hover, and active states still remain readable.
• Add one dynamic success message and decide whether it should move focus or use a live region.

Quick Check

• Question: Should ARIA be the first solution? Answer: No, use semantic HTML first and ARIA only when it adds needed meaning.
• Question: What should every control have? Answer: An accessible name and a visible or understandable purpose.
• Question: What catches focus order problems? Answer: Manual keyboard testing with Tab and Shift+Tab.
• Question: Can automated tools prove a page is accessible? Answer: No, they catch many code issues but not every human task issue.
• Question: What is a good first manual test? Answer: Complete the main task without using a mouse.

Debugging Checks

• Inspect the accessibility tree or browser accessibility panel to confirm names, roles, and states.
• Check whether hidden content is hidden from everyone or only visually hidden.
• Look for div or span elements that act like buttons, links, tabs, or menus without keyboard behavior.
• Confirm focus is visible, logical, and restored after dialogs, menus, validation, or route changes.
• Run automated checks after manual testing so code-level issues are not missed.

Mini Project

Build an accessibility test checklist for A11y Testing Tools (Axe, Lighthouse): keyboard steps, screen reader steps, automated audit steps, contrast checks, and regression notes for future edits.

Mastery Check

• You can test the A11y Testing Tools (Axe, Lighthouse) pattern without a mouse.
• You can identify the accessible name and state of each control.
• You can explain which checks require manual testing.