You have 1 article left to read this month before you need to register a free LeadDev.com account.
Are we giving accessibility the attention that it demands?
As a tech lead, you probably find yourself involved in conversations around things like resourcing, coaching, and how to evaluate the success of your team. There are many questions you’ll ask and decisions you’ll make that ultimately determine the quality of your product. There’s one question though, that needs to be asked a lot more: are we giving accessibility the attention that it demands?
This question should already be being asked regularly throughout every project, but the stats suggest otherwise. In a recent study, 97.4% of the 1,000,000 most popular pages tested failed automatic checks against the Web Content Accessibility Guidelines, with an average of 51.4 distinct accessibility errors each. Low contrast text, missing alt text, incorrectly labeled forms, poor usage of ARIA attributes: the list of issues is as long as the list of excuses. Whether this is due to a lack of time, gaps in knowledge within the team, or even a complete lack of awareness around accessibility, these are all things that you can help to mitigate.
If you’re involved in making websites, apps, digital tools, anything that has the aim of being used by people, you should be striving to ensure that it can actually be used. Not by a particular demographic of people. Not by the people who you think best constitute your users. Everyone.
That’s not to mention the fact you have a legal duty to meet accessibility requirements, or that by doing so you can tap into the lucrative ‘purple pound’. This goes way beyond that. 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 that universal access today.
Inclusivity benefits everyone
Even the best user research can’t tell you the individual circumstances of every user that visits your site. With people with disabilities making up 15% of the global population (and that’s not including folks with situational disability), it’s fair to assume that one of those 1.2 billion might visit your site. Even if it were true that no folks with a disability will use your site (spoiler: it’s not), you still need to ensure that it’s accessible. The work you do under the guise of accessibility will benefit many more people than you perhaps considered, thanks to what is referred to as the curb cut effect.
Curb cuts (or dropped kerbs) are the little slopes from a pavement to the road, usually at designated crossings. They are so ubiquitous nowadays that you probably take them for granted. But it wasn’t long ago that pavements ended abruptly at the roadside, making it difficult for wheelchair users to cross safely. Thanks to activists like Ed Roberts and John Hessler who campaigned to get curb cuts implemented in their local area, and a wave of activism supporting the Disability Rights Movement in the decades that followed, curb cuts today are mandatory in many countries.
Angela Glover Blackwell, founder of PolicyLink describes the curb cut effect: ‘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.’
Subtitles (text captions) are another example of an innovation developed in the name of accessibility that has benefits for all. Initially primarily used by those in the Deaf community, they are now widely embraced, for example, when watching clips in public places, or learning foreign languages. Even the technology around captioning has had knock-on benefits: automatically generated captions can be derived from videos, audio recordings, and even still images, potentially saving hours of time for content teams.
Digital curb cuts
On the web, there are a number of things that have their own curb cut effect. Semantic markup, clearly separating content and presentation, implementing useful labels and messaging, considering the scalability of a design across devices, appropriately communicating state changes, flexible 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, from SEO to the ability to share content across different platforms.
Of course, the curb cut idea isn’t the primary reason for focusing on accessibility. You should be doing that anyway. But the fact that some improvements can benefit a wider group is a bonus. Often, when you do the right thing in the first place, good things will continue to come out of it.
Embed it in your team
The best time to think about accessibility for your project is long before it starts. If you missed that, then the next best time is now. In your next sprint, rather than adding new features, look at allocating time towards improving accessibility. Don’t end up with bags of experience debt; instead work on the core features, ensuring that the key journey is as good as it can be for everyone. This isn’t merely about providing access – it’s about providing an equal experience. Access is a very low benchmark when what you should be striving for is equal enjoyment for people whatever their requirements.
In some projects, accessibility considerations only come in during testing, when the QA team is expected to highlight any issues that may be present. Testing is of course an opportunity to understand what may be going wrong, and there are many great tools available to specifically check against accessibility guidelines, but accessibility issues are not bugs and shouldn’t be considered as such. Perhaps you’ve even brought in an external accessibility expert to provide an audit of your work. Again, this can be valuable, but any review at the end of a project should be to verify you’ve done good things, not to spot problems for the first time.
Many of the difficulties developers have with implementing accessible features stem from having to make concessions at a late stage of a project and reworking existing code. Yes, there are aspects of developing accessible sites that can be tricky, but there is so much documentation available, and so many examples to draw from, that learning these techniques is possible for developers with any level of experience.
If you can ensure that accessibility is considered from the very beginning, not only will you save time and effort, but you’ll be able to evaluate each decision with inclusivity in mind. Every piece of work should have accessibility written into its requirements and should be tested as it’s built. By introducing incremental improvements throughout a project lifecycle, and taking the learnings from each stage into the next, you can avoid extensive (and expensive) retrospective fixes.
Inclusivity from start to finish
Ultimately, it’s your users who define the success of your work. But if you’re leaving it to your users to let you know if you’ve done a good job at the end of a project, you’re taking a big risk. Not only should you be getting work out to users as soon as you can (during a project) for feedback, but you should strive to have a diverse group of people contributing to the project in the first place. If you can specifically include human differences in your team, you’ll not only end up with more robust and inclusive products, but your team will be more creative and innovative. Feedback is great, but co-creation with people who have disabilities is even better. As the saying goes, nihil de nobis, sine nobis (nothing about us, without us).
Getting accessibility right doesn’t happen overnight. To be truly successful, it requires buy-in from everyone, at all levels of your business and from each team within it. From design to UX, frontend to backend development, QA to CMS integration and content, each discipline comes with its own set of challenges regarding accessibility. As long as everyone keeps in mind that the real reason they’re building anything at all is for people to access it – whoever and wherever they are – then that’s a good start. They may need training and time to learn. They may need support to have these conversations in the first place. They may need someone raising awareness in your organization. They definitely need someone asking, ‘are we giving accessibility the attention that it demands?’. That’s where you come in.
