Intermediate
Product Design
#accessibility
#wcag
#inclusive-design
Accessibility Design Language
6 exercises — learn to discuss WCAG conformance levels, contrast ratios, focus indicators, touch targets, alt text, and inclusive design considerations in English.
0 / 31 completed
1 / 31
What is the difference between WCAG Level A, AA, and AAA in a design context?
WCAG conformance levels — Level A, AA, AAA describe increasing strictness of the Web Content Accessibility Guidelines:
• Level A — the minimum: basic accessibility (e.g., all images have alt text, content isn't seizure-inducing)
• Level AA — the industry standard, and the level most legal requirements (ADA, EN 301 549, EAA) reference: includes 4.5:1 text contrast, resizable text, visible focus indicators, keyboard operability
• Level AAA — the strictest level, including 7:1 contrast and sign-language interpretation for video — rarely achievable across an entire product, so it is usually applied selectively (e.g., to a specific critical flow)
When a designer says "this needs to be AA compliant," they mean it must pass the ~50 AA success criteria, not just Level A. When reviewing a design against WCAG, always specify the level — "accessible" alone is not a precise, testable requirement.
• Level A — the minimum: basic accessibility (e.g., all images have alt text, content isn't seizure-inducing)
• Level AA — the industry standard, and the level most legal requirements (ADA, EN 301 549, EAA) reference: includes 4.5:1 text contrast, resizable text, visible focus indicators, keyboard operability
• Level AAA — the strictest level, including 7:1 contrast and sign-language interpretation for video — rarely achievable across an entire product, so it is usually applied selectively (e.g., to a specific critical flow)
When a designer says "this needs to be AA compliant," they mean it must pass the ~50 AA success criteria, not just Level A. When reviewing a design against WCAG, always specify the level — "accessible" alone is not a precise, testable requirement.
2 / 31
Fill in the blank:
"The text achieves a contrast ___ of 7.2:1, meeting WCAG AAA."
Contrast ratio — the standard measurement of the difference in luminance (perceived brightness) between two colours, expressed as a ratio from 1:1 (identical, no contrast) to 21:1 (pure black on pure white, maximum contrast).
Key thresholds to know and cite precisely in reviews:
• 4.5:1 — WCAG AA minimum for normal body text
• 3:1 — WCAG AA minimum for large text (18pt+/24px+, or 14pt+/18.66px+ bold) and for UI component boundaries/graphical objects
• 7:1 — WCAG AAA minimum for normal text
• 4.5:1 — WCAG AAA minimum for large text
Always state the exact ratio in a design review, not a subjective description: "the text achieves a contrast ratio of 7.2:1" is checkable and unambiguous; "the text looks readable enough" is not. Design tools and browser extensions (Stark, Figma's built-in contrast checker, Chrome DevTools) calculate this ratio automatically from the two colour values.
Key thresholds to know and cite precisely in reviews:
• 4.5:1 — WCAG AA minimum for normal body text
• 3:1 — WCAG AA minimum for large text (18pt+/24px+, or 14pt+/18.66px+ bold) and for UI component boundaries/graphical objects
• 7:1 — WCAG AAA minimum for normal text
• 4.5:1 — WCAG AAA minimum for large text
Always state the exact ratio in a design review, not a subjective description: "the text achieves a contrast ratio of 7.2:1" is checkable and unambiguous; "the text looks readable enough" is not. Design tools and browser extensions (Stark, Figma's built-in contrast checker, Chrome DevTools) calculate this ratio automatically from the two colour values.
3 / 31
A designer removes the default blue outline around buttons "because it looks messy," without adding a replacement. What accessibility concept have they violated?
Focus indicator — the visible outline, highlight, or ring that shows which interactive element currently has keyboard focus. It is essential for anyone navigating with a keyboard, a switch device, voice control, or any input method other than a mouse — without it, a keyboard user pressing Tab has no way to see where they are on the page.
Vocabulary in this space:
• Visible focus ring — the outline style (often
• Skip link — a hidden-until-focused link at the top of a page ("Skip to main content") that lets keyboard users bypass repetitive navigation
• Keyboard navigation — the ability to reach and operate every interactive element using only Tab, Shift+Tab, Enter, Space, and arrow keys, in a logical order matching the visual layout
• Focus trap — intentionally, temporarily confining keyboard focus within a modal/dialog so Tab doesn't escape to the page behind it
The correct design pattern: keep the focus indicator, or replace it with an equally or more visible custom style — never delete it outright for aesthetic reasons alone.
Vocabulary in this space:
• Visible focus ring — the outline style (often
outline or box-shadow in CSS) shown on :focus. Removing it without a replacement is a Level AA failure (2.4.7 Focus Visible)• Skip link — a hidden-until-focused link at the top of a page ("Skip to main content") that lets keyboard users bypass repetitive navigation
• Keyboard navigation — the ability to reach and operate every interactive element using only Tab, Shift+Tab, Enter, Space, and arrow keys, in a logical order matching the visual layout
• Focus trap — intentionally, temporarily confining keyboard focus within a modal/dialog so Tab doesn't escape to the page behind it
The correct design pattern: keep the focus indicator, or replace it with an equally or more visible custom style — never delete it outright for aesthetic reasons alone.
4 / 31
A mobile design review flags: "This icon button is only 32×32pt." What is the concern, according to WCAG 2.5.5 and platform guidelines?
Touch target size — the minimum tappable area for an interactive element on touchscreens, distinct from the visual size of the icon inside it.
Key standards to cite by name in a review:
• WCAG 2.5.5 Target Size (Level AAA) — recommends at least 44×44 CSS pixels
• WCAG 2.5.8 Target Size (Minimum, Level AA, added in WCAG 2.2) — requires at least 24×24 CSS pixels, with some exceptions
• Apple Human Interface Guidelines — minimum 44×44pt
• Material Design (Android) — minimum 48×48dp
Note the distinction between the visible icon and the tappable hit area: a 20×20px icon can still have a 44×44pt tap target by adding invisible padding around it — you don't have to make the icon itself larger to fix this issue, just the touchable region. This matters for users with motor impairments, tremors, or anyone using a phone one-handed on a moving bus — small targets increase mis-taps and frustration.
Key standards to cite by name in a review:
• WCAG 2.5.5 Target Size (Level AAA) — recommends at least 44×44 CSS pixels
• WCAG 2.5.8 Target Size (Minimum, Level AA, added in WCAG 2.2) — requires at least 24×24 CSS pixels, with some exceptions
• Apple Human Interface Guidelines — minimum 44×44pt
• Material Design (Android) — minimum 48×48dp
Note the distinction between the visible icon and the tappable hit area: a 20×20px icon can still have a 44×44pt tap target by adding invisible padding around it — you don't have to make the icon itself larger to fix this issue, just the touchable region. This matters for users with motor impairments, tremors, or anyone using a phone one-handed on a moving bus — small targets increase mis-taps and frustration.
5 / 31
When should a decorative icon (with no functional meaning, purely visual) receive alt text?
When to write alt text — and when to deliberately leave it empty — a nuanced but important accessibility design decision:
• Functional/informative images — need descriptive alt text explaining their purpose or content:
• Decorative images — carry no information (a background pattern, a purely stylistic icon next to a text label that already says the same thing) — these should have
• Icon buttons with no visible text — need an accessible name via
A missing alt attribute (not even an empty one) is worse than either extreme — screen readers may announce the image's filename instead, e.g. "IMG_4821.png," which is meaningless noise. The design/handoff rule: annotate every icon and image with "decorative" or "needs alt text: [suggested text]" so developers never have to guess.
• Functional/informative images — need descriptive alt text explaining their purpose or content:
alt="Download PDF invoice" for a download icon, alt="User's profile photo: Sarah Chen" for an avatar• Decorative images — carry no information (a background pattern, a purely stylistic icon next to a text label that already says the same thing) — these should have
alt="" (empty, not missing) or aria-hidden="true", so screen readers skip them silently instead of reading out clutter like "image, decorative swirl, image, decorative swirl" between every list item• Icon buttons with no visible text — need an accessible name via
aria-label even if there's no traditional "alt text," e.g. a trash-can icon button needs aria-label="Delete item"A missing alt attribute (not even an empty one) is worse than either extreme — screen readers may announce the image's filename instead, e.g. "IMG_4821.png," which is meaningless noise. The design/handoff rule: annotate every icon and image with "decorative" or "needs alt text: [suggested text]" so developers never have to guess.
6 / 31
A researcher notes: "This flow has high cognitive load for users with ADHD or memory impairments — too many steps and choices per screen." What inclusive design consideration does this describe?
Cognitive load — the amount of mental effort required to use an interface: how many things a user must remember, compare, or decide at once. High cognitive load affects everyone under stress or distraction, and disproportionately affects users with ADHD, dyslexia, memory impairments, or those unfamiliar with the domain.
Inclusive design vocabulary beyond visual/screen-reader accessibility:
• Cognitive load — reduce steps, chunk information, avoid unnecessary choices, use progressive disclosure (show advanced options only when needed)
• Motor impairment — considerations like larger touch targets, generous spacing between interactive elements, avoiding actions that require precise dragging or fast timing, and supporting keyboard-only or switch-device operation
• Low vision — considerations beyond contrast: resizable text without breaking layout, avoiding reliance on colour alone to convey meaning (e.g., not using only red/green to indicate error/success), supporting 200%+ browser zoom
• Situational impairment — a broader inclusive-design idea: a user holding a baby (one-handed use), in bright sunlight (needs contrast), or on a poor connection (needs graceful loading states) faces temporary, situational versions of the same barriers as permanent disabilities
Inclusive design language moves the conversation from "compliance checklist" to "who might struggle here, and why" — a more durable framing for design reviews.
Inclusive design vocabulary beyond visual/screen-reader accessibility:
• Cognitive load — reduce steps, chunk information, avoid unnecessary choices, use progressive disclosure (show advanced options only when needed)
• Motor impairment — considerations like larger touch targets, generous spacing between interactive elements, avoiding actions that require precise dragging or fast timing, and supporting keyboard-only or switch-device operation
• Low vision — considerations beyond contrast: resizable text without breaking layout, avoiding reliance on colour alone to convey meaning (e.g., not using only red/green to indicate error/success), supporting 200%+ browser zoom
• Situational impairment — a broader inclusive-design idea: a user holding a baby (one-handed use), in bright sunlight (needs contrast), or on a poor connection (needs graceful loading states) faces temporary, situational versions of the same barriers as permanent disabilities
Inclusive design language moves the conversation from "compliance checklist" to "who might struggle here, and why" — a more durable framing for design reviews.
7 / 31
// Code Review Comment
"Hey @john.doe, noticed you've used the standard `button` style. While it's functional, consider adding `role='button'` and `aria-label='Submit Form'` for screen reader users. It currently lacks explicit semantic meaning; this improves keyboard navigation and helps users understand its purpose."This scenario tests understanding of ARIA roles and labels. Simply adding a border doesn't provide the necessary semantic information for screen readers. Using `role='button'` explicitly defines the element's purpose, and `aria-label` provides a textual description for those who cannot see or hear the button's visual appearance.
8 / 31
"@alice.smith: Just finished implementing the new login form. It's using a simple text field for the password and a submit button. I haven't added any specific accessibility features yet – it should work fine!"
This question checks recognition of immediate accessibility needs. While a submit button is necessary, failing to include features like password masking and ensuring keyboard focus on the input fields violates WCAG guidelines and creates barriers for users with disabilities. The response highlights the importance of proactive accessibility implementation.
9 / 31
// PR Description
"Implemented the new user profile update feature. Added a simple form with text fields for name and email."PR descriptions need to highlight accessibility aspects alongside functional changes. Simply saying 'user profile update' doesn't address whether the form is navigable with a keyboard, has appropriate labels, or provides alternative input methods – all crucial for users with disabilities. A good PR description would briefly mention these considerations.
10 / 31
{ "status": 200, "data": {
"user": {
"name": "John Doe",
"email": "john.doe@example.com"
},
"form_fields": [
{
"id": "password",
"type": "text",
"label": "Password",
"placeholder": "Enter password"
},
{
"id": "name",
"type": "text",
"label": "Name",
"placeholder": "Enter your name"
}
]
} }
This tests understanding of how accessibility-related data might be represented in an API response. While labels are present, a more robust response would include details about color contrast ratios (essential for visual impairments) and other relevant attributes like `aria-required` to clearly indicate which fields are mandatory.
11 / 31
"Sarah: I'm working on the new e-commerce checkout flow. It's pretty standard – a product list, an add-to-cart button, and a checkout form. I haven't focused on accessibility yet, but it's on my radar."
This scenario probes understanding of the importance of incorporating accessibility considerations early in the design process. While functionality is vital, neglecting accessibility from the outset can lead to significant barriers for users with disabilities. It's a reminder that accessibility should be woven into every stage of development.
12 / 31
// Code Review Comment
"Hey @john.doe, noticed you've used the standard `button` style. While it's functional, consider adding `role='button'` and `aria-label='Submit Form'` for screen reader users. It currently lacks explicit semantic meaning; this improves keyboard navigation and helps users understand its purpose."This scenario tests understanding of ARIA roles and labels. Simply adding a border doesn't provide the necessary semantic information for screen readers. Using `role='button'` explicitly defines the element's purpose, and `aria-label` provides a textual description for those who cannot see or hear the button's visual appearance.
13 / 31
"@alice.smith: Just finished implementing the new login form. It's using a simple text field for the password and a submit button. I haven't added any specific accessibility features yet – it should work fine!"
This question checks recognition of immediate accessibility needs. While a submit button is necessary, failing to include features like password masking and ensuring keyboard focus on the input fields violates WCAG guidelines and creates barriers for users with disabilities. The response highlights the importance of proactive accessibility implementation.
14 / 31
// PR Description
"Implemented the new user profile update feature. Added a simple form with text fields for name and email."PR descriptions need to highlight accessibility aspects alongside functional changes. Simply saying 'user profile update' doesn't address whether the form is navigable with a keyboard, has appropriate labels, or provides alternative input methods – all crucial for users with disabilities. A good PR description would briefly mention these considerations.
15 / 31
{ "status": 200, "data": {
"user": {
"name": "John Doe",
"email": "john.doe@example.com"
},
"form_fields": [
{
"id": "password",
"type": "text",
"label": "Password",
"placeholder": "Enter password"
},
{
"id": "name",
"type": "text",
"label": "Name",
"placeholder": "Enter your name"
}
]
} }
This tests understanding of how accessibility-related data might be represented in an API response. While labels are present, a more robust response would include details about color contrast ratios (essential for visual impairments) and other relevant attributes like `aria-required` to clearly indicate which fields are mandatory.
16 / 31
"Sarah: I'm working on the new e-commerce checkout flow. It's pretty standard – a product list, an add-to-cart button, and a checkout form. I haven't focused on accessibility yet, but it's on my radar."
This scenario probes understanding of the importance of incorporating accessibility considerations early in the design process. While functionality is vital, neglecting accessibility from the outset can lead to significant barriers for users with disabilities. It's a reminder that accessibility should be woven into every stage of development.
17 / 31
// Code Review Comment
"Hey @john.doe, noticed you've used the standard `button` style. While it's functional, consider adding `role='button'` and `aria-label='Submit Form'` for screen reader users. It currently lacks explicit semantic meaning; this improves keyboard navigation and helps users understand its purpose."This scenario tests understanding of ARIA roles and labels. Simply adding a border doesn't provide the necessary semantic information for screen readers. Using `role='button'` explicitly defines the element's purpose, and `aria-label` provides a textual description for those who cannot see or hear the button's visual appearance.
18 / 31
"@alice.smith: Just finished implementing the new login form. It's using a simple text field for the password and a submit button. I haven't added any specific accessibility features yet – it should work fine!"
This question checks recognition of immediate accessibility needs. While a submit button is necessary, failing to include features like password masking and ensuring keyboard focus on the input fields violates WCAG guidelines and creates barriers for users with disabilities. The response highlights the importance of proactive accessibility implementation.
19 / 31
// PR Description
"Implemented the new user profile update feature. Added a simple form with text fields for name and email."PR descriptions need to highlight accessibility aspects alongside functional changes. Simply saying 'user profile update' doesn't address whether the form is navigable with a keyboard, has appropriate labels, or provides alternative input methods – all crucial for users with disabilities. A good PR description would briefly mention these considerations.
20 / 31
{ "status": 200, "data": {
"user": {
"name": "John Doe",
"email": "john.doe@example.com"
},
"form_fields": [
{
"id": "password",
"type": "text",
"label": "Password",
"placeholder": "Enter password"
},
{
"id": "name",
"type": "text",
"label": "Name",
"placeholder": "Enter your name"
}
]
} }
This tests understanding of how accessibility-related data might be represented in an API response. While labels are present, a more robust response would include details about color contrast ratios (essential for visual impairments) and other relevant attributes like `aria-required` to clearly indicate which fields are mandatory.
21 / 31
"Sarah: I'm working on the new e-commerce checkout flow. It's pretty standard – a product list, an add-to-cart button, and a checkout form. I haven't focused on accessibility yet, but it's on my radar."
This scenario probes understanding of the importance of incorporating accessibility considerations early in the design process. While functionality is vital, neglecting accessibility from the outset can lead to significant barriers for users with disabilities. It's a reminder that accessibility should be woven into every stage of development.
22 / 31
// Code Review Comment
"Hey @john.doe, noticed you've used the standard `button` style. While it's functional, consider adding `role='button'` and `aria-label='Submit Form'` for screen reader users. It currently lacks explicit semantic meaning; this improves keyboard navigation and helps users understand its purpose."This scenario tests understanding of ARIA roles and labels. Simply adding a border doesn't provide the necessary semantic information for screen readers. Using `role='button'` explicitly defines the element's purpose, and `aria-label` provides a textual description for those who cannot see or hear the button's visual appearance.
23 / 31
"@alice.smith: Just finished implementing the new login form. It's using a simple text field for the password and a submit button. I haven't added any specific accessibility features yet – it should work fine!"
This question checks recognition of immediate accessibility needs. While a submit button is necessary, failing to include features like password masking and ensuring keyboard focus on the input fields violates WCAG guidelines and creates barriers for users with disabilities. The response highlights the importance of proactive accessibility implementation.
24 / 31
// PR Description
"Implemented the new user profile update feature. Added a simple form with text fields for name and email."PR descriptions need to highlight accessibility aspects alongside functional changes. Simply saying 'user profile update' doesn't address whether the form is navigable with a keyboard, has appropriate labels, or provides alternative input methods – all crucial for users with disabilities. A good PR description would briefly mention these considerations.
25 / 31
{ "status": 200, "data": {
"user": {
"name": "John Doe",
"email": "john.doe@example.com"
},
"form_fields": [
{
"id": "password",
"type": "text",
"label": "Password",
"placeholder": "Enter password"
},
{
"id": "name",
"type": "text",
"label": "Name",
"placeholder": "Enter your name"
}
]
} }
This tests understanding of how accessibility-related data might be represented in an API response. While labels are present, a more robust response would include details about color contrast ratios (essential for visual impairments) and other relevant attributes like `aria-required` to clearly indicate which fields are mandatory.
26 / 31
"Sarah: I'm working on the new e-commerce checkout flow. It's pretty standard – a product list, an add-to-cart button, and a checkout form. I haven't focused on accessibility yet, but it's on my radar."
This scenario probes understanding of the importance of incorporating accessibility considerations early in the design process. While functionality is vital, neglecting accessibility from the outset can lead to significant barriers for users with disabilities. It's a reminder that accessibility should be woven into every stage of development.
27 / 31
// Code Review Comment
"Hey @john.doe, noticed you've used the standard `button` style. While it's functional, consider adding `role='button'` and `aria-label='Submit Form'` for screen reader users. It currently lacks explicit semantic meaning; this improves keyboard navigation and helps users understand its purpose."This scenario tests understanding of ARIA roles and labels. Simply adding a border doesn't provide the necessary semantic information for screen readers. Using `role='button'` explicitly defines the element's purpose, and `aria-label` provides a textual description for those who cannot see or hear the button's visual appearance.
28 / 31
"@alice.smith: Just finished implementing the new login form. It's using a simple text field for the password and a submit button. I haven't added any specific accessibility features yet – it should work fine!"
This question checks recognition of immediate accessibility needs. While a submit button is necessary, failing to include features like password masking and ensuring keyboard focus on the input fields violates WCAG guidelines and creates barriers for users with disabilities. The response highlights the importance of proactive accessibility implementation.
29 / 31
// PR Description
"Implemented the new user profile update feature. Added a simple form with text fields for name and email."PR descriptions need to highlight accessibility aspects alongside functional changes. Simply saying 'user profile update' doesn't address whether the form is navigable with a keyboard, has appropriate labels, or provides alternative input methods – all crucial for users with disabilities. A good PR description would briefly mention these considerations.
30 / 31
{ "status": 200, "data": {
"user": {
"name": "John Doe",
"email": "john.doe@example.com"
},
"form_fields": [
{
"id": "password",
"type": "text",
"label": "Password",
"placeholder": "Enter password"
},
{
"id": "name",
"type": "text",
"label": "Name",
"placeholder": "Enter your name"
}
]
} }
This tests understanding of how accessibility-related data might be represented in an API response. While labels are present, a more robust response would include details about color contrast ratios (essential for visual impairments) and other relevant attributes like `aria-required` to clearly indicate which fields are mandatory.
31 / 31
"Sarah: I'm working on the new e-commerce checkout flow. It's pretty standard – a product list, an add-to-cart button, and a checkout form. I haven't focused on accessibility yet, but it's on my radar."
This scenario probes understanding of the importance of incorporating accessibility considerations early in the design process. While functionality is vital, neglecting accessibility from the outset can lead to significant barriers for users with disabilities. It's a reminder that accessibility should be woven into every stage of development.
Frequently Asked Questions
What will I practice in "Accessibility Design Language — Product Design Exercises"?
This is a Product Design exercise set. It walks through 31 scenario-based multiple-choice questions built around real usage of product design terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 31 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the product design vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Product Design exercises?
See the Product Design exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — product design vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.