A screen reader-friendly app is a description we use for an application that can be used by blind people because their screen reader can identify its buttons and controls, read the information it displays, and interact with its options and features. Another term we use is “accessible,” meaning an app that blind users can take advantage of, focusing on the specific needs of visually impaired individuals rather than the broader definition of accessibility.
Stating that an app is accessible or screen reader-friendly is not an easy task, as we sometimes mix our personal preferences and subjective thoughts with accessibility. In this article, I am not going to define accessibility or conduct scientific research about its objective standards, as I admit that I am a pragmatic and forgiving person when it comes to defining accessible apps. The objective of this article is to highlight a few wrong thoughts about accessibility that I have come across over the years while using and testing apps and exchanging emails with developers.
Table of Contents
Not Recognizing the Native Screen Reader Capabilities
A screen reader is software that blind people use to interact with applications on their devices. This screen reader is advanced enough to identify the type of control we are dealing with, such as a checkbox, a button, etc.
Understanding the basic differences between the types of onscreen elements is an important aspect that should gain the focus of trainers, so blind beginners can understand the control and element types and their roles in the application.
The fact that a screen reader is capable of reporting the types of elements to the blind user is not known by some app developers, so they try, usually with good intentions, to intervene and clarify a certain control or option. During an email exchange with a developer recently, I noticed this fact clearly. The developer is known for respecting accessibility, and he quickly responded positively when I told him that the app was missing the proper labeling of two checkboxes. In the test version that I received from the developer, I found that the options were labeled, but with a change in the option name according to its state, whether it is checked or not. This change was reflected in the name itself, not in a description or summary that follows it.
I tried to explain to the developer that changing the name itself is confusing and doesn’t work as intended, as we are dealing with a checkbox for which the state is known by the checked or unchecked status. As the conversation continued, I noticed that the developer wasn’t understanding that blind users can differentiate between a button and a checkbox like sighted users. The final result was pleasing after a detailed explanation, but the conversation itself was proof that app developers are sometimes unaware of basic facts regarding screen readers.
Not Understanding the Role of Actions
Accessibility or screen reader actions, despite being introduced some years ago, are still unimplemented in most applications. It is already a well-known and repeated fact that most of Google’s apps themselves lack action support or are not properly implemented. An example is the “Drive” app from Google, which has one action support when navigating files in the home tab: the action is to show more options. Why this action was added is beyond my understanding. It only gives the impression that the team who added the action doesn’t know the main goal of having actions in the first place, which is to make reaching options simpler for blind users. This shy implementation is not extended to the files tab where no actions are supported.
As Google sets a bad example, blaming other developers becomes less intuitive. If the company that created actions is not respecting them, what can we say to other companies and developers? However, we are used to other developers, especially indie ones, being more serious about accessibility and more collaborative. One example is the Tusky developers, who were able to add actions as they should be, removing all unnecessary clutter in the Mastodon feed.
Tusky is not the standard, though. Our team noticed on more than one occasion that developers don’t know the role of actions and what they achieve for a blind user. They don’t know that adding them properly could save a blind person many swipes and time loss. It is known that many blind people use swiping between onscreen elements, a method that is reliable in many situations. In some Android apps like YouTube, the swiper has to pass by the more actions button after each video when navigating channels or the subscription feed. This more actions button could be easily hidden with its options added as actions that the screen reader can utilize.
Someone might say that this is how the element is on the screen and that this may lead to the blind user not getting exactly what is on the screen like their sighted counterparts. While this is true, it is less convenient to have the same elements shown to the screen reader in certain situations because the eye can see more items on the screen, whereas the blind user is hearing one item at a time.
Going back to my pragmatic approach, I want to admit that I don’t see an app as inaccessible if it doesn’t support actions, assuming that I can reach the same options using a long press, for example. I still prefer to have an accessible normal method to reach options sitting side by side with actions. I find Tusky’s approach slightly radical, as I cannot easily long press a toot and find the options if I want to. However, this doesn’t mean that actions are not important and that I don’t campaign for their implementation. The most important part of this campaign is to introduce them in simple terms to developers so they can support them properly in their applications when they are needed.
Assuming that Blind People are Naive
An app developer who believes in inclusivity and decides, with good intentions, to respect accessibility might unexpectedly make the app a nightmare for blind people instead of making it a joy to use. This type of developer often uses very long descriptions and clarifications or strips the app of certain options or makes them unreachable for blind users for their safety.
An example is a recorder app that was in development a few years ago. While there is no doubt about the developer’s good intention, the implementation was very annoying, leading to some blind users being unwilling to use the application. I still remember how much time we needed to convince the developer to add a discard recording button. He kept saying that this button could be pressed by a blind user by mistake, which might lead to unintended consequences.
Carelessness and naivety are present in both sighted and blind communities, as people do not have equal abilities. I can say that a blind user is more careful when dealing with apps and is less likely to press a button without reading what it does. Moreover, long chatty messages are the last thing that a screen reader user may like to have in an application, as they would make the experience more time-consuming. Sometimes the name of the button itself is enough to know what it does; a correct reporting of the on/off state is enough to understand the change, etc.
Seeing Accessibility as a Serious Complication that Negatively Impacts the Sighted Experience
Every app developer has the right to design their app as they like. They may strive to make it visually appealing, which is completely fine and understandable. However, a screen reader-friendly app doesn’t need to be an ugly-looking app. Accessibility and an attractive design can coexist peacefully.
Some app developers think that they need to make many changes to make the app accessible, changes that will destroy the visual look of the app. This assumption is based on incorrect ideas about accessibility and screen readers. Usually, these developers don’t know that the label the screen reader reads doesn’t affect the shape of the button and is rather a text that the naked eye doesn’t see, so they avoid adding labels to buttons and controls. They also know nothing about screen reader accessibility focus and that it is easy to make an element focusable and clickable by the screen reader.
It is important to note, however, that using certain libraries that don’t respect accessibility complicates matters for developers who need to search for more accessible libraries, a step that some are unwilling to take unfortunately. Additionally, some design elements might pose a challenge for partially sighted users who may prefer a certain approach or are sensitive to certain designs.
In this regard, it is important to strike a balance between the app’s design and usability for users. A balance that cannot be accomplished without serious collaboration between app developers and the community.
Moreover, seeking alternative workarounds may be the way to respect accessibility. For instance, the developer can keep the fancy time picker but add a more traditional text-based time input that can be activated in settings.
Final Thoughts
Owning a device like a smartphone or tablet, no matter how high its specs are, is just a part of the user experience. This device cannot be fully utilized without being able to use the operating system and third-party applications. The more accessible those applications are, the better the experience. For this reason, accessibility is not a luxury; it is a necessity. Even if blind people are a minority, they have the right to use their devices similarly to how sighted users use their devices. Misconceptions about accessibility can be hurdles in building a more inclusive ecosystem. They can transform good intentions into bad decisions easily.
It is always important to keep the door of discussions with app developers open and to deal with them kindly. We should not take a very strict stand or have mean attitudes. We should be calm, logical, and realistic in what we ask for. Our community should be aware of accessibility basics so we can pass them on to sighted developers. We may have differences regarding how strict we are in our accessibility judgments, and we may sometimes request features or changes that we prefer in the name of accessibility, even if they are not truly related to accessibility.
Advocating for accessibility while showing flexibility is key to more productive discussions with app developers. Indie app developers have always shown more tendency to care for accessibility compared to big companies, and they are a core element in building a more screen reader-friendly platform.
Highlighting some accessibility misconceptions and thoughts could be an introduction to better communication with developers. When a developer learns to think accessibly and understands that accessibility is not a complicated procedure, the whole community benefits.
Let’s not forget that sometimes a simple explanation or a gentle clarification can make a big, long-lasting difference.
Comments