Accessibility and inclusive design

Accessibility means that people with disabilities can perceive, understand, navigate and interact with a product, and contribute to it, as effectively as anyone else. It is a legal requirement in many settings, an ethical obligation, and a matter of reaching customers: in the 2022 Canadian Survey on Disability, Statistics Canada reported that 27 percent of Canadians aged 15 and over, about 8 million people, had one or more disabilities, and the US Centers for Disease Control and Prevention estimates that more than one in four American adults has some type of disability. The World Health Organization estimated in 2023 that about 1.3 billion people, roughly one in six worldwide, experience significant disability. Populations are aging, and age brings declining vision, hearing, dexterity and memory. Accessibility is not a niche.

CMPUT-404 covered semantic HTML, landmarks, form labels and the basics of WCAG for web developers; ROB-430 applied inclusive design to robots. This lesson takes the HCI view: models of disability, the range of assistive technologies, WCAG 2.2 and its principles in more depth, including the criteria added in 2.2, ARIA and its pitfalls, an accessible design and evaluation process, inclusive design beyond compliance, and the legal frameworks in Canada and the United States.

Models of disability

How a team thinks about disability shapes what it builds. The medical model locates disability in the individual's body or mind, as an impairment to be diagnosed and treated. The social model, developed by disabled activists in the United Kingdom in the 1970s and articulated by Mike Oliver, distinguishes impairment (a characteristic of a person) from disability (the exclusion created by an environment designed without that person in mind): a wheelchair user is disabled by stairs, not by the wheelchair. In the social model, inaccessible software is a barrier the designer created. The World Health Organization's International Classification of Functioning, Disability and Health (2001) combines the two, treating disability as an interaction between health conditions and contextual factors. Disability is also diverse and often invisible: chronic pain, fatigue, mental health conditions, learning disabilities and many sensory and cognitive differences are not apparent to an observer. The disability rights movement's slogan 'Nothing about us without us' is a direct call for participatory design.

Assistive technologies

People with disabilities use a wide range of assistive technologies, and an interface must work with them. Screen readers, such as JAWS and NVDA on Windows, VoiceOver on Apple platforms, TalkBack on Android and Narrator, convert the interface into speech or refreshable braille; their users navigate by headings, landmarks, links, form controls and swipe gestures, relying on the accessibility tree that the platform builds from the interface's semantics. Screen magnifiers and zoom enlarge content, so layouts must reflow without horizontal scrolling (WCAG 1.4.10). Switch access lets people with severe motor impairments operate a device with one or two switches by scanning through options. Voice control, such as Voice Control on iOS and macOS or Voice Access on Android and Windows, lets users speak the visible names of controls, which works only if the accessible name matches the visible label (WCAG 2.5.3). Keyboard-only users, including many with motor impairments and many screen reader users on desktops, need every function to be operable from the keyboard with a visible focus indicator. Captions and transcripts serve deaf and hard-of-hearing users, and sign language interpretation serves Deaf users whose first language is a signed language such as American Sign Language (ASL) or Langue des signes québécoise (LSQ). Cognitive accessibility supports include plain language, consistent layouts, reminders and the absence of time pressure.

WCAG 2.2

The Web Content Accessibility Guidelines, published by the World Wide Web Consortium's Web Accessibility Initiative (W3C WAI), are the global reference standard for digital accessibility. WCAG 2.0 appeared in 2008, 2.1 in 2018 and 2.2 in October 2023. Although written for web content, WCAG is applied to mobile apps, documents and software through guidance such as W3C's WCAG2ICT and standards such as the European EN 301 549, which Canada has adopted as CAN/ASC-EN 301 549:2024.

WCAG is organized around four principles, summarized as POUR. Perceivable: information and interface components must be presentable in ways users can perceive (text alternatives for images, captions for video, sufficient contrast, content that can be presented in different ways without losing meaning). Operable: interface components and navigation must be operable (keyboard access, enough time, no content that causes seizures, navigable structure, input modalities beyond the keyboard). Understandable: information and operation must be understandable (readable text, predictable behavior, input assistance and error prevention). Robust: content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies, which mostly means valid, semantic markup with correct names, roles and values. Under the principles are 13 guidelines and, in 2.2, 86 testable success criteria at three conformance levels: A (minimum), AA (the level required by most laws and policies) and AAA (enhanced, not generally required for entire sites).

WCAG 2.2 added nine success criteria, focused on users with cognitive and learning disabilities, low vision and motor impairments, and removed one obsolete criterion (4.1.1 parsing). Among the new ones at levels A and AA: 2.4.11 focus not obscured (the focused element is not entirely hidden by sticky headers or banners); 2.5.7 dragging movements (any drag action has a single-pointer alternative, such as tapping arrows instead of dragging a map); 2.5.8 target size minimum (24 by 24 CSS pixels, lesson 3); 3.2.6 consistent help (help mechanisms appear in the same relative place across pages); 3.3.7 redundant entry (do not make users re-enter information already provided in the same process); and 3.3.8 accessible authentication (minimum) (no cognitive function test, such as remembering a password or solving a puzzle, without an alternative such as a password manager, copy and paste or a passkey).

WCAG 3, a major redesign with a new structure, scoring model and broader scope, remains a Working Draft; the W3C published an updated draft for review in March 2026 and does not expect it to replace WCAG 2 for some years. Laws and procurement standards in force as of October 2026 reference WCAG 2.0, 2.1 or 2.2, so teams should target WCAG 2.2 level AA now.

Contrast

Text must contrast sufficiently with its background. WCAG defines a contrast ratio from the relative luminance L of the lighter and darker colors, \((L_1 + 0.05)/(L_2 + 0.05)\), which ranges from 1:1 (no contrast) to 21:1 (black on white). Success criterion 1.4.3 (level AA) requires at least 4.5:1 for normal text and 3:1 for large text (at least 18 points, or 14 points bold, roughly 24 and 18.7 CSS pixels). Criterion 1.4.11 requires 3:1 for the visual boundaries of interface components, such as input borders and focus indicators, and for meaningful graphics. Relative luminance weights the linearized red, green and blue channels by 0.2126, 0.7152 and 0.0722, reflecting the eye's greater sensitivity to green. The program below checks RideLine's palette.

# WCAG contrast ratio: (L1 + 0.05) / (L2 + 0.05) using relative luminance of sRGB values.
# Check RideLine's palette against AA (4.5:1 normal text, 3:1 large text and UI parts)
# and find the darkest-needed adjustment for a failing brand shade.
def lum(hexcode):
    def ch(c):
        c = int(c, 16) / 255
        return c / 12.92 if c <= 0.04045 else ((c + 0.055) / 1.055) ** 2.4
    r, g, b = (ch(hexcode[i:i + 2]) for i in (1, 3, 5))
    return 0.2126 * r + 0.7152 * g + 0.0722 * b
def ratio(fg, bg):
    a, b = sorted((lum(fg), lum(bg)), reverse=True)
    return (a + 0.05) / (b + 0.05)
pairs = [("body text on white", "#333333", "#ffffff"), ("brand teal link on white", "#2aa198", "#ffffff"),
         ("white on brand teal button", "#ffffff", "#2aa198"), ("light placeholder on white", "#a0a0a0", "#ffffff"),
         ("alert text on pale yellow", "#7a5a00", "#fff4cc"), ("focus ring vs white", "#1a5fb4", "#ffffff")]
for name, fg, bg in pairs:
    r = ratio(fg, bg)
    verdict = "AA text" if r >= 4.5 else ("AA large text / UI only" if r >= 3 else "fails")
    print(f"{name:28} {fg} on {bg}: {r:5.2f}:1  {verdict}")
def darken(hexcode, f):
    return "#" + "".join(f"{int(int(hexcode[i:i + 2], 16) * f):02x}" for i in (1, 3, 5))
f = 1.0
while ratio(darken("#2aa198", f), "#ffffff") < 4.5:
    f -= 0.01
print(f"darken brand teal to {darken('#2aa198', f)} ({ratio(darken('#2aa198', f), '#ffffff'):.2f}:1) for link text")

body text on white           #333333 on #ffffff: 12.63:1  AA text
brand teal link on white     #2aa198 on #ffffff:  3.16:1  AA large text / UI only
white on brand teal button   #ffffff on #2aa198:  3.16:1  AA large text / UI only
light placeholder on white   #a0a0a0 on #ffffff:  2.61:1  fails
alert text on pale yellow    #7a5a00 on #fff4cc:  5.79:1  AA text
focus ring vs white          #1a5fb4 on #ffffff:  6.29:1  AA text
darken brand teal to #22847c (4.51:1) for link text

The brand teal passes only for large text and interface components, so links in body text need the darker shade the program finds; the gray placeholder fails outright, another reason not to use placeholders as labels (lesson 7). Contrast is necessary but not sufficient: thin, small type can be hard to read even at 4.5:1, and some users need higher contrast or dark mode, which operating system settings, and CSS media features that report a user's contrast and light or dark preferences, let interfaces respect. A newer contrast method, APCA, which models perceived lightness contrast more accurately and accounts for font size and weight, was explored for WCAG 3 but is not part of WCAG 2.

Semantics and ARIA

Assistive technologies rely on each element's name (what it is called), role (what it is, such as button, link, checkbox or heading), state (checked, expanded, disabled) and value. Native HTML elements and platform controls provide these automatically: a button element is announced as a button, can receive keyboard focus and responds to Enter and Space. Custom controls built from generic elements, such as a div styled to look like a button, provide none of this unless the developer adds it. WAI-ARIA (Accessible Rich Internet Applications) is a set of attributes that supply roles, states and properties for custom widgets and dynamic content, such as role='tab', aria-expanded='true' and aria-live regions for announcements.

The first rule of ARIA, in the W3C's guidance on using ARIA, is not to use ARIA if a native element with the required semantics and behavior exists. ARIA changes only what is announced, not how the element behaves: adding role='button' to a div does not make it focusable or keyboard operable. WebAIM's annual survey of the home pages of the top one million websites has repeatedly found that pages using ARIA have more detectable accessibility errors on average than pages without it, which reflects misuse rather than ARIA itself. On mobile platforms, the equivalents are the accessibility properties of UIKit and SwiftUI (accessibilityLabel, accessibilityTraits) and of Android views and Jetpack Compose (contentDescription, semantics).

An accessible design and evaluation process

Accessibility is cheapest when designed in from the start and most expensive when retrofitted after an audit or complaint. In design, teams specify heading structure, reading and focus order, accessible names for icons, alternative text for meaningful images, error messages and their association with fields, contrast and target sizes, and behavior at 200 percent text size and 400 percent zoom. Design systems with accessible components (lesson 7) multiply the benefit. In development, semantic markup and native controls do most of the work; automated checks in continuous integration catch regressions (lesson 8).

Evaluation combines automated tools, expert review and testing with disabled users. An expert review covers keyboard-only navigation (can every function be reached and operated, is focus visible and in a logical order, are there keyboard traps?), a screen reader pass on desktop and mobile, zoom and reflow, contrast, captions and media alternatives, forms and error handling, and the new WCAG 2.2 criteria. Testing with disabled participants finds problems that conformance checking misses, such as a technically conformant but bewildering screen reader experience. Recruiting disabled participants takes more time and should be paid fairly; remote testing lets participants use their own configured devices, which is usually essential, since assistive technology users customize settings heavily. Organizations document conformance in an accessibility conformance report, commonly based on the Voluntary Product Accessibility Template (VPAT).

RideLine's accessibility complaint came from Gerald, the screen reader user persona's real counterpart: the old app's arrivals were available only by exploring a map whose pins had no accessible names. The redesign added a list view as the default (which also proved faster for sighted users in the experiment in lesson 9), labeled every control, announced arrival updates in a polite live region no more than once a minute, and provided a step-free route option.

Inclusive design

Inclusive design goes beyond compliance by designing with, and for, the full range of human diversity. Microsoft's Inclusive Design toolkit (2016) puts it in three principles: recognize exclusion, learn from diversity, and solve for one, extend to many. Its persona spectrum (lesson 6) shows that designing for a permanent disability often helps people with temporary and situational limitations: captions, designed for deaf viewers, help people in noisy bus shelters and quiet libraries; one-handed operation helps an amputee, a person with a broken wrist and a parent holding a child. This is sometimes called the curb-cut effect, after the sloped curb cuts that disability activists won in the 1970s, which now serve people with strollers, luggage and bicycles. Universal design, a term coined by the architect Ronald Mace, sets out seven principles, including equitable use, flexibility, simple and intuitive use, perceptible information and tolerance for error.

Inclusive design also extends to other dimensions of diversity: language and literacy (plain language, translation, support for right-to-left scripts), age, culture, socioeconomic status (older devices, limited data plans, shared phones), gender identity (forms that do not force binary choices) and neurodiversity. The Inclusive Design Research Center at OCAD University in Toronto, founded by Jutta Treviranus, has been influential in arguing that designing for the edges of the distribution, rather than the average, produces better designs for everyone.

Accessibility law

In the United States, the Americans with Disabilities Act (1990) prohibits discrimination on the basis of disability. Title II covers state and local governments, including public transit agencies. In April 2024 the Department of Justice issued a rule requiring their web content and mobile apps to conform to WCAG 2.1 level AA; in April 2026 it issued an interim final rule extending the compliance dates by one year, to 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts (check for later changes). Title III covers public accommodations; it has no technical web rule, but courts and the Department of Justice have treated inaccessible websites and apps as potential discrimination, and thousands of digital accessibility lawsuits are filed each year. Section 508 of the Rehabilitation Act requires federal agencies' information and communication technology to be accessible under standards that incorporate WCAG 2.0 level AA, and the Air Carrier Access Act and Department of Transportation rules cover airline websites and kiosks. For an app like RideLine, run by a public transit agency, Title II and its WCAG 2.1 AA requirement apply directly.

Outside North America, the European Accessibility Act, which applies from 28 June 2025, requires many consumer products and services sold in the European Union, including e-commerce, banking, e-books and passenger transport services, to meet accessibility requirements, using EN 301 549 for digital ones. Products sold internationally increasingly meet WCAG 2.2 AA as a common baseline.

Worked examples