Skip to content

Top 5 web accessibility complaints and how to address them

It’s a common scenario – you’re a web developer on a tight deadline. You think everything is pretty much wrapped up for the client until that pesky accessibility-related request crops up. It might be an unexpected need to caption a video, or perhaps it’s the need to change that cool rollover effect you spent three days mastering. Worse still, it may be that killer last-minute web accessibity check that reveals the entire project is in jeopardy resulting in long nights and budget problems as it all gets fixed up.

But does it have to be this way? If you ask a room full of accessibility specialists, the answer will be a resounding ‘no’. However, if you ask a room full of web designers and developers, the response is likely to be ‘yes, because there’s no other choice – accessibility is hard, time-consuming and expensive’.

At the risk of having other accessibility specialists grab their pitchforks and march on my place, I’m going to say that both groups are right – to a point. Web developers and other associated ICT professionals are absolutely correct in saying that accessibility can be hard, it can be time-consuming and it can be expensive. However, I’d disagree that there’s no other choice. If the key accessibity issues are incorporated into work practices, meaning that issues are addressed in the early stages of a web project, there’s no need for accessibility to be hard, time-consuming or expensive, and I base this on over a decade of experience in the field.

So, with that in mind, here’s a list of the five most common complaints web developers have raised with me about accessibility and some practical tips on how to address them.

1.    Web accessibility can be expensive – if you only consider it at the end of a project

The biggest complaint people raise with me when I run workshops and training is that web accessibility is expensive. I’d agree that if you don’t consider compliance to the current WCAG standard during the development process then this is absolutely true. However, most aspects of WCAG do not require additional work, but rather provide a different way of working. For example, adding descriptive links instead of ‘read more’ isn’t much of an effort, making sure there’s an online language declaration can be done pretty quickly and not using colour to indicate a change of context doesn’t require any effort at all.  In fairness, there are some things that may incur an extra cost such as audio describing a video so I wouldn’t say definitively that accessibility costs nothing, but if staff are trained to incorporate web accessibility into work practices, the cost will be barely noticed in the budget of a typical web project.

2.    Web accessibility is time-consuming – if you don’t learn WCAG

It’s important to acknowledge right away that while the W3C’s current WCAG standard is a really big deal to me, it only represents a small part of what web developers need to consider. As such, I’m not asking you to dedicate your life and career to the pursuit of web accessibility, but it is important to be aware of what’s in the WCAG standard and how it applies to your work. I’d estimate that about two-thirds of WCAG 2.0 Level AA, the typical implementation target, requires no noticeable extra time in their implementation, it’s more about working smarter than harder. Granted that still leaves the other third but most of those get faster with practice only leaving a few requirements by my count that actually require a bit of additional planning. The upshot is that if you can get your head around WCAG and adjust your work processes accordingly, you’ll achieve most of the standard during the normal development process and will be able to plan effectively for the additional parts such as captioning a video – which is the next point on this list.

3.    Captioning a video is a pain – unless you’re aware of all the fantastic free tools out there to help you.

It’s interesting when giving a presentation just before a big web project, going through the WCAG 2.0 At A Glance document and hearing the groans when ‘captioning a video’ is mentioned as a Level A requirement. It’s been my experience that the rest are generally considered okay – no major complaints about alternative text, no issue with colour contrast, but captioning a video is perceived to be a big job. The important thing to acknowledge is that yes, captioning a video can be a big job, but it doesn’t have to be. There are many great free tools available to help you with this work, the first being YouTube’s automated captions in which Google can caption your video for you and you can use those captions for other projects. Importantly these captions are unlikely to be 100% accurate, and depending on the audio the quality will range significantly, but what the auto-captions are able to do well is get the timing right which is half the battle. After that you can then turn to many of the other free captioning suites online, or do your captioning from scratch if the auto-captions just don’t work. My personal favourite online captioning tool is Amara.org but there’s one built into YouTube itself and WGBH’s recent tool CADET is getting great reviews as well. In the course I teach, we have a captioning assignment and most students go into it thinking it’ll be really hard work and are generally surprised at how quickly and easily captioning a video can be done with the right tools.

4.    Accessible websites can be boring and ugly – if you’re not creative enough

If I didn’t have people storming my house after my opening remarks, they probably are now. However, it is important to address this reoccurring point that ‘accessibility = boring’ or ‘accessibility = ugly’. The first point I’d make here is that WCAG was not designed to stop your creativity. In fact, the millions of people with disabilities out there that use the web want to experience your creativity, your flair and your hard work, so please don’t hold back! Secondly, there’s lots of great websites out there that demonstrate you can be creative and accessible. The BBC website is one of the most media-rich websites in the world and has everything from videos to children’s games, and has consistently done a great job in making things accessible. As mentioned previously, most of WCAG is about the way you can do things, not an extra thing to stop you doing things, so keep the creative ideas flowing so we can all enjoy them.

5.    Accessibility can affect security – until you use the techniques that give you the best of both worlds

Out of all the complaints listed, this is the one that in my opinion is the most legitimate concern. You don’t have to look too far in the news to witness cyberattacks sweeping the world, and there’s no way security should be sacrificed to make a website accessible – and I’m absolutely not asking you to do so. Security issues generally need to be dealt with on a case-by-case basis, but what I would say is that in most cases there are accessible ways of implementing popular security mechanisms on a website.

For example, I’m often asked about CATPCHAs. I’ve recently completed some research as part of the W3C Research Questions Task Force (RQTF) and it’s pretty clear from the literature out there that traditional CAPTCHAs are no longer as effective as they used to be. As such, it’s important to consider alternatives not just for people with disabilities or people unfamiliar with the English character set but to also get something with improved security. E-mail verification, for example, is a popular alternative that is generally considered more secure and accessible.

A second example is giving people more time to complete online processes such as accessing government records. Understandably for security reasons you don’t want to leave this open to anyone for very long, but WCAG says people should have enough time. One solution is to provide a ‘+5 minutes’ button on the website. This confirms that the user is still present which addresses the security concerns, and also provides that bit of extra time needed for a person with a disability using a screen reader to complete the task. These are just two examples and in most security-related scenarios presented to me I’ve been able to find a solution that works for everyone. Furthermore, with more developments in biometrics and alternative authentication techniques it’s likely this will become even easier to address in the future.

So that’s a short overview of the five most common complaints made to me regarding accessibility and some practical tips on how to address them. If you’d like to keep up with other accessibility news you’re welcome to subscribe to my newsletter by e-mailing newsletter@hollier.info  with ‘subscribe’ in the subject line or you can follow me on Twitter @scotthollier.   

Published incommentary