Practical guide to mobile accessibility testing

If you are a developer, designer, tester, auditor or any other professional already working on accessibility but unsure how to approach mobile accessibility testing by hand, this guide is for you.

Automated accessibility testing is fast, consistent and helpful, but not enough to form a real picture of the accessibility of your app. We wrote a blog about the different ways of testing and its benefits. Automated testing reveals only a fraction of the issues and is perfect for regular accessibility hygiene. However, to get the full picture, you need to test manually.

Start with the right mindset

Accessibility ensures that people with disabilities – whether visual, auditory, motor, or cognitive – can use your app. It also includes users who experience temporary or situational limitations.

Situational disabilities happen more often than we think, and they affect everyone at some point. For example:

• Bright light makes it hard to read the screen

• In a silent train carriage, using sound is not possible

• Holding a baby can limit how you use your hands

These are all examples of everyday conditions where accessibility plays a role.

When you design, develop, or test a screen, it helps to ask:

• Can all the functionalities be used if I cannot see the screen?

• Do I receive all the information if I cannot hear any sound?

• Can I use the app with all the functionalities if I can only use a keyboard or a screen reader?

• Can I see and reach all the content if I increase text size?

Accessibility is more than just meeting a standard or complying with for example the EAA legislation. It means creating a product that works for everyone, in all situations and under different conditions. A truly accessible app adapts to real-world usage and supports all users – not just by design, but by experience.

How to approach testing

Accessibility testing means that each element on each screen, and each screen in general, is usable by everyone. Some requirements apply to the entire screen or even the whole app, such as orientation or language support, while others apply to individual elements, such as buttons, images or text fields. Since apps often have multiple flows and screens, it is easy to miss things if you test randomly.

We recommend testing screen by screen. This helps you catch all issues without overlooking specific components or flows. In most cases, the same problems will appear across multiple screens. By testing one screen thoroughly and sharing your findings, your team can apply the fixes across the entire app. This leads to consistent improvements in small, manageable steps.

Start by resetting the device to its default settings (normal text size, unlocked orientation, no accessibility features enabled). Then use the checklist in this guide as your reference.

Select a screen and go from general issues applicable to the whole screen to each element in particular. Start inspecting visually (for example, with text scaled to 200%), and afterwards proceed with testing using a screen reader. After that, test with an external keyboard.

Use one assistive technology at a time. For example, test a screen only with a screen reader or only with large text enabled. Mixing assistive technologies is possible, but it quickly leads to too many combinations and makes testing less effective. At Abra, we’ve decided to test with only one assistive technology at a time.

Learn more about app testing at the Abra Academy.

Checklist: what to check

The checklist consists of 11 categories. Each category focuses on a specific area of accessibility and contains several checks (we call them Abra rules) to perform.

List of categories:

1. General

2. Color

3. Text

4. Non-text context

5. Multimedia

6. Interactive elements

7. Actions, gestures and sensory cues

8. Control

9. Status messages and errors

10. External keyboard

11. Screen reader

These categories are not isolated. In practice, multiple categories often apply to a single element or screen. For example, a button with a text label must be tested under several categories:

• Color: does the button or its label have enough contrast?

• Text: does the text resize properly or get cut off?

• Interactive elements: is the button announced correctly with the right name, role, and state?

• Actions, gestures and sensory cues: does the button avoid triggering actions too early or relying on gestures?

• External keyboard: can the button be reached and activated using a keyboard?

• Screen reader: can the button be reached and activated using a screen reader?

Categories are designed to reflect how people actually use apps. Some focus on visual clarity or input methods. Others address structure, feedback or interaction. Together, they ensure you are not just meeting the rules, but supporting real users in real situations.

Looking for the Abra Rules? You’ll find them in Abra Documentation: some open to all, others part of our paid premium resources.

1. General

These checks apply to the overall app or full screens. They ensure that the app works correctly in different settings – for example, when users switch device orientation or use the app in another language.

Checklist items:

• The app supports both portrait and landscape modes. With Abra Desktop you can find this rule automatically.

  • Rules: Content is not restricted to landscape orientation (free) & Content is not restricted to portrait orientation (free).

• The language of the app and its elements is set correctly, so that the screen reader uses the pronunciation in the right language.

  • Rules: Language of content correct (paid) & Language of the app correct (paid)

2. Color & contrast

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 or color is the only way to convey information, users may miss information or not be able to interact with the app at all.

Checklist items:

• Text has sufficient contrast (for both small and large text).

  • Rules: Contrast for bold text 14pt or larger is at least 3.0:1 (Paid) & Contrast for bold text smaller than 14pt is at least 4.5:1 (Paid) & Contrast for regular text 18pt or larger is at least 3.0:1 (Paid) & Contrast for regular text smaller than 18pt is at least 4.5:1 (Paid)

• UI elements like icons, lines and buttons also meet contrast requirements.

  • Rule: Interface elements contrast at least 3.0:1 (paid)

• Color is not the only way to convey information

  • Rule: Color of the element is not the only cue (Paid) & Color of keyboard focus indicator is not the only cue (Paid)

• The focus indicator (when using a keyboard or a screen reader) is clearly visible and has enough contrast.

  • Rules: Keyboard focus indicator contrast at least 3.0:1 (Paid) &

3. Text

This category covers how text is displayed, scaled and structured. It ensures that users who increase text size or rely on screen readers can still read and navigate through the content. If text is cut off, overlaps, or is not marked up correctly, users may miss important information or not be able to navigate through the content effectively.

Checklist items:

• Text scales properly when increasing font size to 200%.

  • Rules: Text scaling (Paid) & Scaled text not clipping (Paid) & Scaled text not obscured (Paid) & Scaled text not truncated (Paid)

• No images of text are used (unless essential and well-described).

  • Rule: Text presented as plain text (Paid)

• Headings are correctly marked as headings in the code.

  • Rule: Heading role present (Paid)

• Paragraphs and lists are separately navigable with the screen reader.

  • Rule: Paragraphs separately navigable (Paid) & List items separately navigable (Paid)

4. Non-text context

This category covers all visual or interactive content that is not plain text – such as images, icons, graphs, sliders, timelines or maps. These elements must be clearly described for users of assistive technologies. Meaningful visuals must have accurate labels that describe their purpose, while decorative visuals should be hidden. Complex visuals like maps should offer a clear text alternative that communicates the same information.

Checklist items:

• Images are marked up as images in the code.

  • Rule: Image role present (Paid)

• Label for meaningful non-text content is present and describes its meaning.

  • Rules: Non-text content label present (Paid) & Non-text content label correct (Paid)

• Decorative non-text content is hidden from assistive technologies.

  • Rule: Decorative non-text content hidden (Paid)

• Text alternative is provided for maps or complex graphics.

  • Rule: Map text alternative present (Paid)

• Tables and grids include row and column indexes that are announced correctly by screen readers.

  • Rules: Column index within a collection present (Paid) & Column index within a collection correct (Paid) & Row index within a collection present (Paid) & Row index within a collection correct (Paid)

5. Multimedia

This category applies to audio and video content. These types of content must be accessible for users who are deaf, hard of hearing, blind, or have cognitive disabilities. Key information in multimedia must always be available in alternative form (for example, text), so users do not miss anything if they cannot hear or see it. Background audio should not interfere with content or control.

Go to all 9 rules about multimedia (Paid).

Checklist items:

• Text alternative for audio-only content is present and describes all the information presented in video or audio.

• Captions are provided for all pre-recorded video with audio.

• Captions are accurate and synchronised with spoken content.

• Audio can be paused, stopped or its volume controlled separately from system volume.

• Video does not start automatically and includes controls to pause or stop playback.

• Captions are clearly visible and do not obscure important visual content.

6. Interactive elements

This category applies to all elements that users can interact with – such as buttons, links, checkboxes, input fields, sliders and other controls. These elements must not only be displayed correctly, but also be programmatically determined. Each interactive element needs a proper accessible name, role, state and value that are exposed to assistive technologies. This ensures that users who rely on assistive technologies can identify the element, understand its purpose, and interact with it successfully.

Checklist items:

• Interactive element has an accessible name that describes its purpose.

  • Rules: Interactive element name present (Paid) & Interactive element name correct (Paid)

• Accessible name matches or includes the visible label in the correct order.

  • Rules: Label present in name (Paid) & Visible label for an input field present (Paid)

• Interactive element has a role that reflects what it is and how it behaves.

  • Rules: Interactive element role present (Paid) & Interactive element role correct (Paid)

• Interactive element has a state that reflects its current condition (e.g. selected, disabled).

  • Rules: Interactive element state present (Paid) & Interactive element state correct (Paid)

• Interactive element has a value if it needs to communicate data (e.g. slider position, selected option).

  • Rules: Interactive element value present (Paid) & Interactive element value correct (Paid)

• Target size of interactive elements is sufficiently large. With Abra Desktop you can find this rule automatically.

  • Rules: Target size (minimum) (Free) & Target size (enhanced) (Free)

7. Actions, gestures and sensory cues

Apps often rely on motion, gestures or sensory cues (like sound or color). This category focuses on making sure users who cannot perceive or perform these actions can still use the app. All interactions must be operable without complex gestures or motion. Actions should not be triggered too early, and users must have a way to cancel or undo them. Any visual or auditory cue must be supported with a clear, perceivable alternative.

Checklist items:

• Action is not triggered on down-event (for example, tapping a button should activate it only when the finger is lifted, not when it first touches the screen).

  • Rule: No action triggered on down-event (Paid)

• Action triggered by movement can be disabled or has an alternative.

  • Rule: Alternative for device motion present (Paid)

• Action can be aborted or undone.

  • Rule: Cancel or undo action mechanism present (Paid) & Actions reversable on up-event (Paid)

• Gesture-based action has an accessible alternative (e.g. button or single-point tap).

  • Rules: Alternative for multi-point gestures present (Paid) & Alternative for path-based gestures present (Paid)

• Information or functionality is not conveyed by sound, color, shape or location alone.

  • Rule: Sensory cue is not the only way (Paid)

• Motion or audio-based actions do not activate automatically without user consent.

  • Rules: Audio control present (Paid)

8. Control

Users must be able to operate and navigate your app at their own pace. This category focuses on giving users enough time, avoiding unexpected changes, and making sure they can pause or stop any moving content. Apps must not take over the interface or interrupt the user without warning. Controls should be predictable and reversible, so users remain in control of what happens and when.

Checklist items:

• User is not forced to complete a task within a limited time.

  • Rule: Time limit for completing tasks adjustable (Paid) & Time control for content display present (Paid)

• User can pause, stop or hide any moving, blinking or scrolling content.

  • Rule: Content motion control present (Paid)

• Changes to content or context do not happen automatically or these are clearly communicated to the user.

  • Rules: No context change on focus with external keyboard present (Paid) & No context change on focus with screen reader present (Paid) & No unexpected context change on input present (Paid)

9. Status messages and errors

This category ensures that users are informed when something changes or goes wrong, without disrupting their navigation. Error messages must clearly describe what went wrong, where it happened, and how to fix it. Status updates should be announced automatically to users who rely on assistive technologies, without shifting screen reader focus.

Checklist items:

• Error message is announced to the user in text. Error message clearly describes what went wrong, where it happened and how to fix it.

  • Rules: Error message correct (Paid) & Suggestion how to fix error present (Paid)

• Status message is announced without moving focus away.

  • Rules: Status message announced (Paid) & No automatic focus on status message (Paid)

10. External keyboard

Some users rely entirely on a physical keyboard to navigate and use mobile apps. This category ensures that all functionality remains available without touch. Interactive elements must be reachable and operable using only an external keyboard, and focus must follow a clear, logical order without causing confusion or unexpected behaviour.

Checklist items:

• Interactive elements must receive keyboard focus. Focus must follow a logical, sequential order through visible interactive elements.s

  • Rules: Interactive elements focusable using a keyboard interface (Paid) & Keyboard focus sequence includes all interactive elements (Paid) & Keyboard focus order correct (Paid)

• There must be no unexpected keyboard shortcuts (such as single-key activation).

  • Rule: Key shortcuts customized properly (Paid)

• Keyboard focus must stay within modals until they are closed.

  • Rule: Keyboard focus within modals correct (Paid)

• Focus must not cause unexpected context changes or get trapped – users must be able to exit all parts of the screen using a keyboard.

  • Rule: No context change on focus with external keyboard present (Paid) & keyboard trap present (Paid)

11. Screen reader

A screen reader announces everything on the screen and allows users to navigate and interact with apps without sight. This category focuses on making sure that all content, structure and functionality can be understood and operated based on what is announced. If the focus order is unclear, elements are not grouped properly, or information is missing, users cannot navigate or complete tasks. All functionality must be available and operable without relying on vision.

Checklist items:

• All non-decorative elements must be focusable using the screen reader.

  • Rule: Meaningful elements focusable with accessibility interface (Paid) & Screen reader focus order includes all meaningful elements (Paid)

• Focus must follow a logical, sequential order.

  • Rule: Initial focus in a reading order correct (Paid) & Screen reader focus order correct (Paid)

• Reading order must match the visual order, and related elements must be grouped and announced correctly. Sequences of steps or events must be announced in the correct order.

  • Rule: Reading order correct (Paid) & Reading order of related content correct (Paid) & Relation between elements announced (Paid) & Sequence of events or steps announced (Paid)

• Focus must remain within modals until they are closed.

  • Rule: Screen reader focus within modals correct (Paid)

• Focus must not trigger unexpected context changes.

  • Rule: No context change on focus with screen reader present (Paid)

• There must be no screen reader traps – users must be able to exit all parts of the screen.

  • Rule: No screen reader trap present (Paid)

Exceptions

In some cases, an exception can be applied:

• If a complex feature like a map is difficult to make accessible, but there is an alternative that provides the same information in an accessible way, the original feature may be exempt.

• If a specific feature is essential to how the app works – for example, a piano app that only functions in landscape mode – then limiting orientation can be considered acceptable.

• Decorative elements that do not provide meaningful information for users should be marked as decorative and are exempt from accessibility requirements.

Use exceptions carefully, and always ask: can users still access the same content, complete the same tasks, and have the same experience – even if they use the app differently?

Documenting issues

Clear and consistent documentation in the Abra ecosystem helps your team understand, prioritise and fix issues faster. Include a short title, screenshot, brief description, steps to reproduce and platform details; and reference relevant accessibility rules where possible.

Abra now makes documenting even easier. With our semi‑automated testing flow, you can capture, annotate and report issues directly from the app. Abra Desktop lets you:

• Create a manual result.

• Select the vendor and accessibility rule, and select a severity level of the issue.

• Add a screenshot automatically from your connected device or simulator, or upload it from your laptop.

• Edit the issue description to match the app context.

• Once added, your issue appears in the results list and is immediately available in the Abra Dashboard.

Once in the Dashboard, you can review, edit or manage results with the same steps. Each result also includes a direct link to the corresponding rule in Abra Documentation.

This seamless flow reduces up to 90% of administrative work, allowing you to focus on identifying real issues.

Wrapping up

Manual accessibility testing takes time and attention, but it gives you the clearest picture of how accessible your app really is – for everyone.

Start small, share your findings and build accessibility into your process step by step. With the right tools and mindset, accessible design becomes not only possible, but practical.

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.