Published on: 8th June 2020
Have you ever tried using a website with your eyes closed? Have you ever been without a (computer, not pet) mouse? Are you short of sight or colour-blind? You've definitely had a slow internet connection before, had to decrypt paragraphs filled with nonsense or squint to read something on your smartphone.
In those situations, you've been hampered by inaccessibility. You may not even realise it; we're all used to blaming computers or weak connections. Sometimes we'll even blame ourselves. But that’s where accessibility comes in – no matter the person, technology or situation (within reason), they should get a more or less equal experience. It’s much further than disability, or a site not being ‘for’ a user because they have an old phone or a rural broadband. A website, especially in the public-sector, should aspire to cater to everyone.
Outside the box
In comes the mindset you have to have to approach accessibility with. As a developer, designer, strategist, whatever the title - great, it's pretty and works for you in the scenario you're in right now. What about the long list of other situations and needs that will, at some point, want to experience it too? Are you going to consider those?
To be denied use of an inaccessible website is a sort of arbitrary exclusion. Imagine being told you can’t go walk down that street to get to the corner shop, while you see that other people can. There’s no defined reason, but their situation is perfect for that street; yours isn’t. Maybe you’re wearing the wrong type of shoes, and that street wasn’t designed for your shoes. They’re old… the architect didn’t consider shoes that old.
A lot of the web will be inaccessible to a lot of users for that very reason; it’s just not at the forefront of our minds. When there's so much to plan for anyway through the process of creating a website, what's to take priority? Given that accessibility doesn’t to affect you directly - at least in any way you've noticed – it won’t come close on that priority. We're just tackling what's in front of us. After all, not only are those old shoes not your shoes, they’re not even the shoes of the majority of your users.
To think about web accessibility is to think outside of that narrow box.
Accessibility has always been on our radar at Frank. Our accessibility toolbar is very much proof of that; it's been around for a while, has had numerous iterations, and adapts sites to different languages, contrasting styles for colour-blindness, and text sizes for those needing larger or smaller text. And it’s not the chequered flag, but you’d rather have it than not.
The end goal
So if not a toolbar that does those things, then what is the chequered flag? What are we actually aiming for? That's where Web Content Accessibility Guidelines (WCAG) 2.1 come in. First published in 1999 by the Worldwide Web Consortium (W3C), these guidelines outline best practices for an accessible website. If you're not sure who the W3C are, they're the organisation responsible for maintaining and progressing web standards. And if that doesn't convince you, it's led by Tim Berners-Lee, the inventor of the World Wide Web; good enough for me.
Based on complexity and reachability, those standards are classed from least to most challenging as A, AA or AAA. In the UK, Government Digital Services only recommend that you should be aiming to meet all A and AA standards. That's great, because if every website had to tick every AAA box as a minimum, web developers would never sleep.
Even then, the A and AA standards are designed to cover a wide range of needs on an accessible web. From colour schemes, imagery and the text on a page, to the code the user experience, the assistive technologies and their interactions. It all contributes to what’s in front of the end user and, if executed poorly, could all lead to a bad experience.
Strategy
Meeting those standards is a matter of compromise. Those colours look great together, but the contrast isn't high enough so a number of people will struggle to make them out. The page of content you've just written - it makes sense to you, but how many people know what all of those abbreviations and acronyms mean? While planning this new feature out, are you putting function over form, a complex search mechanism for the 1% over something everyone can make use of? Are you keeping screen reader users at the front of your mind?
At Frank, approaching the prospect of this becoming a standard across the public sector, we knew we’d have that new bar to work to. As noted, what we were already did matter… in as much as it alone ticked a handful of the 50 or so boxes. With that came hours, on hours, on hours (on hours…) of reading and explaining, research and testing. Life became accessibility, and websites that aren’t fully or even trying to be accessible are doing an injustice to their users.
It very much goes across the board, with knock-on effects on design, development and even scope. To speak from my own position, developers have had to learn a lot, with a need to take a good quality of code even higher. I coined the term of ‘accessible-first’ code. The earlier we think about accessibility, the better the end product.
We’re all acquainted with technologies like screen readers; to speak for myself again, I now know what they’re going to say without even testing with them…
And as much as has been done, there’s always improvement to be had. We’ll keep moving forward, keep learning and researching. One day there will be WCAG 3.0 with a revised set of standards to meet to the ever-updating technologies of the web, and we’ll kick-off all over again…
Breaking the rules
That all begs the question – should everything be accessible? Should the entire web be aiming for these standards? In terms of aiming, yes. If it’s actually possible for you to cater to and include a wider audience, I think you probably should.
But that’s where there are sticking points. In the realm of possibility that is web technologies most of it evolves every day, nothing is perfect, and there are only a few golden eggs (if any) who know it all. New technology X isn’t accessible day one, but it pushes the web in other ways that we haven’t seen before. That’s great, we need that – if accessibility were in the way of everything, we’d wouldn’t move the web forward.
As such, very often in the name of innovation, innocence, of time and cost compromise… accessibility will fall to the wayside, and justifiably so. That’s absolutely fine; it’s not about being perfect and ticking every box any more than it is having a reasonable go at doing what’s possible. Not every function developed will work with screen readers, not every colour scheme designed will be optimal for everyone.
Inclusivity is the real goal and in the path to get there, even if you know you can’t take action, thought (and just a bit of effort) matters a lot.
Action
The good news is that we all have a role to play! I mention the team behind the website, designers, developers and the like – their role in web accessibility is much clear, as the web and surrounding technologies are part of their job. But what about the person in-between? Perhaps you manage a website or are part of a wider team.
So here’s one of the things we can all do: write accessible content. Government Digital Services provide some great advice for writing on Government sites, but we’d do well to apply much of it to our own as well! Section things clearly with headings and paragraphs. Write shorter, simpler sentences. Avoid jargon and spell acronyms out. For the most part, that's everything that I haven't done here… And try to think about it everywhere; Twitter is an accessible platform, but your Tweets are only as accessible as the words that you string together. Think about who will really be reading this, take a moment to write it for them in a way that actually makes sense.
I like to think I’m fairly attuned to all of this, but for years I hated reading the abbreviation ‘ICYMI’ just because I no idea what it meant, but I saw those 5 letters everywhere. Often I’d just click away. For reference that stand for ‘In case you missed it’. Unfortunately that’s a really helpful notice; it’s highlighting an event that is in my interests, making sure it didn’t slip under my radar. But speaking from my own experiences, if I can’t get past the first abbreviated word, is there much to encourage me on?
I’m guilty of the Twitter thing too. I’ve not personally written an ‘accessible content’ guide, but we’ll start one now with ‘do as I say, not as I do’.
Cameron Barnes, Front End Web Developer, Frank