1. What is accessibility in Android applications and what is it for?
2. Current and Future Regulations Regarding Accessibility in Mobile Applications
3. Accessibility for Android Devices with Jetpack Compose
4. Conclusion
In today’s digital landscape, mobile applications are an integral part of our lives. From communicating and learning to entertainment and daily tasks, we increasingly depend on these tools. However, have you ever wondered if everyone can use these apps without barriers? This is where accessibility in Android applications comes into play—a fundamental concept for building an inclusive digital world, now easier to implement with Jetpack Compose
1. What is accessibility in Android applications and what is it for?
Accessibility in Android applications refers to designing and developing apps so that they can be effectively used by everyone, including people with disabilities. These disabilities may be visual (blindness or low vision), auditory (deafness or hearing loss), motor (restricted motor skills), or cognitive, among others.
Accessibility is not just about fulfilling an obligation; it’s about expanding your app’s reach and improving the experience for all users. By making your app accessible, you allow one billion people with disabilities worldwide to have equal access to its content and features.
But the benefits of accessibility go beyond people with disabilities. Accessibility features and considerations often result in clearer, more intuitive, and easier-to-use user interfaces for everyone. For example, good color contrast benefits users with low vision but also makes reading easier in bright environments for anyone. Voice commands, designed for people with motor difficulties, can be useful for any user in situations where they can’t use their hands.
In summary, accessibility in Android applications serves to:
- Ensure digital inclusion for people with disabilities.
- Expand your app’s user base.
- Improve the user experience for everyone.
- Potentially increase user satisfaction and retention, and improve app ratings.
2. Current and Future Regulations Regarding Accessibility in Mobile Applications
Accessibility in the digital environment is not just a recommendation; it is also supported by various national and international regulations.
Currently, there are laws and regulations that require the accessibility of digital products and services, especially in the public sector. In Spain, Royal Decree 1112/2018 transposes Directive (EU) 2016/2102 and establishes accessibility requirements for public sector websites and mobile applications. Similarly, the ADA (Americans with Disabilities Act) in the United States sets guidelines for accessibility. Internationally, the Web Content Accessibility Guidelines (WCAG) from the W3C are a widely adopted reference that, although originally intended for the web, offer principles applicable to mobile applications.
Looking to the future, the European Accessibility Act (EAA) 2025 is a European directive that will expand accessibility requirements to a broader range of private sector products and services, including mobile apps, e-commerce websites, banking services, e-books, and more. This means that more and more companies will have a legal obligation to create accessible mobile applications.
In addition to these laws, there are technical standards such as UNE-EN 301 549:2019 (based on the European standard EN 301 549), which defines accessibility requirements for Information and Communication Technology (ICT) products and services. This standard is an important reference for developers and accessibility evaluators, as it details specific technical criteria largely aligned with the WCAG.
Complying with these regulations is not only a legal obligation but also demonstrates a commitment to social responsibility and inclusion.
3. Accessibility for Android Devices with Jetpack Compose
Jetpack Compose, the UI toolkit for Android, was designed with accessibility in mind. Many of the accessibility APIs from the classic framework have direct equivalents or are handled more intuitively in Compose.
How to Make Apps More Accessible with Compose
There are basic principles and best practices developers can follow to improve the accessibility of their Compose applications: :
Label UI elements clearly and descriptively: Use the contentDescription parameter within the semantics modifier for non-textual elements like Image or IconButton. For textual elements like Text or Button, Compose generally uses the text itself as the default label, but you can override it if necessary. For purely decorative elements, you can remove them from the semantic tree.
- Group related content: Use the mergeDescendants = true parameter within the semantics modifier on a container Composable (Column, Row, Box, etc.). This makes TalkBack treat all descendant elements as a single focusable entity, reading their content descriptions in order. It’s useful for grouping elements that form a logical unit, such as a complex list item.
- Provide accessible titles for panels: Use the paneTitle property within the semantics modifier on the Composable representing a panel or distinct section of the screen. This helps accessibility services announce the transition when focus moves to this area.
- Use standard Composables: The basic Material Design Composables (Button, Text, TextField, Checkbox, etc.) already incorporate the necessary accessibility semantics by default. If you create complex custom Composables, make sure to use the semantics modifier to expose their state, role (using SemanticsProperties.Role), and custom actions.
- Use cues that do not rely solely on color: This design principle remains crucial. In Compose, you can easily combine color with icons (Icon), changes in border thickness (border), or descriptive text to indicate states.
- Provide alternative content descriptions: As seen in the first point, use contentDescription in the semantics modifier for Image, Icon, IconButton, and other visual elements without text.
- Consider the size of touch targets: Clickable elements in Compose should have a recommended minimum size of 48×48 dp. You can use the sizeIn modifier to set minimum dimensions. The clickable modifier also helps, as it slightly expands the touch area by default, but sizeIn is more explicit to ensure compliance.
- Ensure adequate color contrast: The same contrast rules apply (WCAG 4.5:1 for normal text, 3:1 for large text and graphics). Use contrast checking tools and define accessible color palettes in your Material Design theme (MaterialTheme).
- Allow users to adjust text size: Use sp (scale-independent pixels) for font size (fontSize) in your Text Composables. Compose automatically respects the user’s system font size settings when you use sp.
- Documentation and feature activation: If your app has documented accessibility features, make sure they can be easily activated. Any documentation and help provided with the app should be accessible.
Principles of Accessibility
- Behind the best practices are fundamental principles that guide accessible development (applicable to both Views and Compose):
- Equitable use: The app should be useful and marketable to people with diverse abilities.
- Flexibility and adaptability: The app should adapt to different individual needs (e.g., text size, contrast).
- Comprehensibility: The information and operation of the user interface should be easy to understand (e.g., clear labels, logical navigation).
- Robustness: Content should be robust enough to be reliably interpreted by a wide variety of user agents, including assistive technologies (e.g., using semantics correctly).
- Perceptibility: Information and UI components should be presented to users in ways they can perceive (e.g., adequate contrast, text alternatives).
How to Test the Accessibility of Your Compose App
Testing your app’s accessibility is a crucial step Existing tools also work with Compose:
- Accessibility Scanner: This Google tool analyzes the UI (both Views and Compose) and suggests improvements (contrast, touch size, labels).
Accessibility Test Framework for Android: Allows you to include accessibility checks in your instrumented Espresso or Compose tests. In Compose, you can use ComposeTestRule and SemanticsMatcher to verify semantic properties in your UI tests.
- UI Automator Viewer: Still useful for inspecting the accessibility hierarchy and properties, although Compose’s internal structure is different from Views.
- Accessibility Insights for Android: Performs automated tests and generates reports.
- A11y Ally: Helps analyze accessibility from the developer’s perspective.
In addition to automated tools, it is essential to perform manual testing using Android’s accessibility features such as TalkBack (gesture navigation, content reading), Switch Access (switch navigation), and Voice Access (voice control). These tests will help you understand the real experience of users with disabilities.
Remember that automated tools have limitations and cannot verify logic or semantic clarity. Testing with real users is always the most valuable way to ensure accessibility.
Conclusion
Accessibility in Android applications is an investment that benefits everyone. By understanding the importance of digital inclusion, knowing the regulations, and applying accessible development and testing principles and techniques (using the semantics modifier, appropriate sizes, contrast, etc.), you can create applications that reach a wider audience and provide a superior user experience for all. It is in our hands to start building a more accessible digital world today.