Towards Web Accessibility: 7 Lessons We're Learning

by Ian Forrest

Web accessibility is not easy. Sure, the fundamentals are simple enough, but most developers aren’t taught accessibility in school and it’s something that is often taken for granted. As user interactions in web applications become more complex, accessibility is often not considered until someone complains. But it doesn’t have to be this way. There are some very basic things you can do to improve the accessibility culture at your workplace. At BiblioCommons, we’re going through this process and we’re becoming a better company for it.

Everybody needs to know the basics

Building software can be a long process and it involves many people along the way. If an accessibility issue isn’t found until the end of the process, then the feature needs to be revisited at some point along the development chain, resulting in rework for everything that happened after. This can be a very expensive mistake. Accessibility problems are defects and have an associated cost multiplier at each point of the chain where the defect is not discovered. This cost is easily mitigated by integrating accessibility into all aspects of the software development life cycle.

Not everybody needs to be an expert, but it pays to uncover these issues as soon as we can. At BiblioCommons, we have an #accessibility Slack channel where we can get advice from each other across all teams. It’s been a great way to get a quick answer to a question or to share useful resources.

The longer you ignore accessibility, the messier it gets

A strawberry ice cream cone.  Source:  Wikimedia

A strawberry ice cream cone.

Source: Wikimedia

“Accessibility is like ice cream... the longer you ignore it, the messier it gets.” This quote comes from a recent talk at #a11yTOConf given by Phil Springall, and it summarizes nicely why accessibility needs to be considered up front. When you start with accessibility in mind, it makes your life so much easier. When ignored or pushed to the back burner, it turns into a mess that's very hard to clean up. Fixing this mess comes at a large cost, pushing back other priorities that are important to stakeholders. As accessibility legislation becomes more frequently enforced, this is going to be the reality for a lot of companies.

Developers don’t use screen readers properly… unless they are trained

It’s actually quite funny to think back to how I used screen readers when I first stepped into the world of web accessibility. When first learning, developers enable VoiceOver, sit back, and let the screen reader recite the page contents to them like it was a cassette tape. This is a very passive experience, but using a screen reader is much more active in practice. I’ve known developers who didn’t know you could do anything more than tab through the site or how to make the screen reader read paragraphs. While this is a great start, a little basic training could easily up their game. They need to understand which screen readers are used most in practice, that screen readers come with a variety of controls, and that many users aren’t running the latest versions of their software.

To help with training, we’ve had accessibility consultants, Simply Accessible, present at the office, and many of us have been attending accessibility conferences and meetups. This has been great, but the hard part is going to be transferring this knowledge to new developers. At present, we’ve created documentation for accessibility best practices and have all new front-end developers take the “Web Accessibility by Google” course offered for free from Udacity.

Web accessibility is not just about screen readers

A BiblioWeb homepage viewed in High Contrast mode on Windows.

We need to understand that web accessibility is much more than just screen readers. Fifteen percent of the population identifies as having a disability, and this number increases dramatically as we get older. We need to consider people with low vision, dexterity issues, or hearing issues. And while addressing accessibility concerns in our software is beneficial for everyone, for many users it is crucial. For a person with no disabilities, fixing an accessibility issue might save a few seconds when trying to accomplish a task, but the same fix might save a person with a disability ten minutes of frustration.

It’s not just about people with physical disabilities either. Our applications need to be accessible to people with cognitive disabilities, such as Autism Spectrum Disorder. Text content needs to be written in an accessible way using plain language. There are some great tools out there to help content creators with this, such as the Hemingway Editor.

Automated accessibility validation tools can be misleading

Don’t get me wrong, validation tools like WAVE or Pa11y can be a useful resource. They can help you find some essential accessibility issues that users will find frustrating. But when it comes down to it, they aren’t great at catching issues which involve more complex user interactions or thought. They won’t tell you when your lack of focus management makes overlays inaccessible, when images should be decorative, when links should be buttons, or when users aren’t notified with form error messages. Issues like these require human consideration and can only be uncovered with a solid understanding of web accessibility and by using assistive technology.

Your tech stack doesn’t matter to users

There have been times when we've found an accessibility issue that seemed completely trivial to fix at first, but in practice required a more complicated solution. These problems are our own and do not matter to our users, and we need to find good solutions regardless of our current technical situation. A perfect example of this is with decorative images in our BiblioWeb product. An issue was reported to us where we had informative images that were missing alt text. Seems like a simple enough problem to fix, right?

The issue is tougher than it seems, as library staff have the ability to upload their own images and use them throughout the site. Programmatically, we weren’t able to determine whether an image is decorative or informative. The solution to this problem required both client training and for us to build functionality to specify whether an image is decorative or informative. This is much more complicated than simply adding alt text to some images in a rendered page.

There are often grey areas when it comes to what is considered accessible

When we have an accessibility issue that we need to fix, there are often different approaches we can take to address the problem. Depending on the context, a recommended fix might not be the best fix because it makes the experience significantly worse for a large group of users. A feature that is accessible for one user who requires assistive technology, might not be accessible for another user using different technology. Sometimes this places restrictions on how a feature is designed or developed.

Something I’ve been thinking about lately is the idea of technically correct versus practically correct accessibility. For example, there are a lot of JavaScript libraries or plugins that claim to be accessible. Accessible to whom? Does this mean that a sighted user can use it with a keyboard? What about users who rely on a screen reader? A jQuery <select> replacement might claim (and be correct in saying) that their plugin uses a number of aria attributes to achieve screen reader accessibility, but if recent JAWS versions don’t support these aria tags then the plugin is not accessible. Native <select> inputs have many more features than you likely realize and are different between operating systems. Nothing is going to be more accessible than native form controls.

In a nutshell…

Web accessibility can be easy. Like anything, it takes work, but once the groundwork is laid it gets absorbed into each part of the development process. It’s no longer an ‘extra thing’ we need to worry about because we know how to develop accessible features from the start. Inclusive design starts at the top and it makes a real difference for those who have difficulty navigating the rest of the web.


Ian is the engineering lead for the BiblioWeb team at BiblioCommons. He spends his time managing the technical aspects of the product and working with other teams to keep everything running smoothly.