Web accessibility isn’t easy. Sure, the fundamentals are simple enough, but most developers aren’t taught accessibility in school and it’s something that’s often taken for granted. And as web interactions become more complex, developers become even more likely to ignore accessibility — until someone complains.
Luckily, accessibility is an achievable goal. At BiblioCommons, we’ve learned 7 key lessons about accessibility culture, and we’re a better company for it.
When you start with accessibility in mind, it makes your life so much easier. When ignored or pushed to the backburner, 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 an expensive reality for a lot of companies.
“Accessibility is like ice cream...the longer you ignore it, the messier it gets.”
Phil Springall, Web Editor at the Legislative Assembly of Ontario
Accessibility problems are defects and have an associated cost multiplier at each point of the chain where the defect is not discovered. Mitigate this cost by integrating accessibility into all aspects of the software development life cycle.
To do that, a bit of basic accessibility training can go a long way. Just by bringing everyone into the loop, you make it possible to discover issues at every point in the development chain.
At BiblioCommons, we have an accessibility Slack channel where we share advice across the company. It’s a great way to access quick answers and valuable resources.
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.
But this passive and straightforward experience doesn’t reflect reality. In the real-world, screen readers have a wide range of active controls, which can vary from device to device. And to complicate things further, 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 BiblioCommons office, and many of us have been attending accessibility conferences and meetups. This has been great, but the hard part is 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.
A BiblioWeb homepage viewed in High Contrast mode on Windows.
We need to consider people with low vision, dexterity issues and hearing issues. And while addressing accessibility concerns is beneficial for everyone, for many users it is crucial. For a person with no disabilities, fixing an accessibility issue might save them a few seconds on a particular task; but the same fix might save 10 minutes for a person with a disability.
“Over a billion people, about 15% of the world’s population, have some form of disability.”
World Health Organization
It’s not just about people with physical disabilities either. Our applications need to be accessible to people with cognitive disabilities, such as those on the Autism Spectrum. 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.
Don’t get me wrong — accessibility validation tools like WAVE and Pa11y can be a useful resource, but they can also be misleading. True, they can help you find some basic accessibility issues that users will find frustrating. But when it comes down to it, they aren’t great at catching issues that involve more complex user interactions.
Here are some issues these tools can not and will not warn you about:
Your lack of focus management is making overlays inaccessible
Users aren’t being notified with form error messages
When your images should be decorative
When your links should be buttons
Issues like these require human consideration. They’re uncovered when you combine a solid understanding of web accessibility with assistive technologies.
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. 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 was tougher than it seemed, 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 required both client training and new code to specify whether an image was decorative or informative. This was much more complicated than simply adding alt text to some images on a rendered page.
There are often different approaches we can take to address an accessibility 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.
Web accessibility can be easy, but it does take work. We laid the groundwork by incorporating accessibility into the development process. It’s no longer an ‘extra thing’ we need to worry about; 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 Manager of Software Engineering at BiblioCommons. He spends his time managing the technical aspects of the product and working with other teams to keep everything running smoothly.
For a deep dive into accessibility culture, check out Ian’s talk at the software developer conference Strange Loop: Beyond Alt Text: Trends in Online Accessibility [Video].