Large web teams are usually siloed with specific responsibilities. Developers handle the technical stuff like the architecture, navigation, and code, while content editors add all the words, pictures and, well, content.
But when it comes to accessibility, it’s not quite as clear-cut. Does responsibility for accessibility belong to developers or to content editors?
The answer really depends on who you talk to. Accessibility can be pretty technical. In fact, if you read through the Web Content Accessibility Guidelines (WCAG), you probably won’t understand it. Any content editor would look at it and tell you that it’s clearly a developer’s responsibility because of the jargon and the talk about web code.
(As an aside, here’s a video that explains WCAG in less than two minutes from our ‘Don’t be afraid of accessibility‘ series).
Video Transcript
Wuh-cag, W-cag, W-C-A-G… The way you say it varies, but the rules are universal. Did I say rules? They’re actually guidelines. Insert a witty pirate joke here.
The Web Content Accessibility Guidelines are a list of rules- just go with it… -for making the web available to everyone. This may seem daunting at first, but I’m going to walk you through it.
You often hear or see things like “You must be compliant with WCAG 2.1” What does that even mean? Let’s break it down a little.
WCAG has a standard like 1.0 or 2.1, and a level that’s A, AA, or AAA. At Silktide, we like to say that A is must do, AA should do, and AAA is… reaching for the stars.
So when the legal requirement is WCAG 2.1 AA, it means it’s using the latest standard (2.1) and level AA (the middle one). AA is tougher to master, but still well within the reality of the web today.
All the guidelines are numbered, like 1.4.1 Use of Color. This is a single A requirement and it covers a fair bit of ground. Inside that guideline are success criteria. One such criterion is “Links must be distinguished by more than just color”. We have a video on that topic in this series! But it also covers things like not using color for instructions, like “Red fields are required” or making visuals like pie charts with no labels or patterns to discern the segments.
See, that wasn’t so bad, was it? Now go tell your friends!
Everyone deserves access to the internet if you need help getting your website up to scratch, visit silktide.com
But developers only take care of building the site and its architecture. They’d tell you that they’re not responsible for the content that’s added to it. That’s usually either the marketing department or individual contributors’ responsibility.
So, who’s right?
The truth is, both are. Everyone’s responsible for accessibility.
What is content accessibility?
Content is made up of many individual components. Firstly, you have words and sentences. Then you have images. Then you have methods of presenting those, like a web page with headings and paragraphs, or PDFs and graphs or tables.
Each of these needs some consideration for accessibility.
Long, technical, and hard-to-read sentences make it more difficult for people to understand what you’re trying to say.
Images mostly require text descriptions (although, not always), which assistive technology users rely on to understand their contents. For example, screen readers read out the text on a page, including image descriptions.
Videos require captions, subtitles, and audio descriptions.
Text should be correctly formatted with semantic heading structure (basically, getting your headings in the right order). It’s vital to make a better experience for screen reader users and those navigating with a keyboard.
PDFs are basically terrible and you shouldn’t use them, but if you do, you should try your best to make sure they’re tagged correctly.
As you’ve probably gathered, all the items in this non-exclusive list are the things that content writers contribute to the website. So they don’t fall under the developers’ responsibility.
What is technical accessibility?
When people navigate your site using a keyboard, they get different feedback than if they were using a mouse. By pressing Tab on your keyboard, web browsers allow you to skip through each link on your page. They’ll also get a visual representation of where on the page they are by the use of focus states.
Here’s an example of the UK Government website showing a very obvious yellow and black focus state on a link.
Giving users a way to skip the top navigation completely makes for a more accessible experience. Nobody wants to be forced to tab through thirty menu items on every page just to get to the main content.
Here’s an example of a Skip to Content link on the US Government website. Note that this isn’t usually visible unless you are using keyboard navigation.
For menus, you should allow people to skip through the menu categories without being forced to open each menu item in each category in turn.
Users on mobile phones should be able to scroll up and down or side to side, but never both at the same time. Usually when content scrolls off the side of the page it’s because it’s not been constrained properly to fit the current screen size.
All these examples are things that developers can and should have control over, and equally are things that content creators do not.
How is your team organized?
In large organizations, there might be lots of content contributors. Most of these might not even be in the web team. For example, higher education institutions may have teaching or administrative staff with publishing rights, who add their own course content, PDFs, or tables to websites. This team structure would be known as ‘decentralized’.
The problem is that these contributors’ primary role is teaching and managing students. They’re not part of the web team and probably haven’t been exposed to web accessibility best practices (we wrote a book about that which you can download for free).
They might even assume that developers, being responsible for building the site, are also responsible for making it accessible.
The reality is that content accessibility shouldn’t be put in the same pile of fixes as technical accessibility.
If you run a decentralized team, where content editors publish their own articles without input from the development team, then each individual should make their content accessible first.
There is some nuance to consider here. If your website is managed centrally by a web team who approves all content before it’s published, then technically those people are responsible for making it accessible before they click ‘go’.
But if you’re in the content team, you can make it a lot easier for your web team by adding your alt text (here’s a guide to alt text) and running PDFs through Adobe and Word’s built-in accessibility checker before you hand it over.
For any other web content, use Silktide’s free accessibility checker to get an idea of where to start on a single page.
How can I get my content team to help me?
If you’re a web manager the first thing you should do is sit down with your content teams and let them know how they can help you.
Direct them towards our webinar, “Accessibility for content editors“, because it gives clear recommendations for making content accessible. We define areas of accessibility, explain how poor accessibility affects people, and give practical examples of how to make the content better.
Also, we have our free book “Best practices for implementing great web accessibility”, which is aimed at beginners to accessibility. It gives advice to content editors and developers alike. In it, we highlight the most common accessibility issues found on thousands of websites and explain how you can avoid them. Download the book for free here.
We’re happy to talk to you about your accessibility problems, so you can always request a demo of Silktide or find us on live chat here on our website.
