Have you heard the one about Everybody, Somebody, Anybody and Nobody?
It's a cautionary tale, and goes a little something like this..
There was an important job to be done and Everybody was sure that Somebody would do it. Now, Anybody could have done it, but Nobody did.
That important job was making everything accessible, including your websites and all your PDFs.
But, nothing got done about it.
Management thought it was the Marketing department’s responsibility, because they supplied the content.
Marketing thought it was the external supplier they outsourced the work to’s responsibility because they built the website.
The external web developer didn’t really care about accessibility and just delivered a bog standard website.
Unfortunately, nobody even thought about the PDFs, and they got forgotten about until a customer complained.
Nobody bothered to follow up on checking if the website was accessible either. It wasn’t. A hefty fine was issued and Everybody suffered.
Is that an all-too-familar story?
So, in this scenario, who is responsible for accessibility, and who should have done what?
The short and simple answer is “everyone” within your business or organisation is responsible for accessibility, from the top down.
The longer and more complicated answer - especially when you factor in who exactly should do what - is “it depends on who you ask”...
Specifically, you might ask someone who is a content creator and someone else who looks after the technical side of the website.
As the Silktide website says, in their blog about this:
“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”.
Those same content editors who work on the website might also produce the wording for your PDFs, for instance, and then pass the content on to a graphic designer who produces the finished PDF - either in-house or externally.
Who’s responsible for accessibility there - the content editor or the graphic designer, or both of them?
Actually. both of them are responsible, but in different ways and for different facets of the finished PDF document. And both of them need to do due diligence and apply accessibility best practice for their own remit.
The content editor needs to ensure that the PDF content is accessible and the language used is inclusive, before it goes to the graphic designer.
The graphic designer needs to ensure that the finished PDF is structured and formatted properly and can be read easily with a screen reader. As well as using proper headings and subheadings, the designer needs to use good color contrast, meaningful document properties, and put alternative text in place for all of the images and graphics used in the PDF.
The distinction - and remit, the division of tasks and who is responsible for doing them properly - comes down to the fact that there are two sides to accessibility for PDFs and websites - accessible content and technical accessibility.
Silktide again:
“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.”
And:
“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.”
Content creators are responsible for accessible content and inclusive language.
Web developers are responsible for Technical Accessibility.
It gets even more convoluted for large businesses with many different divisions, and big institutions like universities, with many different ‘decentralised’ content contributors who aren’t web accessibility-savvy:
“In large [organisations], 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 [‘decentralised]’.
The problem is “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.”
There might be an assumption that “developers, being responsible for building the site, are also responsible for making it accessible”.
But, “the reality is that content accessibility shouldn’t be put in the same pile of fixes as technical accessibility”.
Because:
“If you run a [decentralised] team, where content editors publish their own articles without input from the development team, then each individual should make their content accessible first.”
There’s another nuance to consider here - workflow and approval before anything gets published or made live.
Silktide again, “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 a content team member you can help out your web team colleagues by making the content accessible and inclusive before you pass it on through the workflow for approval.
It’s a two-way street. Website managers can also sit down with their content teams and let them know how they can help with accessibility and make life easier.
This is something that Bnode can help you out with, as they provide training and awareness-raising workshops to facilitate better understanding of accessibility for internal teams.
What about if you outsource everything externally? Who’s responsible then?
Even if a service or website is outsourced, the original service provider remains legally responsible for ensuring the final product is accessible - so that’s you as the business or organisation.
So, whilst yes - in theory and strictly speaking, everyone within your business or organisation ultimately has responsibility for ensuring that your digital assets are accessible, including leadership from the top down - in practice, you need to make sure that your content creators and web team (or your suppliers) communicate with each other effectively, work together and share responsibility for the two key components of digital accessibility - accessible content and technical accessibility.
You need to do this because, as Eve Dunne of Taylor Wessing says:
“If service providers do not make their websites, apps and premises accessible to everyone, not only are they potentially losing out on revenue, but they are also exposing their brand to a potential unlawful discrimination claim as well as reputational risk.”
For years now, both businesses and charities in the UK have had some accessibility obligations in relation to accessibility, (including accessible buildings and facilities, and online presence too). Although, as things stand, the digital accessibility requirements for the private sector are less stringent than they are for government bodies in the public sector, who are subject to far more scrutiny.
As far as the public sector is concerned, GOV UK has a detailed section on Digital Accessibility, and is unequivocal on whose responsibility accessibility is. GOV UK states that “Accessibility is the whole team’s job”.
And goes on to qualify that statement by saying:
“Accessibility is not the responsibility of one person. Everyone on your team is responsible for making your service accessible. It’s important that each person on your team understands how to avoid accidentally making things inaccessible. This includes developers, content designers and interaction designers.”
And:
“Product and delivery managers should understand accessibility too so they can ensure it’s considered from the start and built into the service efficiently.”
And if the public sector website work has been outsourced to an external supplier:
“If you’ve outsourced some or all of your website or app to a supplier, you’ll need to work together to make sure your website or app meets the accessibility regulations.”
Again, even if you’ve outsourced services or your website build, the original service provider remains legally responsible for ensuring the final product is accessible.
Also, it’s important to mention that if your business exports to the EU or has operations in Europe it is covered by The European Accessibility Act (EAA).
The EAA applies to both public and private sector organisations, and came into force in June 2025.
Digital service providers are covered too - they’re responsible for accessibility even if services are provided by subcontractors. So, it’s crucial that any digital agencies or subcontractors you work with understand and comply with the EAA requirements but ultimate responsibility still lies with you.
Staff training is also essential to make them fully aware of, understand and effectively communicate and support accessibility features for your digital assets. Bnode can help with that.
When you need advice on and help with Accessibility, Bnode offers three distinct services - Dev Team Coaching, Accessibility and Inclusivity Training and Workshops for marketing and content teams, plus Accessible PDF Conversion and Remediation.
Coaching for your internal Dev Team covers inclusive website design and build, accessible website development, and low carbon web technologies, platforms and coding.
Bnode’s Accessibility and Inclusivity Training and Workshops are specifically designed for marketing and content teams.
And our Accessible PDF Conversion and Remediation service makes your PDF documentation more accessible. Get our Accessibility Audit and Review - professional PDF Accessibility from an expert provider, including Section 508 and ADA Compliance.
Get in touch to find out more.
Sources:
Silktide - Who is responsible for web accessibility?
Taylor Wessing - What is the UK’s Approach to Accessibility
GOV UK - Making your service accessible: an introduction
GOV UK - Understanding accessibility requirements for public sector bodies