Accessible & Inclusive. Design for every body, every device, every language.

Warm-up: what do you already believe?

Before you read, find out where your instincts are already right and where they are quietly wrong.

Most capable developers carry a handful of accessibility myths: that it is mostly about blind people, that it is a final checklist before launch, that adding ARIA makes things more accessible, that it makes interfaces ugly. Each of those beliefs produces specific bugs. Answer the three questions below without scrolling ahead. Getting one wrong is useful: it tells you which chapter to read most slowly.

Also recall two ideas from earlier guides, because this guide builds on them. From The Human Mind: working memory is small and attention is fragile, so every extra thing a person must hold in their head costs them. From Visual Design: hierarchy is made with size, weight, position and contrast, and colour is the weakest of those signals. Accessibility is what happens when you take both ideas seriously for people whose senses, hands or attention differ from yours.

Disability is not a property of a person; it is a mismatch between a person and the thing they are trying to use. Designers create those mismatches, so designers can remove them.

The World Health Organization estimates that about 1.3 billion people, roughly 16 percent of everyone alive, experience significant disability. That is the permanent slice. Add everyone who is temporarily injured, recovering from surgery, or just ageing (eyesight starts losing near focus in most people's forties) and the group grows. Add everyone in a situation that limits them for a few minutes, and the group becomes "all of your users, some of the time".

Kat Holmes, who led inclusive design at Microsoft, makes the point sharply in her book Mismatch (2018): the medical model treats disability as a condition inside a body, but the social model locates it at the point of contact between body and world. A wheelchair user is not disabled by a ramp. They are disabled by stairs. A blind user is not disabled by a well-labelled button. They are disabled by an unlabelled one. Every time you ship an icon with no name, you build a small staircase.

The persona spectrum

Microsoft's Inclusive Design toolkit (2016) gave designers a simple tool: for each human ability (touch, see, hear, speak) think of a permanent, a temporary and a situational version of the same limitation. A person with one arm, a person with a broken arm in a cast, and a parent holding a baby all need to use your app with one hand. Design for the permanent case and the other two come along for free. That is why the spectrum is useful: it turns a "niche" requirement into a mainstream one.

The curb-cut effect

In the early 1970s, disability activists in Berkeley, California, pushed the city to cut ramps into sidewalk curbs so wheelchair users could cross streets. Once curb cuts existed, everyone used them: parents with strollers, travellers with suitcases, delivery workers with trolleys, kids on bikes. Angela Glover Blackwell named this pattern "the curb-cut effect" in a 2017 essay in the Stanford Social Innovation Review: designs made for a specific group routinely benefit far more people than intended.

Software is full of curb cuts. Captions were made for Deaf and hard-of-hearing viewers; today a large share of social video is watched with the sound off. Dark mode and "reduce motion" settings came out of accessibility needs and became mainstream preferences. Keyboard shortcuts help people who cannot use a mouse and make power users fast. Plain language helps people with cognitive disabilities and everyone reading in their second language, which in India is most people using English software.

What this means for your design process

Treat ability as a range, not a binary. Ask "what if this person cannot see the screen right now, cannot hear, cannot use a pointer, cannot read fast, cannot remember the last screen?" at the moment you design a flow, not after. Most fixes are cheap at sketch time and expensive after launch, because accessibility problems are rarely cosmetic: an unlabelled custom control, a gesture-only action, or a colour-only status are structural decisions.

In the wild

• VoiceOver on iPhoneApple, iPhone 3GS, 2009
  Apple shipped a full screen reader on a glass touchscreen that many blind people had assumed they could never use. Touch to explore, double-tap to activate. It became the default phone for a large part of the blind community. A platform that bakes accessibility into its standard controls makes every developer who uses those controls accessible by default.
• Xbox Adaptive ControllerMicrosoft, 2018
  A controller with large programmable pads and ports for external switches, co-designed with gamers with limited mobility. Co-design with the people who face the mismatch, and the product gets better for everyone who can plug things into it.
• Captions on social videoInstagram, TikTok, YouTube
  Automatic captions, first introduced for accessibility, are now a default way people watch muted video on commutes. A curb cut: the "accessibility feature" became core product behaviour.

Accessibility is increasingly a legal requirement for digital products, but the stronger reason for a solo creator is simpler: accessible products are better products, and they reach more paying people.

This chapter is orientation, not legal advice. Laws differ by country, change over time, and depend on who your customers are and how big your business is. What you need is a working map: which rules exist, which technical standard they almost all point to, and why the cost of complying is lowest if you design for it from the start.

The legal map in one picture

Nearly every accessibility law in the world, whatever its name, ends up pointing at the same technical yardstick: the Web Content Accessibility Guidelines (WCAG), usually at level AA. Learn WCAG once and you have learned the test that most regulators and courts use.

United States

The Americans with Disabilities Act (1990) predates the commercial web, and its Title III, covering "places of public accommodation", has been applied to websites and apps by many courts. Thousands of digital accessibility lawsuits are filed each year, many against small online stores. The best-known case, Robles v. Domino's Pizza, involved a blind customer who could not order through the website and app; in 2019 the Supreme Court declined to hear Domino's appeal, leaving in place a ruling that the ADA applied. In 2024 the Department of Justice adopted a rule requiring state and local government websites and apps to meet WCAG 2.1 AA. Section 508 covers federal agencies and what they buy.

European Union

The European Accessibility Act (Directive 2019/882) applies from 28 June 2025. It covers a defined list of products and services sold to consumers in the EU, including e-commerce, consumer banking, e-books and the software used to read them, electronic communications and parts of transport. Its technical standard is EN 301 549, which incorporates WCAG for web and app content. Microenterprises providing services (fewer than 10 staff and annual turnover or balance sheet of no more than €2 million) are exempt from the service requirements. If you are a one-person studio you are likely exempt today, but that changes the day you grow, sell through a larger partner, or a customer asks for a conformance report.

India

The Rights of Persons with Disabilities Act, 2016 requires accessibility in information and communication technology (sections 40 and 42 in particular) and the government publishes guidelines to implement it. The Guidelines for Indian Government Websites and Apps (GIGW 3.0, 2023) align with WCAG 2.1 for public-sector sites and apps, and the Bureau of Indian Standards publishes IS 17802, an ICT accessibility standard modelled on the European EN 301 549. If you build for Indian government, banks, or education, expect these to come up in procurement.

The business case when you are one person

Large companies justify accessibility with risk and market size. Your case is more direct:

1. Reach. One in six people, plus everyone over 50 losing near vision, plus everyone on a cheap phone in sunlight. Many of your competitors fail these people, so they look for the products that do not.
2. Loyalty. Disabled users who find a product that works tend to stay, recommend it in their communities, and write the reviews that tell others it is safe to try. Word travels fast in small, connected communities.
3. Quality. Accessible code is semantic, testable and resilient. Native buttons and labelled fields work with browser autofill, password managers, voice assistants, UI test tools and AI agents that operate interfaces through the same accessibility tree.
4. Cost. Doing it at design time is nearly free. Retrofitting after launch, or after a demand letter, is slow and stressful, and you have no team to absorb it.
5. Sales. Business and education buyers often ask for an accessibility conformance report (a VPAT or ACR). Having one lets a one-person product compete with bigger vendors.

In the wild

• GOV.UKGovernment Digital Service, UK, 2012 onwards
  Publishes an accessibility statement on its services, tests with disabled users, and open-sources an accessible design system that many governments copy. Being public about what works and what does not builds trust faster than a vague "we care about accessibility".
• Domino'sUS, case decided on appeal 2019
  Years of litigation over a pizza ordering flow that a screen reader could not complete. The cheapest version of that fix was a labelled form in the first place.
• E-reading apps in the EUEAA scope, 2025
  E-books and dedicated reading software are explicitly in scope: text must be resizable, readable by assistive technology, navigable. If you build reading tools (a natural fit for your taste), accessibility is part of the category's baseline.

WCAG is organised around four principles: content must be Perceivable, Operable, Understandable and Robust (POUR). Around twenty of its success criteria cause most real-world failures in apps; learn those cold.

WCAG 2.2 became a W3C Recommendation in October 2023. It is backwards compatible: anything that meets 2.2 also meets 2.1 and 2.0. It has 86 success criteria (one older criterion, 4.1.1 Parsing, was removed as obsolete), each graded A, AA or AAA. Level A is the bare minimum, AA is what laws and contracts usually ask for, and AAA is a stricter set that is not required as a whole for entire sites because some content cannot meet it.

Do not try to memorise all 86. Understand the four principles as questions you ask of every screen, and memorise the handful of numeric thresholds, because numbers are where designs fail silently.

The criteria that matter most for app makers

This table lists the criteria that cover the bulk of failures in real products, in the order you will meet them in this guide. Criteria new in 2.2 are marked. Memorise the numbers in bold.

How to read a criterion

Each criterion on the W3C site has an "Understanding" page that explains intent, who it helps, and examples, plus "Techniques" that show sufficient ways to meet it and common failures. When you are unsure whether something passes, read the Understanding page rather than a blog summary; the edge cases are written there. The W3C's "How to Meet WCAG (Quick Reference)" lets you filter by level and topic, which is the fastest way to build your own short list.

What about WCAG 3?

W3C is developing WCAG 3, a different structure with outcomes and a new scoring model. As of late 2026 it is still a Working Draft, not a standard, and laws do not reference it. Read it to understand where things are heading; build to 2.2 AA.

In the wild

• The WebAIM MillionWebAIM, annual since 2019
  An annual automated scan of the top million home pages. Every year around 95 percent have detectable WCAG failures, and the same six problem types dominate: low-contrast text, missing alt text, missing form labels, empty links, empty buttons and missing page language. Fix those six and you are ahead of almost the entire web.
• GOV.UK Design SystemUK Government Digital Service
  Each component page lists the research and accessibility findings behind it. Document which criteria each of your components satisfies; your future self is your team.

Contrast is the difference in lightness between text and its background. Below a threshold, reading becomes slow and tiring for everyone and impossible for some; WCAG sets that threshold at 4.5:1 for body text.

Our eyes are far more sensitive to differences in lightness (luminance) than to differences in hue. Contrast sensitivity also falls with age, with conditions like cataracts and glaucoma, with screen glare, and with cheap displays. A pale grey that looks elegant on your calibrated monitor at night can vanish on a budget phone in the afternoon sun. Low-contrast text is the single most common failure on the web in WebAIM's yearly scans.

How the WCAG ratio works

The formula converts each colour to relative luminance: it undoes the sRGB gamma curve, then weights the channels by how sensitive the eye is to each (roughly 21% red, 72% green, 7% blue). The ratio is (L1 + 0.05) / (L2 + 0.05), where L1 is the lighter colour. It runs from 1:1 (identical) to 21:1 (black on white). The 0.05 term models a little ambient light falling on the screen.

Lab: check any pair of colours

Pick a text colour and a background. The lab computes the WCAG 2 ratio live and gives verdicts for body text, large text and UI components. Try the presets, then try to find the lightest grey on white that still passes 4.5:1 (it is close to #767676).

Where the WCAG 2 formula is imperfect

The WCAG 2 formula is simple and widely implemented, but it has known weaknesses. It treats a pair the same whichever colour is the text, while real perception differs between dark-on-light and light-on-dark. It tends to overstate the contrast of dark colour pairs (some dark greys on black pass on paper but are hard to read) and can understate some mid-tone pairs, such as white text on certain oranges and blues that many people find perfectly readable. It also ignores font size and weight beyond the single "large text" threshold, though thin, small text needs much more contrast than bold, large text.

APCA: an emerging model, honestly described

The Accessible Perceptual Contrast Algorithm (APCA), developed by Andrew Somers, tries to model perceived lightness contrast more accurately. It is polarity-aware (dark text on light is scored differently from light text on dark), reports a value called Lc (lightness contrast) from roughly 0 to about 106 for dark-on-light, and links the required contrast to font size and weight through lookup tables. As a rough guide from its documentation, Lc 90 is preferred for body text, Lc 75 is a minimum for body text, and lower values are acceptable for large or bold text and non-text elements.

Its status matters. APCA has appeared in drafts and discussions around WCAG 3, but it is not part of any W3C Recommendation, WCAG 3 is still a Working Draft, and no law references APCA. The honest practice in 2026 is: meet WCAG 2 ratios because that is what you are measured against; use APCA as a second opinion, especially for dark mode and for thin or small type, where WCAG 2 can approve combinations that are actually hard to read.

In the wild

• iOS "Increase Contrast"Apple
  A system setting that apps can read; native controls and system colours automatically switch to higher-contrast variants. If you use semantic system colours instead of hard-coded ones, you inherit this for free.
• Windows contrast themesMicrosoft
  Users can force a limited, high-contrast palette across apps; on the web this appears as the forced-colors media query. Use real borders and outlines, not only background colours and box shadows, so controls keep their shape when colours are replaced.
• iA WriterInformation Architects
  Near-black text on an off-white paper and a carefully tuned dark mode; the calm comes from type and space, not from low contrast. Minimal and accessible are allies.

Part one recap: connect the ideas

Many more people have low vision than are blind, and most of them use what they already have: bigger text and zoom. Your job is to make sure your layout survives both without clipping, overlapping or scrolling sideways.

Low vision covers blurred vision, loss of central vision (macular degeneration), loss of peripheral vision (glaucoma), light sensitivity and reduced contrast sensitivity. Add the age-related loss of near focus (presbyopia) that affects nearly everyone from their mid-forties, and a large share of your users will prefer text bigger than your default. On phones they raise the system text size. On desktops they use browser zoom, sometimes up to 400%, or a screen magnifier that shows a small portion of the screen enlarged.

Two mechanisms matter. First, text scaling: the system or browser makes text larger while the rest of the layout stays the same size, unless you sized it relative to text. Second, zoom: the whole page scales, which on the web shrinks the effective viewport (1280 px at 400% is a 320 px viewport). Layouts break in predictable ways under each: fixed heights clip text, fixed widths force sideways scrolling, absolute positioning makes things overlap, and truncation hides the very words people zoomed in to read.

Lab: zoom and reflow

The frame below is a small app screen. Use the sliders to shrink the viewport (as zoom does) and enlarge the text (as Dynamic Type or browser text size does). Switch between a layout built with fixed sizes and one built to reflow. Push it to 320 px and 200% and watch what each layout does.

Dynamic Type and its equivalents

On iOS, Dynamic Type offers seven standard sizes plus five larger accessibility sizes; at the largest, body text is roughly three times the default. SwiftUI text styles (.font(.body), .headline) scale automatically, and @ScaledMetric scales your own spacing and icon sizes with them. On Android, use sp units for text so it follows the user's font scale, which recent Android versions allow up to 200%. On the web, size text in rem and let the user's browser default (usually 16 px) be the base, and do not set maximum-scale=1 or user-scalable=no in the viewport meta tag, which blocks pinch zoom.

In the wild

• iOS Settings and MailApple
  At accessibility text sizes, rows stack their label and value vertically rather than truncating both. Plan a second layout for large text instead of letting the first one crush.
• Kindle and Apple BooksAmazon, Apple
  Readers can change font, size, line spacing and margins; the text reflows into pages. Reflowable text is the most accessible format there is. Fixed-layout PDFs are the opposite.
• Zoom and MagnifiermacOS, iOS, Windows, Android
  Built-in screen magnifiers follow keyboard focus and the text cursor. When focus moves predictably, magnifier users see what changed; when you update a distant part of the screen silently, they miss it.

About one in twelve men and one in two hundred women of Northern European ancestry have some form of colour vision deficiency. If colour is the only thing that distinguishes "error" from "success" or one chart line from another, those people cannot tell them apart.

Most of us have three kinds of cone cells, sensitive roughly to long (red), medium (green) and short (blue) wavelengths. Colour vision deficiency happens when one kind is missing or shifted. The common forms are inherited and carried on the X chromosome, which is why far more men are affected.

Deuteranomaly / deuteranopia

Medium-wavelength (green) cones shifted or missing. The most common form. Reds, greens, oranges and browns collapse toward similar olive and yellow tones.

Protanomaly / protanopia

Long-wavelength (red) cones shifted or missing. Similar confusion to deuteranopia, and reds also look darker, so red text on black can nearly disappear.

Tritanomaly / tritanopia

Short-wavelength (blue) cones affected. Rare. Blues and greens, and yellows and pinks, become confusable.

Achromatopsia

Very rare total colour blindness, often with light sensitivity. The world appears in shades of grey.

The practical rule, WCAG 1.4.1, is simple: colour may reinforce meaning but must not carry it alone. Pair it with text, an icon, a shape, a pattern, a position or an underline. This also helps people on monochrome e-ink screens, people in bright sunlight, people with night-shift filters, and anyone who prints your page in black and white.

Lab: see your status UI through other eyes

This build status board and chart use the classic red and green. Choose a type of colour vision to apply an approximate simulation (an SVG colour matrix filter), then switch to the redundant design that adds icons, labels and line patterns.

Techniques that make colour redundant

In the wild

• WordleJosh Wardle, 2021; New York Times since 2022
  Offers a high-contrast mode that swaps green and yellow for orange and blue, so the three tile states differ strongly in lightness and hue. A simple palette switch can rescue a game whose entire feedback is colour.
• GitHubColour-blind themes
  Offers light and dark themes tuned for protanopia/deuteranopia and for tritanopia, which change the diff and contribution-graph colours. If your product leans on status colour, give it a themed alternative, not just a note.
• TrelloAtlassian
  Has offered a colour-blind friendly mode that adds patterns to coloured card labels. Patterns survive any colour filter, print and e-ink.

A screen reader does not read your pixels. It reads a parallel structure, the accessibility tree, in which every meaningful element has a role, a name, a state and a place in order. If you get those four right, the experience follows.

When your app renders, the browser or operating system builds two things: the visual layout and an accessibility tree. The tree is a simplified version of your interface that platform accessibility APIs expose to assistive technology: NSAccessibility and UIAccessibility on Apple platforms, AccessibilityNodeInfo on Android, UI Automation and IAccessible2 on Windows. Screen readers, voice control, switch control and automated test tools all read this tree. Purely decorative elements are dropped; generic containers mostly disappear; buttons, links, headings, fields and landmarks remain.

Role, name, state, value

Every interactive node needs four answers. Role: what kind of thing is it (button, link, checkbox, tab, slider, heading)? The role tells users what they can do with it and tells the screen reader which keys work. Name: what is it called ("Save", "Search notes", "Groceries")? State: is it checked, expanded, selected, pressed, disabled, busy? Value: for things like sliders and text fields, what is the current value? WCAG 4.1.2 Name, Role, Value is the criterion behind all of this.

A screen reader combines them into an announcement, usually in the order name, role, state, sometimes followed by a hint. VoiceOver on iOS might say "Dark mode, switch button, on. Double-tap to toggle setting." NVDA on Windows might say "Dark mode, toggle button, pressed". The exact words differ between screen readers and versions; the information is the same.

The accessible name is computed by a defined algorithm (the W3C's Accessible Name and Description Computation). In practice, the main sources in priority order are: aria-labelledby (text of other elements), aria-label, the native label (a <label> for an input, alt for an image), the element's own text content for buttons, links and headings, and finally title or placeholder as weak fallbacks.

Demo: what does it announce?

The two panes below contain real, live HTML: the same six controls written badly and written well. A small script walks each element and computes a simplified name, role and state, the way a screen reader would, and prints the announcement. Tab into the controls in each pane to hear (read) what a screen-reader user would hear on focus.

Reading order, headings and landmarks

Screen-reader users rarely listen to a page from top to bottom. They skim, like sighted users do, but with the keyboard or gestures: jump from heading to heading (the H key in NVDA and JAWS, the rotor on VoiceOver), jump between landmarks (main, navigation, search, banner, contentinfo), or pull up a list of all links. In WebAIM's screen-reader surveys, navigating by headings has consistently been the most common way to find information on a long page, used by roughly two thirds or more of respondents. So your headings are your table of contents.

Reading order follows the order in the code (DOM order on the web, view hierarchy order on iOS and Android), not the visual position. If you use CSS grid, order, absolute positioning or flex reversal to move things visually, the screen reader will still read them in source order. Keep the source order the same as the visual order.

Meet the main screen readers

In the wild

• iOS rotorApple
  A two-finger rotation gesture that picks a navigation unit (headings, links, form controls, words) and then swipes by that unit. Structure you mark up becomes navigation the user controls.
• Be My Eyes2015; Be My AI 2023
  Connects blind and low-vision users with sighted volunteers over video, and later added an AI image describer. Its own interface is built from standard, well-labelled controls. The most loved tools in the community are not fancy; they are predictable.

A text alternative should do the job the image does, in the context where it appears. Describe the purpose, not the pixels; and say nothing at all for images that are purely decorative.

Alt text is writing, and it follows the same rule as all UI writing in Words: say what the reader needs, in as few words as possible. The trick is to ask "what would I say if I were reading this screen aloud to a friend on the phone?" For a logo in a header that links home, you would say the product name. For a photo of a recipe step, you would describe what the cook should notice. For a decorative flourish, you would say nothing.

Worked examples

Context changes everything. The same photo of a person reading on a balcony needs different alt text in different places.

A few rules of thumb. Don't start with "image of" or "picture of": the screen reader already says "image". Put the most important information first; people can stop listening. Keep it short (a sentence or two) and move longer explanations into visible text, which helps everyone. Include text that appears in the image. Don't describe what the surrounding text already says. For people in photos, describe what is relevant to the context; avoid guessing identity attributes like race or gender unless they matter to the meaning and you know them.

User-generated images

If your product lets people upload images, you share responsibility for their alt text. Offer an alt-text field at upload time, make it easy to reach, and consider a gentle reminder before posting. Automatic descriptions (from on-device or cloud image models) are useful as a starting suggestion, but they miss context and can be wrong; label them as automatic and let people edit.

In the wild

• Mastodon and Bluesky2016 onwards; 2023 onwards
  Both put an image-description field in the composer, and community norms push people to use it; some clients can remind you before you post an image without one. Product design can build a culture: make the right thing visible at the moment of action.
• InstagramMeta, 2018
  Added automatic alt text from object recognition and a field to write your own under Advanced settings. Automation helps at scale, but buried manual fields get little use. Put the field where people already are.
• Seeing AIMicrosoft, 2017
  A camera app that narrates text, scenes, products and people for blind users. Users already carry tools that describe images; your alt text should add the meaning only you know.

Anything your product says with sound must also be said with sight: captions for video, transcripts for audio, and visual or haptic equivalents for alerts.

Hearing loss is common and increases with age; many people are hard of hearing rather than profoundly deaf, and some Deaf people use a sign language as their first language and read captions as a second language. Add the situational group (open-plan offices, trains, sleeping babies) and the case for visual alternatives is overwhelming. For a software product, sound appears in three places: media (video, audio, podcasts), feedback (alerts, chimes, notification sounds) and voice interfaces.

Captions done properly

Captions are synchronised text of speech plus meaningful sound ("[door slams]", "[soft piano music]"). Subtitles usually translate speech only, assuming the viewer can hear. Good captions are accurate, synchronised, complete and readable: one or two lines, high contrast, not covering important on-screen text, with speaker identification when it is not obvious. Automatic captions have improved a lot but still mangle names, jargon, accents and Indian English mixed with Hindi; correct them for anything you publish.

Transcripts

For audio-only content (podcasts, voice notes), provide a transcript. For video, a transcript is also useful: it lets people skim, search, read at their own pace, and use a braille display. Deaf-blind users rely on text that can be sent to braille. A transcript is also great for search engines and for you, since it becomes a blog post.

Visible and tangible feedback

If a sound means something (message received, timer done, error), pair it with a visual change and, on phones, a haptic. Never make the sound the only cue. Allow sounds to be turned off and respect system mute. For voice features, offer a typed alternative: people with speech differences, strong accents, or in quiet places cannot always speak to your app.

In the wild

• Live CaptionAndroid 10, 2019; iOS Live Captions, 2022
  On-device captioning of any audio playing on the phone, including calls and videos without captions. Platform features help, but do not replace authored captions for your own content; they can be wrong on names and terms.
• Sound RecognitioniOS 14, 2020
  Detects sounds like doorbells, alarms and crying babies and shows a notification. Turning sound into visual notifications is a pattern your app can apply to its own alerts.
• YouTube captionsGoogle
  Viewers can change caption size, font, colour and background opacity. Captions as text, not pixels, let each viewer adapt them.

Part two recap: connect the ideas

If something works with a mouse, it must work with a keyboard. And a keyboard user must always be able to see where they are: the focus indicator is their mouse pointer.

Keyboard access is the foundation that many other assistive technologies build on. Switch devices, sip-and-puff controllers, some voice control modes and many screen-reader interactions are translated into keyboard-like "move next" and "activate" commands. People with tremor, repetitive strain injury or limited fine motor control often prefer the keyboard. Power users choose it because it is fast. If your app is fully keyboard operable with a visible focus, you have served all of them.

The keyboard contract

Users expect a small, consistent set of keys. Tab and Shift+Tab move between interactive elements. Enter activates links and buttons. Space activates buttons and toggles checkboxes. Arrow keys move within a composite widget (radio group, tabs, menu, listbox, grid). Escape closes the thing that just opened (dialog, menu, popover). Home and End jump to the first and last items in a list-like widget. Native elements already behave this way; custom ones must be taught every key.

Demo: div buttons versus real buttons

Click inside the pane, then press Tab repeatedly. In "Without", the toolbar is built from divs with click handlers and the one real button has its outline removed. In "With", every control is a native element with a strong focus indicator, and a skip link appears on the first Tab.

Designing a focus indicator

Browsers draw a default focus ring, but many designs remove it with outline: none because it appears on mouse click. The modern fix is :focus-visible, which browsers apply when focus came from the keyboard (and for text inputs always), so you can style a strong indicator without it flashing on every click. A good indicator is thick enough to see (2 to 3 px or more), contrasts at least 3:1 with the colours around it, is not only a colour change of the element itself, and is not hidden by overflow or sticky elements. WCAG 2.2's AAA criterion 2.4.13 Focus Appearance gives a precise target: an outline area at least as big as a 2 CSS px perimeter, with 3:1 contrast between focused and unfocused states.

/* One focus style for the whole product */
:focus-visible {
  outline: 3px solid var(--focus);
  outline-offset: 2px;
}
/* Keep focused things clear of sticky headers (2.4.11) */
html { scroll-padding-top: 72px; }

Focus management

When the interface changes, put focus somewhere sensible. Opening a dialog moves focus into it; closing returns focus to the button that opened it. Deleting a list item moves focus to the next item (or the list heading), not to the top of the page. After a route change in a single-page app, move focus to the new page's heading or main region, otherwise screen-reader users have no idea anything changed. Never use positive tabindex values (1, 2, 3); they create an order that fights the DOM. Use tabindex="0" to make a custom element focusable and tabindex="-1" to make something focusable only by script.

Skip links

A skip link is the first focusable element on a page, usually hidden until focused, that jumps to the main content. Without it, a keyboard user tabs through every header link on every page. In apps with a sidebar, a "Skip to editor" or "Skip to results" link saves dozens of key presses.

In the wild

• Linear2019 onwards
  Built keyboard-first: a command menu (Cmd-K), shortcuts for nearly every action and visible focus within lists. Keyboard operability as a brand value serves accessibility and speed at once.
• Things 3Cultured Code, 2017
  On Mac, you can create, move, schedule and complete to-dos without the mouse, with a clear selection highlight. A calm app can be a fully keyboard-driven one.
• GOV.UKDesign System
  Uses a distinctive yellow focus state with a dark underline, chosen to stand out on any background colour. A focus style can be bold and on-brand.

People reach your interface with fingers that shake, a single switch, their voice, a head pointer, or one thumb on a moving bus. Make targets big and well spaced, give every gesture a simple alternative, and never make people race a clock.

Fitts's law, which you met in The Human Mind, says the time to hit a target grows as it gets smaller and farther away. For people with tremor, arthritis, cerebral palsy, Parkinson's, or cold hands at a bus stop, small targets are not just slower; they produce errors, and errors on destructive actions are costly. Motor accessibility is mostly about margin: bigger targets, more space, simpler gestures, more time, undo.

Target size

WCAG 2.2's 2.5.8 sets a minimum of 24 by 24 CSS pixels (or enough spacing). Platform guidance is more generous and you should follow it: Apple recommends at least 44 by 44 points, Material Design 48 by 48 dp (about 9 mm). The visible icon can be smaller than the target; extend the hit area with padding. Space destructive actions away from frequent ones.

Gestures and dragging

Complex gestures (multi-finger swipes, pinches, path-based gestures like drawing a shape) are hard or impossible for many people, and invisible to everyone until learned. WCAG 2.5.1 Pointer Gestures requires that anything done with a multipoint or path-based gesture can also be done with a single pointer without a path (a tap or click). 2.5.7 Dragging Movements, new in 2.2, extends that to dragging: reordering a list, moving a slider, dragging a card between columns must also be possible with taps or clicks, such as "Move up" and "Move down" buttons or a "Move to…" menu. 2.5.4 Motion Actuation says shake-to-undo and tilt controls need a regular control too and must be possible to turn off.

Switch control and voice control

Switch users operate a device with one or two buttons (or a head movement, a sip-and-puff tube, a blink). iOS Switch Control and Android Switch Access scan through the interface, highlighting groups and then items, and the user presses the switch to select. Every extra focusable element adds scanning time, so clean grouping and logical order matter enormously. Elements that only appear on hover or after a timeout are often unreachable.

Voice control users speak commands: "Tap Save", "Scroll down", "Show numbers" (which overlays a number on every control). iOS Voice Control, macOS Voice Control, Android Voice Access and Windows Voice Access all match spoken words against accessible names. If your visible button says "Send" but its accessible name is "Submit message form", saying "Tap Send" fails. That is WCAG 2.5.3 Label in Name: the accessible name must contain the visible label, ideally starting with it.

Time limits

Some people read slowly, type slowly with a head pointer, or need to look something up. WCAG 2.2.1 requires that time limits can be turned off, adjusted, or extended (with a warning and at least 20 seconds to respond), unless the limit is essential (like a live auction). 2.2.2 requires that moving, blinking or auto-updating content lasting more than five seconds can be paused. In practice: don't auto-dismiss toasts that contain actions (like Undo) in three seconds; don't auto-advance carousels; warn before a session expires and let people extend it with one tap; save drafts so a timeout never loses work.

In the wild

• iOS Mail swipe actionsApple
  Swiping a message reveals actions, but the same actions exist as buttons in the message view and as VoiceOver custom actions on the row. A gesture can be the shortcut, never the only door.
• Gmail "Undo Send"Google
  Gives a configurable window (5 to 30 seconds) to recall a sent email. Letting users choose the time limit is the WCAG idea in product form.
• Voice ControliOS 13 and macOS Catalina, 2019
  Full device control by voice, including "show names" and "show numbers" overlays. Your accessible names are literally the vocabulary users speak.

Cognitive accessibility means reducing what people must understand, remember and decide at once. It helps people with learning disabilities, dyslexia, ADHD, autism, dementia, brain injury and anxiety, and it helps every tired, distracted human using your product.

Cognitive and learning disabilities are the largest and least visible group. They vary enormously: difficulty with reading, with numbers, with short-term memory, with sustained attention, with processing speed, with unexpected change, with ambiguity. WCAG 2.x covers only part of this territory, because many cognitive needs are hard to test as pass or fail. So the W3C's Cognitive and Learning Disabilities Accessibility Task Force (COGA) published a separate guide, Making Content Usable for People with Cognitive and Learning Disabilities (2021), organised around eight objectives.

Plain language

Write at a level most people can read quickly when tired: common words, short sentences, active voice, one idea per sentence, the most important thing first. This is not "dumbing down"; it is respect for attention. Everything in Words applies with extra force here. Avoid idioms and metaphors that confuse literal readers and second-language readers ("ballpark figure", "circle back"). Explain numbers ("₹499 a year, about ₹42 a month"). Use the same word for the same thing everywhere.

Memory and predictability

Working memory holds only a few items. Every time your product asks people to remember something from a previous screen (a code, a choice, an instruction), some of them will lose it. Show what they need where they need it: keep earlier answers visible in a summary, let password managers fill fields, allow paste, offer "magic link" or passkey login as alternatives to memorised passwords (WCAG 3.3.8). Predictability matters too: WCAG 3.2.3 and 3.2.4 ask for consistent navigation and consistently named components; 3.2.6 asks for help to be in a consistent place. Unexpected changes of context, such as a form that submits when you pick a dropdown option, disorient everyone and can stop some people entirely (3.2.2).

Attention, distraction and anxiety

For people with ADHD, distraction is not a minor annoyance; it can end the task. For anxious users, countdowns ("Offer ends in 04:59"), scarcity messages and aggressive red warnings raise stress and cause mistakes. Calm products are cognitively accessible products: one primary action per screen, no auto-playing motion, notifications that are few and useful, and reassurance at moments of risk ("You can change this later", "Nothing is charged until you confirm"). Respect prefers-reduced-motion (see Motion & Feel): parallax and large animated transitions can cause nausea for people with vestibular disorders, and flashing more than three times a second can trigger seizures (WCAG 2.3.1).

Reading differences: dyslexia

Dyslexia affects decoding written words. What helps is well established and simple: left-aligned (not justified) text, generous line spacing (around 1.5), comfortable line lengths, sans or humanist fonts with clear letter shapes, no long blocks of italics or capitals, and the ability to change font size and spacing. Specially designed "dyslexia fonts" are popular, but controlled studies have generally not found that they improve reading speed or accuracy compared with ordinary clear fonts; what matters more is spacing, size and the reader's own preference. Offer choice (as Kindle and many reading apps do) rather than one prescribed font. Text-to-speech and read-aloud support are often more helpful than any font.

In the wild

• GOV.UK "one thing per page"Government Digital Service
  Complex forms are split into pages that each ask one question, with a check-your-answers summary before submitting. Their research found this easier for users with cognitive and other disabilities and for everyone else. Lower cognitive load per screen beats fewer screens.
• PasskeysApple, Google, Microsoft, 2022 onwards
  Sign-in with a device unlock (face, fingerprint, PIN) instead of a memorised password. Removing a memory test is a security win and a cognitive accessibility win.
• Apple Assistive AccessiOS 17, 2023
  A simplified mode with large buttons, fewer choices and streamlined core apps, designed with people with cognitive disabilities. Sometimes the most accessible version is the one with fewer features, a lesson your calm products already lean towards.

Part three recap: connect the ideas

Native elements and platform controls come with roles, names, states, focus and keyboard behaviour built in. ARIA only changes what assistive technology is told; it adds no behaviour. So use native first, and reach for ARIA only to fill gaps.

The W3C's Using ARIA document states the first rule of ARIA use: if you can use a native HTML element or attribute with the semantics and behaviour you need already built in, do that instead of repurposing an element and adding an ARIA role, state or property. The WAI-ARIA Authoring Practices Guide puts it more bluntly: no ARIA is better than bad ARIA. WebAIM's annual scans support this: home pages that use ARIA tend to have more detected errors, on average, than those that don't, because ARIA is so often used to patch over the wrong element.

The five rules of ARIA, in practice

1. Prefer native. button, a href, input, select, textarea, details/summary, dialog, fieldset/legend, label, table, h1–h6, nav, main, ul/ol.
2. Don't change native semantics unless you really must. Don't put role="button" on a heading; put a button inside the heading.
3. All interactive ARIA controls must be keyboard operable. If you add role="tab", you owe the user arrow keys.
4. Don't hide focusable elements with aria-hidden="true" or role="presentation".
5. Every interactive element needs an accessible name.

The ARIA you will actually use most is small: aria-label and aria-labelledby (names), aria-describedby (hints and errors), aria-expanded, aria-pressed, aria-checked, aria-selected, aria-current="page" (states), aria-hidden="true" for decorative icons, aria-live or role="status" for announcements, and aria-invalid for fields in error.

<div class="btn" role="button"
     aria-label="button"
     onclick="save()">
  <i class="icon-save"></i>
</div>
<span class="lbl">Email</span>
<input placeholder="Email">

<button type="button" onclick="save()">
  <svg aria-hidden="true">…</svg>
  Save draft
</button>

<label for="email">Email</label>
<input id="email" type="email"
       autocomplete="email">

Native platforms: the same ideas, different APIs

On iOS and Android, standard controls are accessible by default. Custom views need you to set the same four things: role (traits), name (label), state and value, and to group or hide elements sensibly.

Image(systemName: "trash")
  .accessibilityLabel("Delete highlight")

HStack { Image(book.cover); Text(book.title); Text(book.author) }
  .accessibilityElement(children: .combine)   // one stop, not three

Text("Chapter 3").font(.headline)
  .accessibilityAddTraits(.isHeader)

Toggle("Dark mode", isOn: $dark)              // role, name, state: free

Image("divider").accessibilityHidden(true)    // decorative

row.accessibilityAction(named: "Archive") { archive(item) }

@ScaledMetric var iconSize: CGFloat = 20       // scales with Dynamic Type

Icon(Icons.Default.Delete, contentDescription = "Delete highlight")

Icon(painterResource(R.drawable.divider), contentDescription = null) // decorative

Row(Modifier.semantics(mergeDescendants = true) {}) { /* cover, title, author */ }

Text("Chapter 3", modifier = Modifier.semantics { heading() })

Switch(checked = dark, onCheckedChange = { dark = it },
       modifier = Modifier.semantics { contentDescription = "Dark mode" })

Modifier.semantics {
  customActions = listOf(CustomAccessibilityAction("Archive") { archive(); true })
}
// Text in sp follows the user's font scale; targets ≥ 48.dp

<ImageButton
    android:src="@drawable/ic_delete"
    android:contentDescription="@string/delete_highlight"
    android:minWidth="48dp" android:minHeight="48dp" />

<ImageView android:src="@drawable/divider"
    android:importantForAccessibility="no" />

ViewCompat.setAccessibilityHeading(titleView, true)
ViewCompat.addAccessibilityAction(row, "Archive") { _, _ -> archive(); true }

<html lang="en">                         <!-- page language: 3.1.1 -->
<title>Library · Margins</title>          <!-- page titled: 2.4.2 -->
<main id="main"> <h1>Library</h1> … </main>

<button type="button" aria-pressed="false">Bold</button>
<nav aria-label="Primary"> <a href="/library" aria-current="page">Library</a> … </nav>

<input id="pw" type="password" aria-describedby="pw-hint pw-err" aria-invalid="true">
<p id="pw-hint">At least 8 characters.</p>
<p id="pw-err">Add 2 more characters.</p>

<div role="status"></div>   <!-- write "Saved" here to announce it -->

Grouping: fewer, richer stops

A list row with a cover image, title, author, progress and a "more" button could be five stops for a screen reader, or one stop that says "The Shape of Design, Frank Chimero, 40 percent read" with "Archive" and "Share" as custom actions. The second is dramatically faster to use. Group static content that belongs together; keep separate only the things people act on separately.

In the wild

• Apple system controlsUIKit and SwiftUI
  Standard controls support VoiceOver, Dynamic Type, Bold Text, Increase Contrast, Switch Control and Voice Control with no extra work. Every custom control you build gives up that inheritance; make sure the custom look is worth it.
• The HTML dialog elementSupported in all major browsers since 2022
  dialog.showModal() gives you a modal with a backdrop, focus moved inside, Escape to close and the rest of the page made inert. The platform keeps absorbing patterns you used to build by hand. Check before you build.

A few composite components cause most keyboard and screen-reader failures. Each has a known contract (roles, states, and which keys do what) published in the W3C's Authoring Practices Guide. Learn the contract, or better, use a well-tested implementation.

The APG is a W3C resource that documents design patterns with roles, states and keyboard interaction, plus working examples. It is guidance rather than a standard, and its examples are not production code, but it is the best shared definition of how components should behave. Below are the four you are most likely to build, with their contracts reduced to what you must remember.

Modal dialog

Contract: role="dialog" (or the native <dialog> opened with showModal()), aria-modal="true", a name from its heading. On open, focus moves inside. Tab and Shift+Tab cycle within it. Escape closes. On close, focus returns to the element that opened it. The rest of the page is inert (not focusable, not read).

Menu button

Contract: a button with aria-haspopup="menu" and aria-expanded. Enter, Space or Down Arrow opens the menu and focuses the first item; Up Arrow can focus the last. Inside, arrow keys move, Home and End jump, typing a letter jumps to the matching item, Enter activates, Escape closes and returns focus to the button. Items use role="menuitem" inside role="menu". Important nuance: ARIA menus are for application-style action menus. Site navigation is not a menu; use a list of links in a nav, with a disclosure button if it collapses.

Tabs

Contract: role="tablist" containing role="tab" elements, each with aria-selected and aria-controls pointing to a role="tabpanel". Only the selected tab is in the Tab order (roving tabindex). Left and Right Arrow move between tabs; Home and End go to first and last. Tab moves from the tab list into the panel. Selection can follow focus (automatic) if panels load instantly, or wait for Enter or Space (manual) if they are slow.

Combobox (autocomplete)

Contract: a text input with role="combobox", aria-expanded, aria-controls pointing at a role="listbox" of role="option" items, and aria-activedescendant naming the highlighted option while focus stays in the input. Down Arrow opens and moves through options, Enter selects, Escape closes (a second Escape may clear). Announce the number of results with a polite status message ("5 suggestions"). Comboboxes are the hardest of these to get right across screen readers; if a native <select> or <datalist> will do, use it, and if not, use a well-tested library component.

In the wild

• React AriaAdobe
  A library of unstyled hooks and components implementing APG behaviour, tested across screen readers and input types. Buying behaviour and owning the visuals is the right split for a solo developer.
• Raycast and Linear command menus2020s
  Command palettes are comboboxes: an input plus a filtered list navigated with arrows. The most "designed" interactions of modern apps are standard patterns underneath; follow the contract and they work for everyone.

Automated tools catch a meaningful but limited share of accessibility problems. A repeatable manual routine (keyboard, screen reader, zoom, grayscale, contrast) catches most of the rest, and testing with disabled people catches what you would never think of.

How much do automated tools find? Estimates vary with what is counted. In a 2017 experiment, the UK Government Digital Service built a page with 142 deliberate accessibility barriers and ran it through 13 automated tools; even the best found well under half of them. Deque, which makes axe, reported in 2021 that across its audits, axe-core's automated rules found about 57 percent of issues by volume, because the most common issues (like contrast) are also the most automatable. A fair summary: tools reliably find missing names, contrast failures, missing labels, invalid ARIA and some structure problems; they cannot judge whether alt text is meaningful, whether focus order makes sense, whether a flow is understandable, or whether a custom widget actually works with a keyboard.

The solo audit routine (about 90 minutes)

1. Automated scan, 10 minutes. Run axe DevTools or Lighthouse on each main screen of your web app; run Xcode's Accessibility Inspector audit on iOS and Google's Accessibility Scanner on Android. Fix everything they report; they are cheap wins.
2. Keyboard pass, 15 minutes. No mouse. Tab through each main task. Check: reachable, visible focus, sensible order, no traps, Escape closes things, focus returns after dialogs, nothing hidden under sticky headers.
3. Screen-reader pass, 25 minutes. Run the script below with VoiceOver (Mac or iPhone), TalkBack or NVDA.
4. Zoom and text size, 10 minutes. 200% text size; 400% browser zoom or a 320 px window; iOS largest accessibility size. Look for clipping, overlap, truncation and sideways scrolling.
5. Colour and contrast, 10 minutes. Grayscale filter on; check every status and chart. Spot-check muted text, placeholders, borders and focus rings with a contrast checker in both themes.
6. Motion and time, 5 minutes. Turn on Reduce Motion; check that large animations calm down. Wait out every timer and toast; check you can still act.
7. Log and prioritise, 15 minutes. Write each issue with the criterion, the user it blocks, severity (blocker, serious, minor) and the fix.

A screen-reader pass script

Use the same script every time so results are comparable between releases.

Lab: a quick grayscale check

Here is the same small dashboard with and without colour. Toggle and ask: does any meaning disappear?

Testing with disabled people

Nothing replaces watching a screen-reader user, a switch user, or someone with a cognitive disability use your product. As a solo creator you can still do it: invite users from your support inbox who mention assistive technology, post in accessibility communities with a clear, paid offer, or use services that recruit disabled testers. Pay people for their time, as you would any expert. Give them a real task, use their own devices and settings, and stay quiet while they work. One session will teach you more than a week of reading. See Testing & Iteration for how to run sessions alone.

In the wild

• axe-coreDeque, open source
  The rules engine behind many tools, including Lighthouse's accessibility audit; it can run inside Playwright, Cypress or Jest tests. Put it in your test suite so regressions fail the build.
• Accessibility InspectorApple, ships with Xcode
  Shows the accessibility properties of any element on Mac or a connected simulator, and runs an audit for missing labels, small targets and contrast. Seeing the tree directly makes role and name bugs obvious.
• Accessibility ScannerGoogle, Android
  An app that scans screens on a real device and suggests fixes for touch target size, contrast and labels. Run it on a cheap phone, not just your own.

Part four recap: connect the ideas

English is a short, left-to-right language with a small alphabet and simple names. Design as if it were the exception: leave room for longer text, mirror for right-to-left scripts, support every script your users write, and never assume a name or an address has a fixed shape.

Text expansion

Translated text is usually longer than English. As a rough rule, long paragraphs grow by 20 to 40 percent in languages like German, French or Hindi, and short UI labels can double or triple ("Save" becomes "Speichern"; "Add" becomes "Hinzufügen"). Some languages are shorter in characters but taller: Indic scripts like Devanagari and Tamil have marks above and below the line and need more line height; Chinese and Japanese are compact but need larger sizes to stay legible. Layouts that fit English exactly will break.

Right-to-left layouts

Arabic, Hebrew, Persian and Urdu are read right to left. In an RTL interface the whole layout mirrors: navigation starts on the right, the back arrow points right, progress fills from right to left, list chevrons point left, and text aligns right. Some things do not mirror: phone numbers, most numerals in many contexts, media playback controls (play points right in most RTL interfaces), logos, and images of real objects like clocks. On the web, set dir="rtl" and use CSS logical properties (margin-inline-start, padding-inline-end, inset-inline-start, text-align: start) so one stylesheet works both ways. iOS and Android mirror standard layouts automatically if you use leading and trailing rather than left and right.

Scripts, fonts and input

Choose fonts that cover the scripts your users write, or define fallbacks that do (Noto families cover most of Unicode). Test Devanagari, Tamil, Bengali and other Indic scripts for clipped marks when line height is tight. Allow mixed scripts in a single field; many Indians type Hindi in Latin letters (Hinglish) and switch scripts mid-sentence. Never restrict name fields to A to Z. Sort and search with locale-aware functions (Intl.Collator), and format numbers, dates and currency with Intl.NumberFormat and Intl.DateTimeFormat: the Indian locale groups 1,00,000 (a lakh), not 100,000.

Names and addresses

Patrick McKenzie's 2010 essay "Falsehoods Programmers Believe About Names" lists assumptions that break real people: that everyone has exactly one first name and one last name, that names don't change, that names are written in one script, that names have no spaces or punctuation, that a name field can be required to have at least two characters. Many people in India use a single given name with an initial standing for a father's name or village; many people across South and Southeast Asia have no family name at all; Spanish and Portuguese naming uses two surnames; East Asian names usually put the family name first.

In the wild

• Google Pay and PhonePe in India2017 onwards
  UPI payment apps offer interfaces in many Indian languages, and payments are identified by phone numbers and UPI IDs rather than Western-style names. Designing around local identifiers removes a whole class of name and address failures.
• iOS and Android RTLApple, Google
  Both platforms mirror standard controls and navigation automatically when the system language is RTL, as long as apps use leading/trailing rather than left/right. Use the platform's direction-aware layout and most mirroring is free.
• Unicode CLDRUnicode Consortium
  The shared database of locale data (plural rules, date formats, number grouping) that powers ICU, the JavaScript Intl API and mobile platforms. Don't hand-write locale rules; the data already exists.

Performance is accessibility. A product that needs a flagship phone and fast Wi-Fi excludes most of the world, including most of India, and an app that freezes is unusable with a screen reader no matter how well it is labelled.

Your development machine is probably among the fastest computers your users will ever touch your product on. Much of the world, and a large share of India's hundreds of millions of smartphone users, is on budget Android phones with modest RAM and slower processors, on mobile networks that vary from good 4G and 5G to patchy 3G and 2G in trains, basements and rural areas, often on prepaid data with daily limits. Engineer Alex Russell has written for years about this "performance inequality gap": the gap between the devices developers use and the median device, which has kept JavaScript-heavy sites slow for most people.

What to design for

Low RAM and CPU: keep bundles small, avoid heavy animation libraries, virtualise long lists, don't keep many large images in memory. Android Go, Google's edition for phones with 2 GB of RAM or less, exists because this is a mass market. Slow and flaky networks: show useful content fast (server-rendered HTML, cached shells), make every action resilient to dropping connections (queue and retry, offline-first storage), and show honest progress. Expensive data: compress images, lazy-load, let users choose lower quality, and never auto-download large media on mobile data. Small storage: keep your install size small; people delete big apps first when storage fills.

In the wild

• Facebook LiteMeta, 2015
  A small Android app built for 2G networks and low-end phones, which became very popular in India and other markets. A deliberately light version can reach far more people than the flagship.
• Flipkart LiteFlipkart, 2015
  An early progressive web app with offline support and fast loading on slow networks, widely cited as a pioneering PWA. The web can feel app-like on modest hardware when it is built lean.
• YouTube GoGoogle, 2017 to 2022
  Showed the data size of each video quality before playing and allowed offline saving; discontinued in 2022 as the main app absorbed improvements for low-end devices. Showing data cost before acting respects users who pay per megabyte.

Inclusion means noticing the defaults that quietly assume one kind of person: young, alone, at a desk, in one time zone, with a gender that fits two boxes, and a culture where red means danger and Sunday starts the week.

Older adults

Ageing brings several changes at once: reduced near focus and contrast sensitivity, slower reaction and less precise fine motor control, some hearing loss, and often less familiarity with newer interaction conventions (hidden gestures, icon-only navigation). None of these are dramatic alone; together they make many apps quietly hostile. The fixes are the ones in this guide: larger default text with scaling, strong contrast, big targets, visible labels, no hidden gestures, undo, and patience in time limits. Older adults are also often targets of fraud, so clear, consistent security messaging matters.

Situational limits

Gender and identity in forms

First ask whether you need to know at all. Most products don't need gender. If you do (for example, for medical or legal reasons), explain why, make it optional where possible, offer more than two options, and allow people to self-describe. Ask for pronouns or a form of address only if you use them. Titles (Mr, Ms, Dr) are often unnecessary. Let people change their name and email without support tickets; names change for marriage, transition, safety and many other reasons. Never show deadnames in old receipts or shared histories once someone has updated their profile.

Culture, colour and symbols

Colours and symbols carry different meanings in different places. In many Western contexts white is associated with weddings; in parts of India and East Asia it is associated with mourning. Red signals danger or loss in Western finance apps, but in Chinese stock markets red often marks prices going up. A thumbs-up, an owl, a number or a hand gesture can be friendly in one culture and rude or unlucky in another. You cannot learn every meaning; you can avoid relying on colour or symbol alone (Chapter 6 again), use words with icons, and check key symbols with people from your target markets.

Time, dates and calendars

Your users live in different time zones (India uses a single +5:30 zone, which surprises software that assumes whole-hour offsets), start their weeks on different days (Monday in much of Europe and India, Sunday in the US, Saturday in parts of the Middle East), write dates in different orders (03/04 is 3 April in India and 4 March in the US), and some use other calendars alongside the Gregorian one (Islamic, Hebrew, Indian national, Chinese lunar, Vikram Samvat for festivals). Show dates unambiguously ("3 Apr 2026", or relative "Tomorrow, 9:00"), store times in UTC with the user's zone, use locale formatting, and let users choose their first day of the week.

In the wild

• Facebook custom genderMeta, 2014
  Expanded beyond two gender options and added a choice of pronouns for how the product refers to you. The form field is a statement about who the product is for.
• Calendar appsApple, Google
  Let users choose the first day of the week and show alternate calendars (such as Hijri, Hebrew or Chinese) alongside Gregorian dates. Small settings respect large differences.
• Bottom navigation and searchMany apps, 2020s
  iOS Safari's move of the address bar to the bottom (iOS 15, 2021) and bottom tab bars in most apps respond to one-handed use on tall phones. Physical reach is a design constraint, not a preference.

Part five recap: connect the ideas

Wrap-up

Accessibility is not a separate discipline bolted onto design. It is design done with a wider picture of who is on the other side of the screen. You now know the mechanism (the accessibility tree, contrast, reflow, focus), the standard (WCAG 2.2 AA and its key numbers), the methods (native first, APG contracts, a 90-minute audit), and the wider frame (language, device, age, identity). The rest is repetition until it becomes taste.

Practice assignment for the next two weeks

The goal is to turn this guide into a habit and a measurably more accessible product.

1. Days 1 to 2: baseline. Run the full 90-minute audit (Exercise 15.1). Publish or update your accessibility statement.
2. Days 3 to 4: tokens and focus. Fix contrast at the token level in both themes and automate the check. Add a global :focus-visible style, a skip link, and scroll-padding for sticky headers.
3. Days 5 to 6: names and structure. Replace every clickable non-interactive element. Add names to every icon button, real headings and landmarks to every screen. Add the accessibility linter to CI.
4. Days 7 to 8: input alternatives. Give every gesture a tap alternative and custom action; enlarge small targets; fix timers and toasts.
5. Days 9 to 10: text and layout. Fix every break at 200% text and 320 px; add large-text and narrow previews to your daily setup; pseudo-localise once.
6. Days 11 to 12: words and memory. Rewrite errors and instructions in plain language; remove one memory demand from sign-in or onboarding (paste, passkeys, magic links).
7. Days 13 to 14: real people. Book one paid session with a screen-reader user or another disabled tester. Re-run the audit and compare your issue log to day 1.

Reading list

• Mismatch: How Inclusion Shapes Design
  Kat Holmes, MIT Press, 2018 · The best short argument for inclusive design as a creative method, with the persona spectrum and many product stories.
• Inclusive Design Toolkit
  Microsoft, 2016 · Free; the source of the permanent, temporary, situational framing. Read it in an hour.
• Web Content Accessibility Guidelines 2.2, with the "Understanding" documents
  W3C, 2023 · The standard itself. The Understanding pages explain intent and edge cases better than any summary.
• WAI-ARIA Authoring Practices Guide
  W3C · The keyboard and role contracts for every common widget, with working examples. Your reference before building any composite component.
• Inclusive Design Patterns
  Heydon Pickering, Smashing, 2016 (and his Inclusive Components site) · Component-by-component, semantic-first thinking from a designer who codes, like you.
• A Web for Everyone
  Sarah Horton and Whitney Quesenbery, Rosenfeld Media, 2014 · Accessibility through personas and UX practice, not checklists.
• Accessibility for Everyone
  Laura Kalbag, A Book Apart, 2017 · A short, friendly overview for designers and developers.
• Form Design Patterns
  Adam Silver, Smashing, 2018 · Accessible, inclusive forms in depth, from someone who worked on GOV.UK.
• Making Content Usable for People with Cognitive and Learning Disabilities
  W3C COGA Task Force, 2021 · The eight objectives and design patterns for cognitive accessibility that WCAG cannot fully test.
• Falsehoods Programmers Believe About Names
  Patrick McKenzie, 2010 · A short essay that will change every sign-up form you design.
• Technically Wrong
  Sara Wachter-Boettcher, W. W. Norton, 2017 · How biased defaults in forms, algorithms and copy exclude people, with real cases.
• The Curb-Cut Effect
  Angela Glover Blackwell, Stanford Social Innovation Review, 2017 · The essay behind the idea that designing for one group benefits everyone.
• The WebAIM Million and WebAIM Screen Reader User Survey
  WebAIM, annual · Real data on what fails most often and how screen-reader users actually navigate.

Next: put numbers on screens in Information & Data, where accessible charts and tables build on Chapters 6 and 8, or jump to Testing & Iteration to plan your first session with a disabled tester.