For my first role as a web developer I worked for a council in the midlands providing public facing applications for the housing department.
This was back when no one was browsing the web on smartphones or tablets and the majority of people used Internet Explorer, whilst the intelligent few favoured Firefox.
The first port of call for QA on any piece of development was to run it through the W3C markup validator and then through AChecker to check for AA accessibility compliance. Any issues, and the code was sent straight back to the developer to fix. As a new developer, you can imagine how frustrating and restrictive this sometimes felt. However, it has led to my continued interest in the topic of accessibility.
So what is accessibility?
The traditional definition, as quoted by W3, isn’t written in the clearest of languages but reads as follows:
However, with the emergence of handheld devices and smart TVs over recent years, I consider accessibility to now mean that any site should be usable on any device within reasonable limits. This could mean users with an old phone, a slow internet connection or a wide screen TV.
Responsive, mobile-first development has become the default for most developers whilst newer trends continue to drive change, trends such as Accelerated Mobile Pages (AMP) and following an offline-first methodology.
Why is it important?
First of all, it’s actually the law in some countries, and this is often forgotten. There are a number of cases in the past where companies have dealt with lawsuits resulting from discrimination on their website. Royal National Institute for the Blind (RNIB) launched a fairly high profile case against BMI-baby in 2012 for this very reason.
However, the biggest drive for me is to develop applications that avoid discrimination completely. As a society, I like to think we’re fairly progressive and inclusive in the physical world. However, as web developers, accessibility can sometimes be one of the first things we drop, often deemed less important and sometimes met with the attitude that it can be retro-fitted later if there’s time, which there never is. This becomes even more tempting when developing internal facing applications for clients where we know the current users may not immediately benefit from image alt tags, keyboard only interactions, video transcripts or mobile first development, for example.
That said, I would encourage everyone to build good accessibility practices into their workflow from the start. We can’t predict who will be using the application in the future or who might access it through their smartphone on the way home from work. Why would we want to prohibit anyone from using our work?
I actually have a mental checklist of sites I avoid on mobile and I’m sure I’m not the only one. If they appear in search results, I skip over them knowing I’ll receive a poor user experience. If a mobile enabled site was prioritised, then this wouldn’t be an issue.
A less concrete reason for building accessibility into any application is that it makes you look good as a developer and/or the organisation you work for. If you can state your application complies with Web Content Accessibility Guidelines (WCAG) 2.0, no one is ever going to think that is a bad thing.
What can we do?
There are a number of resources on the internet for helping with accessibility, here’s a couple I’ve found useful:
Along with these, I’ve added a few more techniques that have helped me.
IDE tools and extensions
Fortunately as the community has now realised the importance of accessibility, a number of tools have been developed to help us. I would encourage anyone to look into accessibility plugins for their IDE of choice. For me, due to using react on my current project, I’ve been using jsx-a11y eslint plugin. It’s been essential in not letting me get away with poorly structured JSX.
Using semantic HTML is one of the biggest changes you can make, utilising HTML elements the way they are defined to be used. HTML5 added a number of new elements, which further helped with this and avoided such widespread divitis.
Too many times throughout my career, I’ve seen HTML like the following:
Authors of such code claim that it gives them more flexibility and greater control over how users interact with their site. I’m not convinced.
WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is a specification defined by W3C. It is primarily used to add further context to the page for screen readers. This is achieved by adding additional attributes to HTML.
An example might be something like:
<div role=”dialog” aria-labelledby=”dialog-title”>
It also enables you to use elements for an undefined purpose. For example, you could write:
<span class=”custom-button” role=”button” tabIndex=”0”>Submit</span>
I would recommend for everyone to get familiar with ARIA, even if it’s just an overview.
Check whether your browser of choice has developer tools that can help you. For example, Chrome Accessibility Developer Tools allow you to run an audit on your page giving you a summary report of what is right and what can be improved. This can even help with colour contrast issues.
Test your website with the screen reader built into your operating system. If you’ve never considered accessibility before, the results can be quite amusing. What makes sense to you when you can see the overall context of a page might not be something as literal as a screen reader.
In general, CSS has a smaller impact on accessibility as HTML. However, always using relative font sizes, ensuring there is enough contrast between fore and background colours, and, in most cases, not hiding elements from the user with display: none or visibility: hidden are good places to start.
This post isn’t supposed to be an in-depth analysis or user guide to accessibility. It is such a large topic and there are plenty of resources already on the web. My intention was to simply share my opinion on why I think it’s important, and offer a few techniques I’ve used throughout my career that have proved effective. I don’t think anyone expects a site to be 100% accessible, but we should all do our part to improve it nonetheless