They say "Accessibility is soooooo expensive". Devs, is that true?
Dear Applevis Community,
Well, I guess I said it in the Subject Line, didn't I? But to go into a bit more detail:
I often write to developers asking them to make changes, and to improove their app's accessibility.
Now, there are two apps in particular whose developers have for a long time either been ignoring my concerns, or have (more or less clearly) stated that they did not intend to make any step towards accessibility.
In both cases, they made the same claim: "Making our app accessible causes tremendously high additional costs, it will break our budget, we don't plan it, or it can't be done at all".
And especially this point about the "additional Cost" is one I'd really like some clarification about.
So I guess I'd like to hear especially from App Developers (which I think are the ones who should know): How much effort / time / money does it really cost to make an IOS App accessible?
As my question of course is asked very broadly, I know I'll probably get all possible answers. Which is a good thing, as I really would like to get some general perspective.
But for the record, let me tell you about the two apps. They won't be of use to most of you readers, as they're both apps used in Switzerland or, in one case, even in and around my home town, Bern.
And to further add to the unattractiveness of my post: I think both apps are only available in the Swiss App Store.
One app is called: TWINT.
Purpose: It's a Swiss Mobile Payment Solution. They actually strive to enable all holders of popular smart phones (iPhones and Android ones) to make and receive payments. Works with scanned QR Codes, with Bluetooth Beacons, with Codes... And it is supported by all major and most minor Swiss banks.
(One detail worth knowing is that most Swiss banks currently refuse to make their credit cards work with the popular ApplePay service. Instead, they try to position Twint as the Primary Mobile Payment Solution for everybody in Switzerland or something similar).
Accessibility: The App currently can be used with VoiceOver, but it's just very hard, and nothing one could call "Welcomed User Experience". There are unlabelled buttons, some status messages aren't read, and VoiceOver sometimes reads page content which is not actually displayed on the screen.
The second app is the official app of Bern's Public Transportation Authority.
Purpose: Well as you can guess: The app delivers schedule as well as real-time tracking of buses and tramlines in the city of Bern. It also allows for purchasing of tickets and keeps the traveler up to date on traffic disturbances.
Accessibility: The sad thing is that this app really was accessible until like four years ago, when they did a redesign. After that, and as of now, again some of it can be used with VoiceOver, but it's just a very bad and frustrating experience.
For example: On the app's home screen, the time tables of upcoming departures is displayed and read aloud by VoiceOver. However, VoiceOver reads the table not by line, but by column, basically reading a bunch of line numbers, followed by a bunch of destinations, ant then a bunch of departure times.
As you see: Yes, one COULd figure it out.
But my oppinion is that one COULD as well, as a developer, really take the time, go into that code, label those buttons and change the reading order.
Or (again to you, developers): Does that really cause such high cost?
Sorry if my questions do sound too rethorical. You can tell clearly how tired and frustrated I am. As for me, I'm not a fully grown app developer. I do a bit of coding, and I've been doing quite some researches on IOS App Development; Also, I am an experienced accessibility consultant. And yes, I do consider myself in the right when I say that making apps as the ones I described accessible is really not hard and really not expensive.
But I am willing to learn and to admit I am wrong.
So, if some Devs could share about their experiences, I'd really appreciate it!
Thanks a lot and best regards from Switzerland,
If a developers does not have accessibility in mind at the outset of their software development effort, retrofitting an app to be accessible can take a lot of extra effort. This extra effort will, of course, have a cost. Considering that the blind and/or other groups that have accdessibility issues are generally a very small part of the market, this additional cost is in excess of what the developers mmight have planned for their project. Thus, unless, the tweat to their software is small, it often won't be done.
This by no means excuses developers from making apps accessible. These days a developer should be aware of accessibility concerns from the outset and, accordingly, develop their apps from the ground up with accessibility in mind.
The only thing we can do is to make developers aware of these concerns and pass along specific recommendations that might help. Only by being aware of the issues will developers know enough next time around to make their apps fully accessible.
BTW, accessibility is not only a concern for visually impaired individuals but also for people with other access concerns. Thus developers must be aware of the range of accessibility problems that people might face.
I can't agree more with the previous comment. I'm not a developer, but I think I know a thing or two about accessibility from being a longtime screen reader user. I agree that we absolutely need to make these developers aware of our access needs. One point which I'd like to make is that some developers seem to include accessibility right from the start without even knowing it. This is most certainly a good thing in my books. One example of this is an online portal which the local hospital network uses to notify patients of upcoming doctor visits, lab results and some other things. I only recently began using this portal. I was at a doc's appointment not long ago, and the person checking us in asked if we were registered on their online portal, and my mom and I said no. So the person at the desk gave us instructions for signing up. I was honestly a bit skeptical at first about the accessibility of this online portal with VoiceOver and Chromevox. I think I had been reading too many medical horror stories from people in the blindness community, lol! But once I got past the audio CAPTCHA on the registration form, I was well on my way. Even their audio CAPTCHA isn't bad if you ask me, even though those things cannot be used by deaf or hard-of-hearing individuals. I don't like the fact that they time out either after only a short period. But once the registration form is submitted, the portal works great on the Mac.
As a designer of a project I can't talk about, I can say it will cost a lot of funding we don't have. We have to redo most of the app, then submit the patch to developers who might not want to implement it. This now is taking us over 8 months, and most of it is a lot of coding. by the way we are doing this with no funding. It kind of sucks for me as I have to eat you know? Lol!
What does the word expensive means exactly?
Because should we talk about a visual game being coded by a single coder and in needs of a new module to get the visual parts translated into something blind people can use to play this might be a very bigg issue envolving hours and hours of code and tests thus being a "expensive" process for a dev who might not have thhe time to work on it specially to support a small amount of users...
But when we are talking aboutt unlabeled buttons on an app built for supporting all financial transactions on your country which also happens to be the more advanced financial center on the planet and when we are talking about reading tables the right way on an app being developped for the whole people then expensive for me takes another meaning and I would stat for sure that pricing or resources seen not to be exactly what is causing these features not to be implemented here.
I would check with the lawyers on your side to see what might be performed to solve this situation ...
I agree that it is subjective, based on the project.
If it's something very visual to begin with and the developers chose a coding platform that does not have accessibility hooks out of the box, retro-fitting it to be accessible can be a large undertaking. They may not have coders/developers familiar with it and they'd have to probably hire consultants or extra developers to handle the retro-fit. It's in cases like this that I really hope that accessibility is something that comes into play during design discussions as a course of habit - currently, even for websites, accessibility is very often an after thought tacked on to the end of a development cycle. This often produces headaches for the developers in the long run ... not that they'll change any time soon, as often the people funding the project just see accessibility as a box to check to avoid lawsuits. But this is with bigger corporations, etc., for websites that actually have laws saying it has to be accessible.
In your case, I don't see how 'expense' should be an excuse. Voice Over actually can make sense of the application in some ways, so it sounds like they're not using some inaccessible multi-platform coding system like Unity. Fixing the problems shouldn'tt be a problem, it is probably just the time and expertise. They're thinking in terms of development time. Because Accessibility is not even covered usually in Software/Web Development programs, they'd have to have one of their own developers stop to research/learn how to make the changes. Either that or they'd have to hire a consultant company to tell them how to do it. (There are a lot of these consultant companies, mostly for websites, to tell people how to make their website or application accessible. It costs the developers money.) It's just unfortunate they don't seem to want to spare at least a single developer to learn this and make the app work for all.
I really do think we need to approach some of the more popular coding platforms - such as Unity - and try to get them to make accessibility hooks for the platform out of the box. If app developers that use these platforms have to do their own coding to make accessibility work, they won't do it - they need a tool from the platform itself to make it easy for them to add it. A lot of app develoeprs use Unity, as it can be ported to IOS and Android at the same time.
Secondly, the developers need to know accessibility is there and need to want to make their application accessible from the ground up. If developers were aware that the cost would be lower if they just designed with accessibility in mind from the beginning, then we wouldn't have these issues. It's just difficult to get them to consider accessibility.
I currently work as a Web Developer and I am completely blind. I have opened a lot of eyes and saved my company a lot of time in ensuring our application is accessible throughout the development cycle instead of how they used to do it - which was basically develp the application, have QA test it for accessibility and then have to basically re-write huge sections of the code because the design didn't work with accessibility.
Yeah as a consultant I'm expensive, so let's say you had to higher me for accessibility work, I would be about $1000 a month. Most devs don't have that kind of funding.
I'm on conversations, or trying to get into conversations with sisco as this so one of the apps the government job I have uses. Sisco filed a paper with the government saying they were accessible, they are, except on the iOs platform. You can't chat as the controls don't even show up.