Avoiding accessibility barriers with a checklist for custom controls - opinion

I’ve spent years navigating the complexities of mobile app development, facing challenges like scaling, security, and user experience. But when it came to accessibility, frustration reached a new level.

Unlike other aspects of mobile development where there’s a clear path to success, accessibility often felt like a black hole – unexplored, confusing, and difficult to master. It wasn’t just about meeting compliance requirements; it was about ensuring that our work truly added value by making it accessible to everyone, regardless of their abilities.

This realization came from countless customer endeavors, discussions with colleagues, feedback from the field, and collaboration with our development and accessibility teams. I found that many of the challenges I faced weren’t unique to my team; they were common pitfalls that many developers encounter when trying to make their apps accessible.

In my current role at Evinced, where we focus on solving accessibility issues through innovative technology, I’ve seen firsthand how these challenges can be effectively addressed. Drawing on the knowledge and feedback I’ve gathered from the field, our developers, and accessibility experts, I’d like to share some of the most common mistakes I’ve encountered and how to avoid them. Here are five key areas to focus on when making your app accessible.

Accessible name and text alternatives

When it comes to accessibility, image buttons without visible labels can be a major stumbling block. For users relying on screen readers and voice input software, missing labels can create confusion and hinder navigation. Ensuring every interactive element has a clear, accessible label is crucial for providing an inclusive, user-friendly experience.

Some common examples are a date picker where the placeholder disappears once selected or icons that lack any visual label or indication, unlike buttons with icons.

Target size

Another common accessibility error in mobile apps is applying the size of tappable areas. Web Content Accessibility Guidelines (WCAG) recommend a minimum size of 24x24 pixels. In contrast, iOS and Android suggest touch targets more attuned to mobile standards: 44x44 points on iOS and 48x48 density-independent pixels (dp) on Android. These recommendations reflect the need to accommodate different screen resolutions and ensure usability for individuals with disabilities. 

The challenge lies in balancing WCAG compliance with these guidelines against providing the best inclusive user experience. While awareness is increasing and this conflict remains complex, it seems that the iOS and Android guidelines are the most appropriate for impaired individuals using mobile devices. This logic applies to common tappable practices such as a touch or mouse click. For more details, check out WCAG. 

Custom controls without the proper attribution 

When creating custom controls like NPS/CSAT rating scales (1-5,1-10 etc.) or any sort of range pickers, it is essential to include proper accessibility properties that start with the element role and all of the related attributes (the element’s semantics).

Without these, users relying on assistive technologies may find it difficult to interact with or understand the controls.

Lack of semantic grouping

A common but somewhat unknown mistake is the lack of proper element grouping that will break the meaningful sequence success criteria. For instance, a picture with a caption should be announced as a single unit by screen readers, providing a cohesive context. Similarly, a button that includes both an icon and text needs to be grouped semantically so that it is read as one element.

Without proper grouping, screen readers might announce these elements separately, causing confusion for individuals relying on assistive technologies. For neurotypical users this separation might not be noticeable, but it can significantly impact users with disabilities. 

Considering all assistive technologies 

A critical accessibility mistake is the tendency to test mobile apps solely with screen readers while neglecting other assistive technologies such as Voice Control, Switch Control, and external keyboards. For example, Voice Control relies on realistic and accurate labels for commands to function effectively. If these labels aren’t practical or descriptive enough, users may struggle to navigate the app using voice commands. For example, a sentence-like label will be very exhausting and is more prone for Voice Control malfunctions. Comprehensive accessibility testing must include all relevant assistive technologies to ensure that the app is truly usable for individuals with various needs and preferences.

And a general tip for accessibility: Shift left & consider accessibility from the very beginning of the concept ideation. 

By integrating accessibility into your software development life cycle early on, you ensure that your app is designed with inclusivity in mind from the get-go. This proactive approach helps identify and address potential issues before they become costly problems, leading to a more accessible and user-friendly final product.

The writer is group product manager at Evinced, a digital accessibility software provider that helps enterprises make their web and mobile offerings accessible to everyone.