Before continuing, write one sentence answering the question below. Return to it after testing the sample.

Work through both sessions independently. Use presentation mode or View all; every activity and reveal includes its own instructions. Keep brief notes. Only Challenge 07 is submitted.

You need WAVE, Chrome Lighthouse, and one generative AI assistant for Session 15. No paid product or model is required. No other accessibility extension is assigned.

For a public course sample, enter its full URL at wave.webaim.org. If you are running the course locally or behind a login, the WAVE extension can evaluate it in your browser; the online service cannot reach localhost. Lighthouse is already built into Chrome.

Errors

Likely accessibility problems. Identify the triggering element, why the rule matters, and the appropriate correction.

Contrast Errors

Measured contrast findings. Revisit Module 02: inspect the foreground, background, text size, and required ratio.

Alerts

Items needing judgment. Alert does not mean failure.

Features

Detected accessibility features. Feature does not mean “passed.” Inspect whether each feature helps in context.

Structure

Inspect headings, landmarks, lists, and reading order. Connect these to the semantic structure from Module 05.

ARIA

Inspect exposed roles and properties. Their presence does not establish correct interaction.

In Details, select a finding to locate its icon and affected element. Use Reference for the explanation, then Code to inspect the underlying markup. Follow: icon → element → explanation → markup. Panel placement can vary by WAVE version.

Open the sample in a new tab. Your task is to choose a studio time and reserve it. Run WAVE before opening Check Your Work. Keep this original page for the Lighthouse comparison.

In your notes, record one Error, one Alert, one Feature, and one thing WAVE did not establish. Include the affected element and the next inspection or test you would use. These are learning notes, not a separate submission.

Check Your Work — open after running WAVE

Error: the search icon button has no accessible name. Inspect the button and its aria-hidden icon. Give the action a meaningful name, such as “Find available times.”

Contrast: the small booking note uses #aaaaaa on white, about 2.32:1. Normal text needs 4.5:1 (WCAG 1.4.3, AA). Inspect the actual colors rather than guessing from appearance.

Alert: “Click here” triggers a Suspicious link text alert. Read the whole paragraph: it identifies the studio preparation checklist, and the link reaches that section. Judge purpose in context (2.4.4, A); this alert alone does not establish failure. Descriptive link text would still make scanning easier.

Features: inspect the explicit select label, skip link, and null image alternative. The illustration is decorative here; all booking information is text. Use Structure for headings, main, and the preparation list; inspect ARIA for the availability status. Their presence still needs contextual review.

Not established: “Reserve this time” responds to pointer clicks but is skipped by Tab and cannot be activated with Enter or Space. Try it. A name and role do not provide keyboard behavior (WCAG 2.1.1, A). WAVE may expose the markup without establishing this interaction.

Your report may include additional alerts or structural indicators. Explain the element and evidence; do not chase a predetermined count.

After comparing both tools on the original, open the revised booking page. Repeat the scans and keyboard reservation task. The contextual “Click here” link may still receive an alert. What changed, and what remains untested?

On that same original sample, open Chrome DevTools → Lighthouse → Accessibility. Select Accessibility, run the page analysis, and expand a finding to inspect its element and explanation. You do not need a browser extension.

Lighthouse scores the automated accessibility audits it performs. Manual checks do not contribute to that score. The result is not a WCAG conformance score: even 100 leaves questions for human testing. Record one finding and one manual check the report asks you to do.

Use the same original page and state for both reports. Copy this table into your notes; no formal submission is required.

Tools use different rules, cover different conditions, and present results differently. Some tools share underlying rules or engines, so agreement is not necessarily independent confirmation. Multiple reports still leave gaps. A WAVE Feature and a Lighthouse passed audit also describe different things.

• Alt text: alt="Three students using equipment in a studio" exists. Does it communicate the image’s purpose in this context? Revisit Module 03.
• Keyboard interaction: reasonable-looking markup does not establish working behavior. Use the control, as in Module 04.
• Error messages: a relationship or error container may exist. Does its message actually help someone recover? Revisit Module 05.
• Cognitive burden: dense instructions can use valid markup and still create a broader accessibility concern. Apply Module 06 without inventing a WCAG failure.

• Automated finding — a rule software can evaluate directly.
• Needs human review — the tool identifies something that requires context or judgment.
• Manual test — the condition must be evaluated through interaction, perception, or task context.

Return to your opening sentence. Zero reported errors establishes only that the tested rules did not report errors on the evaluated page and state. What remains untested?