Accessibility work is often described as a final pass: check the contrast, add some labels, test the keyboard, ship it.
That model is too late. By then, the expensive decisions have already been made.
The more useful question is: what would we build differently if accessibility was allowed to influence the structure of the feature?
Cognitive load is an engineering concern
Consider a recurring reminder form. It could expose every scheduling value at once, because the backend accepts them. That would be technically complete and unpleasant to use.
Instead, recurrence-specific controls should appear only when they are meaningful. Defaults should come from channels the account can actually use. Editing should preserve existing associations the form does not yet support changing.
Those are interface decisions, but each one needs support from types, validation and API contracts. The architecture has to represent the difference between “not relevant”, “not changed” and “intentionally empty”.
Tip (A useful rule)
When the interface has to explain an internal distinction, first ask whether the distinction belongs in the user’s mental model at all.
Predictability beats novelty
Accessible interfaces benefit from familiar behaviour:
- links navigate;
- buttons perform actions;
- focus moves somewhere sensible after a change;
- errors appear near the thing that needs attention;
- destructive actions explain what will be lost.
This can sound conservative. In practice, it creates room for better design because the basics are dependable. A person can spend their attention on the task rather than decoding the interface.
In code, predictability means reusable primitives with explicit states. A button should not invent a different loading pattern on each screen. A dialog should have one focus strategy. A list row should survive large text without hiding its main action.
Device preferences are inputs
The mobile application can encounter increased contrast, reduced motion, reduced transparency, bold text and different colour schemes. Those settings are not edge cases; they are inputs to the design system.
I use isolated component stories with deterministic data to examine those states without loading authentication, live queries or notifications. That separation is valuable because accessibility defects become easier to reproduce. It also prevents a failed network request from obscuring a layout problem.
The point is not to collect screenshots of every theoretical combination. It is to make components honest about the environments they run in.
Clear ownership makes recovery possible
Accessible software must recover well. When logout clears an authentication token but leaves user-specific cached data behind, the problem is not only security or correctness. It can also create a deeply confusing experience for the next session.
That is why the mobile application has explicit owners for state:
| Concern | Owner |
|---|---|
| Remote resources | TanStack Query |
| Authentication | Session provider and secure storage |
| Appearance | Theme provider |
| Form input | The current screen |
| Navigation access | Protected routes |
When ownership is clear, the product can reliably clear, restore or explain each kind of state.
Plain language tests the model
If I cannot describe a behaviour without borrowing field names from the database, the product model probably needs work.
“Mark done stops this recurring series” is understandable. “Set the terminal occurrence flag” is not. The plain-language version also forces the engineering team to decide exactly what should happen to future reminders.
This is one reason accessibility improves software beyond compliance. It exposes ambiguity. It makes accidental state visible. It pushes technical boundaries towards the way people actually understand the product.
The standard is independence
The goal is not merely that somebody can complete a perfect happy path with enough patience. The goal is that people with different access needs can understand what is happening, recover from mistakes and use the product without depending on somebody else to translate it.
That standard belongs in the architecture from the first conversation.