Blog

Product team reviewing mobile app accessibility on phones and a laptop
Meeting WCAG 2.2 and Section 508 in mobile apps.
Share this blog
Accessibility

Mobile App Accessibility: Meeting WCAG 2.2 and Section 508 Standards

People use screen readers, voice control, and larger text settings on their phones every day. As a result, mobile app accessibility decides whether those users can finish a task or give up on your app.

For teams selling to US federal agencies, the stakes are higher. Section 508 sets accessibility requirements for the software those agencies buy, and that includes native mobile apps. This guide explains what Section 508 and WCAG 2.2 expect from an app. It also shows how to test for it before release.

Person using a smartphone with earbuds to test mobile app accessibility

Mobile app accessibility starts with testing on a real device.

What Section 508 and WCAG 2.2 Mean for Mobile App Accessibility

Section 508 is the US law that requires federal agencies to buy accessible information and communication technology. Its technical standards incorporate WCAG 2.0 Level AA. They apply to web content and to other electronic content, such as software and native mobile apps.

WCAG 2.2 is the newer version. According to the W3C’s overview of WCAG 2.2, it adds nine success criteria and removes one obsolete one. Because it extends the older version, designing to WCAG 2.2 Level AA puts a team in a strong position. However, a buyer may still ask for a report against the exact criteria the contract names.

One more point matters here. WCAG was written for the web, so teams apply it to apps by interpretation. The W3C publishes guidance for this, known as WCAG2ICT, which explains how each criterion applies to non-web software.

In practice, federal buyers usually ask vendors for an Accessibility Conformance Report. Many teams write it on the VPAT template. Testing against the criteria below also gives you the evidence to fill it in honestly.

Six WCAG 2.2 Criteria That Shape Mobile App Accessibility

WCAG 2.2 added nine criteria. However, these six have the most direct effect on how a phone app is designed.

1
2.5.8 Target Size (Minimum) · Level AA

Tap targets need at least 24 by 24 CSS pixels, or enough spacing around them. On a phone, aim higher. Apple’s guidelines suggest 44 points, and Google’s Material guidance suggests 48 dp.

2
2.5.7 Dragging Movements · Level AA

Any action that needs a drag must also work with a single tap. For example, a reorderable list needs up and down buttons, not only a drag handle.

3
3.3.8 Accessible Authentication (Minimum) · Level AA

Login cannot depend on memorizing, transcribing, or solving a puzzle unless an alternative exists. Let people paste passwords, use a password manager, or sign in with biometrics.

4
3.3.7 Redundant Entry · Level A

Do not ask people to retype information they already gave in the same process. Pre-fill the shipping address from the billing address, for instance.

5
2.4.11 Focus Not Obscured (Minimum) · Level AA

A focused control cannot be fully hidden behind other content. On a phone, the on-screen keyboard or a sticky bottom bar often covers the active field.

6
3.2.6 Consistent Help · Level A

Help options, such as a support link or chat button, should appear in the same place on every screen where they are offered.

Where Mobile App Accessibility Usually Breaks

Most failures come from a short list of habits. For example, reviewers see the same five problems again and again.

  • Unlabeled icon buttons. A screen reader announces “button” and nothing else, so the user cannot tell what it does.
  • Custom gestures with no alternative. Swipe-to-delete works only for people who can swipe.
  • Text that does not scale. Fixed font sizes ignore the system text-size setting, and layouts clip when text grows.
  • Low contrast and color-only cues. A red or green status with no icon or label fails users with color blindness.
  • Video without captions. Captions start with an accurate transcript, which our guide to audio and video transcription explains.

Build Mobile App Accessibility Into Every Sprint

Accessibility usually costs the least when it starts at design. For that reason, treat it as part of every sprint, not as a final audit.

  • Design. Check contrast, target sizes, and focus order in the mockups before any code exists.
  • Build. Use native components where possible, because they ship with built-in accessibility support. Also add labels, roles, and states to every custom control.
  • Test. Run the routine below on every build. In addition, add automated checks to your pipeline for the easy catches.
  • Release. Record what you tested and what remains open. That record feeds your conformance report, and it shows buyers you take the standard seriously.

A Pre-Release Test Routine for Mobile App Accessibility

You do not need a lab to catch the biggest problems. Instead, run this routine on a real device before every release.

Turn on VoiceOver (iOS) or TalkBack (Android) and finish the main task without looking at the screen.
Set the system text size to its largest option and check that nothing clips or overlaps.
Rotate the device and confirm the app works in both orientations.
Check that every icon-only control has a spoken label.
Move through the key flows with an external keyboard or switch control.
Review color contrast, and make sure no state depends on color alone.
Play every video with captions on and confirm they match the audio.

Automated scanners help, but they catch only part of the problems. Manual testing with real assistive technology finds the rest.

Mobile App Accessibility Across Languages

An app that works well in one language can break in another. German labels run longer and may clip. Right-to-left languages mirror the layout. Screen readers also need the correct language tag to pronounce text properly. Likewise, translated apps must translate the spoken labels on icons and images.

Plan for this early. Build layouts that grow with the text, and keep words out of images. Then review each translated version with a screen reader. Our guides to accessible-by-design localization and the software localization checklist cover the process in more detail.

Building an app for federal or global users?

Our team can help you localize and review your app content so it stays accessible in every language.

Talk to Our Team

Related

Blogs

Professional reviewing document accessibility compliance checklist
Translationary's approach: catch the cost before it becomes a claim
Accessibility

The Real Cost of Inaccessible Documents

In 2025, plaintiffs filed 3,117 website accessibility lawsuits in U.S. federal court — a 27% jump from the year before, and the highest total in three years. Add in state court filings, and the total climbs past 5,000. Nearly half of those cases targeted a repeat defendant — a company already sued once before for the same kind of problem. Most of that litigation traces back to something quietly unglamorous: a PDF without proper tags, a form with no field labels, a document that a screen reader simply can't parse correctly. The cost of inaccessible documents rarely shows up as one dramatic failure. It shows up as a slow accumulation of legal exposure, lost readers, and rework — most of it avoidable at a fraction of the eventual cost. We found a similar pattern when we looked at the real cost of poor localization. Understanding where that cost actually comes from is the first step toward keeping it small. The Legal Cost Is Rising, and It's Not Just Large Companies Web and document accessibility litigation has more than tripled since 2017, according to Seyfarth Shaw's annual tracking of ADA Title III filings. Website accessibility cases alone made up 36% of…
October 2, 2026
Team collaborating on accessible multilingual content with UI overlay icons
Translationary's approach: building accessibility and localization as one
Accessibility
Compliance
Localization

Accessible by Design: Building WCAG Compliance Into Localization from Day One

Most teams treat accessibility and localization as two separate projects, run by two different teams, on two different timelines. One group makes sure the product works with a screen reader. Another group makes sure it reads correctly in Spanish, German, and Japanese. They rarely talk to each other — and that's exactly backwards, because accessible localization isn't two problems solved twice. It's one problem, solved once, if you plan for it that way. Why These Are Actually the Same Problem Both accessibility and localization ask the same underlying question: can everyone actually use this, regardless of how they access it? A screen reader user and a non-English-speaking user hit strikingly similar walls when a product lacks flexibility. The same root cause usually explains both: the interface bakes content in directly, instead of pulling it from a structured, adaptable source. Picture a support page with a well-written FAQ. The English version has clean heading structure, proper alt text on screenshots, and good color contrast — it passes an accessibility audit easily. Then the team translates the page into Japanese, and nobody re-checks it. The accessibility work already happened once, so nobody thinks it needs to happen again. But the heading structure…
September 8, 2026
PDF accessibility remediation service — transforming inaccessible documents into WCAG compliant accessible files
Accessibility
Localization

From PDF to Fully Accessible: What the Process Looks Like Step by Step

Accessibility isn't just a technical checkbox — it's a language in itself. Here's how professional PDF remediation works, and why getting it right matters for every audience you serve. PDF accessibility remediation is the process every organization needs — yet few fully understand. Imagine spending weeks crafting a perfectly translated annual report, a multilingual compliance brief, or a localized product manual, only to discover that someone using a screen reader cannot access a single word of it. That gap between a well-translated document and a truly accessible one is, in fact, more common than most organizations realize. In this guide, we walk you through the exact steps involved in PDF accessibility remediation — taking a document from its raw, often inaccessible state to one that meets WCAG 2.1 and Section 508 standards. Moreover, we explain why each step is more nuanced than it looks, and why language expertise sits at the heart of the process. 1.3B People living with a disability worldwide 71% Of users with disabilities will leave an inaccessible site 96% Of top websites have detectable accessibility failures "A document isn't truly translated until every person — regardless of how they read — can access it." Why Most…
May 14, 2026