# Exercise: Audit the Movie Theater Page

Run a full accessibility audit on the Starlight Cinema's showtimes page, log the ten barriers you find, fix the HTML, and let the tests confirm every fix.

Journeyman · HTML · Web Development · Updated October 30, 2026

The Starlight Cinema's new showtimes page went live last week, and it looks great with a mouse. Then the emails started. A customer who uses a screen reader couldn't find the "Buy tickets" button. Another, who uses the keyboard, kept landing in the newsletter box. A third couldn't tell which showings were sold out. The owner has asked you to audit the page before the weekend's premiere: find every barrier, write each one down, and fix it. There are ten. Tests check each fix when you're done.

## Before you start

You need Node.js to run the tests, and VS Code's **Live Server** extension to open the page. If you haven't installed them yet, *Setup: VS Code, a Browser and Node.js* shows how.

## Get the exercise code

In the **Exercise** box beside the lesson, choose **Get the starter on GitHub** to open its GitHub repository. Click **Code**, then **Download ZIP**, and unzip it into the folder where you keep your web projects. Open that folder in VS Code.

The folder holds:

- `index.html`: the showtimes page, with its ten barriers. For you to fix.
- `audit.md`: your audit log, with one worked example row. For you to fill in.
- `tickets.html`, `thanks.html`, `style.css` and the `media` folder (the posters, the trailer and its captions file): ready to use.
- `page.test.js`: the tests. You don't need to change it.

Open VS Code's terminal (**Terminal > New Terminal**) and run `npm install` once. It downloads the two tools the tests use.

## What to do

Open `index.html` with Live Server (right-click it and choose **Open with Live Server**), then work through the checklist from *Testing a Page for Accessibility*. `audit.md` starts with that checklist, and a table with one example row:

```text
| # | Where on the page | The barrier | Who it stops | How I found it | My fix |
|---|---|---|---|---|---|
| i | The <html> element | The page didn't say its language, so a screen reader could read the English text with the wrong voice | Screen-reader users | Lighthouse | Added lang="en" (already fixed in this starter) |
```

1. **Audit first, with the page in the browser.** Do the keyboard pass, the screen-reader pass with Narrator or VoiceOver, Lighthouse and axe DevTools, 200% zoom and captions on. Each time something stops you, add a row. A mistake that shows up three times, such as the same barrier under all three movies, is one row.
2. **Then read the HTML.** Some barriers are easier to spot in the code: look at every picture, heading, landmark, form field, link and button.
3. **Fix the HTML,** one row at a time. After each fix, check the page again the way you found the barrier.
4. **Run the tests** (below). If one fails, it names a barrier your audit missed: add it to your log, then fix it.
5. **Fill in "What the tools missed"** at the end of `audit.md`: which of your barriers did Lighthouse and axe not report, and why couldn't they?

Fix the HTML, not the stylesheet, keep all of the page's content, and use ARIA only where no HTML element or attribute does the job.

## Check your work

In VS Code's terminal, in the exercise folder:

```bash
npm test
```

At first ten tests fail: that's expected, one for each barrier. The eleventh runs the validator on all three pages. It passes on the starter, so keep it green as you change things. A failing test's message says what it found and what a fix needs, for example *The email box named "email" has no label.*

Passing tests prove what a program can check. Your audit is what proves the page works: when the tests are green, tab through the page and listen to it once more.

## Hints

- **Link or button?** Something that takes you to another page is a link, `<a href>`. Something that does an action on this page, such as sending the form, is a `<button>`. *What a Screen Reader Hears* shows why a `<div>` is neither.
- **Decoration needs alt too.** A picture that's only decoration gets `alt=""`, so a screen reader skips it. A poster tells people about a movie, so its alt text says what it shows.
- **Listen to the headings.** Open the screen reader's list of headings. Do the levels go down one step at a time, as in *Headings and the Page Outline*?
- **A placeholder isn't a label.** It disappears when you type, and screen readers don't all read it.
- **Look for numbers in tabindex.** Only `0` and `-1` belong there. *Keyboard Use and Focus* explains why.
- **The one place ARIA fits.** One control has no words on the screen at all. *ARIA: When HTML Isn't Enough* shows how to name it.

## When you're done

Your `audit.md` has ten rows, each with where, what, who it stops, how you found it and your fix, and every test passes:

```text
✔ every picture has alt text, and every movie poster says what it shows
✔ "Buy tickets" is a real link or button
✔ the newsletter email box has a label
✔ headings go down one level at a time, from a single h1
✔ the page has one main landmark, holding the main content
✔ no element has a positive tabindex
✔ the trailer has a captions track
✔ every link says where it goes
✔ every button has a name
✔ "sold out" is said in words, not only in red
✔ every page passes the validator
ℹ tests 11
ℹ pass 11
ℹ fail 0
```

Look back at your log. Which barriers did you find with the keyboard and the screen reader that no tool reported? Those are the ones only a person can catch, and now you know how.

**Go further:** add a skip link as the first thing in the `<body>`, and mark the current page's menu link with `aria-current="page"`.

## So what

An audit like this one is real work that companies pay for: a page, a checklist, a log of what stops people and how to fix it. You've done the whole job, from finding the barriers to proving the fixes work.

## Key terms

- [Accessibility](https://www.ask-codey.com/glossary/accessibility)
- Screen reader
- [Accessible name](https://www.ask-codey.com/glossary/accessible-name)
- [tabindex](https://www.ask-codey.com/glossary/tabindex)
- [Captions track](https://www.ask-codey.com/glossary/captions-track)
- Lighthouse

## Related

- [Testing a Page for Accessibility](https://www.ask-codey.com/lessons/html-accessibility-testing-a-page)
- [What a Screen Reader Hears](https://www.ask-codey.com/lessons/html-accessibility-what-a-screen-reader-hears)
- [Keyboard Use and Focus](https://www.ask-codey.com/lessons/html-accessibility-keyboard-and-focus)
- [ARIA: When HTML Isn't Enough](https://www.ask-codey.com/lessons/html-accessibility-aria)

Source: https://www.ask-codey.com/lessons/exercise-html-accessibility-audit