Testing mobile apps by method
Different accessibility issues are found in different ways. This guide organises our accessibility rules by testing method, so your team understands how issues are actually discovered as part of a structured testing process.
Two ways to test
Accessibility testing combines automated and manual testing. Each method finds different types of accessibility issues, so both are needed to achieve good coverage.
-
Automated testing
Explore automated rules →Scans the accessibility layer of the app and checks technical accessibility requirements automatically.
- Fast and repeatable
- Runs locally and in CI/CD
- Detects technical implementation issues
-
Manual testing
Practical guide to manual testing →Verifies how people experience the app using assistive technologies and accessibility settings.
- Tests real user experience
- Uses assistive technologies
- Finds usability issues automation misses
01 — Automated testing
Abra Desktop analyses the accessibility layer of your app — the information exposed to assistive technologies. Because this information is available programmatically, automated testing detects implementation issues that are difficult or impossible to identify through manual testing alone.
-
Some accessibility issues are only visible in the accessibility layer
Explore Abra snapshot →Manual testing verifies how an app behaves when used with assistive technologies. Automated testing verifies how accessibility is implemented in the accessibility layer. An element may appear correct during manual testing while still exposing incorrect accessibility information.
-
Automated Abra rules
Explore all Abra automated rules →40+ accessibility checks combined into 13 automated rules.
- Focusable element name, role, value and state (present & correct)
- Language of the app
- Target size (minimum & enhanced)
- Portrait and landscape orientation
-
Benefits of automated testing
Explore Abra Desktop →Automated testing helps maintain accessibility throughout development.
- Detects approximately 20–40% of accessibility issues
- Finds technical implementation issues early
- Runs locally and in CI/CD
- Helps prevent accessibility regressions
02 — Manual testing
Guidelines such as WCAG and EN 301 549 define requirements through success criteria. Based on these guidelines and our audit experience, Abra has translated the success criteria into practical tests for mobile apps. The criteria address the needs of different groups of users — people without vision or with low vision, hearing impairments, physical constraints, speech limitations, or cognitive disabilities. Manual testing verifies whether the app works under these conditions, using several methods:
-
Visual checks
Issues you can find by looking at each screen carefully.
- Visual inspection
- Contrast checker
-
Accessibility settings & assistive technologies
Issues that only appear when the app is used the way real users use it.
- Text scaling
- Screen reader
- External keyboard
Visual inspection
Some issues are visible without any tooling: go through each screen and check how information is presented, how time limits behave, and what happens when something goes wrong.
Checklist
- Color of the element is not the only way to convey information
- Color of keyboard focus is not the only way to convey information
- Multimedia is accessible
- The time limits for completing tasks is adjustable
- All the time-limited content can be paused, stopped, or extended
- Moving, blinking or scrolling content can be paused, stopped or hidden
- Error messages are announced in text and describe what went wrong, where, and how to fix it
- Target size is sufficiently large
Contrast checker
This category focuses on how color is used in the interface — both for text and interactive elements. It affects users with low vision, color blindness, or those using the app in bright light. If contrast is too low, users may miss information or not be able to interact with the app at all.
-
How to test
Contrast is measured between foreground and background colors:
- Make a screenshot of the screen you are testing
- Pick the foreground and background color and test the pair with a tool like the WebAIM Contrast Checker
- Test in the states that change colors too: focused, selected, disabled
- Only meaningful information needs sufficient contrast — duplicate or decorative elements have no contrast requirements
-
Checklist
Text scaling
As many as 1 in 3 users have opted for a larger text size. Text in apps must support scaling to at least 200% — all characters must scale and remain fully visible. Every screen therefore needs a ScrollView to allow scrolling.
-
Set up text scaling
Called Dynamic Type on iOS and Font/Display Size on Android.
- Android: Settings → Accessibility → Visibility Enhancements → Text Size
- iOS: Settings → Accessibility → Display & Text Size → Larger Text
- Tip: add Larger Text to Control Center on iOS
- Tip: long-press gestures are a valid alternative where scaling is not possible, e.g. the navigation bar or tab bar
-
Checklist
Screen reader
A screen reader reads out everything displayed on the screen, so apps can be used without sight. Navigation happens through gestures. The screen reader is needed to find many of the possible accessibility issues. It is called VoiceOver on iOS and TalkBack on Android.
-
Basic gestures
Practice gestures →- Swipe left / right — previous / next element
- Double-tap — activate the focused element
- Touch anywhere — read what is under your finger
- Scroll — 3 fingers on iOS, 2 fingers on Android
- Exit / back — 2-finger Z-shape on iOS; swipe down, then left on Android
-
Set up TalkBack (Android)
TalkBack explained →- Activate: Settings → Accessibility → TalkBack
- Subtitles: Advanced settings → Developer settings → Display speech output
- Navigation: swipe up or down with 3 fingers
- Tip: add a shortcut to activate TalkBack
-
Set up VoiceOver (iOS)
VoiceOver explained →- Activate: Settings → Accessibility → VoiceOver
- Subtitles: directly on the VoiceOver screen
- Navigation: turn with 2 fingers to use the rotor
- Tip: add an Accessibility Shortcut to activate VoiceOver
-
Checklist - Images
- Text is presented as plain text, not as an image of text
- Images are marked up as images in the code
- Meaningful non-text content has a correct label
- The label of meaningful non-text content clearly, accurately, and fully describes its meaning
- Decorative non-text content is hidden from assistive technologies
- Maps and complex graphics have a text alternative
-
Checklist - Text
-
Checklist - Interactive elements
- Accessible name matches or includes the visible label
- The input field should have a label visible
- Name describes the element's purpose
- Role reflects what it is and how it behaves
- State reflects its current condition (selected, disabled)
- Value is exposed where needed (slider position, selected option)
Checklist - General
- The status message is announced by assistive technologies
- The status messages should not receive focus automatically without user interaction
- All the meaningful elements should be focusable
- All the meaningful elements on the screen should be included in the screen reader focus order
- The screen reader focus should start on the first element on the screen
- The focus goes directly to the next visible element with each swipe
- The reading order of elements announced by assistive technologies matches the visual order
- The elements that belong together are presented together
- The related elements should be properly linked
- The sequence of events in a timeline or steps in a process is conveyed to assistive technologies
- The focus remains within modals or dialogs until closed
- The context changes should only occur as a result of intentional user interaction
- All parts of the screen, such as modals or menus, can be closed or exited using a screen reader
External keyboard
With an external keyboard it is possible to control your device. For people with a mobility impairment, operating a touchscreen may be difficult or impossible; for blind users, a keyboard makes navigating and typing faster. Ensure the app is fully operable with an external keyboard — features such as switch control and voice control will also function better as a result.
-
Set up a Bluetooth keyboard
Learn extended keyboard features →- Android: Settings → Connected devices → Bluetooth
- iOS: Settings → Bluetooth
- iOS: also set Settings → Accessibility → Keyboards → Full Keyboard Access to "On"
-
Basic keys
Keyboard gestures explained →- Tab / Shift+Tab — next / previous element
- Arrow keys — navigate
- Space or Enter — activate elements
- Esc — exit a modal or navigate back
- Tab G + arrows — scroll
- Tab Z + arrows — move element up or down
Checklist
- All interactive elements are focusable with a keyboard interface
- All interactive elements on the screen are included in the keyboard focus order
- The keyboard focus goes directly to the next visible interactive element with each keystroke in a sequential navigation
- Key shortcuts are customized properly
- The keyboard focus remains within modals or dialogs until closed
- The context changes only occurs as a result of intentional user interaction
- All the parts of the screen, such as modals or menus, can be closed or exited using a keyboard interface
Useful links
Want to dive deeper or stay up to date with accessibility standards and tools for mobile apps? Here are some helpful resources:
Want to dive deeper or stay up to date with mobile accessibility standards and tools? These resources can help:
Abra Academy – Online trainings on mobile accessibility, from testing techniques to in-depth Android and iOS trainings.
Abra Desktop - Faster testing with (semi) automated tests.
Appt.org – An initiative of the Appt Foundation, a non-profit organisation sharing free content and open-source tools to help make apps accessible for everyone.
EN 301 549 – European standard for accessibility of ICT products and services.
WCAG 2.2 – The international standard for digital accessibility, maintained by W3C.
WCAG2Mobile – Early guidance on how WCAG applies to mobile apps and interfaces.
W3C Mobile Accessibility Task Force GitHub – Ongoing discussions on how WCAG applies to mobile apps, with open issue tracking and drafts.