My progress
Menu

UI/UX Product Designer · Focus area 3: Interactive prototypes

UX7: Accessible and inclusive design

Goal: design screens that work for people with disabilities and in difficult situations: by keyboard, with a screen reader, with large text and touch, and for India's many languages, literacy levels and phones.

You'll need: UX4 to UX6, Module 13 (Forms and Inputs), Module 19 (Browser Interactions), Module 39 (Frontend Quality), and the SehatSlot practice kit.

Where this is used: a clinic booking site that a blind patient can't use, or that a grandmother can't read, isn't finished. Banks, government services and large companies check accessibility before launch, and in India the Rights of Persons with Disabilities Act, 2016 makes accessible information and communication technology an obligation.

How it differs: most design choices are trade-offs. Accessibility has measurable requirements (WCAG) as a floor, and the work is checking that every person can complete the task, not just most people.

Time: reading about 2½ hours · practice (the Try it tasks) about 3 hours · assignment about 3 hours.

Lessons

  1. 1Why accessibility, and what WCAG asksReading 15–25 minutes, plus practice✓
  2. 2Keyboard use and focusReading 15–25 minutes, plus practice✓
  3. 3Screen readers: names, roles and statesReading 15–25 minutes, plus practice✓
  4. 4Touch, zoom and reflowReading 15–25 minutes, plus practice✓
  5. 5Inclusive design for IndiaReading 15–25 minutes, plus practice✓

🛠️Assignment: Make SehatSlot work for everyone

  1. Run axe on every page and fix what it reports; then list what axe didn't find.
  2. Complete the journey with only a keyboard; fix anything you can't reach or can't see.
  3. Use a screen reader on the slot and details screens; write down what is announced and fix missing names, roles or states.
  4. Check every target at 375 pixels wide and every page at 320 pixels and at 200% text.
  5. List the changes needed for Hindi, assisted booking and budget phones.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How do you make a booking journey accessible and inclusive, and how do you check it?

Show a good answer

A good answer mentions: who benefits, including situational limits; WCAG 2.2's POUR principles and AA as the usual target; automated checks plus manual keyboard and screen reader checks; real controls with names, roles and states, and announced changes; visible focus with 3 to 1 contrast and a logical order; targets of at least 24 pixels (44 in the kit) with space between; reflow at 320 pixels and 200% text; and designing for languages, literacy, budget phones and shared devices, with personal details masked.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A team's pages pass axe with no problems. What's the right conclusion?

Why each option is right or wrong

  • “The pages are fully accessible and need no more checking before launch” (Incorrect): Automated tools find many problems but miss others.
  • “The design meets WCAG AAA, since axe checks every success criterion” (Incorrect): axe checks a subset of criteria, mostly A and AA.
  • “Nothing at all, since automated tools aren't useful for accessibility work” (Incorrect): They're useful and quick; they just aren't enough.
  • “Some problems are ruled out; keyboard and screen reader checks still matter” is correct.

    Tools can't judge label meaning, focus order or forgotten placeholders.

    • Add: testing with disabled participants.
    • Kit: tests 2, 3 and 7 check what axe can't.

📖 Revise: Lesson 1: Why accessibility, and what WCAG asks

Question ID sp-ui-ux-07-q1 · Report a mistake in this question
2. Time slots are div elements with click handlers. What's the best fix?

Why each option is right or wrong

  • “Add tabindex="0" so they can be reached with the Tab key” (Incorrect): Reachable isn't enough: Enter and Space still won't work, and there's no role or state.
  • “Add a note telling keyboard users to use a mouse for this step” (Incorrect): That excludes people who can't use a mouse.
  • “Make the slots bigger so they're easier to click with a mouse” (Incorrect): Size helps touch and mouse users but not keyboard users.
  • “Make each slot a button with aria-pressed” is correct.

    Buttons are keyboard-ready, and aria-pressed announces which time is chosen.

    • Also: a visible selected style and a status line.
    • Kit: test 3.

📖 Revise: Lesson 2: Keyboard use and focus

Question ID sp-ui-ux-07-q2 · Report a mistake in this question
3. A designer removes the focus outline because it "looks messy". What should happen instead?

Why each option is right or wrong

  • “Nothing, as long as mouse users can still see the hover style” (Incorrect): Keyboard users lose track of where they are.
  • “Keep it for links only and remove it from buttons and fields” (Incorrect): Every focusable control needs a visible indicator.
  • “Show the outline only after the user has pressed Tab five times” (Incorrect): Focus needs to be visible from the first press.
  • “Design a clear :focus-visible style with at least 3 to 1 contrast” is correct.

    A deliberate focus style can look tidy and still show where people are.

    • Kit: 3 px outline, 5.12 to 1 on the background.
    • WCAG: 2.4.7 Focus Visible.

📖 Revise: Lesson 2: Keyboard use and focus

Question ID sp-ui-ux-07-q3 · Report a mistake in this question
4. After choosing a time, nothing is announced to a screen reader user. What helps most?

Why each option is right or wrong

  • “A sound effect that plays each time a slot is selected” (Incorrect): Sounds don't say what was chosen, and may not be heard.
  • “Moving focus to the top of the page each time a slot is chosen” (Incorrect): That loses the user's place.
  • “Making the chosen slot flash a few times so it is easier to spot” (Incorrect): Flashing is visual only, and can be harmful.
  • “A status line with role="status" saying "Selected: 10:30"” is correct.

    Changes in a status region are read out without moving focus.

    • Plus: aria-pressed="true" on the chosen button.
    • Visible: the same text helps everyone.

📖 Revise: Lesson 3: Screen readers: names, roles and states

Question ID sp-ui-ux-07-q4 · Report a mistake in this question
5. Two buttons, "Confirm" and "Cancel", are 32 by 32 pixels and 2 pixels apart. What's the main risk?

Why each option is right or wrong

  • “They meet the WCAG minimum, so there's no risk worth fixing here” (Incorrect): They meet 24 by 24, but closeness still causes mis-taps.
  • “Screen readers can't tell the two buttons apart from each other” (Incorrect): Their names differ; the risk is for touch.
  • “The buttons will look too large on bigger tablet screens” (Incorrect): The problem is that they're small and close.
  • “People tap the wrong one, especially older users or those with tremors” is correct.

    Small, close targets cause errors; separation and size reduce them.

    • Kit floor: 44 by 44.
    • Also: make the destructive action less prominent.

📖 Revise: Lesson 4: Touch, zoom and reflow

Question ID sp-ui-ux-07-q5 · Report a mistake in this question
6. The confirmation page shows the patient's full mobile number. Why does this matter?

Why each option is right or wrong

  • “It doesn't; patients like to check their number is correct” (Incorrect): Checking is useful, but the last four digits are enough for that.
  • “It slows the page down for patients on 2G connections” (Incorrect): The number is a few bytes; privacy is the issue.
  • “Screen readers read long numbers too slowly for most users” (Incorrect): That's not the main concern.
  • “Phones are shared and seen by others, so it exposes personal data” is correct.

    Masking keeps the confirmation useful without showing the whole number.

    • Reference: "Ending in 4321".
    • Research: P4 raised it.

📖 Revise: Lesson 5: Inclusive design for India

Question ID sp-ui-ux-07-q6 · Report a mistake in this question
7. What does WCAG 2.2's reflow criterion ask for?

Why each option is right or wrong

  • “That pages load in under three seconds on a phone connection” (Incorrect): That's performance, not reflow.
  • “That every page has a printable version with the same content” (Incorrect): Reflow isn't about printing.
  • “That the text can be translated into at least two Indian languages” (Incorrect): Languages matter, but that isn't what reflow means.
  • “Content usable at 320 CSS pixels wide without sideways scrolling” is correct.

    This also covers people who zoom to 400% on a desktop.

    • Kit: test 8.
    • Fix: flexible layouts, no fixed widths.

📖 Revise: Lesson 4: Touch, zoom and reflow

Question ID sp-ui-ux-07-q7 · Report a mistake in this question
8. A team plans to translate the app into Hindi after launch. What's the main risk?

Why each option is right or wrong

  • “Hindi users will use the app less often than English users do” (Incorrect): That's an assumption, not the risk of the plan.
  • “Translators charge more when work is done after a launch” (Incorrect): Possibly, but the bigger risk is design.
  • “Hindi text needs a different colour scheme from English text” (Incorrect): Colours don't depend on language.
  • “Layouts and images may not fit; text may be baked into images” is correct.

    Planning languages from the start avoids rework and broken screens.

    • Do: strings outside images; room for longer words.
    • Test: with each script.

📖 Revise: Lesson 5: Inclusive design for India

Question ID sp-ui-ux-07-q8 · Report a mistake in this question
9. What are a control's name, role and state?

Why each option is right or wrong

  • “Its CSS class, its colour and its size in pixels on the screen” (Incorrect): Those are visual properties, not what assistive technology uses.
  • “Its file name, its folder and its version in the design system” (Incorrect): Those are about the code, not the person using it.
  • “Its label text, its tooltip and its keyboard shortcut, in that order” (Incorrect): Partly related, but name, role and state are the core.
  • “What it is called, what kind it is, and its condition” is correct.

    Screen readers announce all three, such as "10:30, toggle button, pressed".

    • HTML first: native elements give roles and states.
    • ARIA: for what HTML can't express.

📖 Revise: Lesson 3: Screen readers: names, roles and states

Question ID sp-ui-ux-07-q9 · Report a mistake in this question
10. Who benefits from captions on a video explaining how to book?

Why each option is right or wrong

  • “Only people who are deaf, which is a very small group of the users” (Incorrect): Many more people use captions.
  • “Nobody, since most people watch help videos with the sound on” (Incorrect): Many watch without sound, in public or in noise.
  • “Only people who are learning English as a second language” (Incorrect): They benefit too, but they're not the only ones.
  • “Deaf people, and anyone watching without sound, such as on a bus” is correct.

    Accessible design helps people with disabilities and in situational limits.

    • Like: the ramp that helps prams and suitcases.
    • Also: a text version of the steps.

📖 Revise: Lesson 1: Why accessibility, and what WCAG asks

Question ID sp-ui-ux-07-q10 · Report a mistake in this question

ProLearners Assist