Accessibility and Inclusive Prototyping

Introduction

Accessibility is the practice of designing products that can be used by people with diverse abilities, technologies, environments, and preferences. Inclusive design extends this idea by recognising that exclusion can result not only from permanent disabilities, but also from temporary or situational conditions: a broken arm, bright sunlight, noisy surroundings, limited bandwidth, unfamiliar language, or a device used with one hand.

In UI/UX work, accessibility is not a final compliance inspection. It is a design quality that must be considered while requirements are gathered, content is written, interface components are created, and interaction flows are prototyped. Figma prototypes are particularly useful because they allow teams to test structure, content, keyboard paths, focus order, error recovery, and motion before implementation.

The Web Content Accessibility Guidelines (WCAG) provide a widely used framework. WCAG is organised around four principles: content should be perceivable, operable, understandable, and robust. The guidelines include success criteria at Levels A, AA, and AAA. In most professional projects, Level AA is the practical baseline, although legal obligations vary by jurisdiction and product type. Compliance does not automatically guarantee a good experience; user research and testing with disabled users remain essential.

Learning Objectives

By the end of this chapter, students should be able to:

• explain the relationship between accessibility, inclusive design, and WCAG;
• evaluate colour contrast, text hierarchy, and non-colour information;
• create meaningful focus order and keyboard interaction in a prototype;
• design usable touch targets, forms, validation, and error recovery;
• assess motion, content clarity, and assistive-technology requirements;
• use Figma to document accessibility decisions and test prototype flows;
• identify limitations of automated checking and plan inclusive user testing.

Accessibility as a Design Responsibility

Disability is not only an individual characteristic. The interaction between a person and an environment creates barriers. A person with low vision may use a screen magnifier; a person with dyslexia may benefit from clear language and predictable layouts; a person with limited motor control may depend on keyboard navigation, voice control, or switch access. The same interface can therefore be accessible to one user and obstructive to another.

A useful design distinction is:

• Impairment: a difference in physical, sensory, cognitive, or psychological functioning.
• Activity limitation: difficulty performing an activity.
• Participation restriction: difficulty taking part in an important life situation.
• Accessibility barrier: a feature of a product or environment that creates unnecessary difficulty.

Inclusive prototyping asks, “What assumptions does this interface make?” Examples include assuming that every user can distinguish red from green, use a mouse, hear an alert, read small text, remember information between screens, or understand an icon without a label.

Accessibility also has a professional and ethical dimension. Public services, education, banking, employment, and health products can exclude people from essential opportunities. Designers should treat accessibility as part of user safety, fairness, quality assurance, and risk management—not merely as visual polish.

WCAG-Informed Design Principles

Perceivable

Information must be available through more than one sensory channel where necessary. Text alternatives support images and icons. Captions support video. Sufficient contrast supports users with low vision. Colour should not be the only means of communicating status.

Operable

Users should be able to operate controls with different input methods. Interfaces should support keyboard use, provide visible focus, avoid inaccessible timing requirements, and give controls adequate target areas.

Understandable

Content and behaviour should be predictable. Labels, instructions, validation messages, and navigation should use clear language. Errors should be identified and explained in a way that helps users recover.

Robust

Content should work with current and future user agents, browsers, operating systems, and assistive technologies. In practice, designers should use conventional semantics and communicate intended roles, names, states, and relationships to developers.

Colour, Contrast, and Visual Communication

Colour contrast is the difference in perceived luminance between foreground and background. WCAG contrast requirements are expressed as a ratio. For ordinary text at Level AA, the usual minimum is 4.5:1. Large text requires at least 3:1. WCAG defines large text as at least 18-point regular text or 14-point bold text. User-agent rendering and font properties affect the practical interpretation, so designers should not treat size thresholds as a substitute for judgement.

For non-text user-interface components and meaningful graphical objects, WCAG 2.1 and 2.2 generally require a contrast ratio of at least 3:1 against adjacent colours when the component or graphic is needed to identify controls or states. Disabled controls are treated differently by the standard, but making disabled content extremely faint often harms comprehension and should be avoided where possible.

The contrast ratio is calculated from relative luminances:

Here, L₁ is the higher relative luminance and L₂ is the lower relative luminance. Relative luminance is calculated from linearised red, green, and blue components; it is not the simple average of RGB values. The formula applies to colours represented in the sRGB colour space under the WCAG method. Designers normally use a validated contrast tool rather than calculating it manually.

Contrast is necessary but not sufficient. A pale blue link may meet a ratio requirement yet remain difficult to find if it is distinguished from surrounding text only by colour. Links in body text should usually have another cue, such as an underline, especially when the surrounding text is not clearly differentiated. Error, success, and warning states should combine colour with text, icons, patterns, or position.

Figma practice for contrast

Create named colour styles or variables such as “Text/Primary,” “Surface/Default,” and “Status/Error.” Test colour pairs in normal, hover, focus, disabled, and error states. Do not test only the default screen. A component library should record contrast results and define approved combinations. If a background is an image or gradient, test the worst affected area rather than an ideal patch.

Colour-blindness and environmental variation

Colour-vision differences are not identical to blindness. Users may confuse particular hue combinations, but poor contrast, thin strokes, and low saturation can affect many users. Preview designs with colour-vision simulation, grayscale, zoom, and high-brightness conditions. Simulation is a diagnostic aid, not a replacement for testing with users.

Typography and Content Clarity

Accessible typography involves more than selecting a large font. Important considerations include readable typefaces, adequate line spacing, sufficient paragraph width, meaningful hierarchy, and predictable alignment. Avoid long passages in all capitals, excessive italic text, tightly packed controls, and text embedded in images.

Users should be able to enlarge text without losing content or functionality. A responsive design should reflow rather than requiring horizontal scrolling for ordinary text. In a prototype, test a screen at enlarged zoom and inspect whether labels wrap, buttons expand, dialogs remain usable, and important content is still available.

Content should be concise and specific. “Invalid input” is less useful than “Enter a valid 10-digit phone number.” Headings should describe the purpose of a section. Button labels should state the action, such as “Save changes” rather than “Submit.” Instructions should appear before the action they govern, and critical requirements should not be communicated only through placeholder text.

Plain language is an accessibility technique. Short sentences, familiar terms, meaningful headings, and consistent terminology support users with cognitive disabilities, users working in a second language, and users who are reading under stress.

Focus Order and Keyboard Interaction

Keyboard accessibility is a design requirement, not only a developer implementation detail. A keyboard user commonly moves through controls with Tab, moves backward with Shift+Tab, activates buttons with Enter or Space, and uses arrow keys in some composite widgets. The exact behaviour depends on the control pattern and platform.

The focus order should follow the reading and task order. A common sequence is:

1. skip link or page-level navigation;
2. header and primary navigation;
3. main heading and content;
4. form fields in the order required to complete them;
5. supporting links and actions;
6. footer content.

Avoid inserting a positive custom tab index merely to force a visual order. Such changes frequently produce a confusing path. Instead, arrange the document structure and component order to match the intended interaction sequence. A visual design that places a sidebar before the main content may still require the main content to be encountered first, depending on the task and semantic structure.

Every interactive element must have a visible focus indicator. Do not remove the browser focus outline without replacing it with an equally clear or clearer treatment. WCAG 2.2 includes a Focus Appearance criterion with detailed requirements for focus indicators; teams should verify the current standard and platform interpretation during implementation. A practical design pattern is a high-contrast outline or ring that is distinct from the component’s normal border and remains visible against surrounding backgrounds.

Figma does not simulate a real browser accessibility tree. Therefore, create a “keyboard path” annotation in the prototype or design specification. Number the intended sequence, show focused states, and document expected keys. Test the exported or implemented interface with only a keyboard as soon as possible.

Dialogs, menus, and composite controls

A modal dialog should move focus into the dialog, provide a clear title, offer a predictable close action, and return focus to the control that opened it when closed. A menu should not behave like a collection of unrelated links if users expect arrow-key navigation. Tabs, accordions, radio groups, and listboxes each have established interaction patterns. Designers should consult the WAI-ARIA Authoring Practices when specifying behaviour, while remembering that ARIA cannot repair poor underlying structure.

Touch Targets and Input Flexibility

Small controls are difficult for users with motor impairments and for anyone using a device while moving. WCAG 2.2 Level AA includes a Target Size (Minimum) criterion of 24 × 24 CSS pixels, with defined exceptions. This is a web standard and should not be confused with a universal physical measurement. Mobile platform guidance often recommends larger targets, commonly around 44 × 44 points or pixels depending on the platform’s terminology.

The active target may be larger than the visible icon. For example, a 20-pixel close icon can sit inside a 44-pixel button. Adequate spacing reduces accidental activation, particularly where destructive controls are adjacent to navigation controls. Do not rely on precision gestures when a simple alternative is possible. Drag-and-drop should have a keyboard or button-based alternative; swipe-only carousels should provide buttons and semantic navigation.

Forms, Validation, and Error States

Forms are frequent sources of exclusion because they combine reading, memory, motor input, and error recovery. Each field should have a persistent, programmatically associated label. Placeholder text is not a substitute for a label because it disappears when users type and may have insufficient contrast.

Group related fields with a clear heading. State required fields consistently. If input format matters, provide an example before entry—for example, “Date of birth: DD/MM/YYYY.” Do not demand information that is unnecessary for the task.

Effective validation has four characteristics:

• Identification: the problematic field is clearly indicated.
• Description: the message explains what is wrong.
• Correction: the message tells the user how to fix it.
• Persistence: the user’s valid input is retained whenever possible.

An error should not be communicated by a red border alone. Pair the border with text and, where appropriate, an icon. For a long form, provide a summary near the beginning and link each summary message to the relevant field. Ensure that focus moves to a sensible location without unexpectedly disorienting the user.

A confirmation message should also be accessible. “Your application was submitted successfully” is clearer than a temporary green toast that disappears before a screen-reader user encounters it. Important status messages need an appropriate announcement strategy in the implemented product; the prototype should document this requirement.

Motion, Timing, and Reduced Motion

Animation can explain change, establish spatial relationships, and provide feedback. It can also trigger vestibular discomfort, distraction, or cognitive overload. Avoid unnecessary parallax, rapid zooming, flashing, and large-scale movement. Never use flashing content that could create seizure risk.

Provide a reduced-motion experience. On the web, implementation commonly responds to the user’s prefers-reduced-motion setting, but a prototype should still show both the default and reduced-motion versions. Reduced motion does not necessarily mean no animation: a brief opacity change or an instant state transition may preserve comprehension with less movement.

Timing must not make users race. If content expires, provide a way to extend or disable the limit where the task permits. Authentication codes and security constraints may require a time limit, but the reason and recovery path should be clear. Avoid automatically advancing carousels and ensure that users can pause or control moving content.

Assistive Technology and Semantic Structure

Assistive technologies include screen readers, screen magnifiers, speech recognition, switch devices, refreshable Braille displays, and alternative keyboards. They rely on information exposed by the operating system and browser accessibility tree. A visual mock-up cannot fully prove that a product will work with these technologies, but it can specify the information they require.

For every control, document:

• its accessible name, such as “Search products”;
• its role, such as button, link, checkbox, or heading;
• its state, such as expanded, selected, checked, or invalid;
• its value, where relevant;
• its relationship to instructions, errors, and groups.

An icon-only button needs an accessible name even if its visual meaning seems obvious. Decorative images should not create unnecessary announcements. Informative images need alternative text that communicates their purpose, not a literal description of irrelevant visual details. Complex charts require a text summary and, when necessary, an underlying data table.

Semantic HTML is usually preferable to constructing familiar controls from generic containers. A real button provides expected keyboard and assistive-technology behaviour; a styled div does not automatically become a button. Designers should communicate the intended semantic element in component documentation so that developers do not have to infer it from appearance.

Accessibility Workflows in Figma

A practical Figma workflow can integrate accessibility throughout the design process.

1. Establish requirements

Identify the audiences, devices, input methods, languages, legal requirements, and assistive technologies relevant to the product. Include accessibility acceptance criteria in the project brief.

2. Build accessible foundations

Define type styles, spacing, colour variables, focus styles, error styles, and component states. Name layers and components consistently. Create variants for default, hover, focus, pressed, disabled, loading, success, and error states.

3. Annotate behaviour

Use descriptions or an accessibility annotation page to record heading levels, reading order, labels, keyboard commands, focus movement, validation rules, announcements, and reduced-motion behaviour. An annotation is a communication aid, not a substitute for semantic implementation.

4. Prototype realistic task flows

Include incomplete, invalid, slow, and interrupted journeys. Test sign-in failure, empty search results, expired sessions, permission denial, and network delay. Accessibility problems frequently appear in these states rather than in the ideal path.

5. Inspect at different conditions

Review designs with zoom, grayscale, simulated colour-vision differences, reduced motion, large text, keyboard-only operation, and mobile reachability. Use a contrast plugin or checker, but confirm results manually.

6. Test with people

Recruit users with relevant disabilities and compensate them fairly. Ask participants to complete realistic tasks rather than asking whether they “like” the design. Observe barriers, workarounds, errors, and confidence. Protect participant privacy, particularly when research involves health, identity, or financial information.

An Applied Case: Accessible Municipal Service Prototype

The following is an illustrative case. A city team is prototyping an online application for residential parking permits. The original concept contains a map, a colour-coded eligibility result, a multi-step form, document upload, and payment.

Background and problem

Early testing shows that users cannot identify eligible streets without distinguishing green and red regions on the map. Keyboard users cannot reach the map controls in a logical sequence. The form displays “Something went wrong” at the top after an invalid postcode, and uploaded documents are represented by icons without names. A confirmation toast disappears after three seconds.

Analysis

The team maps the journey against the four WCAG principles. The map is not perceivable without colour or a text equivalent. The controls are not fully operable by keyboard. The error is not understandable because it lacks a correction instruction. The prototype does not specify names, states, or relationships for assistive technology, creating a robustness risk.

Approach and solution

The team changes the map result so that eligibility is communicated through colour, a pattern, and a text panel listing the street and reason. A searchable address field and a text-based street list provide an alternative to direct map interaction. The tab order follows the task: address search, result summary, street list, map controls, and continuation action.

The form labels are persistent, and the postcode field provides an example. On error, the interface presents a summary—“Check the postcode”—and links to the field. The field retains valid entries and identifies the exact correction required. Uploaded documents display file names, types, sizes, and removal controls with accessible names. The final confirmation remains available on the page and includes a reference number; it is not delivered only through a temporary toast.

The team creates default and reduced-motion prototypes. A progress indicator identifies the current step in text as well as visually. The payment page includes a clear timeout warning and an extension option where permitted. The design specification records heading structure, expected focus return after dialogs, and the status message that implementation must expose to assistive technology.

Outcome

In a second round of testing, keyboard users complete the form without a pointer, screen-reader users can understand the eligibility result through the text alternative, and participants with colour-vision differences identify outcomes correctly. The team also discovers that the address autocomplete closes unexpectedly when users press Escape; this is corrected before development.

Learning points

The case demonstrates that accessibility is systemic. Fixing a colour pair would not have solved the map’s interaction problem. A successful prototype represents content, structure, behaviour, state changes, and recovery—not only the appearance of the happy path.

Evaluation, Limitations, and Governance

Automated tools are valuable for detecting some contrast failures, missing labels, heading-order problems, and other machine-testable issues. They cannot reliably judge whether language is understandable, whether focus order supports the task, whether alternative text is meaningful, or whether a complex interaction is usable. Manual inspection and user testing are therefore necessary.

WCAG is also not a complete design philosophy. A product can satisfy success criteria while remaining frustrating, culturally inappropriate, cognitively demanding, or inaccessible because of performance and content decisions. Standards evolve, and teams should record which version and conformance level they are applying. Legal compliance should be reviewed with appropriate organisational or legal expertise rather than inferred from a design checklist.

Accessibility work must respect privacy and autonomy. Do not ask participants to disclose diagnoses unnecessarily. Store research data securely and obtain informed consent. Avoid portraying disabled users as testing instruments; involve them as experts whose experience informs design decisions. Where possible, include disabled professionals in research, design, development, and governance roles.

Artificial intelligence can assist with tasks such as generating initial alt-text suggestions, identifying possible contrast issues, or clustering usability findings. However, AI-generated descriptions may omit context, misidentify objects, reproduce stereotypes, or expose sensitive material. Human review and user testing remain essential. AI should support—not replace—professional judgement and participation by disabled people.

Best-Practice Checklist

Before handoff, confirm that:

• text and meaningful graphics have appropriate contrast;
• information is not communicated through colour alone;
• text can enlarge and reflow without loss of content or function;
• every control has a clear visible label or accessible name;
• the focus order follows the task and focus is always visible;
• keyboard users can operate every essential function;
• touch targets and spacing support accurate activation;
• forms have persistent labels, instructions, and recoverable errors;
• status messages and confirmation states are available beyond transient animation;
• motion has a reduced-motion alternative;
• headings, landmarks, lists, tables, and controls have an intended semantic structure;
• images, icons, maps, and charts have appropriate alternatives;
• prototype annotations document roles, states, keyboard behaviour, and focus movement;
• automated checks are supplemented by manual review and testing with disabled users.

Chapter Summary

Accessibility and inclusive prototyping treat diverse abilities and contexts as fundamental design conditions. WCAG provides a useful framework through the principles of perceivable, operable, understandable, and robust content, with Level AA commonly used as a professional baseline. Designers should verify text and non-text contrast, avoid colour-only communication, use clear typography and language, and provide meaningful alternatives for images, maps, and charts.

Accessible interaction requires logical focus order, visible focus indicators, keyboard operation, adequate touch targets, and predictable behaviour for dialogs and composite controls. Forms should use persistent labels, clear instructions, specific error messages, preserved input, and recoverable states. Motion should be purposeful, controllable, and compatible with reduced-motion preferences. Figma can support this work through component states, realistic task flows, annotations, contrast inspection, and testing under varied conditions. Because automated tools and visual prototypes have limits, accessibility must be validated through implementation review and research with disabled users.

Key Terms

Accessibility: The degree to which a product can be used by people with diverse abilities and needs.

Inclusive design: A design approach that aims to include people with varied abilities, identities, contexts, and preferences.

WCAG: Web Content Accessibility Guidelines, a widely used standard for accessible web content.

Perceivable: Available to users through sensory channels they can access.

Operable: Usable through available input methods and interaction techniques.

Understandable: Clear, predictable, and usable in terms of content and behaviour.

Robust: Compatible with user agents and assistive technologies.

Contrast ratio: A WCAG measure comparing the relative luminance of foreground and background colours.

Relative luminance: The lightness value used in the WCAG contrast calculation.

Focus: The current interface element selected for keyboard or comparable input.

Focus order: The sequence in which interactive elements receive focus.

Touch target: The interactive area activated by touch or pointer input.

Semantic structure: Meaningful roles, relationships, headings, and states communicated to technology.

Accessible name: The text exposed to assistive technology to identify a control.

Alternative text: A text equivalent that communicates the purpose or meaning of non-text content.

Reduced motion: An interaction mode that minimises unnecessary movement and animation.

Error recovery: The information and mechanisms that help users correct input problems.

Assistive technology: Hardware or software that helps people access digital products.

Inclusive user testing: Research involving participants with varied abilities and access requirements.

Review Questions

5 Short Answer Questions

1. What are the four WCAG principles?
2. Why should colour not be the only way to communicate an error?
3. What is meant by logical focus order?
4. State two characteristics of an effective form error message.
5. Why is automated accessibility testing insufficient on its own?

5 Long Answer Questions

1. Explain how a Figma component library can support accessibility across a product.
2. Discuss the relationship between text contrast, typography, colour use, and content clarity.
3. Describe how a designer should specify keyboard interaction for a modal dialog.
4. Explain why reduced-motion alternatives are important and how they can be represented in a prototype.
5. Discuss the limitations of WCAG as a complete measure of user experience quality.

3 Analytical / Application Questions

1. A checkout form uses red borders to identify invalid fields, removes typed values after submission, and displays “Invalid details” at the top. Analyse the accessibility problems and propose a revised interaction.
2. Design an accessibility test plan for a mobile banking prototype. Include conditions, tasks, tools, and participants.
3. A map-based service cannot be used without dragging and colour recognition. Develop an inclusive alternative that preserves the original service goal while supporting keyboard, screen-reader, and touch users.

Multiple Choice Questions with Answers

Question 1

Which WCAG principle concerns making content usable through available input methods?

A. Perceivable

B. Operable

C. Understandable

D. Robust

Correct Answer: B. Operable

Question 2

What is the usual WCAG Level AA minimum contrast ratio for ordinary text?

A. 2:1

B. 3:1

C. 4.5:1

D. 7:1

Correct Answer: C. 4.5:1

Question 3

Which practice best supports keyboard users?

A. Removing the browser focus outline

B. Using positive tabindex values throughout the page

C. Providing a logical focus order and visible focus indicator

D. Making every control mouse-dependent

Correct Answer: C. Providing a logical focus order and visible focus indicator

Question 4

Why is placeholder text not a sufficient replacement for a form label?

A. It always has excessive contrast

B. It disappears when users enter information

C. It prevents responsive layout

D. It cannot contain any letters

Correct Answer: B. It disappears when users enter information

Question 5

Which is the strongest error message?

A. Invalid input

B. Error

C. Something went wrong

D. Enter a valid 10-digit phone number

Correct Answer: D. Enter a valid 10-digit phone number

Question 6

What is a suitable accessible alternative to communicating a result only with green and red colours?

A. Reduce the saturation of both colours

B. Add text or another meaningful non-colour indicator

C. Use smaller coloured icons

D. Place the colours closer together

Correct Answer: B. Add text or another meaningful non-colour indicator

Question 7

What should generally happen when a modal dialog closes?

A. Focus should disappear

B. Focus should move to the browser address bar

C. Focus should return to the control that opened the dialog

D. The page should automatically reload

Correct Answer: C. Focus should return to the control that opened the dialog

Question 8

Which statement about automated accessibility tools is accurate?

A. They replace testing with disabled users

B. They can judge every aspect of content clarity

C. They can detect some issues but require manual and user evaluation

D. They are useful only for colour testing

Correct Answer: C. They can detect some issues but require manual and user evaluation

Question 9

What is the purpose of a reduced-motion version of an interface?

A. To remove all text from the interface

B. To minimise unnecessary movement for users who need or prefer less motion

C. To make every transition longer

D. To disable keyboard interaction

Correct Answer: B. To minimise unnecessary movement for users who need or prefer less motion

Question 10

Which information should an accessibility annotation commonly document?

A. Only the brand colour palette

B. Only the developer’s job title

C. Roles, states, labels, focus movement, and keyboard behaviour

D. The number of layers in every decorative illustration

Correct Answer: C. Roles, states, labels, focus movement, and keyboard behaviour