Mobile app accessibility: turnkey audit and remediation

Why mobile app accessibility breaks during updates

Mobile app accessibility doesn't break at launch, but at the third or fourth iteration. A new screen is added for a specific task and rushed: an icon is drawn without a label, a toggle is assembled from ready-made layers, a pop-up panel is placed over the main content.

Screen readers either skip such elements or announce them generically — "button," "element" — and the person doesn't understand what will happen after the tap.

Inaccessible controls are almost always in the same place: where business logic requires a minimum of actions.

A custom slider doesn't respond to press-and-hold control gestures, a masked field accepts input only from the on-screen keyboard, and the cart icon on a product card is read as a decorative image.

For screen reader users, this is not a minor issue but a dead end: the action exists visually, but is unreachable by ear and by touch.

A broken focus order is noticeable only during sequential traversal. A modal opens, but traversal continues through the dimmed content underneath, and after closing, focus flies to the top of the screen — and the person has to find again where they stopped.

Move blocks around during a redesign, and the reading logic diverges from the visual: the screen reader follows the meaning from the previous version, and the hint plays before the heading.

Large system font and increased contrast finish off the scenario: labels get clipped, text goes under a button, required fields aren't highlighted. An abandoned scenario — that's the real cost.

The share of unfinished checkouts grows, more "can't tap" requests come in, and the app store lowers the app in search rankings based on accessibility criteria. Let's break down how this is addressed.

Screen readers, large font, and contrast: what an update delivers

Accessibility work is measured not by the number of markup fixes, but by how many scenarios a person completes independently. Below are three areas, and for each we record the metric before and after.

Screen reader support

Every interactive element is assigned a meaningful description and role, and traversal order is built according to screen logic, not markup order.

Result: the share of scenarios completed by a blind user without outside assistance grows from single-digit percentages to most key paths — login, payment, booking.

System font scaling and high-contrast mode

The layout stops breaking with enlarged font: text wraps, buttons grow, nothing gets clipped or overlaps. At the same time, contrast is checked — an element's state is read by brightness and shape, not only by color. The failure class "label ran past the button boundary" disappears entirely.

Switch control

Scenarios become passable without precise touches: focus traverses all elements, order is predictable, external switches and voice control carry the action through to completion. This removes another layer of failures — "can't reach the element."

The closing effect is fewer support requests: complaints like "can't see the button," "the font clipped the text," "can't tap" stop reaching the front line, while the product itself doesn't change.

Implementation options: markup fixes vs. navigation rework

Accessibility rests on two layers. The first is semantic markup: labels for elements, their roles, focus traversal order, and announcing changes on screen. The second is navigation: screen structure, logic of transitions and returns. The scope of work depends on which layer is degraded and at what stage the product is.

Semantic markup fixes are the shortest cycle: screens and scenarios stay the same; attributes and label texts change. Navigation rework affects structure, so it requires coordination with design and a full regression.

Automated checks show only part of the picture: they find elements without labels and broken contrast, but they don't tell you whether the scenario is understandable by ear — screen reader modes still have to be checked manually.

It makes sense to include automated checks in the build pipeline for any of these options: they're inexpensive, catch regressions, and keep markup from "overgrowing" as new screens are added.

But an automated check report can't be considered acceptance — it covers form, not scenario. The final criterion is one: a person completes the main path with the screen reader on and stays within a reasonable time.

Work stages: audit, screen traversal map, configuration, verification

Accessibility can't be checked "by eye" — it is assembled sequentially. First we record the current state, then build a map of screens, and only after that change markup and settings. This way fixes don't scatter across releases and don't break already working scenarios.

1. Accessibility audit. We run key scenarios with the screen reader on, check contrast, touch target sizes, labels, and response to system font scaling. We record each defect tied to a screen and a reproduction step.
2. WCAG requirements review. We choose the target level and group discrepancies: semantics, navigation, alternative texts, resilience to large font and disabled animation.
3. Screen map and traversal order. We describe the transition tree and mark places where focus is lost, loops, or ends up in a dead end after a modal closes.
4. Element descriptions. We assign roles, states, and labels for buttons, fields, images, and dynamic blocks; we make state-change announcements explicit.
5. Focus configuration. We set reading priority, focus trapping in modals, and correct return to the source element.
6. Verification on device. We go through the same scenarios with the screen reader, large font, and external keyboard, compare the result with the screen map, and close discrepancies.
7. Handover. We provide the screen map, element description rules, and accessibility verification procedure in the release cycle — new screens are immediately built by the same rules.

Handover: markup, element descriptions, procedure

We hand over the package together with the source code: the client's team can change the interface further without losing the markup.

The materials are intended for a developer and tester without specialized accessibility training — they are not excerpts from a standard, but working instructions with specific values.

• Navigation scheme and focus order. A screen map with screen reader traversal order: where focus is set manually, which overlay layers capture it, and how they return it.
• Element descriptions. A "component → label, role, hint" table for all repeating blocks: buttons, fields, switches, loading states. Separately — rules for dynamic lists, so the screen reader doesn't reread the entire list after every update.
• Contrast and scaling rules. Threshold ratios for text and icons, behavior under maximum system font enlargement, values for dark theme.
• Verification procedure. What is run before each release: manual scenarios with the screen reader and enlarged font, plus automated rules in the build that stop it when a label is lost.
• Instructions for the development team. Where to add a description and how to name an element so it enters the traversal; which interface changes require updating the description table.
• Instructions for testers. A set of scenarios with expected announcement order and a defect report template — reproducibility instead of "the screen reader reads something incomprehensible."

Case study: what changed after navigation and markup rework

The client came with a problem that at first glance didn't look technical: the share of completed checkout scenarios held around 60%, and support received a stream of identical requests — "can't find the button," "announcement doesn't read the field," "can't go back a step." Reviews in app stores repeated the same: the interface works only for those who see the screen and confidently hit a small element with their finger.

What the analysis showed

Our engineers went through all key screens for purchasing, payment, and delivery tracking with an audit according to Web Content Accessibility Guidelines.

They found three classes of defects: labels weren't associated with the fields themselves, element traversal order didn't match the visual order, and touch targets were smaller than the comfortable minimum. Because of this, users lost context midway through the scenario and closed the app.

What was changed

We reworked navigation and markup: elements got correct names and roles, focus followed a logical order, touch targets were enlarged, and icons without text got descriptions.

We separately rewrote return and order confirmation — when the app was minimized, the step and entered data were lost.

What the result was

The share of completed scenarios grew from 61% to 88%, and support requests about navigation dropped by 2.4 times. The share of users with a screen access program rose from 4% to 11% — some of them simply hadn't reached payment before.

In reviews, the wording shifted: instead of "nothing is clear," more often "everything is found on the first try."

Metrics were verified against product analytics and support request exports for comparable periods, not by the team's feelings — the data source is documented in the project report.

What to do if accessibility wasn't built into the design from the start?

What to do if accessibility wasn't considered in the mockups: a finished product doesn't need to be rewritten entirely.

Most problems lie not in the visual layer but in markup — elements have no labels for the screen reader, icons have no alternative text, focus traverses the screen in random order, and button state isn't announced.

Such fixes don't change the appearance by a single pixel, so they can be shipped in a separate release without waiting for a redesign.

Next, screen priority is determined by analytics, not by menu position. Login, account recovery, the key scenario, and payment come first — where inaccessibility completely blocks the user.

A screen with a form and validation is more important than a decorative feed: an input error must be read aloud by the screen reader, not silently highlighted in red.

Phased implementation is structured so that each step is self-contained. Semantic fixes don't touch data exchange contracts and don't break layout, so backward compatibility is preserved, and an unsuccessful release can be rolled back without consequences for other screens.

Visual changes — font scalability, contrast, touch target size — come second, when the non-visual layer is already covered and the product has stopped losing users on basic actions.

So that one-off fixes don't dissolve in subsequent sprints, markup requirements are moved into the design system and into automated checks at build time: new screens pass the same rules without manual control.

After two or three cycles, accessibility stops being a separate task and becomes a default property of the product.

Technical concerns: scope of fixes, timelines, release risks

Concerns about accessibility are usually not about the technology itself, but about how the fixes will fit into the release cycle.

Below are answers to common questions at the start: scope of work, compatibility with the build, verification timelines, and risks to the upcoming release.

Will the updates break the current release?

Fixes go in a separate branch and are enabled by remote configuration, not for everyone at once. The build can be released in its previous form, accessibility can be opened to a subset of users, and coverage can be expanded after the result is confirmed. If a regression appears, the configuration is turned off without a new build.

How long does it take and how is it verified?

The timeline depends on the number of screens and their condition: standard lists and forms are fixed quickly; customizable charts and custom controls are handled separately. The first pass through key scenarios takes weeks.

We verify with manual traversal using a screen reader on real devices, a checklist for key paths, and automated tests for contrast and target size.

How are roles distributed within the team?

We handle markup, verification, and screen reporting; your team agrees on priority and ships the build in its own cycle. On your side, one person who knows the product and confirms scenarios is enough.

Let's discuss the task and come back with an estimate and work plan

Analyzing the task takes one 30–40 minute conversation: the engineer goes through your scenarios — login, payment, checkout, support — and notes where the interface loses users with screen access programs, large system font, or external keyboard control.

As a result, you receive not general words, but a screen map with priorities and an estimate of effort for each block.

To make the analysis substantive, it's enough to send this to start:

• a list of platforms and current OS branches you support;
• a list of key scenarios and screens where users most often drop off;
• reports from previous checks, support requests, or screenshots of problem areas;
• access to a test build or mockups — with an account and test data;
• the target level of compliance with accessibility guidelines (WCAG) and the list of screens included in it;
• deadlines by which the result is needed, and who on your side accepts the work.

In response, you receive an estimate and plan: scope of work by stage, start order, team roles, verification points, and the format of the result report. If some materials are under a non-disclosure agreement, we sign it before transferring access. Describe the task — we'll come back with an estimate and work plan.