Book chapters

Accessibility means a person can complete a task on their own: pay, reschedule, contact support, turn off a setting. It's a product requirement with a pass/fail result, not a set of labels added before release. This chapter sets the model the rest of the book uses: the task, the ways a person interacts, and the team's responsibility for each one.

2 smells · 2 patterns · 2 guides

A user arrives at the app with their settings already on: Larger Text, Reduce Motion, Voice Control, captions. The app doesn't get to ask for a separate in-app setting before it becomes usable. This chapter maps the system settings to what the app has to do for each one and how to check it in code review.

4 smells · 2 patterns · 1 guides

One task, several ways to do it: touch, VoiceOver, Voice Control, Switch Control, a hardware keyboard, a pointer. The app doesn't choose the input method, the user does. This chapter shows what each method needs from the app, and why one native control covers most of them at once.

6 smells · 7 patterns · 3 guides

Accessibility is not a layer of labels added after design. Every state a screen can be in — selected, empty, loading, error, disabled, modal, success — either tells the user what happened or leaves them guessing. This chapter goes through those seven states on one checkout flow and gives each one a fix and a check.

5 smells · 4 patterns

VoiceOver reads semantics, not pixels. Each element gives it a label, a value, traits, sometimes a hint, a position in the order and a set of actions. This chapter treats each of these as an implementation decision and checks it against a real VoiceOver transcript from the Leaf demo.

5 smells · 5 patterns · 4 guides

Users change how the screen looks: text gets bigger and bolder, contrast goes up, transparency and motion go down, color stops being a reliable signal. The design was made for one combination of these settings, and the app has to work with all of them. This chapter covers what breaks under each setting and the fix that holds.

3 smells · 2 patterns

Motor accessibility breaks when the UI assumes a precise, fast, steady finger. Tremor, limited reach, one hand, a switch instead of a finger, a voice instead of a hand all break that assumption. This chapter covers the five places it usually fails: target size, gestures, scanning, time limits and destructive actions.

5 smells · 5 patterns · 3 guides

Some information in an app arrives only as sound, and some actions accept only voice. Both exclude users: people who are deaf or hard of hearing, people with speech disabilities, and anyone in a loud train or a quiet library. This chapter covers media captions, sound-only feedback, voice-only input and Voice Control names.

3 smells · 2 patterns · 1 guides

Cognitive accessibility means taking unnecessary work off the user: remembering, guessing, deciding under pressure, starting over. It's not "dumbing down". Clear errors, saved progress and one obvious next step help everyone, and for some users they decide whether the task can be done at all. This chapter covers five sources of load and the iOS modes, Assistive Access and Guided Access, that simplify the device for the people who need it most.

4 smells · 3 patterns

SwiftUI gives good accessibility defaults as long as you use native controls. Custom UI loses them one modifier at a time. This chapter is a PR-ready set of SwiftUI decisions: which control, which modifier, and how to confirm the result.

11 smells · 8 patterns · 2 guides

Most production apps still have UIKit screens, usually the oldest and most custom ones. Standard UIKit controls are accessible by default. Custom views, cells and drawn content say nothing until the code describes them. This chapter covers the UIKit decisions: grouping, custom controls, drawn content, order, actions and notifications.

10 smells · 10 patterns · 2 guides

The same task is done differently on each platform: a tap on iPhone, a keyboard shortcut on iPad, a menu command on Mac. Shared code is fine, but shared assumptions break accessibility. This chapter covers what changes when an iPhone app moves to iPad, Mac Catalyst or AppKit, and how to describe one task so it works on each.

2 smells · 2 patterns

A testing workflow where each finding is tied to a user task, a piece of evidence and an owner. Testing starts from the critical task, not from a tool. This chapter covers the layers, from automated audit to a manual walkthrough with VoiceOver, and what each one can and can't prove.

13 smells · 11 patterns · 4 guides

AI speeds up three things: finding risks before testing, reading transcripts after testing, and turning findings into clear reports. It doesn't prove anything about how the app behaves with VoiceOver, Switch Control or Dynamic Type. This chapter covers where AI fits, how to prompt it with enough context, and how to keep its guesses from turning into release evidence.

2 smells · 2 patterns

Pick tools by the question you need answered, not by the vendor's promise. A tool earns its place when its findings turn into fixes with an owner. This chapter maps common questions to tools, then shows how a finding gets from a tool into the backlog and back to a verified fix.

4 smells · 3 patterns · 1 guides

Accessibility holds up between releases only when the process carries it: discovery, design, PR, QA, release, support. One champion fixing bugs before each release doesn't scale. This chapter splits the ownership by role and gives each role a checklist, a severity scale and an evidence format.

6 smells · 5 patterns · 2 guides

Earlier chapters go by topic. This one goes by screen: search, checkout form, settings, map, media, onboarding. Each case covers what breaks, the code fix, the check and the catalog entries that apply. Use a case as a template when reviewing a real screen.

12 smells · 10 patterns

The release decision for accessibility is made on evidence: which critical tasks were walked through, with which profiles, what failed, who accepted the remaining risk. Not on a dashboard color and not on "QA said it's fine". This chapter is the checklist for the last three days before release.

7 smells · 8 patterns · 2 guides