Skip to content

Category: commentary

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.   

City of Fremantle commits to escaping the accessibility island

I recently ran a workshop titled ‘Escaping the Accessibility Island’ for approximately 40 people at the office of the City of Fremantle. The workshop was designed to support the City of Fremantle as it continues to update its web presence and the accessibility of public-facing ICT infrastructure by incorporating digital accessibility techniques across different organisational roles.

The workshop included a hands-on practical exercise of using a screen reader, an overview of the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0 and how it applied across a variety of roles including policy officers, ICT professionals, content producers, marketing staff and communication specialists. The workshop also provided some insights into how to perform visual checks on web content and use an automated tool.

While the workshop provided valuable information in how staff can incorporate accessibility into their work practices, there was also a lot of fun had by all as the practical aspects of digital accessibility were explored.  I’d like to take this opportunity to sincerely thank everyone at the City of Fremantle for the opportunity to provide you with accessibility training.

If you would like to have a digital access training workshop run for your organisation, you’re more than welcome to get in touch.  All the details can be found on the hollier.info Contacts page.

Screen readers and web browsers – what’s the best pairing for testing?

Testing web content for accessibility can be a difficult task, but fortunately there’s some great guidance from W3C in the form of the Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0. However, many people get stuck at Step 1 – defining the evaluation scope.  While setting a conformance target is generally straightforward such as WCAG 2.0 Level AA, it’s much harder to decide baseline-related issues such as which assistive technologies should be used for testing against the WCAG 2.0 Success Criteria and in which browsers the content should be displayed.  Recently encouraged by a student question in the course I teach, I’ve put together some information on the topic for you to consider.  

Before outlining my thoughts though there’s two important things to keep in mind: firstly, if you are doing a web audit for a client, the answer to ‘what browser and screen readers should I use to form a baseline?’ should generally be answered as ‘whatever the client wants’.  You’re certainly welcome to point them to this post if it helps to explain your point of view about accuracy of testing, but I appreciate there may be very specific reasons why the client wants to test out, say, JAWS with Chrome.  While some pairings in industry may be unusual, there’s often a method to the madness especially in locked-down enterprise-level systems where the Standard Operating Environment (SOE) gets changed for no one. Secondly, keep in mind that this assessment is a point in time and is purely my opinion based on working in the industry and many anecdotal conversations with screen reader users, so this can change quickly.

With that in mind, here are my recommended pairings for screen readers and web browsers.

1.    NVDA and Mozilla Firefox

If you want to test in a traditional desktop environment on a Windows platform, it’s hard to go past NVDA with Firefox.  NVDA is a fantastic screen reader with the developers at NV Access working hard to ensure the screen reader is up-to-date with great support across a number of recent Windows versions.  In addition, updates tend to come out very quickly ensuring that it caters for changes to web standards and best of all, it’s free. 

 The benefits of NVDA are also in many ways the benefits of Firefox. The browser focuses heavily on standards-compliance with a legacy of effective support in this area and it plays very well with NVDA. As Firefox is also updated regularly you’re well placed to use these two together to maximise your accessibility testing with a degree of certainty for the results and at no charge to your organisation.

 2.    JAWS and Microsoft Internet Explorer

While NVDA and Firefox is arguably the most accurate paring for testing, there’s no denying that JAWS remains the king of screen readers and it’s likely that organisations will want to know how things go for JAWS users as a result.  In my opinion JAWS testing should remain with Microsoft Internet Explorer despite the browser being so old that its existence in Windows 10 is barely acknowledged to the point that you probably didn’t realise it’s still there.  The reality is that there’s still a lot of screen reader users that rely on old versions of JAWS due to the cost of upgrading, and its slow upgrade cycle has caused issues for it with other more modern web browsers.  People testing websites often get frustrated with this combination as Internet Explorer is not the most standards-compliant browser, and JAWS certainly has its own quirks so the two combined may show up errors that you don’t believe most users would experience, yet this pairing is still reflective of a large number of desktop users and you may need to consider this if your organisation has JAWS users.

 3.    VoiceOver (iOS) and Safari (iOS)

 With WCAG 2.1 on the way a time is coming when testing on a mobile will be an essential part of WCAG conformance, and with that in mind it’s important to know which pairing is best for mobile devices. On iOS devices such as an iPhone or iPad, it’s a pretty easy choice – use the built-in VoiceOver screen reader with the built-in Safari browser. Both work great together and in my experience there’s no other iOS browser that comes close to VoiceOver support.

 4.    Android TalkBack and Google Chrome

As noted above, with WCAG 2.1 coming it’s likely you will need to test on mobile devices, and the best Android option is to test using the TalkBack screen reader with the Chrome browser which works very well, better than any other web browser I’ve tested.  If you have to choose only one mobile platform for testing though I’d go iOS at this point as while Android dominates the market in the general population, Apple iOS is far more popular among people who are blind or vision impaired – and I’m acknowledging this despite being primarily an Android user myself.  That said, there’s nothing wrong in using Android for testing and if you do, go for TalkBack with Chrome.

5.    ChromeVox and Google Chrome (desktop)

From a  testing perspective, you may not be aware that there’ is a little-known screen reader tucked away for users of Google Chrome called ChromeVox, and this screen reader is also found in Chromebooks. While its not commonly used by people with vision disabilities, it can be a useful pairing for testing purposes  Just be mindful that while it can help pick up issues, the overall experience is not going to be reflective of most screen reader users hence its further down this list. That said, Chrome is an excellent browser and both Chrome and ChromeVox are free. Furthermore, given the popularity of Chrome as a desktop web browser there’s a good chance it’s already on your computer.

6.    Windows 10 Narrator and Edge – in the near future

 At this point, screen reader purists are likely to start questioning my sanity by including Windows Narrator on the list paired with anything. I certainly won’t argue that Narrator in Windows 2000, XP, Vista and 7 was a terrible screen reader.  However, updates in Windows 8 and significant improvements in Windows 10 including the Braille support coming soon highlight its significant improvements.  I’ve used Narrator for testing and while it should certainly be no higher than six on this list, it has the advantage of being built-in so people are likely to have it, and Edge is a reasonably standards-compliant browser – well, significantly more so than Internet Explorer anyway!  At the moment Microsoft still recommends Narrator users in Windows 10 use Internet Explorer, but with updates to both Narrator and Edge in the insider preview of Windows 10 likely to be released later in the year.  This will become an option for testing.  Not the best option, but good enough to be an option if your machine at work is locked down like a fortress and you have no other choice.  

7.    VoiceOver (Mac) and Safari (Mac)

I’ll be the first to admit that VoiceOver and Safari on iOS are fantastic, but VoiceOver on Mac OS and Safari on the desktop is in a desperate need for a massive overhaul.  It’s unfortunate that VoiceOver on a Mac is good enough that you don’t really need another screen reader, but not good enough when its functionality is compared to other screen readers on other platforms. If you specifically have a blind user in your organisation that only uses VoiceOver on a Mac, then your best option is to test the content in Safari. I should stress that my opinion here is not because I particularly dislike VoiceOver – indeed it was the introduction of VoiceOver in Mac OS 10.4 Tiger that is credited for having the first fully-fledged screen reader in a desktop OS and that deserves respect, but its way overdue for an update.

So that’s a bit of an overview of my favoured pairings of screen readers with web browsers from a testing perspective.  Hope it helps.