Background image
logologo symbol

4 - Connecting to the World

Accessibility

Description

Accessibility is one of the core aspects of connecting to the rest of the world. When we build websites we want everyone to be able to use them. There are plenty of reasons why a website that looks totally normal to us, might prove har to use, or even impossible by other people. Some people have hard times seeing certain colors, some are blind, old people often have very bad vision etc.
In the day and age of AI there is no reason for not making a website accessable to all and it can even cost your work giver money as the new European laws (Web Accessibility Directive) state that you can be fined for not having the accessibility things in order. A conference to prepare the Icelandic web indistry for this was helt this autumn and the law will take palce in January 2027

Topics

  • WCAG
  • Semantic HTML
  • ARIA labels
  • Accessible names
  • Landmarks
  • Heading hierarchy
  • Skip links
  • Alt text
  • Colour contrast
  • Keyboard navigation
  • Focus management
  • Focus indicators
  • Modal dialogs
  • Live regions
  • Form labels
  • Form validation
  • Screen readers
  • Target size
  • Reflow
  • Playwright
  • axe-core
  • Agent skills
  • Accessibility testing

Goals

Knowledge

• Accessibility barriers faced by people with different disabilities and ways of using the web.
• The role of semantic HTML, accessible names and ARIA in communicating interface structure and purpose to assistive technology.
• Keyboard navigation, focus management and feedback in accessible interfaces.
• WCAG principles and the importance of text alternatives, colour contrast, readable layouts and target sizes.
• The strengths and limitations of automated checks, manual testing and screen-reader testing.
• The influence of accessibility guidance on AI-generated interfaces and the need for human judgement.

Skills

• Translating accessibility needs into design and development decisions.
• Building semantic interfaces with accessible controls, forms and dialogs.
• Evaluating accessibility with automated tools, keyboards, screen readers and zoom.
• Fixing accessibility barriers and writing tests to prevent regressions.
• Writing reusable accessibility guidance for AI agents and assessing their output.
• Comparing test results, recognising evidence limits and giving useful accessibility feedback.

Idea for return

One page on a topic you choose, such as volcanoes, films or board games, with at least 8 items written in a JSON file. Use the colours and type from your Module 3 style guide. The page must have these three sections, whatever your Module 3 design looked like:
Every page has: a header with a skip link and a nav linking to the three sections, a main, a footer, one h1 and no skipped heading levels.
  1. Search and results. A search field labelled "Search". Each result has a heading, an image and an icon-only save button named "Save item name". Show the number of results, and have it read out when it changes.
  2. Details dialog. Clicking a result opens a dialog with more about the item. Focus moves into the dialog, Escape and a "Close" button close it, and focus goes back to the result you opened.
  3. Sign-up form. Name, email, one choice (radio buttons or a select) and a consent checkbox. Errors appear as text next to the field, only after the user has tried. The form shows a success message when it is sent.
The main task is: search for an item, open its details, close them, save the item and sign up.
How to do it
Use one repo: index.html the landing page you return spec.md your accessibility decisions prompt.md the one prompt you use for both builds a/ Project A, no skill b/ Project B, with your skill report/ your report tests/ Playwright tests, run against a/ and b/
  1. Write the prompt. In prompt.md, describe the page: the three sections, your topic and the names above. Attach screenshots of your Module 3 style guide.
  2. Write the spec. Decide what an agent can't decide for you, and write it in spec.md:
    • the heading outline, from h1 down
    • the landmarks: header, nav, main, footer
    • the focus order of the main task, step by step
    • the alt text for each kind of image, and which images are decorative
    • the colour pairs you use, with their contrast ratios (AA: 4.5:1 for text, 3:1 for icons and borders)
  3. Write the tests before you build. Your agent can help, but read every line.
    • A keyboard test that does the main task with Tab, Shift+Tab, Enter, Space and Escape.
    • A test that focus is visible.
    • A test that focus returns to the result after the dialog closes.
    • An axe scan with no serious or critical violations.
    • Commit them failing.
  4. Build Project A. Give the agent prompt.md in a fresh session. There is no skill in the repo yet. Don't fix anything by hand. Run the tests and write down the number of failures and which tests failed.
  5. Write your skill. Put it in .claude/skills/accessibility/SKILL.md for Claude Code, or .agents/skills/accessibility/SKILL.md for Codex. It should be about one page.
    • Frontmatter: name: accessibility and a description saying when to use it: "Use whenever you build or change UI."
    • Rules:
      • native elements (button, a, label, dialog, nav)
      • a name for every control
      • visible focus
      • how a dialog handles focus
      • how form errors are shown and read out
      • alt text, with alt="" for decorative images
      • 24 px minimum touch targets
    • Your spec: tell the agent to follow spec.md.
    • Last line: "When you are done, run the tests and fix what fails."
    • For ideas, read the accessibility guides in Chrome's Modern Web Guidance, but don't install it. The skill you wrote should be the only thing that differs between A and B.
  6. Build Project B. Use a fresh session and the same prompt, and tell the agent to work only in b/. Run the tests and write down the failures. Then work on B until every test passes. A stays as it was.
  7. Let an agent use your page. Give an agent browser tools (Chrome DevTools for agents, Playwright MCP, or the browser built into Codex) and ask it to do the main task on B. Then, in a copy, turn the save button into a div and ask again. Write down what changed.
  8. Test by hand, no AI. Use the keyboard only, then a screen reader (VoiceOver, NVDA or Orca), then 200% zoom. Write down what the tests missed, and add a test for at least one of those problems.
  9. Set up CI and publish. GitHub Actions runs the tests on b/ and must be green. Publish the repo with GitHub Pages.
Return the guide
  • The return is the landing page, with links to Project A, Project B and the report.
  • The report shows:
    • the failures for A and for B, and which tests they were
    • what the agent did on B, before and after the div
    • what your hand test found that the tests missed
    • your skill, with one rule that made a difference
    • what the AI got wrong
  • In the return form, put the repo under GitHub repository and the landing page under Live page. In the description field, write the main task with your own item, for example "Search for Hekla, open it, save it and sign up."
Review two classmates
  1. Put your mouse away and do their main task on Project B with the keyboard only. Write down every step where focus got lost, disappeared or jumped somewhere odd.
  2. Do it again with a screen reader. Compare what you hear with their spec.md: are the headings, the alt text and the focus order what they decided?
  3. Compare with their report. Did you find anything they missed?
  4. Vote:
    • Pass: you finished the main task with the keyboard only, the Actions check is green, and the report has the A/B numbers.
    • No pass: any of those is missing.
    • Hall of Fame: you found nothing they hadn't already found.

Materials

W3C WAI Easy Checks — a starting checklist for your manual review: headings, skip links, keyboard focus, contrast, labels and zoom. These checks are not a complete audit.W3C WAI Forms Tutorial — use the labelling, grouping, validation and notification examples for your sign-up form.W3C WAI Images Tutorial — use the alt-text decision tree to choose useful alternatives and identify decorative images in spec.md.web.dev Learn Accessibility — lessons on HTML and ARIA, focus, forms and testing; use these to prepare your specification and agent skill.MDN Accessibility on the web — practical learning material on semantic HTML, CSS, JavaScript and accessible interactions.W3C Digital Accessibility Foundations — an introductory course on disability, assistive technology, accessibility principles and evaluation.WCAG 2.2 Quick Reference — look up the relevant A and AA criteria, especially contrast, keyboard access, focus, target size, errors and status messages.WAI-ARIA APG Modal Dialog Pattern — check naming, keyboard behaviour, initial focus and focus return for the details dialog.Playwright Accessibility Testing — integrate axe-core, scan interactive states and understand the limits of automated testing.