AI Global Academy Join the waitlist

Courses / Frontend: the website

Lesson 3.6 · 55 minMobile and accessibility

Duration~55 min in the lesson + ~25 min homework
PrerequisitesCheckpoint lesson-3.5; a phone for real-device testing.
Checkpointlesson-3.6

What you will have

The landing page has no horizontal scrolling at phone width, a working mobile menu, every interactive element reachable and operable by keyboard, and an automated accessibility check that reports no serious issues.

Video

The video for this lesson is not recorded yet.

Prompts used in this lesson

Part 3 — Test three widths and fix

Prompt to Claude
Purpose: make the landing page work at phone, tablet and desktop widths.

Context: built in lesson 3.5 mostly at desktop width. Tailwind 4, mobile-first.
What I saw at 375px: (1) header navigation is hidden with no menu; (2) the
page scrolls sideways around the "How it works" section; (3) FAQ questions are
small and close together.

Done when:
- at 375px, 768px and 1280px there is no horizontal scrolling anywhere on the
  page;
- the header has a mobile menu below the md breakpoint: a button with an
  accessible name that opens and closes a panel with the navigation links and
  the CTA; choosing a link closes the panel; the Escape key closes it;
- multi-column sections collapse to one column on a phone and use an
  intermediate layout on a tablet where it helps;
- every link and button is at least 44×44px to tap and has clear space
  around it;
- body text is at least 16px on a phone.

Constraints: fix the components, not individual pages. Only theme tokens. No
new libraries. Before reporting: open the page at each of the three widths,
take a full-page screenshot of each, measure whether the document is wider
than the viewport, and give me a table: width → horizontal scroll yes/no →
issues found → fixed.

Part 5 — The automated check

Prompt to Claude
Purpose: find and fix accessibility problems on the landing page.

Context: the dev server is running at http://localhost:3000. I tested by
keyboard and found: [paste your own list, or "nothing so far"].

Steps:
1. Run npm run lint and fix any accessibility warnings it reports.
2. Run: npx @axe-core/cli http://localhost:3000 --save axe-before.json
   Run it for /styleguide as well.
3. Read the saved JSON and give me a table of violations: rule, impact
   (minor / moderate / serious / critical), how many elements, and a
   one-sentence plain-language explanation.
4. Fix every violation with impact serious or critical, and every moderate
   one that is a simple fix. Also fix my keyboard findings above.
5. Run the check again and show me the before and after counts by impact.

Done when: the re-run shows no serious or critical violations on either page,
every interactive element can be reached and operated by keyboard, and focus
is always visible.

Constraints: fix causes in the shared components and tokens. If a contrast
failure comes from a colour token, do not change the token — stop and tell me
which token, its current ratio, and the nearest value that passes, so I can
decide and update docs/design.md. Do not hide content from screen readers to
silence a rule. Delete the axe JSON files when done; do not commit them.

Do along

Work on your own project and pause the video where told.

  1. Start from lesson-3.5 with the dev server running.
  2. Pause after Part 3. In DevTools, view the page at 375, 768 and 1280 pixels wide. Write down everything that looks wrong at each width.
  3. Run the responsive prompt from Part 3 with your own list of findings.
  4. Push, then open your live domain on your phone. Scroll the whole page, open the menu, rotate the phone. Send any problems to Claude with a screenshot.
  5. Pause after Part 4. Keyboard test on the desktop: reload, then use only Tab, Shift+Tab, Enter, Space and Escape to reach the header CTA, open each FAQ question and reach the footer links. Repeat at 375 pixels for the mobile menu. Write down every place where focus was invisible, out of order or stuck.
  6. Pause after Part 5. Run the accessibility prompt from Part 5 with your keyboard findings pasted in.
  7. If Claude asks about a colour token, decide, update docs/design.md, and let Claude update the theme. Check /styleguide afterwards.
  8. Save the checkpoint with the commands under "Recap and next".

Check your work

  1. DevTools at 375 pixels wide, scroll the full page. Expected: the page never moves sideways and no element is cut off.
  2. On your real phone at the live domain. Expected: the menu opens and closes, links scroll to their sections, every button is easy to tap.
  3. Keyboard only, from page load to the footer. Expected: every link, button and FAQ question is reached in page order, shows a visible focus mark, and works with Enter or Space.
  4. Run npx @axe-core/cli http://localhost:3000 --save check.json and ask Claude to summarise the file by impact, then delete it. Expected: zero serious and zero critical violations.
  5. npm run build and npm run lint. Expected: both pass.

Common problems

  • The axe command fails to start, mentioning Chrome or a driver → Chrome is missing or its version does not match the driver the tool downloaded → install or update Chrome; then give Claude the exact error text and ask it to get the check running, or to run axe-core through the browser-automation tool from lesson 1.6 instead.

Homework

About 25 minutes, after the lesson. No later lesson depends on it.

  1. Someone else's phone. Ask a person with a different phone to open your live domain and, without help, open the menu, jump to the FAQ, open a question and find the quote area. Watch and say nothing. Deliverable: a list of where they hesitated or tapped the wrong thing. Done when: each item is fixed through Claude (screenshot plus numbered points) or written down as accepted. Commit without a tag.
  2. Keyboard test on a second site. Repeat the keyboard test from Part 4 on the site of a business like yours. Deliverable: three lines in your notes: where focus was invisible, out of order or stuck, or that it passed. Done when: you reached their main contact button or form by keyboard, or wrote down where you got stuck.
  3. Bright light, one hand. Outdoors, or with the screen brightness turned down, read your page on your phone held in one hand. Deliverable: a list of text that was hard to read and buttons that were hard to reach. Done when: each item is fixed as in the lesson and steps 1, 3 and 4 of "Check your work" still pass, or the list is empty.

Save your work

git add -A
git commit -m "Lesson 3.6: responsive layout, mobile menu, accessibility fixes"
git tag lesson-3.6
git push
git push --tags