37. Accessibility and global reach

The question. How does this app adapt to different users, languages, regions and devices?

37.1 Why this concern exists

A team designs an app on a handful of devices, in one language, with good eyesight and steady hands. The app is then used by people who cannot see the screen, who read at twice the default text size, who read from right to left, who live eleven time zones away, and who unfold the device into a tablet halfway through a task.

Three of the seven constraints (Chapter 2) shape the response.

• Human attention. The constraint assumes one small screen and a user who looks at it. Some users do not look at it at all, and listen instead. Others need larger text, stronger contrast or less motion to use it. The screen is also no longer one size.
• Platform rules. The operating system owns the settings through which a user states these needs: text size, screen reader, appearance, motion, language, region and time zone. An app adapts by reading them. Stores and regulators add rules that differ by country, and some of them make accessibility a legal requirement.
• Slow release. Text compiled into the app is fixed until the next release. A wrong translation, or a legal sentence that must change in one country, cannot wait for that. So some text moves to the backend, and the split is visible.

This concern has an unusual property for a teardown. Its probes are settings switches. Each takes a minute, costs nothing, and the result is plainly visible. That makes most findings here Observed. The inferences come afterwards, when you ask what a result says about where text lives, where times are formatted and who decides what a region may see.

The two halves of the chapter are one subject. Accessibility adapts the app to the person. Global reach adapts it to the person’s language, place and device. Both depend on the same engineering habit: nothing about the user is assumed, and everything is read from a setting or from the backend at run time.

37.2 The design space

For every adaptation in this chapter, the design question is the same: who decides? There are four answers. They form a ladder, and an app sits on different rungs for different adaptations.

Fixed. The app has one text size, one appearance, one language, one layout. Nothing is read from the device. This costs nothing to build and excludes users silently. Teams end up here by default, not by choice, usually for a first version in one market.

Platform-driven. The app reads the device’s settings and lets the platform’s toolkit do the work. Text uses the system’s text styles and grows with the system setting. Controls carry labels that the screen reader speaks. Layout is declared in terms of leading and trailing edges, so that the toolkit mirrors it for right-to-left languages. Dates and numbers go through the platform’s formatters. This is the cheapest correct design, because the operating system already contains the hard parts. Its cost is discipline. Every screen must use the system’s mechanisms and never a fixed size, a fixed direction or a hand-built date string.

App-driven. The app has its own settings that override the device’s: an in-app language picker, an in-app theme, an in-app text size. Teams choose this where users commonly run the device in one language and want the app in another, or where the app serves shared devices. The cost is that every adaptation is now the app’s job, including the parts the platform would have handled.

Backend-driven. The backend decides, using what it knows about the account and the request: the language of content, the currency, which features exist, which legal terms apply, and sometimes fully formatted strings. This is the only design that can change an adaptation without a release, and the only one that can enforce a rule the client must not be trusted with (Chapter 21, which asks what the backend refuses to trust the client with). Its cost is a network dependency, and a second source of text and formats that can disagree with the first.

Decided by	Changes without a release	Works offline	Follows device settings	Typical for
Fixed	No	Yes	No	First versions, single-market apps
Platform	No	Yes	Yes, at once	Text size, screen reader, appearance, layout direction, formats
App	No	Yes	Only when the app’s own setting says so	Language and theme pickers
Backend	Yes	Only what was cached	Only if the client sends them	Content text, currency, region features, legal terms

The rung belongs to the adaptation, not to the app. One app usually has platform-driven text size, an app-driven theme, bundled labels, backend-driven content and backend-driven region rules. The interesting findings are the places where two rungs meet and disagree.

37.3 Anatomy

Figure 37.1 shows the inputs an app can adapt to and the two places where text and rules live.

Figure 37.1. Device settings enter through platform services. Text and rules live in two places, the app and the backend.

Three things in this figure carry the chapter.

First, the device settings are several independent inputs, not one. Language, region and time zone are separate settings. A user can run the device in one language, with another country’s formats, in a third country’s time zone. An app that derives all three from one of them is making an assumption you can expose.

Second, text has two homes. Bundled text ships inside the app and follows the device language at once, offline. Backend text arrives in responses and follows whatever language the backend chose. Section 37.5 is about telling them apart.

Third, the backend learns the user’s language and region only from what the client sends and what the account records. The client usually sends the device language with each request. What the backend does when that conflicts with the account’s stored language is a design decision, and a probe finds it.

37.4 Accessibility

The screen reader

A screen reader does not read pixels. It reads a structure the UI publishes: a list of elements, each with a name, a role, a state and a position in an order. A user moves through that list by swiping and acts on the focused element. The quality of an app’s support is the quality of that structure. Four properties matter.

• Labels. Every control needs a name. Text buttons have one for free. Icon buttons do not, and a developer must supply it. A missing label is announced as “button” with nothing else, or as an image’s internal name.
• Order. The reading order should follow the visual and logical order. Custom layouts, overlays and absolute positioning scramble it.
• Grouping. A list row with a title, a subtitle, a price and a badge is one thing to a sighted user. Announced as four separate stops, a list of fifty rows takes two hundred swipes. A well-built row is one element with a combined description, and its secondary actions are offered as actions on that element.
• Custom controls. A control from the platform’s toolkit announces its role and state by itself. A control the team drew, such as a custom slider, a star rating or a swipeable card, announces nothing unless the team adds role, value and actions by hand.

There is also a fifth, which is easy to miss: change. When content updates without the user acting, such as an error appearing or a list finishing its load, the screen reader user learns of it only if the app announces it. A modal must also trap focus inside itself, or the user swipes into the screen behind it.

What screen reader support reveals about the drawing path is the subject of Chapter 32. Here the question is simpler: could a person complete the app’s main task with the screen off?

Text scaling

The system text size is a multiplier the user sets once for the whole device. An app honors it in three steps, and many stop after the first.

1. Text grows. The app uses the system’s text styles and not fixed sizes.
2. Layout survives. Rows grow taller, labels wrap onto more lines, side-by-side elements stack, and every screen scrolls. A layout built with fixed heights clips the larger text or lets it overlap its neighbors.
3. Nothing is lost. Truncated text can still be reached in full. Fixed bars do not grow until they cover the content.

Outcomes follow from the family of design. Fixed heights give clipped text. A cap on scaling gives text that grows a little and then stops. Reflow gives a longer, fully usable screen. Text scaling is also a rehearsal for translation, because both make strings longer. A layout that breaks at large text will break in a language whose words are longer.

Contrast, dark appearance and reduced motion

Dark appearance is implemented by naming colors by purpose, such as background, primary text and separator, and giving each name a light and a dark value. An app built this way switches at once when the system setting changes. An app that was painted with fixed colors has no dark appearance, or has one bolted on behind an in-app setting, with stray screens that stay light. A screen that stays light inside a dark app is often embedded web content or a third-party screen.

Contrast is a property of those color pairs. Gray text on a slightly lighter gray is the common failure. The platform also offers an increased-contrast setting, which few apps read.

Reduced motion is a system setting that asks apps to replace large movement, such as sliding, zooming and parallax, with a fade or nothing. Autoplaying video and looping animation fall under the same request. An app either reads the setting or does not. When it does, the team has a central place where motion is defined.

Touch targets

Each platform publishes a minimum target size, large enough for a fingertip. The drawn icon can be smaller, as long as the tappable area around it is not. Small targets packed together, or an icon whose tappable area is only its own pixels, show that no shared control enforces the minimum. You can judge this without tools. Count how often you miss.

37.5 Language and text

Bundled text and backend text

Bundled text is a table inside the app. It maps a key to a string for each language the app ships. The UI asks for a key, and the platform picks the row for the device language. It is instant, works offline and changes only with a release.

Backend text arrives in responses. It includes content, which was always going to come from the backend, and often much more: section titles from server-driven UI (Chapter 31, which asks how much of the screen the backend decides), error messages, notification text, promotions, onboarding copy and legal documents. The backend picks the language from a request header, from the account’s stored preference or from the region.

Some apps treat all text as backend text. They download the string table at launch and keep it in a cache, which lets them fix a translation without a release. The table bundled in the app is then only a fallback.

The mixed-language signal

Switch the device language and the two kinds of text separate. This is the most informative probe in the chapter, and Figure 37.2 shows why.

Figure 37.2. After a language switch, bundled text changes at once and backend text follows its own rules.

Read the result as a map. Everything that changed at once, with no network, is bundled. Everything that changed after a refresh is backend text keyed to the request. Everything that stayed in the old language is one of three things: backend text keyed to the account, backend text with no translation, or a cached response that has not been refetched. Refresh, then sign out and in, to separate the three.

The pattern is often telling. Navigation in the new language with section headings in the old one points to a screen-describing response (Chapter 10). Error messages in the old language mean the backend writes the errors. A notification in the old language means push text is composed on the backend from the account’s stored language, at a time when the device cannot be asked.

Fallback

No app has every string in every language. Each lookup therefore runs down a chain.

function resolve(key, preferences):
  // preferences: the user's ordered list, for example a regional variant, then its base language
  for language in preferences:
    if table[language] has key: return table[language][key]
    if table[baseOf(language)] has key: return table[baseOf(language)][key]
  return table[defaultLanguage][key]       // the language the team writes in

The chain runs per string, not per screen. A single untranslated label in an otherwise translated screen is a string added after the last translation pass. It shows that release and translation run on different schedules. The language of that stray label is the team’s default language.

Translation is more than word replacement. Plural forms differ by language, and some have several. A message built by joining fragments, such as a number, then a noun, then a verb, comes out in the wrong order in languages with a different word order. Both failures are visible to a reader of the language, and both show strings assembled in code.

Right-to-left layout

In a right-to-left language the whole layout mirrors. The back control moves to the right. Lists align right. A swipe to go back starts from the other edge. Progress bars fill from right to left. Icons that imply direction, such as arrows, flip. Things that do not imply reading direction stay as they are: media playback controls, clocks, phone numbers, and images.

The platform’s toolkit does most of this when layouts are declared with leading and trailing edges. Hard-coded left and right survive as defects: an arrow that points the wrong way, padding on the wrong side, an animation that slides in from the wrong edge. Partial mirroring is a reliable sign of older screens next to newer ones.

Mixed-direction text is the hard case. A right-to-left sentence that contains a product name or a number in left-to-right script must be laid out in both directions at once. Misplaced punctuation at the end of such a line shows text that was assembled without direction marks.

37.6 Formats and time

Dates, numbers and currency

Language and region are separate inputs, and formats belong to region. The same language is written with different date orders, decimal separators, first days of the week and measurement units in different countries. An app that uses the platform’s formatters picks these up from the device’s region setting. An app that builds its own strings shows one fixed format everywhere.

Currency has two parts that are decided in different places. Which currency a price is in, and how much, is a business decision made by the backend. How the amount is written, with its symbol position and separators, is a format, and belongs to the user’s region. A backend that sends a finished string, such as a price with symbol and separators, has taken the second decision too. You can tell, because the price then ignores a change in the device’s region.

What you see after changing only the region	Where the format is made
Dates, numbers and the first day of the week change at once	On the client, by the platform’s formatters
They change after a refresh	On the backend, from the region the client sends
They never change	On the backend from the account, or hard-coded in the client

Time zones

A moment in time is one value everywhere. The correct design stores it as an absolute instant and formats it in the device’s current time zone at the moment of display. Change the time zone, and every timestamp shifts.

Three kinds of time must not shift, and they separate careful designs from simple ones.

• A time at a place. A flight departure, a restaurant booking or a store’s opening hours belong to the place’s time zone. The app should show that local time and say so, wherever the device is.
• A wall-clock time. A daily alarm at seven means seven wherever the user wakes up. It is stored without a zone.
• A calendar date. A birthday is a date, not an instant. Stored as midnight in one zone, it shows as the day before in zones to the west.

Day boundaries are the subtle case. A streak, a daily limit or a “today” section needs a definition of when a day ends. The device’s zone, the account’s home zone and a single global zone are all in use. Each produces a different result for a traveler, and Chapter 12 covers what happens when the clock itself is wrong.

37.7 Regions

A region changes more than formats. It can change the catalog, the prices, the payment methods, which features exist, the minimum age, the consent prompts and the legal terms. These are backend decisions, because the client is untrusted and because they change with the law.

The first question is which signal the backend uses to place a user. There are several, and they can disagree.

Signal	What it is	Why a team uses it
Store account country	The country of the account that installed the app	It decides which listing and which payments the store offers
Account country	Chosen or verified at sign-up	It is stable, and it ties to legal identity
Device region setting	A preference, freely changeable	It is a formatting hint, and rarely trusted for rules
Network location	The country the request arrives from	It reflects where the user is now, which licensing rules often require
Phone number or payment method	The country of a verified number or card	It is hard to fake

Changing the device’s region setting is the only one of these a probe can safely change. If features change with it, the app trusts a client setting for a region rule, which is a weak design. If nothing changes, the rule is keyed to one of the other signals, and you cannot tell which without travelling. Do not attempt to disguise your network location. That defeats a protection, and it is outside the method.

Legal terms and consent are published text, and you can read them. A terms document that names a specific country’s law, a consent prompt that appears only for some regions (Chapter 22, which asks what the app asks to access and what it does when refused), and a settings screen with region-specific controls such as a data export or deletion request all show a backend that holds rules per region.

Where data is stored

Some laws require that personal data stay within a country or region. A backend that complies runs separate backend stores per region and routes each account to its own. This is invisible from outside. The hints are indirect: an account that must be created anew to move countries, a sign-in screen that asks for a region first, a published statement in the privacy policy, or a feature that cannot find users from another region. Each hint has other explanations. Any claim about where data is stored is Speculative unless the maker has published it, in which case you record the statement and its source.

37.8 Screen sizes, foldables and tablets

A phone in portrait is one of many windows an app must fill. The same app runs on a tablet, in a split view beside another app, on a foldable that changes size while in use, and in landscape.

There are three designs.

• Locked. The app runs in portrait at phone size only. On a larger screen it is stretched or shown in a letterbox.
• Stretched. The phone layout fills the wider window. Rows become very long and images very large.
• Adaptive. The layout changes structure at certain widths. A list and its detail screen sit side by side. A tab bar becomes a side rail. A grid gains columns.

An adaptive app must also keep its state across the change. Unfolding a device or rotating it is, on some platforms, a rebuild of the screen. Navigation state, view state and typed input have to survive it. Chapter 9 and Chapter 8 cover the mechanisms. A list and detail pair that becomes two panes also shows how navigation state is modeled. When it is one tree that the layout renders in one or two panes, the selected item stays selected across the change. When the two-pane layout is a separate screen, the selection is lost.

37.9 Probes

Every probe here is a settings change, so run them in the order of least disruption: P37.1, P37.3 and P37.4 first, then the screen reader, then language, region and time zone. Change one setting at a time and restore it before the next. Select the outcome you saw in each probe, and it is recorded in your worksheet for the teardown chosen here.

New teardownOpen worksheet

P37.1 Large text

Do

1. Raise the system text size to its largest ordinary step in the device's display settings.
2. If the accessibility settings offer still larger sizes, try the largest of those as a second run.
3. Open the app's main screens: a list, a detail screen, a form and a settings screen.
4. Try to read every label and reach every control.

Watch

Whether text grows, whether rows grow taller and labels wrap, and whether any text is clipped, overlapped or cut off with no way to read the rest.

Caution. This probe changes a device-wide setting. Every app will redraw with larger text. Restore your usual text size when you finish.

Read

Text grows and the layout reflows, with everything readableObservedThe app uses the system's text styles and flexible layouts. Platform-driven text scaling, carried through.Text grows, and some of it is clipped, overlapped or truncatedObservedSystem text styles on fixed-height layouts. The same screens are likely to break under long translations.Text grows on some screens only, or stops growing earlyInferredUneven adoption, a cap on scaling, or screens drawn by a different path (Chapter 32).Nothing growsObservedFixed font sizes. The app does not read the setting.

Select what you saw to record it in your worksheet. Select it again to clear it.

P37.2 Screen reader task

Do

1. Choose the app's main task, such as sending a message, finding an item or playing something.
2. Turn on the screen reader.
3. Complete the task by swiping from element to element and activating the focused one. Do not look for shortcuts by sight.
4. Note every control with no name, every jump in order, and every place you could not reach.
5. Turn the screen reader off.

Watch

Whether every control is announced with a name and a role, whether list rows are one stop or many, and whether errors and loading results are announced.

Caution. This probe turns on the device's screen reader, which changes how every touch works. Learn the gesture or shortcut that turns it off before you turn it on.

Read

The task completes, and every control has a name and a sensible orderInferredThe team maintains the accessibility structure and tests with a screen reader.The task completes, with unnamed controls or a confusing order on the wayObservedPlatform controls give a baseline for free. Icon buttons and custom controls were not labeled.The task cannot be completedObservedA control on the main path publishes no structure, or focus cannot reach it. A custom control or a drawn surface.

Select what you saw to record it in your worksheet. Select it again to clear it.

P37.3 Dark appearance

Do

1. Open the app, then switch the device between light and dark appearance while the app is in the foreground or just behind the settings screen.
2. Return to the app without restarting it.
3. Visit several screens, including help, terms, checkout and any screen you suspect is web content.
4. Look in the app's own settings for a theme option.

Watch

Whether the app switches at once, whether every screen switches, and whether any text becomes hard to read against its background.

Caution. This probe changes a device-wide setting. Restore your usual appearance when you finish.

Read

Every screen follows the system at onceInferredColors are defined by purpose with a light and a dark value. Platform-driven appearance.The app changes only through its own theme settingObservedApp-driven appearance. The app keeps its own preference and does not read the system's.Most screens switch, and some stay lightInferredThe screens that stay light sit outside the shared color definitions. Often embedded web content or a third-party screen.The app has no dark appearanceObservedFixed colors.

Select what you saw to record it in your worksheet. Select it again to clear it.

P37.4 Reduced motion

Do

1. With the setting off, note the app's large movements. Look at screen transitions, expanding cards, parallax, animated reactions and autoplaying media.
2. Turn on the system's reduced-motion setting.
3. Repeat the same actions.

Watch

Whether large movements are replaced by a fade or removed, and whether autoplay stops.

Caution. This probe changes a device-wide setting. Turn it off again when you finish if you do not normally use it.

Read

Large movements are replaced or removedInferredThe app reads the setting, which implies one central definition of its animations.Only the system's own transitions change, and the app's custom motion staysObservedThe platform's controls adapt by themselves. The app's own animations do not read the setting.Nothing changesObservedThe setting is not read. If the app has almost no motion, this outcome carries no information.

Select what you saw to record it in your worksheet. Select it again to clear it.

P37.5 Switch the language

Do

1. Choose a language the store listing says the app supports.
2. Turn on airplane mode, switch the language, and open the app. Note which text changed.
3. Turn airplane mode off and refresh each screen. Note which further text changed.
4. Trigger an error, such as a failed form, and read its language.
5. Sign out and in again if some text is still in the old language. Check any notification that arrives afterwards.

Watch

Three groups of text. What changed at once offline, what changed after a refresh, and what stayed in the old language.

Caution. This probe changes a language setting. Use the per-app language setting if the device offers one, or the app's own language setting. If you must change the device language, note the path back first and restore it when you finish.

Read

Everything changes, labels at once and content after a refreshInferredBundled text for labels, and backend text keyed to the language the client sends.Labels change, and some sections, errors or notifications stay in the old languageInferredThose parts are backend text keyed to the account's stored language, or text with no translation. The screen is partly composed by the backend.Labels stay in the old language until the app is online, then changeInferredThe string table itself is downloaded from the backend and cached. The team can fix translations without a release.Nothing changesObservedThe app does not ship that language and fell back to its default, or it has its own language setting that overrides the device.

Select what you saw to record it in your worksheet. Select it again to clear it.

P37.6 Right-to-left

Do

1. Check the store listing for a right-to-left language the app supports. If there is none, record that and stop.
2. Switch to that language with the device's language setting or its per-app language setting. If the app has its own language setting, try that as a separate run, since it may change the text without changing the layout direction.
3. Visit the main screens and compare each with a screenshot taken beforehand.
4. Look at the back control, list alignment, arrows and chevrons, progress bars, swipe gestures and screen transitions.

Watch

Whether the whole layout mirrors, and which elements stay on the side they were on.

Caution. This probe changes a language setting to a script you may not read. Use the per-app language setting if the device offers one. Before you start, note the position of each step on the path back to your own language.

Read

Everything mirrors, including navigation, gestures and directional iconsInferredLayouts are declared with leading and trailing edges throughout, and the team tests in a right-to-left language.Text aligns right, and some layout, icons or animations do not mirrorObservedHard-coded directions remain. The screens that fail are usually older, or custom drawn.The app supports no right-to-left languageObservedNot applicable. The app has not entered those markets, which is itself a fact about its reach.

Select what you saw to record it in your worksheet. Select it again to clear it.

P37.7 Change the region

Do

1. Note how the app shows a date, a large number, a price and the first day of the week in any calendar.
2. Change the device's region setting to a country with different formats. Keep the language the same.
3. Open the app and look at the same values. Refresh and look again.
4. Look for any change in currency, catalog or available features.

Watch

Whether formats change, whether they change before or after a refresh, and whether anything beyond formats changes.

Caution. This probe changes a device-wide setting. Change only the region used for formats, not the country of your store account, which can affect purchases and subscriptions. Restore the region when you finish.

Read

Formats change at once, and nothing else doesInferredThe client formats with the platform's formatters. Region rules are keyed to something other than this setting.Formats change only after a refreshInferredThe backend formats values, using the region the client sends.Currency, catalog or features change as wellObservedThe backend trusts the device's region setting for a region rule. A weak basis, since any user can change it.Nothing changesSpeculativeFormats are tied to the language, fixed in the client, or made on the backend from the account. These three cannot be separated by this probe.

Select what you saw to record it in your worksheet. Select it again to clear it.

P37.8 Change the time zone

Do

1. Note the displayed time of three things. Use a past item such as a message or an order, a future event if the app has one, and anything described as today.
2. Turn off automatic time zone and choose a zone at least six hours away.
3. Return to the app without refreshing, and read the same three times.
4. Refresh, and read them again.

Watch

Whether past timestamps shift by the zone difference, whether they shift before or after a refresh, and whether an event at a place keeps its local time and says so.

Caution. This probe changes a device-wide setting. Alarms, calendar entries and other apps follow the new zone while it is set. Restore automatic time zone when you finish.

Read

Past timestamps shift at onceInferredInstants are stored as absolute values and formatted on the client at display time.Past timestamps shift only after a refreshInferredOne of three designs. The backend sends formatted times using the zone the client reports, the client caches formatted strings, or the client formats at display time with a zone that its runtime read at launch. If a restart of the app was the refresh that worked, the third is the likely one.Past timestamps do not shiftSpeculativeTimes are formatted for a zone stored on the account or fixed for the service, or they were saved as local text.

Select what you saw to record it in your worksheet. Select it again to clear it.

P37.9 Rotate or resize

Do

1. Open a list and select an item, or start typing in a form.
2. Rotate the device. On a foldable, unfold it. On a tablet, put the app beside another app and drag the divider.
3. Rotate or fold back.

Watch

Whether the layout changes structure or only stretches, and whether your selection, scroll position and typed text survive each change.

Read

The layout changes structure and keeps your placeInferredAn adaptive layout over one navigation state. State is held outside the views that were rebuilt.The same layout stretches to fill the spaceObservedA phone layout with flexible widths. No separate design for large windows.The app stays in portrait or in a fixed-size windowObservedOrientation and size are locked. The cheapest way to avoid both layout and state work.The layout changes and your selection, position or text is lostInferredThe screen was rebuilt for the new size and its state was not carried over (Chapter 9).

Select what you saw to record it in your worksheet. Select it again to clear it.

P37.10 Read the regional terms

Do

1. Open the app's terms, privacy policy and privacy settings.
2. Look for a named country or governing law, sections addressed to residents of particular regions, and a statement on where data is stored.
3. Look in settings for region-specific controls, such as a data export, a deletion request or a consent manager.
4. Compare with the store listing's list of countries and languages, if it shows one.

Watch

Whether the documents and controls are written for your region specifically, or are one global text.

Read

Documents or controls are specific to your regionInferredThe backend holds legal text and settings per region and has placed your account in one.One global document with sections per regionObservedA single text for all users. Region rules, if any, are applied elsewhere.The maker states where data is storedObservedA published statement. Record its wording and source. It tells you what the maker claims, which is as far as an outside reader can go.

Select what you saw to record it in your worksheet. Select it again to clear it.

37.10 Signal-to-design table

Signal	Design it points to	Confidence
An icon control is announced as button with no name	A control with no accessibility label	Observed
A list row takes several swipes to pass with the screen reader	Row contents published as separate elements with no grouping	Observed
Screen reader focus reaches the screen behind a modal	A modal drawn over content that was not marked inactive	Inferred
Text is clipped or overlaps at large text sizes	System text styles on fixed-height layouts	Inferred
Text grows a little and then stops	A cap on text scaling set by the app	Inferred
One screen stays light when the device is dark	A screen outside the shared color definitions. Often embedded web content or a third-party screen	Inferred
The app's theme changes only through its own setting	App-driven appearance	Observed
Custom animations continue with reduced motion on	Motion defined per screen with no central setting	Inferred
Labels change language at once offline	Bundled text	Inferred
Section titles stay in the old language after a language switch	Backend text in a screen-describing response	Inferred
Error messages stay in the old language	Errors worded by the backend	Inferred
A notification arrives in the old language	Push text composed on the backend from a stored account language	Inferred
A single label is in a different language from the rest of the screen	Per-string fallback to the team's default language	Inferred
An arrow or animation points the wrong way in a right-to-left language	A hard-coded left or right in an otherwise mirrored layout	Observed
A price ignores the device's region format	Prices sent by the backend as finished strings	Inferred
Timestamps do not shift when the time zone changes	Times formatted on the backend or stored as local text	Speculative
A date of birth or due date shows one day early	A calendar date stored as an instant	Inferred
Selection or typed text is lost on rotation or unfolding	State held in views that are rebuilt on a size change	Inferred

Search the signals from every chapter in the signal lookup.

37.11 The backend this implies

• Bundled text only. Nothing. The backend sends identifiers and numbers, and the client words them.
• Backend text. A store of text per language, a rule for choosing the language of a response, and a fallback when a translation is missing. If the choice comes from the request, every cache between client and backend must keep languages apart, or one user receives another’s language (Chapter 11).
• Notifications in the user’s language. The backend stores a language per account or per device, updated when the client reports a change. A notification in the old language after a switch shows that the stored value was not updated.
• Formats made on the backend. The backend knows the user’s region and time zone, and formats with them. This suits text that leaves the app, such as email and notifications. Inside the app it produces values that ignore device settings.
• Times. Instants are stored in one global reference and formatted late. Times at a place are stored with the place’s zone. The backend needs both types, and an API that says which is which.
• Region rules. A service that maps an account or a request to a region, and a table of what each region allows. It is evaluated on the backend for every request that matters, since the client’s claim cannot be trusted.
• Regional storage. Possibly a backend store per region with routing in the gateway. Speculative from outside.

37.12 Failure modes and what they reveal

• A button announced only as “button”. An icon control with no label. Nobody on the team ran the screen reader on that screen.
• Screen reader focus moves into the screen behind a modal. The modal is drawn over the screen without telling the platform that the content under it is inactive.
• Clipped or overlapping text at large sizes. Fixed-height layouts. The same screens will break under long translations.
• One light screen in a dark app. A screen from another drawing path or another team, outside the shared color definitions.
• One label in another language. A string added after the last translation pass, resolved by fallback to the team’s default language.
• Section titles or errors in the old language after a switch. Backend text, keyed to the account or cached.
• A sentence with its parts in the wrong order. A message assembled from fragments in code.
• An arrow pointing the wrong way in a right-to-left language. A hard-coded direction in a layout or an image that was not marked for mirroring.
• A price that ignores the device’s region format. The backend sends prices as finished strings.
• A birthday or due date one day off. A calendar date stored as an instant and shifted by a time zone.
• An event shown at the wrong hour after travel. A time at a place converted to the device’s zone.
• A streak lost on a flight. The day boundary follows the device’s zone, or a zone the user was not told about.
• A lost selection or cleared form after unfolding. The screen was rebuilt for the new size and its state was not carried over.

37.13 Worksheet entries

These are the fields this chapter adds to the teardown worksheet. Probe outcomes fill some of them in. Fill the free-text fields with the places where two sources of text or format disagreed.

New teardownOpen worksheet

Touch targets that are too small or too closeText that comes from the backendTimes at a place and day boundariesFeatures that differ by regionRegional data storage claim and its confidenceFailure modes seen

37.14 Summary

• Every adaptation is decided by one of four parties: nobody, the platform, the app or the backend. An app sits on a different rung for each adaptation.
• Screen reader support is a published structure of labels, order, grouping and roles. Custom controls and icon buttons are where it fails.
• Text scaling has three steps: text grows, layout survives, nothing is lost. A layout that fails at large text will fail under translation.
• Switching the device language separates bundled text from backend text. What stays in the old language maps the backend’s share of the screen.
• Language, region and time zone are independent inputs. Changing one at a time shows where formats are made and what timestamps really are.
• Region rules are backend decisions keyed to a signal the user cannot easily change. Only the device’s region setting can be probed safely.
• Where data is stored by region leaves no reliable signature. Mark it Speculative, or cite what the maker published.
• Rotation, resizing and unfolding test both the layout and the survival of state across a rebuild.