Web accessibility – ensuring that websites can be accessed by anyone, regardless of any disability – is far from a new topic. The idea of universality is one of the core principles of the web, as outlined by Tim Berners-Lee way back in 1989, and having an accessible website is a fundamental part of being able to provide that universal access today.
Unfortunately, even after three decades of ‘surfing the web’ being a thing that people do (I miss that phrase – petition to bring it back), many sites are lagging behind where they should be in regards to accessibility.
A recent study by WebAIM (Web Accessibility In Mind) of the top 1,000,000 home pages produced some startling results, showing that at least 97.8% of the pages tested failed automatic checks against the Web Content Accessibility Guidelines (WCAG), with an average of 59.6 detectable errors each.
As a developer who strives to make dynamic, rich content sites, I know from experience that it can seem difficult to handle the relationship between form and function. I couldn’t hand-on-heart ever claim that every page I’ve ever worked on is 100% accessible. In fact, having spent my early career working with Flash, I know full well that I’ve put some things out there which I’d rather gloss over now for the purposes of this post.
I definitely understand some of the difficulties that people have when trying to reach the seemingly mythical Level AAA WCAG compliance. However, what we’re seeing is not just that sites are failing to hit AAA, they’re failing at the first hurdle by not implementing some of the most basic attributes of an accessible site. The WebAIM report goes on to highlight that:
- Low contrast text was the most common detectable issue, with an average of 36 instances of low contrast text on each home page
- One-third of all images (12.3 images per page on average) were missing alternative text
- 59% of form inputs were not properly labelled
This is fundamental stuff, and not knowing how to technically implement these features is unlikely to be the issue. Yes, some aspects of developing accessible sites can be tricky – but there is so much documentation available, and examples to draw from, that learning these techniques is possible for developers with any level of experience. The issue then is potentially one of time, but I think more than that, one of motivation.
Treating accessibility as a priority
Accessibility can still regrettably be treated as an afterthought, and sometimes isn’t afforded the same attention and resource as the rest of the build process. Far too often it’s left to the end of a project, with awkward fixes put in place once someone happens to notice that a menu item can’t be navigated to with a keyboard.
I feel like part of the umbrage that some developers can take toward implementing accessible features stems from having to make concessions at a late stage of a project; reworking existing code, or wading through the results of automated tests can be such an inconvenience when you thought you’d already finished.
The solution to that is of course, to embrace the importance of factoring it in from the beginning and making it part of your everyday approach to work. Everyone involved in a project, from project manager to QA, needs to appreciate that if there is any additional time required to develop accessible work – and there may well be, particularly at first – then that will ultimately benefit their entire audience.
I’ve seen people use the claim that “this site isn’t aimed at people with disabilities” as an excuse for not providing an accessible site, but (as well as being grossly offensive) this is woefully inaccurate.
You have no way of knowing the individual circumstances of every user that visits your site. There are over 13 million people in the UK with a disability (according to the Disability Living Foundation) – that’s almost one fifth of the population – and even if by some bizarre set of circumstance it was true that none of them ever attempted to use your site, that’s still no reason not to ensure it’s accessible.
Inclusivity helps everyone, whether you notice it or not
Making an accessible site isn’t something you do ‘only for people with disabilities’. The advantages of actively considering what users need will be appreciated by all. This is sometimes referred to as the curb-cut effect – something that was ostensibly implemented under the guise of accessibility, that is also utilised by many more people.
The term concerns those little drops on curbs at crossings which are so ubiquitous now, that most people take them for granted. But there was a time when curbs simply ended at the roadside, placing at worst, a literal barrier in front of people using wheelchairs to get around, and at best, an occasional trip hazard.
It took campaigning by activists like Ed Roberts and John Hessler (originally focused at UC Berkeley) to get curb-cuts implemented in their local area, with further protests in the 1970s and 80s continuing to bring attention to disabled rights. Today, curb-cuts are one of the many lasting outcomes of that era – they’re used as de facto crossing points by people of all abilities, and it’s noticeable when you encounter a crossing that doesn’t have one.
As Angela Glover Blackwell, founder of PolicyLink describes:
When the wall of exclusion came down, everybody benefited—not only people in wheelchairs. Parents pushing strollers headed straight for curb cuts. So did workers pushing heavy carts, business travelers wheeling luggage, even runners and skateboarders. A study of pedestrian behavior … revealed that nine out of 10 “unencumbered pedestrians” go out of their way to use a curb cut.
Out there, in the real world, there are many other examples that follow the same pattern as the curb-cut effect; innovations done in the name of accessibility and inclusivity which have wide-reaching benefits for all.
Source: Tenor GIF Keyboard
Having grown up in a predominantly deaf household, I remember the days when subtitles (text captions) on television programmes were a rarity, only ever used by those in the Deaf community. Today, captions on videos are almost the default and the benefits of displaying what is being said on a screen are now felt by many more. Whether merely watching clips in a loud public place, or utilising them to get to grips with a foreign language, captions mean that video content can be consumed and understood in a wide range of circumstances.
When it comes to building for the web, there are a number of things that each have their own ‘curb-cut effect’:
- Semantic markup, clearly separating content and presentation
- implementing useful labels and messaging
- considering the scalability of a page across different devices
- appropriately communicating state changes
- thinking about typography
- ensuring navigation is possible regardless of the input method
…the list goes on. These are all things that have clear accessibility benefits but also a range of supplementary advantages that will be felt by many people. Those other users might not necessarily be the initial target audience of your accessibility work – they might not even notice it – but they’d definitely notice if you get it wrong.
If you’ve ever wrestled with a multi-page form only to have it time-out before you get to submit, or tried to read a page with tiny grey text whilst on your phone, then you should be able to appreciate why accessibility issues don’t just affect people with disabilities.
The ‘curb-cut’ idea shouldn’t be seen as a reason for thinking about accessibility. You should be doing that anyway, but the fact that some things turn out to also benefit a wider group of people is a nice bonus. The outcome of doing the right thing in the first place is often that good things will continue to come out of it.
Accessibility is more than a checklist
Making an accessible site is not a zero-sum game where providing an accessible interface means that design or other functionality has to be scaled back. Not every site has to end up looking exactly like gov.uk (that’s not a dig – I do actually love the work they’ve done on that site).
It’s also more than simply running an automatic test to evaluate a page. There are many tools available which can highlight and assist with many accessibility issues: the axe extension, Google’s Lighthouse, and Accessibility Insights from Microsoft are just some that can be easily integrated with your workflow to help the build.
But in much the same way that passing a spell-check doesn’t mean that a document actually makes sense, your approach has to be more considered than merely pressing a button and working through the list until there are ‘no errors found’.
Beyond the automated checklists, there are some methods you can adopt to try to emulate common situations, like actually trying to navigate only using a keyboard, or installing and running a screen reader – but even then there is no real substitute for meeting and talking to people, witnessing their experiences and learning from them.
Have a little empathy
It hopefully goes without saying at this point, but pursuing accessibility is way more than just making sure you meet any legal requirements so you don’t get sued one day. The fear of prosecution might be one very tangible motivator for some, but the underpinning reason for doing this work is because it’s the right thing to do.
I’m a big fan of the idea of Empathy-Driven Development – a term I first saw used in this great talk by accessibility advocate Marcy Sutton – and I wholeheartedly agree that it’s a mindset that benefits all users. The ‘empathy-driven’ approach doesn’t just apply to developers: everyone involved in the creation of a website should adopt it. From design to UX, front-end to back-end development, QA to CMS integration and content, each discipline comes with its own set of challenges. As long as everyone keeps in mind that the only real reason we’re building a website at all is for people to access it – whoever and wherever they are – then hopefully it’ll be as good as it can be.
Ultimately, it’s your users who define the success of your work. Making it inclusive from the start makes it better for everyone.