90-minute class plan
- 0–10 min — Opening and visual warm-up: Introduce the learning goals, review the previous class, and discuss a relevant website example.
- 10–25 min — Mini-lesson: Explain the key concepts and show examples. Keep the presentation focused on what students will apply.
- 25–45 min — Instructor demonstration: Walk through the interactive CodePen or a live example. Pause for predictions and questions.
- 45–70 min — Guided and independent practice: Students complete the lesson exercise, first following a short demonstration and then making their own decisions.
- 70–83 min — Apply and critique: Students connect the skill to their website project, compare results with a partner, and make one improvement.
- 83–90 min — Share-out and exit ticket: Review key takeaways and ask students to identify one thing they learned and one next step.
Course: Introduction to Web Design
Week: 12
Learning objectives
By the end of this lesson, you should be able to:
- Recognize common accessibility issues involving contrast, headings, labels, and focus.
- Explain why automated checks cannot replace human testing.
- Conduct a basic keyboard and peer usability review.
Key concepts
Accessibility helps people with different abilities use digital content. Basic practices include adequate text contrast, logical heading structure, meaningful labels, visible keyboard focus, useful alternative text, and controls that can be operated without a mouse.
Usability testing asks whether people can complete tasks and understand the interface. Observe where they hesitate, misunderstand a label, or take an unexpected path. Treat those moments as evidence about the design—not as failures by the participant.
An automated checklist can reveal some issues, but it cannot certify a website as accessible. Combine automated tools, keyboard testing, and human feedback.
Interactive demonstration
Demo file: 09-accessibility-checker.html
Change each setting in the Accessibility First Lab. Observe the simulated issue, then try tabbing through the interface. Discuss what the demo can and cannot prove.
See the Pen 09-accessibility-checker by Nicholas D’Angelo (@ndangelo) on CodePen.
Run a peer test of your project. Ask a classmate to complete two tasks without coaching. Check keyboard access, visible focus, heading order, labels, and text contrast. Record at least two improvements.
Connection to your website project
Use testing evidence to revise your midterm site and strengthen the accessibility plan for the final website.
Sublime Text coding lab
Complete this coding task in Sublime Text, save the files using the names below, and open the HTML page in a browser to test it.
Today’s coding focus
Accessibility, keyboard testing, semantic fixes, alt text, contrast, validation
Project files and folder structure
Create week-12/index.html, week-12/css/styles.css, and week-12/accessibility-audit.txt.
Syntax to practice
Semantic landmarks, descriptive links, alt attributes, label associations, heading order, :focus / :focus-visible, contrast.
Build it
Audit an earlier page using only the keyboard. Check heading order, image alternatives, link text, labels, focus visibility, and contrast. Make at least three code corrections and retest.
Code along: Make keyboard focus visible on links and form controls.
Open in Sublime Text: week-12/css/styles.css
Type the example below, save the file, and read the comments and selectors carefully. Use this as a starting point, then modify it for your own project.
a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible {
outline: 3px solid #2563eb;
outline-offset: 3px;
}
Complete HTML and CSS example
These are matching files. Create the folders shown below, save each code sample using the exact filename, and keep the stylesheet link consistent with your folder structure.
HTML file: week-12/index.html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Keyboard Accessibility Check</title>
<link rel="stylesheet" href="css/styles.css">
</head>
<body>
<main><h1>Keyboard test</h1><p>Use Tab to move between these controls.</p><a href="#details">Read details</a><button type="button">Example button</button><section id="details"><h2>Details</h2><p>Focus indicators help identify the active control.</p></section></main>
</body>
</html>
CSS file: week-12/css/styles.css
body { margin: 0; padding: 24px; font-family: Arial, sans-serif; line-height: 1.7; color: #172033; }
main { max-width: 720px; margin: auto; }
a, button { margin-right: 12px; }
button { padding: 10px 14px; border: 0; border-radius: 5px; background: #1d4ed8; color: white; }
a:focus-visible, button:focus-visible { outline: 3px solid #f59e0b; outline-offset: 4px; }
Important: The HTML links to css/styles.css. Keep that path correct relative to the HTML file.
Modify it
Use Tab and Shift+Tab to navigate. Add a visible focus style wherever an interactive element lacks one.
Save and test
- Save the file in the exact folder shown above.
- Open the HTML file in a browser, or refresh it after saving if it is already open.
- Check that linked CSS, images, and navigation work. If something fails, inspect filenames, capitalization, nesting, and relative paths.
Assignment and required deliverables
Submit every item below. Use the specified filenames and folder structure. A screenshot does not replace a required source file.
Required files
week-12/index.htmlandweek-12/css/styles.css— revised accessible page.week-12/accessibility-audit.txt— at least five checks marked pass/fail with evidence.week-12/before-after.png— evidence of at least one improvement.week-12/README.txt— three fixes and user benefit of each.
Submission checklist
- Five checks documented; three fixes made; keyboard focus visible; appropriate text alternatives included.
- Keep all HTML, CSS, image, text, and PDF files inside the named weekly or project folder.
- Open the HTML file in a browser before submitting and confirm linked CSS and images load.
Before you leave (3-minute exit check)
Write down one thing you changed, one thing you learned from the result, and one question you still have.
References
These references support the key concepts and practices covered in this lesson. They are provided for verification and further study.
- Mozilla Contributors. (n.d.). *Accessibility on the web*. MDN Web Docs. https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Accessibility
- World Wide Web Consortium. (n.d.). *Web accessibility tutorials*. Web Accessibility Initiative. https://www.w3.org/WAI/tutorials/
- World Wide Web Consortium. (n.d.). *Web Content Accessibility Guidelines (WCAG) 2.2*. W3C. https://www.w3.org/TR/WCAG22/