I was recently disciplined for bringing up accessibility (a11y) issues on a project at the agency where I was a dev. Even more troublingly, I had already developed a ready-to-push accessible feature for a client. It was nixed at the client’s request, stamped by a higher-up’s approval.
I pushed back, a little. The resulting squabble descended into a minor panic within our agency. Might the client face an ADA lawsuit? Or, would they become upset that we did not implement their request against better accessibility practices? It resulted in my first official discipline as a developer over the two years I’ve committed to this agency. It hurt a little.
Basically, I had suggested that making a digital product — already developed — less accessible was a bad idea. Then, suddenly, everything became dramatic. The client was a small business, so ADA litigation wasn’t likely. I suppose the intended lesson in my discipline was: “keep your mouth shut about accessibility.” I consider that a lesson not learned.
Web dev shops have an existing set of accessibility tools already represented within the HTML code-chest! To me, it’s a real no-brainer to utilize them. It requires no advanced knowledge. Let’s be honest with ourselves as software makers. If we can Google Flexbox every other week but can't be bothered to look up ARIA and Fieldset, the blame falls on us.
A general apathy against implementing accessibility is disturbingly common, rearing its head on even most-critical civic websites. It’s a trend making national news, as many COVID vaccination appointment scheduling sites are inaccessible to blind web users. These sites’ forms and fields were not designed well, with broad accessibility in mind. Many are functionally broken.
I understand that there must have been a rush to get these info sites and web forms up as soon as possible. And, I don't know the tech stacks the developers used. In fact, I do not think it’s fair to assume that actual coders held much decision-making power in how the sites were built. It is, in my experience, often not the case.
I realize that this topic isn't new. My take isn’t novel, but it’s a topic that never seems to find a resolution. We should keep talking about web a11y right now, and as the technology evolves. Maybe coding with accessibility in mind can become second-nature and expected, as opposed to the other way around?
Adopting that expectation may be a challenge, but it is an arena where the browsers can wield influence. They have wholesale blocked sites with insecure content before, over a range of issues. Other times, they’ve placed cautionary labels in toolbars. Google search results already favor sites with a11y implemented. It wouldn’t be a stretch for Chrome(ium), Firefox, Safari, or Edge to display a label notifying users and development stakeholders that a site isn’t accessible.
This ongoing (and seemingly never-ending) web accessibility crisis pushed me to write this: my very first dev-related article. I hope that it helps to further the conversation! Understanding the impact, importance, and relative ease of implementation is how web accessibility will become more accessible.
Note: I won't pretend to be blameless in implementing accessibility in my work. Moving forward, however, I'll be implementing it into my workflow. Including it in my work estimates.
a11y Resources:
Copy editor: Brint Davy
Top comments (2)
It should have hurt a lot!
I don't know the details but it sounds like the agency should "take the blame" not you as you did what was right, protected the client's interests and the interests of their customers.
It sounds like someone higher up didn't want to take the blame for it (but it is your recounting so obviously I can only infer whether you deserved a reprimand or not 😋)
ADA litigation is not likely for *most * businesses and people focus too much on the legal aspect (the "stick"). When talking to anything other than a multi national about accessibility run the numbers with them and focus on the increase in profits (the "carrot").
A basic example
If the widget or feature costs less to implement than the revenue it will add to the bottom line in 12 months then push hard as it is a "no brainer".
I tend to look at their current conversion rates with them and then use a 1% uplift in their current rate as a starting point. Run the numbers from visitors to conversions and see if the item pays for itself.
For example:
Before:
1,000 visits a day
2% conversion rate
20 sales
average sale £50
Annual Revenue: £365,000
After:
1,000 visits a day
2.02% conversion rate (1% increase)
20.2 sales
average sale £50
Annual Revenue: £368,500
So implementing the feature should add £10 a day in the above fictitious scenario.
Assuming the feature doesn't cost more than £3,650 (1 year return) then the client should go ahead with it.
Then you pile on top of that the fact that their competitors are not meeting the needs of people with disabilities so they can steal clients from them easily (more potential visitors), that it adds to their Corporate Social Responsibility Policy (if they have one) and the moral grounds and I guarantee 99% of business owners will agree.
Obviously I know you are a Dev and it is perhaps "not your place" if that is the culture where you currently are, but that is how I build the case for accessibility (simplified but you get the idea) and I would hope you could take what I do and turn it into your own case (assuming this experience has not put you off too much, I hope it doesn't!).
Oh and as a nice added side effect did you notice that your boss would be happy too, extra revenue in the pot for your company so a win-win!
I really appreciate this response.
Sharing an example of how to make the financial case is really helpful.
It's partially why the request to spend time(money) removing an existing feature that could easily have existed in tandem with the client request.
Regardless, with your example and the lessons learned from my experience I, and others, can hopefully better navigate similar situations in the future.