Confession: I Have Not Given Web Accessibility The Consideration It Deserves
I am a web developer specializing in front end. If you are reading this, you probably already know what this means: the majority of the code I write is code that is executed in the browser on a user’s device (as opposed to code that executes on a server). As a front end developer, I am the last person on the project assembly line that takes the concept — as designed and defined by requirements — and implements it as code. As such, it is my responsibility that the final product that I ship provides a baseline user experience that is available to every potential user. However, I have a confession to make — I have not given web accessibility the consideration it deserves.
Yes, I have sinned against Browsor, the terrible and vengeful God of WebDev, who defends the rights of all users to have access to web content. (Browsor also smites all those who use tables for layout). For this, I seek penance.
I was not alone in committing my sin. There is plenty of blame to go around: from stakeholders who never considered it, to UX designers who never designed for it, to testers who never tested for it, we are all guilty in the eyes of Browsor. However, my own actions belong to me, and that is where I hope to begin my journey of transformation.
Why It Matters
Many of us have probably been through several projects in which accessibility wasn’t “an issue” — at least not as far as our stakeholders and management were concerned. It seldom (if ever) was raised, and if so it was perhaps “de-scoped” as “too time consuming for now”. It fell victim to the same fate as so many other cross-cutting, non-feature dev work does: your project manager assured you it would be handled in the 2.0 release that you both know will never come.
As developers, we too often have to “make a case” — to fight to be allocated the time to do work that isn’t particularly interesting to stakeholders but that is crucial nonetheless. Be it unit tests, security, or CI, the onus frequently falls to the developer to ensure that these items are tracked and accounted for in estimates of work. Accessibility is just the same; it is all too easy to let accessibility be pushed to the back burner in favor of other work.
But there are compelling reasons that accessibility deserves more consideration than it often garners. Let’s explore the arguments, starting with the most cynical and pragmatic reasons and working our way to the most lofty and high-minded ones.
It’s the law
The reality is that, in failing to implement a sufficiently accessible website, you may be breaking the law, and putting your client at risk of legal liability. Many countries have laws and policies outlining the requirements around websites and accessibility. In the US, Section 508 dictates the rules regarding accessibility of government websites; however, the Section 508 site states that “Even when Section 508 doesn’t apply, many non-federal websites are still required to be accessible under other laws.” Specifically, the Supplemental Advance Notice of Proposed Rulemaking on State and Local Government Web Accessibility to the ADA considers making adherence to the W3’s WCAG standard a guiding principle for web accessibility.
While I hope to explore the legal considerations more in depth in a later post, the ultimate takeaway is that failure to provide an accessible website may result in legal trouble for your client. Why, just in 2008 Target was forced to pay a $6 million settlement for a lawsuit over its website’s failure to provide an accessible experience for people who are unable to see. Even though more sentimental/ethical appeals may fail to move your stakeholders to action, the risk of a lawsuit is much more likely to garner their attention.
💰 Money (for your client) 💰
With every second of load time for your site you increase the chance that the user will abandon it and move on. Imagine how much quickly a user might abandon your site if they were completely unable to navigate it. Per the National Federation for the Blind, there were ≈6.83 million visually disabled adults in the United States in 2015. A company would be foolish to completely preclude several million potential customers from patronizing their business, but that is just what happens when a business fails to make an accessible website. And visual disabilities are only one type disability; there are several others, from users restricted to keyboard navigation or other assistive technology to users with cognitive issues that affect how they interact with your site.
While these users may not be using the web in what we consider to be a “traditional” way, they are still potential customers with money in their wallets. Failure to cater to these individuals is simply leaving money on the table. This can be a compelling argument to stakeholders reluctant to fully invest the time and effort needed in creating an accessible site.
🤑 Money (for you!) 🤑
The metrics on accessible websites are, sadly, rather bleak. For example, both the United States and the United Kingdom both fare pretty poorly regarding accessibility of both commercial and government sites. Although I do not have world-wide metrics, I suspect the global numbers tend to follow the same trend. And given the potential loss of revenue and legal issues associated with an inaccessible site (see above) it stands to reason that the demand for developers who can create accessible websites may be rising in the coming years. As this is a skill set that is currently lacking in the developer community, a developer who has mastered the ins and outs of accessible websites would be positioned to charge a premium for their services.
It will improve your site
In Laura Kalbag’s excellent book Accessibility for Everyone, she notes that “building accessibility into your project and processes has a wealth of business benefits.” We’ve enumerated some of these benefits in the above sections, such as increasing your audience and ensuring legal compliance. Developing for accessibility will also tend to improve your SEO, tend to improve interactions generally on the site, and tend to just generally make your site easier to find and use. For the client, this can translate to more revenue, and cost savings in other areas of the business that will offset any cost spent on implementing an accessible site. As a developer, this makes your job easier — by building a site with accessibility best practices in mind, you are getting some things “for free” that you might have otherwise had to add in separately.
It’s the right thing to do
Without the protections provided by the ADA in the United States, life for people with various forms of disability would be far more difficult. Imagine being wheelchair-bound with no access to handicapped parking or wheelchair-accessible entrances, or being deaf without closed captioning. While we are far from a world in which we have adequately accommodated the needs of all people with a disability (imagine being blind in the US and needing to deal with paper money) those living in countries with guaranteed rights for people with disabilities probably fare much better than they would without those guarantees.
On the internet, the cost of creating a level playing field for all is far lower than it would be in a building, business or transportation system. A website built using proper web standards and best practices is already relatively accessible. The lives of home-bound people could be vastly improved if they had access to an accessible web experience. The lives of people with physical limitations that make turning a page extremely difficult could be improved if they were able to access content that they could navigate with a keyboard. The lives of people with visual disabilities are worsened when they don’t have the same access to all the conveniences of the web that their sighted neighbors do, simply because the content isn’t properly structured for screen readers. Regardless of whether or not it is criminal, I would argue failure to build accessible web experiences represents a failure of morality — not borne of malice, but rather of ignorance, or indifference, or best intentions never realized. Every inaccessible site we create is another part of the world that is shut-off from those with disabilities — another thing from which they have been excluded. Building properly accessible sites isn’t only the smart and legal thing to do — it is the right thing to do.
My Goal
In the foreword to Kalbag’s Accessibility for Everyone, Heydon Pickering notes that, in reading this particular work, the reader accepts some responsibility that they “might have failed people in the past”. This really resonated with me. I knew as I started reading this that I was acknowledging to myself that, on previous sites I had worked on, I had perhaps created something that was exclusionary to users with disabilities. As a user interface developer I had failed to consider a diverse set of potential users, and excluded a whole lot of them as I simply developed for the easy majority.
I knew that to become a developer that could create inclusive interfaces and champion accessible web development I would need to transform myself. I would need to understand what “user” could mean in its totality, to learn and internalize the best practices of accessible development, and to find my voice to make the case for considering accessibility in every step of the project process.
I’ve been gathering and reviewing material on accessibility best practices. However, this time I’m going to try something new: learning by blogging. Over the coming weeks and months, I hope to provide additional articles on how to define an inclusive definition of “user”, some accessibility best practices, and more. At the end of this journey, I hope to become a developer with an innate sense of how to build an accessible site, and to generate some helpful content to enable others do the same.
Stay tuned.
Update — The next article has been published: Defining “Accessibility”
