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:

• w3 Introduction to Web Accessibility
• MDN Accessibility Portal
• Google Web Accessibility

Copy editor: Brint Davy