Ignorance used in the title is deliberate! You have to realize by now that when it comes to accessibility, all the talented people who have been trying to make things accessible have been ignored. The reasons behind this happening could be anything from not knowing how to do it, not being aware of the users that depend on accessibility features, or simply, having no budget!
The state of accessibility today
At the end of 2023, I wrote a blog showcasing the current state of app accessibility. The blog was a culmination of a variety of research and observations. you can read the entire blog here.
In short, this is what is happening with accessibility right now
About one-quarter of the most popular apps have less than 10% accessibility labels attached to them, making them virtually non-existent for users who rely on screen readers.
It is also worth noticing that out of one-quarter of the apps that have most of the accessibility labels present, might not have the labels that make sense to the users.
The overall condition of accessibility in the realm of mobile apps can be assumed to be below average or even critical.
Why accessibility is an afterthought
This is again a blog written to cover the basics of why IT firms have been putting accessibility considerations on the back burner.
Long story short, regarding accessibility, it all comes down to return on investment. In the current scenario where the leadership thinks that they can incorporate accessibility at the last moment or just before the release of the app, the cost of accessibility appears to be much higher, in turn, making the ROI low. There are other reasons like the inability to comprehend the WCAG, Lack of genuine feedback, and assumptions that are detrimental to the accessibility considerations of the application under development.
Accessibility overlooked lays
The biggest aftermath of accessibility being an afterthought came out as the accessibility overlays. Accessibility overlays are the tiny plugins that are added to a website that claim to make the website accessible, without the development team having to put in any extra effort! There are many studies indicating that these accessibility overlays do not work! I will discuss the same in the upcoming article. Meanwhile, you can check these articles if you are interested
Why Accessibility Overlays are a Very Bad Idea by Glenn Barfield
Ethical Problems with Overlays and How to Overcome Them by Karl Groves
Should I use accessibility overlays? by The A11y Project Team
Happy Enlightment!
Why is this happening
In the current scenario, the checks for accessibility happen when the app goes for testing. This means, that while the app is being developed, there is seldom the consideration of the accessibility requirements! Now I am not claiming this as a fact, however looking at the current scenario, one can infer that this might be the case. Of course, big organizations have experts who advocate accessibility, but it all comes down to the bottom line!
This is what a regular product lifecycle looks like when superimposing the cost of fixing accessibility on top of it.
These values are approximated and taken from this LinkedIn post by Miriam Nabinger. The approximation indicates that a few companies may have to spend more than 30x the cost to fix accessibility if they do not invest that ‘x’ during the Requirements and Design phase. This cost does not just include the monetary costs and efforts, but also includes reputational costs, lost users, and sometimes, legal costs as well! The testing phase will incur more cost than development since the development teams need to get involved to fix the numerous Jira tickets (btw, if the Jira tickets are raised to transfer bugs, can they be called Jira crickets?)
Another trouble with the current scenario is that the FIX works only once! If there is no culture of considering accessibility from the start, the product may need fixing with every subsequent release. Every new iteration will have something new, that won’t be accessible by default!
In the current scenario, there are two checkpoints where accessibility considerations are taken into account. The first is the design system that powers the design process. Many people are under the impression that making the design system accessible makes the overall design accessible. That’s nowhere even close to reality! with the most accessible design systems, people who do not care can create a completely inaccessible app!
The second checkpoint is the accessibility checkers. There are Gitlab-full plugins that can check if the application qualifies as accessible or not. These tools focus on fixing the components like tappable sizes, color contrast, and the presence of labels. However, if you rely on these tools, then you may end up in a place where the app passes with flying colors but in the real world, becomes unusable. Drawing from the LinkedIn blog mentioned above, when I tested the trip.com app myself, I found out that despite 90% of the accessibility labels being present in the app, not one of them was useful, effectively rendering the app unusable by people who rely on assistive technology such as TalkBack and VoiceOver. Here is a snippet of how the labels are as of Dec 2023.
In conclusion, relying on the compliance of design systems and blindly trusting the reports generated by the accessibility checkers can give the developing teams wrong ideas, making the users suffer!
Shifting left
Not physically, philosophically
Shifting left means being proactive from the earlier stages of the product lifecycle. In this case, shifting left might mean shifting the accessibility considerations towards the early stages of the product lifecycle, aka, scoping and design.
Designers are responsible for making sure that all the users can use the products they design. That’s the basic definition of User experience. However, we have been ignoring the word ‘ALL’. This means designers are responsible for ensuring that the products are usable by everyone, irrespective of their abilities.
When we change the responsibility towards the left, the Product Managers, Product Owners, and Designers start sharing the responsibilities to make the product accessible as well. While in the design phase, the cost of remediation is quite low. The designers can start creating accessibility flows and assigning the right labels and functions to all the elements. That may consume about 5% extra effort on the designer’s end, but as an organization, it will have a significant impact on the cost of fixing accessibility during the testing and production stages.
Now there are obvious barriers to this approach like, designers not having the exact knowledge of how to do this stuff or Product managers not knowing how to pitch this to leadership and get extra budget and time allocated for the project. This is where my research comes in handy!
Mobile Accessibility Rituals
While working with WHO, I had to get acquainted with WCAG. In the later stage of my career, I had to work with mobile apps. There is no direct translation available where you can directly get a repository of accessibility guidelines for mobiles. I created a bunch of tricks to ensure that my team understands the accessibility guidelines. This book is exactly that. All the tips and tricks for making the app work with assistive technologies are explained as simple rituals a team can follow! Follow the link below to know more about this book.
Yes, I have compiled books!
Every once in a while, the content gets a bit large for blog posts. So it is assimilated and published as a book (or a notion template). You can buy the existing books and find upcoming books on this page.