When advocating for accessibility to be built into a product, it’s not only the developers we need to convince. There are many layers of the business that we often need to speak to and convince.
I read this blog post recently
And thought it had interesting points to use when speaking to different layers of the business about accessibility.
What do you think? Is there anything you’d add to the list when advocating for accessibility? Would you expand on any of the points in the article?
Was inspired by this episode BBC World Service - Digital Planet, Blindness in the digital age of the Digital Planet podcast. Where I work, we don’t use web as a big part of our offering, so much of this has been a lower priority concern for me. We lost our UX advocate who was quite knowledgeable on this area a year ago, so I have been background reading up on this, and in a silly way hoping to do part of his job. Crazy, but that’s who I am. Accessibility is not a background or 50% task is all I can say, doing WCAG is really a full time job.
Reading the linked article immediately struck me as a summary of things I have learned in 2020 already, it’s all good stuff. But all artfully written up in a font, which, I struggled to read.
I put it to colleagues like this:
Our product is sold all over the world. We have no way of knowing who will be using it. So we should make the product as accessible as we can, because at some point, a potential client may have a choice between our product and a competitor’s, and if the only difference between the two is that they have a member of staff with particular access needs who finds the competitor’s product easier to use than ours, then we lose the sale.
Many companies have hard-nosed business types in the management team who will be immune to the argument that “It’s the right thing to do” and say “What’s in it for us?”. I found this argument works, for some strange reason.
There’s also quite a few browser extensions around now that can demo what a website looks like to individuals with varying abilities.
That can be quite a good way to convince others - “look at our site! this is how some individuals see it!”
I guess that would be “the stick” approach 
I 100% believe we should do stuff with accessibility in mind, and not as an after thought. In my experience people can be a bit afraid because its perceived as difficult. Its not always a clear “pass/fail” situation. There is alot of nuance and grey areas. There is some truth to that, but like most things a little knowledge goes a long way.
Working in a UK government department, we have standards to meet as part of legislation. Even with something scary and legal thats says “we must do this”, getting understanding and buy-in from people can be hard.
Things I’d add:
It can be hard to know how to test for accessibility. Which is why I’ve shared some of my organisation’s scripted manual tests. I’m not saying this is the only or best way to test! But it has helped people get started, and might do the same for you. I’m a big fan of the GDS Accessibility Posters for quick “do’s and don’ts”.
I’ll get off my soapbox now.
“…getting understanding and buy-in can be hard”. I’ll bet.
I’d also wager that you have some colleagues who look at accessibility legal requirements and complain about “pointless bureaucracy”. I know I did when I was in the civil service. I used to mutter darkly that “if you’re so against ‘pointless bureaucracy’, why did you come to work for one?” I always felt that my role as a career bureaucrat (or so I thought I then was) was to get the best outcome for clients and taxpayers whilst ticking all the boxes I was required to for the least expenditure and the most efficient use of effort.
Some more reasons I can think of:
I agree with all the points above especially with everyone having a role to play in accessibility.
IMO, the unfortunate reality is cost vs benefit. If the cost of developing and maintaining accessibility/AY features is far greater than the benefit, then companies are less likely to do it. To make a stronger case for AY we would need to show the benefits. Some ways of showing the benefits of AY could be by showing significant number of disabled users, talking about temporary disability and helping veterans with disabilities.
Understandably, veterans have a special place in many of our hearts. If we can show genuine cases where AY helped a significant number of veterans, then it might make a stronger case for AY. There are no guarantees, but it might make people more interested and aware about AY, if not anything else. IMO, awareness is a critical 1st step. If your leadership is not really aware of it, then you first have to make them aware and then make your case for why your company needs AY. They might avoid it due to higher priority items, which are always present.
Temporary disability (broken arm, eye surgery etc.) - I think this is one way to remind able bodied people that they could need AY too. So, they should educated themselves about AY & try to add at least some AY features. I had seen one link with excellent examples of how able bodied people might end up needing AY features, but I can’t find it. But here is something which talks about temporary and situational disabilities - https://download.microsoft.com/download/b/0/d/b0d4bf87-09ce-4417-8f28-d60703d672ed/inclusive_toolkit_manual_final.pdf
Another thing we could try is to see how able bodied users could benefit from AY tools. This might not be possible in in all cases, but I can think of one case. I’d like to have news articles read to me instead of reading them myself, so that I can do other stuff in parallel. Maybe I could benefit a little bit from some AY tools too? I think Wall street journal has a read button for their news articles. That is not an AY tool, but it could surely help blind people read the news if its combined with AY features for blind people.
As an aside, perhaps we could have an open source repository of AY design, code, testing, tools etc. Maybe this repo could be made by big, wealthy companies who have budgets for AY. Smaller companies with low budgets could use the repo instead of getting intimidated by costs & giving up without trying. But, I am not sure if big companies would want to give away their investment for free or even make it open source.
PS -
Doing AY is a noble goal indeed. But, I sometimes wonder if the people who advocate very passionately for AY have an idea of the costs involved and the challenges which a business faces.
One issue is that, under current UK legislation, employers have to make “reasonable adjustments” to facilitate the employment of staff with disabilities. Too often this is honoured in the breach rather than the observance (“reasonable” is well-known in legal circles as an exceptionally weaselly word, but it was ever thus); many poor employers get around this by finding other excuses not to employ someone, and it only comes home to them when someone they value becomes disabled through circumstance.
The implications for software producers depend on the product. If you are a website publisher, the measures to use to maximise accessibility to the site are fairly well-defined. To go to perhaps the opposite scenario, if your product is a specialist piece of professional software, re-engineering the application so that a range of users with a range of possible impairments is probably not going to be cost-effective, because only a minority of users will ever have similar impairments that will allow for a well-defined out-of-the-box accessibility solution.
Rather, the more likely situation the developers are going to be confronted with is where an existing client has a differently-abled member of staff that they already have an idea as to how they will accommodate. Your product then has to be easily adaptable to possibly a range of physical access technologies; and that level of adaptability is something that needs to be baked into the design at an early stage. System designers aren’t going to be able to anticipate exactly which accessibility need they might have to accommodate until the need actually arises. This is a case for arguing for building in the foundations of accessibility at a far earlier stage in the product lifecycle.
I want to bring a very specific application or product type case in here.
As someone who works more in the hardware space I have used apps with GUI’s that are pretty much bitmaps. For example an oscilloscope app is an extreme case, perhaps even a webcam preview app is another such extreme case. And So, I’m wondering, is providing a magnifier that is easy for a legally blind person to use enough? Windows and Mac and some Linux distros have one built into the box when you install the OS for example.
I know this is a little off the track, but is it worth advocating to make sure we get a real live disabled person to test for us. How much of a ripoff does that become? My pain is that testing this as a sighted person who also already knows how to use the app is a bit pointless, because if you did put a thick filter over my screen, I would still figure it out from memory. I’m asking because the question came up at work recently and I know part of the pain is that a big portion of my UI is really just a bitmap, and it’s impossible to describe the bitmap contents. So making only the menus highly accessible using accessibility hints for the voiced assistant frameworks feels a little pointless to me if the only thing that works is the menus and dialogs but not the oscilloscope? This just gets even more fun if I did convert my native oscilloscope app to a web app.
I have some questions about this.
1 - What are the estimated costs of developing, maintaining and testing for accessibility, say for a news website? Do you know any examples of such analysis for any software?
2 - Without estimated costs and benefits, how can we convince management to commit to accessibility?
3 - Accessibility is the right thing to do, but what if the costs are way more than the benefits in some cases? Perhaps wealthy companies could afford it easily, but what about less wealthy ones?
@conrad.braam, @robertday , @moorpheus, @flynnbops, @marie.drake
1 - In most companies and organisations, this sort of information rarely percolates down from the management level, and usually only on a “need to know” basis. Testers don’t need to know this (they say).
2 - see post #3 above (Advocating For Accessibility: Anything to Add? - #3 by robertday)
3 - My only answer is to bake accessibility in via the mark-up coding that the WCAG standard needs to work at the earliest stage possible in the application design. (In our case, we produce specialist software that has a very small user base. Our app doesn’t need to be accessible to everyone all the time; but it does need to be potentially available to anyone who needs assistive technologies at some point in their lives.) Building in mark-up codes that can have accessibility solutions bolted on to them as necessary is going to be cheaper when the app system architecture is being designed than trying to back-engineer accessibility on a product that is close to deployment.
On point 2, I think there are examples around now of what happens when certain applications are found to not be accessible.
This can be used as an argument to add in accessibility. There are also gov.uk resources on accessibility that are quite useful. See earlier for this. It’s not the hurdle it used to be.
I wonder if we could ask the product owners to share this information with us if its allowed. They often have insights into these things. Maybe we could also encourage them to do some accessibility/AY early on.
I don’t think that such reasoning is necessarily flawed or that such people are callous. As someone low in the hierarchy, I don’t have insights into the reasons which upper management uses to make decisions. So, I don’t want to make assumptions about their motivations.
I have seen some AY code and done a little bit of AY testing. But honestly, I don’t really know how AY works and what is the effort in maintaining AY features. If we do it well from day one itself, then does it take “minor” or “major” effort/money to maintain and test AY? If we can answer that question, then we might be able to easily make the case for AY.
@moorpheus - thanks for the link. I have lots of questions and I’d like to dig deeper. But, I’ll ponder on them later.
1 - How much monetary damages were awarded in this case?
What are the average values in most cases? Is it far greater than the cost of accessibility/AY? If yes, then companies will simply treat it as “the cost of doing business” and absorb the hits just like some financial companies do. Otherwise, they are being financially unwise and also hurting their image. Some might even try to lobby the government to prevent good faith lawsuits.
2 - Did the company even have any AY features for blind users to begin with?
If yes, then were they “reasonably good”?
etc…
However, if we somehow knew that AY needs “low/high” upfront costs, but “low” or “reasonable” long term maintenance costs, then it becomes easier to make a case for it. We can add the threat of lawsuits like this in case management still don’t understand it.
On my opinion of management: perhaps I’m just an old cynic. In a forty-year working career - not all in testing by any means! - I’ve come across all sorts of managements, and yes, perhaps the tide is turning. But you may well still encounter islands of old-fashioned thought and it’s useful to have some idea as to how to argue against it.
@anon68517856 Getting buy-in is really difficult. One way to convince management to commit to accessibility is to talk about inclusive design principles which you can find here Microsoft Design. Disabilities can be permanent, temporal or situational so everyone really benefits from it.
If you introduce accessibility at the beginning, the cost would be less than the benefits. If you haven’t introduced it, start now. Make small steps, there’s a lot of free accessibility tools out there that won’t cost anything and most of these tools can be integrated on the team’s development workflow. These tools only catch a subset of issues but it’s still better than nothing. Also, just making sure your application is keyboard friendly makes a big difference already.
All my opinions, so take from it what you will.
TLDR: Good HTML will lead to good accessibility. Doing it afterwards is expensive.
The dominoes example is a great example to use. I’m surprised more companies haven’t been called out. I don’t have a well researched example, but can share an andecdote from one of the organsiations I’ve worked in. They tested for accessibility and was nowhere near WCAG2 AA compliance. They spent 6 months, redesigining, developing and testing those changes. One of the project people said it cost around £250,000. And that was an underestimate based on what figures they could see.
I’m not a frontend dev, and I fully appreciate it is a skillset with lots of challenges. In my experience, well written HTML provides the majority of accessibility benefits. So the cost of accessible sites, is part of the cost of development. Little of it should require “making accessibility features” for your apps / site. If you need to do that, then perhaps you’re approaching the design wrong.
This is a interesting one. This sort of issue falls under the area of disproportionate burden. In short, you might be able to make a case to not be fully compliant, if the cost is too much for your org. It’s not a way to “not do accessibility” but understands different situations, and some things could be mammoth tasks. To me that makes sense for exisiting applications / sites. But if you are creating something new, there’s no excuse to not put accessibility first.