Eli Lambez, Founder of WEB-A

The short answer: an accessible mobile app works with the phone’s screen reader (VoiceOver on iOS, TalkBack on Android), with large text settings and with alternatives to complex gestures. The essentials are clear labels on every control, a logical focus order, touch targets of at least 44 by 44 points, good contrast, text that scales, and forms that explain errors.

One thing I tell every product team before we start: in apps there is no magic layer. On websites people still try floating accessibility widgets. In a native or cross-platform app there is nothing you can install that makes it accessible with one click. Accessibility lives in the code, the UX and the app logic, or it is not there at all.

The good news is that most of the issues we find in our app audits come back to the same short list. Use this checklist with your designers, developers and QA team, from the first wireframe to every release.

1. Labels and roles

In our app audits, the most common blocker is still the simplest one: a button or icon with no accessible name. For a screen reader user, that screen is simply blank or broken.

• Every button, icon and image that does something has an accessible name (accessibilityLabel on iOS, contentDescription on Android).
• Icon-only buttons say what they do: “Search”, not “Magnifier”.
• Decorative images are hidden from the screen reader.
• Custom controls expose the right role (button, switch, tab) and state (selected, expanded, off).

2. Focus order and navigation

• Swiping through the screen moves in a logical reading order.
• When a dialog or bottom sheet opens, focus moves into it, and returns to the trigger when it closes.
• Headings are marked as headings so screen reader users can jump between sections.
• Nothing traps focus.
• Content that changes on its own is announced, so the user knows the screen has changed.

3. Touch targets and gestures

• Targets are at least 44 x 44 points on iOS and 48 x 48 dp on Android, with space between them.
• Every swipe, drag, pinch or long press has a simple alternative, such as a button.
• Nothing depends on shaking or tilting the device alone.

4. Color and contrast

• Text contrast is at least 4.5:1, and 3:1 for large text and key icons.
• Color is never the only signal. An error has text or an icon too.
• The app works in dark mode without losing contrast.

5. Text size and layout

• Text follows the system font size (Dynamic Type on iOS, sp units on Android).
• At the largest sizes text wraps instead of being cut off.
• The app works in both portrait and landscape unless one orientation is essential.

When we work with UI and UX designers, the goal is to support dynamic text and proper contrast without hurting the look of the brand. It is almost always possible when it is planned in the design system.

6. Forms and errors

Sign up, login and checkout forms are where we see users get stuck most often. A typical case: the error message appears on screen, but the screen reader never reads it, so the user has no idea why the form will not submit.

• Every field has a visible label that stays after the user starts typing.
• Errors say what went wrong and how to fix it, and are announced to the screen reader.
• Use the right keyboard type for email, phone and numbers.

7. Media and motion

• Videos have captions; audio has a transcript.
• Animations respect the “Reduce motion” setting.
• Content does not auto-play with sound.

8. Test it like a user

We test apps on physical devices, on both iOS and Android, with the screen reader turned on, exactly the way a blind user or a user with a motor disability would use them. We compare what is shown on screen with what is actually heard. That gap is where most problems hide.

• Run through the main journeys with VoiceOver and TalkBack turned on: sign up, login, search, purchase, contact.
• Repeat at the largest text size and with an external keyboard.
• Use the platform tools (Accessibility Inspector in Xcode, Accessibility Scanner on Android) as a first pass, then test by hand.

Automated tools catch part of the issues. The rest shows up only when a person uses the app the way a screen reader user does. When possible, we also include testing by users with disabilities on their own devices, with their own assistive technology. It is not always required, but it saves surprises after launch.

A note on AI-generated code

Many teams now build screens and even whole apps with AI tools. The code looks great and the interface runs smoothly, but in our experience the AI almost always forgets accessibility. We see missing labels and hints, broken focus order, system messages that are not read aloud (especially in Hebrew apps) and contrast that does not meet the standard. Fast development still needs a real accessibility check.

Where to start if your app is already live

My recommendation is always the same: plan accessibility before development, not after. It is much easier to adjust screens, menus and content in a new app than in one that is already in the stores.

If your app is already live, do not jump straight into fixes without knowing what is actually broken. Start with the journeys that matter most to your business and your users, find the critical blockers there, then work through the rest screen by screen. Add the checklist to your design review and your definition of done so new features stay accessible, and keep checking after version updates instead of waiting for things to break.

A developer knows how to implement the fixes, but usually cannot spot every gap and check it against the standard alone. The process works best as a partnership between an experienced developer and an accessibility consultant.

Our experts have tested and fixed native and hybrid apps for 9+ years. See our app accessibility services or read Apple’s Human Interface Guidelines on accessibility.

FAQ

Which standard applies to mobile apps?

WCAG 2.1 and 2.2 at level AA are the common reference for apps as well as websites. In the EU, EN 301 549 applies to apps, and in Israel IS 5568 is based on WCAG. Either way, the app needs to be accessible on both iOS and Android.

Do cross-platform apps (React Native, Flutter) need special care?

Yes. Native and cross-platform apps talk directly to the operating system’s accessibility layer. Both frameworks support accessibility, but labels, roles and focus need to be set deliberately and tested on each platform.

How often should we test app accessibility?

Before every major release, and whenever you add a new flow. A short screen reader pass in each QA cycle prevents most regressions.

The short answer: an accessible document is one that a screen reader, a keyboard user or someone with low vision can read from start to finish without help. In practice that comes down to seven habits: real headings, plain language, alt text for images, readable fonts and contrast, simple tables, built-in lists, and descriptive links. Then you run the built-in checker before you share the file.

Clients and colleagues ask me the same question every few weeks: “How do I actually make a document accessible?” This guide is my answer. It is the checklist our team has refined over 9+ years of accessibility work, written for content teams, marketers, website managers and anyone who publishes files online.

A bonus most people miss: accessible documents are also clearer documents. They are easier to scan, easier to search and easier to reuse.

Who this guide is for

• Website managers and content editors who upload files to a site
• Marketing and SEO teams producing brochures, reports and white papers
• HR, finance and legal teams sharing forms and policies
• Business owners who want their content to reach every customer

1. Structure the document with real headings

Screen reader users jump between headings the way sighted readers skim. That only works when headings are built with styles, not just bold text.

• Heading 1: used once, for the document title.
• Heading 2: the main sections.
• Heading 3 and below: subsections inside a section. Do not skip levels.

In Word: select the text, then choose a heading in Home > Styles. Open View > Navigation Pane to see your outline the way a screen reader will.

2. Write in plain, clear language

Plain language helps everyone, including people with cognitive disabilities, readers in their second language and busy managers.

• Keep sentences short, ideally under 25 words.
• If a sentence must be long, keep it to three key facts or fewer.
• Use the active voice: “We will schedule your visit” instead of “Your visit will be scheduled.”
• Spell out abbreviations the first time and avoid slang.

3. Use images that add meaning, and describe them

A good diagram can make a complex idea easier to follow. Two rules make it accessible:

• Add alt text. Right-click the image > View Alt Text. Describe what the image shows and why it matters. Mark purely decorative images as decorative.
• Place images in line with the text, usually after the paragraph they support. Avoid text wrapping around images, which breaks the reading order.

An image supports the content. It never replaces it. Anything important in a chart should also appear in the text.

4. Choose readable fonts, sizes and contrast

Fonts

There is no single “accessible font”, but clear sans-serif fonts such as Arial, Calibri or Verdana work well. Avoid thin, light or condensed fonts that blur for readers with low vision.

Size and spacing

• Use 12 pt as the minimum for body text, and make headings visibly larger.
• Leave space between paragraphs. Crowded pages are hard to follow.
• Offer a large-print version on request.

Emphasis and contrast

• Emphasize with bold, not underline or italics. Underline looks like a link.
• Keep text-to-background contrast at 4.5:1 or higher (WCAG AA). Dark text on a white background is the safest choice.
• Do not use color alone to convey meaning.
• Set the correct document language and text direction (for Hebrew or Arabic, right to left) so the screen reader reads in the right order and voice.

5. Keep tables simple, and only for data

Use a table when you are really comparing data, such as a schedule or a price list, not to lay out the page.

• Mark the header row: Table Design > Header Row, and Table Properties > Row > “Repeat as header row”.
• Avoid merged or split cells and empty rows or columns.
• Keep tables as real text, never as a picture of a table.
• For complex data, add a short text summary next to the table.

6. Use built-in lists

When a list is created with the Bullets or Numbering buttons, the screen reader announces “list, 5 items” and tells the reader where they are. Typed dashes or numbers do not do this.

7. Write descriptive links

“Click here” tells a screen reader user nothing when links are read out of context. Make the link text describe the destination, for example “WEB-A document accessibility services”. In Word, select the text, press Ctrl+K and add a ScreenTip if more context helps.

8. Check the document before you share it

In Word: Review > Check Accessibility. The checker lists errors and warnings, explains why each one matters and shows how to fix it. Keep it open while you work. Microsoft’s guide, Make your Word documents accessible to people with disabilities, walks through the same checks.

Exporting to PDF: File > Save As > PDF > Options, and make sure “Document structure tags for accessibility” is checked. Then check the PDF itself in Adobe Acrobat (Accessibility Check). A tagged PDF built from an accessible Word file needs far less fixing. For the PDF-side checklist, see our PDF accessibility rules.

Automated checkers catch only part of the issues. For important documents, our experts also test with a real screen reader.

Quick checklist

• One Heading 1, logical H2/H3 structure
• Short sentences, active voice
• Alt text on every meaningful image
• Sans-serif font, 12 pt+, contrast 4.5:1+
• Document language and direction set
• Simple tables with header rows
• Built-in bulleted and numbered lists
• Descriptive link text
• Accessibility Checker passed, tagged PDF exported

Need a hand with your documents?

For 9+ years our experts have made websites, apps and documents accessible by hand, tested with real assistive technology. If you have a backlog of Word files or PDFs, or want your team trained to create them right the first time, talk to our document accessibility team.

FAQ