How to Build an Accessible App for a Blind Person

Many apps try to implement accessibility features for the visually challenged. To ensure true success, software engineers must ensure that their applications are convenient and concise.
May 25, 2022
Share on facebook
Share on twitter
Share on linkedin

Get the best of
The Daily Bundle in your inbox every week

Get the best of The Daily Bundle in your inbox every week

Even though building accessible apps is time-consuming and complex, it’s the need of the hour. What’s more, accessibility is a highly beneficial goal that all software engineering teams should strive to achieve. Naturally, accessibility, as a whole, is a very broad topic, so it’s always best to focus on specific features to guarantee specific types of accessibility. 

One of the most difficult things when it comes to accessibility? Working for people with visual impairments. For people suffering from vision loss, even simple tasks such as searching and option selection can be difficult. Yet, as this research by the University of Washington shows, many app designers neglect the needs of visually challenged users while creating their apps. 

It’s time to stop that. And the best way to do so is to learn the potential ways forward to help people with visual impairments use applications without any accessibility issues. 

What Are Some Common Issues Visually Challenged Users Face?

1. User Interface 

A user interface is the first thing any app user interacts with. Unfortunately, for most apps, UI settings are only configured for users with normal vision. Some apps try to implement accessibility features, including reading options aloud and vibrating in specific ways when carrying out an action. However, very few apps actually achieve true accessibility. 

2. Links/buttons

An app has many actionable items such as buttons and links through which you interact with the different features. An application’s usage highly depends on these items. That’s why, without properly adapted links and buttons, visually challenged people won’t find much use to an app.

3. Implementation

Even if an app is accessible and has options for voice input, there may be some times when visually challenged users may face challenges when using the application. For example, if there are no captions/headings/alt-texts in the code, the app won’t return any audio output. Furthermore, the listener won’t know why the reader has stopped if there’s no alt-text setup. 

4. Standardization

Many apps don’t have standard design features. Normal users can figure out how to navigate such apps, but this can create consistency issues for users with limited vision. Visually challenged users depend on simple layouts/menus to perform tasks. When they aren’t positioned predictably, it becomes difficult for users to move from one page to another, navigate back, and access other features. 

Another fact engineers should consider before developing apps is that many visually challenged users have limited literacy, an issue that piles up on top of the already demanding accessibility-focused development plan. 

So How Do You Make an Accessible App?

According to a recent WHO report, there are at least 2.2 billion people in the world with some form of visual impairment. And with increased life expectancy, this number is only going to increase in the coming years. Therefore, engineers should consider incorporating accessibility in their mobile applications and strive to improve their apps to satisfy this growing demand. 

How can they do so? Here are some ideas. 

1. Screen readers

Screen readers are specialized devices that transmit data from a computer screen to a refreshable braille presentation device that a visually challenged person can touch and use to read. This allows them to process digital information and applications without actually interacting with a screen.

The easiest way to develop an accessible app is by integrating a screen reader into it. This makes any application highly accessible. In fact, many companies have already started integrating screen-readers in their applications. For example, the Uber app is compatible with popular screen reading tools such as VoiceOver by Apple and Android’s TalkBack. Netflix also allows users to scroll through and play content using screen readers. 

2. Alternative methods of screen input

You can incorporate assistive methods of screen input to your application, such as specialized keyboards, joysticks, and “sip and puff” devices. These devices allow users with disabilities to use your application. Along with input, these devices also help in-app navigation and exploration. 

3. Labeling buttons

Although screen readers make it possible for the visually challenged to navigate screens and perform basic operations, it’s also important to make the buttons and links accessible as well. Labeling important buttons allows disabled users to understand what each button/option does. 

Not just the button, loading screens should also be accessible. Visually challenged users can get confused if an operation runs longer than expected since they can’t see the loading screen. They don’t know whether an input is required or if the app has crashed. But if you have a loading screen label, the screen reader would return the label text, which would inform the user that an operation is still processing.  

Furthermore, you can also add alt-text to your images. Screen readers can read this text and enable users to recognize images. In fact, companies such as Facebook are now using AI to explain images to visually challenged users.

4. Sound notifications

Apps should have built-in sounds to inform users when a change has occurred on the screen. These should be stereo sounds, i.e., sounds that reverberate in both ears. These sounds can be set off to acknowledge events such as page refresh, image transitions, app errors, etc. 

Text to audio software is also highly useful for the unsighted as it helps them navigate applications without using specialized assistive devices. Accessible applications should have integrated text-to-speech software that can take voice commands to perform basic functions. You can also use them to generate verbal output. 

5. Changes in content structure 

Since visually challenged users use screen readers or text-to-voice software for reading, it becomes difficult for them to comprehend long text paragraphs. As a rule of thumb, you should keep your paragraph length between 150 to 200 words for maximum understanding. A break in the text also informs the user that a paragraph has ended and a new one is about to begin. 

You should also define clear headings for your paragraph since they indicate when a new topic has begun. They are also important for searching and indexing. 

Accessibility for All   

Many organizations have started including accessibility components in their systems. For example, Netflix has audio assist subtitles to enhance watch parties, and Twitter has automated alt-text for all uploaded images. Even though universal accessibility is a long way to go, many companies worldwide are trying to bring down barriers and work towards a common goal—to make accessible mobile applications. 

Billions of users worldwide can’t use mobile applications because of accessibility issues. As a software engineer, it’s your responsibility to ensure that your app is accessible. There are accessibility options present in iOS and Android development kits that you can use.  

Making an accessible app means putting yourself in the shoes of a visually challenged user. Keep that in mind, and you can have a huge impact on the lives of disabled users worldwide.

Notify of
Inline Feedbacks
View all comments

How useful was this post?

Click on a star to rate it!

Please enter a valid E-mail address.

Contact Us

How can we help you?

  • This field is for validation purposes and should be left unchanged.
Scroll to Top

Get in Touch

Jump-start your Business with the
Top 1% of IT Talent.

Need us to sign a non-disclosure agreement first? Please email us at [email protected].


By continuing to use this site, you agree to our cookie policy.