The Accessibility of Rabbit Holes

Cargo recently attended a brilliant Frontend NE talk given by Amy Hupe and Tim Paul titled ‘A design system for everyone’. Both Amy and Paul work for the Government Digital Services (GDS) and their dual-talk covered their design systems, approach to accessibility, the WCAG 2.1 guidelines AND community involvement all the while straddling the upkeep of their open source codebase. It really was a great talk.

There were a lot of take aways from the talk (not just the pizza *chuckles*) but the area that stood out the most to me was from Tim’s foray into the accessibility of various components within the GDS’ design system. He displayed examples of how they have tackled radio buttons, checkboxes, colours and plain old links to ensure the website can be used by absolutely anyone, regardless of how they are interacting with their system. It was very honest and even showed that a solution they had implemented for a long period of time actually made a part of their codebase inaccessible for some users. He showed that, for total accessibility, even small things like making a link look like a button required in depth consideration – it’s not just a visual challenge, the correct aria role needed to be added along with javascript solutions to cover keyboard operability. Like I say, things are hard.

Rich, meet Rabbit Hole. Again.

• How can we, at Cargo, introduce something similar to the design system?
• Do we need to?
• Is it even possible when we work across such a broad range of websites?
• Accessibility is already a core part of our offering, but how can we improve that?
• How long will that take?
• Are clients willing to allow budget for more accessibility resources?
• Are we, even?

It all comes down to budget and resource.

*Thud*

Inevitability? Is that you?

Every website on the internet should allow all users to achieve their goals, or the goals the website requires of them. It’s pretty simple. But it’s also not.

Users may struggle to get around a website for a myriad of reasons. For example, your users may have the inability to use a mouse and / or a keyboard or may require assistive technologies such as screen readers to navigate. Have you tried browsing your favourite website without using a mouse or have you tried purchasing a product using only a screen reader for interaction? It’s really tough. Like, REALLY tough.

As an able-bodied user, it’s very easy to ignore and overlook how hard it actually is to use the web and that can lose you business. You wouldn’t open a toilet roll store and build an assault course in-front of the tills. That would be insanity – unless your target market were marines after their full English breakfast and morning coffee.

The web has historically been incredibly inaccessible. The lack of technology – user assistive technology as well as what browsers can actually parse – is a big player, and can be blamed quite easily, but more recently how our code is structured and organised can make a huge difference to aiding users. It can also make things even worse.

By sheer coincidence, the next podcast on my list (well, the one AFTER an unrelated Hearthstone podcast – yes, I’m that much of a nerd) after the talk was episode 355 of the ShopTalkShow – Accessibility with Heydon Pickering. Although the episode was hilariously off-topic in some places, the accessibility discussions were really interesting.

Heydon, among many things, is a freelance web accessibility consultant. It’s pretty much his job to help companies and agencies build accessible websites for their users. In the podcast he mentions an experience he had when consulting a company who had already tackled some accessibility challenges and had put some solutions in place, which is great. What Heydon found was that a stray aria role (in this case role=“switch”) was being used in slightly the wrong place. To most users this wouldn’t affect anything. However, to some assistive technologies, this stray aria role make the website inaccessible. The whole page’s text was read as one paragraph causing content consumption to be pretty much impossible. The aria role was added to help with accessibility and, in doing so, actually did the opposite.

Oh, you’ve already met Mr. R Hole? You may resume your plummet.

• We can add solutions to code to help assistive technologies
• Some of them (aria roles) make a lot of sense
• Knowing a bit is great and can make a difference
• Only knowing a bit can also fluff things up
• Is it better to try these things and hope for the best?
• How can we possibly test everything on every project before launching?

It all comes down to budget and resource.

De ja vu?

It’s pretty straight forward though, right?

The Web Content Accessibility Guidelines (WCAG) ‘…develops international Web standards: HTML, CSS, and many more.’. They provide pretty strict guidelines to ensure your website is accessible which works almost like a checklist. A really long, intimidating checklist.

For the most part, what they ask for is pretty obvious.

• Don’t use a text colour that is illegible against it’s background
• Don’t make your text too small
• Make sure you have hover and focus effects on interactive elements across the board
• Don’t have things flying around the screen at great speed
• Give users enough time to interact with content or inputs / actions
• Don’t flash colours / images on the page in quick succession to advertise your nefarious schemes etc.

Summarising there, of course, so don’t quote me too hard.

When building websites, Cargo aim to cover as many of these off as possible from the outset and more often than not we do. After all, building an accessible website is much easier / better integrating solutions from the outset than trying to retrospectively rework sections to fit the guidelines.

Saying that, honestly, we aren’t accessibility experts. We have a love for the web and aim to design and build our websites for all but, without the budget, we simply can’t always deliver AAA WCAG compliant builds.

The great thing is, that’s ok.

Accessibility is and incredibly interesting challenge, and one I personally enjoy tackling when I come across an issue, but it’s very situational and dependant on what is trying to be achieved within the project.

It’s also an incredibly complex part of the web that requires specialisms of it’s own. People, and consultancies, like Heydon who can advise on how to approach more technical functionality, suggest focus testing groups and push toward making the web a much more accessible place are a valuable resource.

Maybe, together, we can change the ‘inevitability’ from “The website looks good to me, we don’t need further testing” to “Let’s allocate more budget to testing so this website is for everyone”.

As I brush myself off and pick the soil from my teeth, I take a step forward. The ground seems firm. Is that the end? Is that all you had for me? A second stride forward sees me flopping down. My eye catches a glimpse of a sign post pointing into the abyss. ‘What is a Front End Developer?’.