Skip to Content
Lab 1 (AI)

Accessibility Audit with a Socratic Tutor

In this lab, you will explore the key principles of accessible web design through an interactive Scrimba lesson, and then put those principles to work by auditing and repairing an intentionally inaccessible web page with Claude acting as your Socratic tutor. Accessibility audits are a routine professional task for front-end developers, and learning to reason through one yourself, rather than being handed the answers, builds the judgment that employers expect. This lab is asynchronous and takes approximately 2 hours in total.

Scenario

You are a junior front-end developer at Accessible Design Co., the same company featured in this module’s Skills-Based Assessment. A contractor has delivered a marketing page that, embarrassingly for a company with this name, fails the company’s own accessibility standards. Your engineering mentor has agreed to guide you through the audit, but company policy is firm: the mentor asks questions and checks your reasoning, and you find and write every fix yourself. In this lab, Claude plays the mentor in the AI as Socratic Tutor role: it may question, probe, and confirm, but it is never allowed to write code for you.

Objectives

By the end of this lab, you will have demonstrated your ability to:

  • Apply semantic HTML to improve accessibility.
  • Use ARIA attributes to enhance accessibility for screen readers.
  • Ensure proper color contrast and text readability.
  • Design forms and interactive elements with accessibility in mind.
  • Conduct a structured accessibility audit through Socratic dialogue, proposing, implementing, and defending your own fixes.

Part 1: Interactive Accessibility Lesson (approximately 70 minutes)

Access the Scrimba Learn Accessible Web Design Course using the link below. This course covers essential topics, including:

  • Understanding web accessibility and its importance.
  • Using semantic HTML to make content more understandable.
  • Ensuring that color contrast meets accessibility standards.
  • Adding alternative text to images.
  • Using ARIA roles and attributes to improve navigation and interaction.

Link: Scrimba Accessible Web Design Course 

Note

If the Scrimba course is unavailable, has moved behind a paywall, or you cannot create an account, complete these free readings instead; together they cover the same topics:

When you finish Part 1, you should be able to recognize the major categories of accessibility problems. Part 2 asks you to find them in real code.

Part 2: Socratic Accessibility Audit (approximately 50 minutes)

Step 1: Set Up Your Project (about 5 minutes)

  1. Create a project folder with before and after directories, and initialize a Git repository:

    mkdir accessibility-audit-lab
cd accessibility-audit-lab
mkdir before
mkdir after
git init

    These commands work in Git Bash, macOS and Linux terminals, and Windows PowerShell.

  2. Create the file before/index.html and paste in the starter page below, exactly as written. This is the contractor’s page, and it contains many deliberate accessibility problems.

    <!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Accessible Design Co.</title>
  <style>
    body {
      font-family: Arial, sans-serif;
      margin: 0;
      background-color: #ffffff;
      color: #9a9a9a;
    }
 
    *:focus {
      outline: none;
    }
 
    .top {
      display: flex;
      justify-content: space-between;
      align-items: center;
      padding: 16px 24px;
      background-color: #e8e8e8;
    }
 
    .menu {
      display: flex;
      gap: 16px;
    }
 
    .menu a {
      color: #b3b3b3;
      text-decoration: none;
    }
 
    .content {
      max-width: 720px;
      margin: 0 auto;
      padding: 24px;
    }
 
    .hero-img {
      max-width: 100%;
    }
 
    .cta {
      width: max-content;
      padding: 12px 24px;
      background-color: #d1d1d1;
      color: #ffffff;
      cursor: pointer;
    }
 
    .form-area {
      display: flex;
      flex-direction: column;
      gap: 12px;
      max-width: 320px;
    }
 
    .form-area input {
      padding: 8px;
      border: 1px solid #dddddd;
    }
 
    .bottom {
      padding: 16px 24px;
      background-color: #e8e8e8;
      font-size: 14px;
    }
  </style>
</head>
<body>
  <div class="top">
    <img src="images/logo.png" width="120">
    <div class="menu">
      <a href="#home">Home</a>
      <a href="#services">Services</a>
      <a href="#contact">Contact</a>
    </div>
  </div>
 
  <div class="content">
    <h1>Design that works for everyone</h1>
    <h4>Trusted by teams that care about their users</h4>
 
    <img class="hero-img" src="images/team.jpg">
 
    <p>
      Accessible Design Co. helps companies build products that every user
      can operate with confidence. To learn more about our services,
      <a href="#services">click here</a>.
    </p>
 
    <div class="cta" onclick="alert('Thanks for signing up!')">Sign Up</div>
 
    <h4>Contact us</h4>
    <div class="form-area">
      <input type="text" placeholder="Your name">
      <input type="text" placeholder="Your email">
      <div class="cta" onclick="alert('Message sent!')">Send</div>
    </div>
  </div>
 
  <div class="bottom">© 2026 Accessible Design Co. All rights reserved.</div>
</body>
</html>

    The referenced image files are intentionally not provided. Broken image icons are expected in the browser, and they are a useful reminder of why alternative text matters.

  3. Copy the starter page into the after directory. All of your fixes will go into after/index.html; the before copy must remain untouched so your instructor can compare the two.

    cp before/index.html after/index.html

    (This command also works in Windows PowerShell, where cp is a built-in alias for Copy-Item.)

  4. Make your initial commit:

    git add .
git commit -m "Add starter page before audit"

Step 2: Set Up Your Socratic Tutor (about 5 minutes)

Copy the following role prompt. You will give it to Claude before the audit begins, and it defines the rules of the entire conversation.

You are a Socratic accessibility tutor. I am a learner auditing an HTML page
for accessibility problems. Follow these rules for the entire conversation:

1. Never write, rewrite, or dictate code. Do not provide corrected HTML, CSS,
   or JavaScript, even if I ask for it. If I ask for code, remind me of this
   rule and ask a guiding question instead.
2. Audit the HTML I provide against WCAG 2.1 Level AA. Raise one issue at a
   time.
3. Phrase every observation as a guiding question. For example: "How would a
   screen reader user know what this image shows?"
4. When I propose a fix, do not confirm it immediately. Ask a follow-up
   question that tests whether my fix is complete and correct. Confirm an
   issue as resolved only when my explanation and my code are both correct.
5. Keep a running count of open issues. Each time you raise a new issue,
   state the current count. When I resolve one, acknowledge it and update
   the count.
6. If I head down the wrong path, do not give me the answer. Ask a narrower
   question that points me at the evidence.
7. Continue until at least these categories have been covered: semantic
   structure, alternative text, color contrast, keyboard access, form
   labeling, and appropriate ARIA use.

Choose one of the two setup paths below.

Option A: claude.ai (recommended for this lab)

  1. Sign in at https://claude.ai  with your Per Scholas-provided Claude Pro account.
  2. Create a new Project named Socratic Accessibility Tutor.
  3. Paste the role prompt into the Project’s custom instructions. Placing the prompt in the Project instructions applies it to every conversation in the Project, which is the reliable way to enforce the role.
  4. Start a new chat inside the Project. Paste the full contents of before/index.html as your first message, along with the request: “Please begin the audit.”

Option B: Claude Code

  1. If you have not installed Claude Code, run npm install -g @anthropic-ai/claude-code (Node.js 18 or later is required).

  2. Create a file named CLAUDE.md at the root of your project folder. Paste the role prompt into it, then add these two lines at the end:

    You may read files in this repository, but you must never create, edit,
or delete any file. If you are about to suggest an edit or offer to
apply a fix, ask a guiding question instead.

  3. Run claude inside the project folder, and log in with the Per Scholas-provided Claude account when prompted (/login).

  4. Ask: “Audit before/index.html against WCAG 2.1 AA and ask me your first question.”

  5. Claude Code asks permission before editing files. If it ever requests permission to edit or create a file during this lab, decline the request; in this lab, all editing is your job.

Note

If you do not have access to a Pro-level Claude account through Per Scholas, you may complete this lab using the free tier of Claude or another AI assistant with equivalent capabilities. Free-tier usage limits may require you to complete the lab across more than one session. The free tier does not include Projects, so paste the role prompt as the very first message of your chat, then paste the starter HTML in your second message. Keep your turns concise to stay within message limits.

Step 3: Run the Audit Loop (about 25 minutes)

Claude will open with a Socratic question about the first issue it finds. For each issue, work through this loop:

  1. Answer in words. Explain what the problem is and which users it affects. Do not touch the code yet.

  2. Propose a fix in words. Describe exactly what you intend to change and why.

  3. Write the fix yourself in after/index.html. Never paste code from Claude; if the role prompt is working, Claude will not be producing any.

  4. Commit the fix with a descriptive message, one commit per fix:

    git commit -am "Add descriptive alt text to hero image"

  5. Report back. Paste the changed lines to Claude and answer its follow-up questions until it confirms the issue is resolved and moves to the next one.

If Claude ever writes corrected code despite the prompt, reply: “You are my Socratic tutor. Do not write code. Ask me a question instead.” Your transcript must show that the fixes are yours.

Note

As you work, remember the first rule of ARIA: prefer native semantic HTML, and add ARIA only when native elements cannot express the meaning you need. For example, a <nav> element already has a built-in navigation role, so adding role="navigation" to it is redundant, and a native <button> needs no role="button". Expect your tutor to question any redundant ARIA you propose.

Important

Checkpoint: before moving on, your audit must have surfaced and fixed issues in at least five of these six categories: semantic structure, alternative text, color contrast, keyboard access, form labeling, and appropriate ARIA use. The starter page contains problems in all six. If you are short, ask Claude: “Which categories have we not covered yet?”

Step 4: Verify with Tools (about 10 minutes)

  1. Lighthouse cannot audit a page opened directly from your file system (a file:// address), so serve the project over HTTP first. From the project root, run:

    npx serve

    The command prints a local address, typically http://localhost:3000. Open that address in Chrome, navigate to the /after/ path (for example, http://localhost:3000/after/), and run an automated check with Lighthouse (open DevTools, select the Lighthouse panel, check the Accessibility category, and run the audit) or with the axe DevTools  browser extension. When you are done, stop the server with Ctrl+C.

  2. Perform a keyboard-only test: set your mouse aside and use only Tab, Shift+Tab, Enter, and Space. Confirm that every interactive element is reachable, shows a visible focus indicator, and can be activated.

  3. Paste anything the tools or the keyboard test flagged into your Claude conversation for one final Socratic round. Fix what you find in after/index.html and commit.

Step 5: Wrap Up and Prepare Your Submission (about 5 minutes)

  1. Capture your transcript. In claude.ai, use the Share button on the conversation to create a public link. If sharing is disabled in your workspace, or you used Claude Code, copy the full transcript into a file named TRANSCRIPT.md in your repository instead.

  2. Write REFLECTION.md in the repository root, answering the Reflection Questions below. If you created a share link, put it at the top of this file.

  3. Push to GitHub. Create a new repository on GitHub, then:

    git add .
git commit -m "Add reflection and transcript"
git branch -M main
git remote add origin <your-repository-url>
git push -u origin main

Reflection Questions

Answer all three questions in REFLECTION.md:

  1. Which accessibility issues did Claude’s questions lead you to discover that you might have missed on your own?
  2. Which WCAG 2.1 success criteria does each of your fixes address? List every fix alongside its criterion, for example: “Added alt text to the hero image: 1.1.1 Non-text Content.”
  3. Where did the Socratic format help you learn more than being given the answers directly, and where did it slow you down?

Additional Resources

Submission Guidelines

Submit the link to your GitHub repository on Canvas. Your repository must contain:

  • before/index.html: the unmodified starter page.
  • after/index.html: the page with all of your fixes.
  • A shared claude.ai conversation link (at the top of REFLECTION.md) or a TRANSCRIPT.md file demonstrating the Socratic exchange.
  • REFLECTION.md answering all three reflection questions.
  • A commit history showing one commit per fix, authored by you.

This lab is graded as complete or incomplete. To receive a complete, your submission must show all four of the following:

  1. The repository contains both the before and after versions of the audited page, and the before copy is unmodified.
  2. At least five distinct accessibility issue categories were surfaced through Socratic questioning and fixed by you in after/index.html, with commits showing learner-authored fixes.
  3. The shared conversation link or transcript shows that the AI asked guiding questions and did not write corrected code.
  4. REFLECTION.md answers all three reflection questions.
Lesson 2: Flexbox, Grid, and DevToolsLesson 3: Integrating Accessibility into Web Design