I was recently invited to speak at ExtendsConf, an indie online conference primarily targeted to the Craft CMS community. The timing couldn’t have been better as I needed to get this talk ‘out of my system’.
You can watch the full talk below or read the slides. Here are the main takeaways.
In Feb 2020 Studio 24 was awarded the contract to redesign the W3C website. My job as part of this project was to select a Content Management System (CMS) to power the redesigned W3C website. There were many requirements from W3C for the CMS functionality but the one requirement that caused the biggest hurdle was accessibility.
It was important that the CMS would comply with the Authoring Tools Accessibility Guidelines (ATAG), to AA standards.
We searched high and low; read accessibility statements, consulted accessibility experts, talked to CMS developers… but we couldn’t find any accessible CMSs. There is one, JADU, but unfortunately, it didn’t fit all the other equally important requirements of the project.
In the end, we chose to work with Craft. Not only did Craft fit the bill in terms of other technical features, but the Craft team had also made the commitment for Craft v4 (to be released in April/May 2021) to comply with ATAG AA standards. They even brought their accessibility agenda forward as a result of our discussions.
The accessibility paradox
The funny thing was, no matter who we talked to or who we read from, the unanimous message was: “We care very much about accessibility”. And yet, none of the CMSs were accessible.
I found that very intriguing and wanted to explore the question: what is coming between our good intentions and the practice when it comes to CMS accessibility?
Accessibility is also about expression
Another thing I realised during this journey, is that not only users of assistive technologies struggle to access web content… they are also lacking the tools to EXPRESS themselves on the web.
So the internet which is supposed to be open and universal is most probably under-representing a good fraction of the population.
So, what could explain the gap between our good intentions and our results in terms of CMS accessibility?
Accessibility is really hard
We underestimate how much knowledge is needed to do accessibility properly. It can be hard for developers to understand the recommendations as they are dry, difficult to read, and difficult to understand.
It is hard to assess the level of accessibility of a website or a piece of software. For example, if you want to check your website navigation is accessible to a non-sighted user who uses a screen reader, you need to do paired testing. This is where you have a non-sighted user and a sighted user side by side in front of a screen. The non-sighted user will use the screen reader and keyboard to tab through the links. If one of the links is not accessible it could be missed by the screen reader altogether and the non-sighted user wouldn’t even be aware of it. The sighted user next to them needs to flag that they’ve missed the link, and ask whether they meant to do that. This takes two people and a lot of time, and you have to do it every time you make updates to a website…
Most of us are clueless at accessibility
When we started researching CMSs for the W3C, we didn’t know that hardly any CMSs would be compliant. We didn’t know there would be so much work required to make these tools accessible, and we didn’t think it would be so hard to get information about how accessible each CMS was.
CMS developers are not always clear on how compliant their software is because they don’t have the knowledge to make that assessment. When I was learning to be a developer, accessibility wasn’t a big part of my course at all. I recently checked Coursera for web development courses and looked at the first 20 courses that teach you how to build a whole website. Out of these 20 courses only three mentioned accessibility.
As developers, we don’t even know how to plan our applications and choose the right tech to factor in accessibility. In theory, a well-formed HTML document that follows all the semantic rules is accessible. The issues often arise when you add layers of JavaScript. For example, if JavaScript updates the markup on the page then you need to tell screen readers that the area of the page has been updated. You can also replace a form submit button with an anchor link for example. It’s very easy to slip away from accessibility and proper semantics using JavaScript.
Where are the accessibility advocates at CMS vendors?
In most CMS vendor organisations, accessibility groups seem to be operating in the margins. It’s not clear how their work falls into the main development work and how much influence they have on the roadmap. Sometimes when CMS accessibility is improved, it’s then botched at the next release cycle by the core developers.
There is also an image issue with accessibility experts. They don’t have the aura of security experts for example. We don’t hear about accessibility gurus. It would be good to operate a mind shift in the developer community. And maybe there is PR exercise in this for the accessibility community.
A lack of demand?
Many CMS developers concur that there is no demand for accessibility. But even though accessibility is hardly ever requested, it doesn’t mean there isn’t a need for it. Maybe we’re just not very good at identifying our needs.
There are a plethora of organisations that list inclusivity as part of their values. It’s estimated that about 20% of web users have some form of disability – that’s a large group of people. If, for example, a marketing department wants to be inclusive and employ people that rely on assistive technologies, they need to give them the right tools to do the work – which in this case would be an accessible CMS. I think the need is there – we just need to be aware of it.
Solutions?
Now that we’ve explored the gap between our intentions and practice in terms of accessibility, what could be the solutions? The good news is that in a situation that is so terribly bad, there is something for everyone to do!
Making accessibility accessible
Accessibility is hard and that can’t be changed – the rules are the rules. What would help would be to revamp the learning material for developers to more easily understand accessibility and to make accessibility assessments. It might be time for the accessibility community to simplify their language or have specifications in plain English.
It would be great if they could offer accessible code patterns with examples that developers can copy and tweak to fit their requirements. I’ve heard that the Web Accessibility Initiative has plans to make ‘accessibility more accessible’, and we can’t wait!
Education, education, education
If you’re a student – even if you are just starting a course or attending a bootcamp – ask whether accessibility is on the curriculum. If it’s not, ask for it to be added. If enough people ask about it, repeatedly, and if students preferentially sign up to courses that do cover accessibility, that might be enough to make course providers include it in the curriculum.
If you are a teacher or trainer, how much do you mention accessibility? Are you covering the subject, and can you do more?
To the developer community
Have you thought about accessibility in the context of the framework or library you are developing?
If you are developing a new technology – such as a new framework or library – have you thought about documenting ways to ensure the output of your tool is accessible? How about documenting any potential accessibility pitfalls? This might prevent developers from getting into bad habits.
To CMS developers
If you are developing a CMS, accessibility starts when you plan your application and you choose what tools and languages you’re going to use for building it. It’s much easier to get it right at the start of the project than retrofitting software to be accessible. It’s also best not to crush accessibility fixes every time you release new features – in other words, you need to bake accessibility into the development and design process.
My suggestion would be to get all developers up to a minimum level of accessibility awareness and knowledge. Then use your accessibility experts as educators and in-house consultants and give them a prominent voice when you’re setting up your roadmap and planning the application.
And if this requires slowing down… slow down!
Talking about accessibility experts…
I think that the solution to improving the image of accessibility experts is fairly straightforward. If all of us try, even for a single day, to make one feature of our application accessible, we’ll automatically have more respect for accessibility experts.
It’s OK to slow down
We are so quick to rush development and then move on to the next thing that we don’t even take the time to get the foundations right – including making our software accessible for users of assistive technologies. As we keep rushing forward, we are leaving people behind.
Looking at the features now being added to CMSs, we’re out of the fundamentals and clearly in the realm of ‘nice-to-haves’ and optimisation. I think it’s OK to ‘pause’ and ensure we get the fundamentals right for everyone.
Use your consumer superpowers
I think the main driver to improve the accessibility of CMSs lies in demand. That’s where we, as developers, have the most power: as consumers of CMSs. If you work as a dev in an agency, you are the one setting and defining the requirements when choosing the CMS. You are the one who can sell accessibility to the client.
We need to factor in the accessibility of editing tools when we build our websites. We need to make that explicit when we talk to the client.
We need to talk about accessibility when we make feature requests to CMS developers. I think that if there is enough demand, it will get done…
but we need to give it time.
It will only work if we accept that accessibility is a lot of work and that we may have to compromise on other ‘sexy’ features. Before we request the latest trendy tech to be integrated into our favourite CMS, how about asking ourselves “how much of a pain will it be to make it accessible? Will a dev ever get around to making it accessible?”
We should also be ready to accept that the CMS developers may decline one of our feature requests because it will impact accessibility. Or that the cost of making it accessible is too high. At the moment I don’t think CMS developers think of giving accessibility as a reason to push back on feature requests.
Over to you!
This is my personal take on why, despite our best intentions, the vast majority of CMSs are not accessible.
A lot of what I’ve said here has been said by accessibility experts before; and I’d like to apologise to them as I realise it has taken me 10 years of working in this industry and this ‘ordeal’ of looking for an accessible CMS for the penny to drop!
This is only one person’s opinion. I’d really like for this to be a conversation opener and would love to get your input on what you think can work or what is not realistic. It’s time to have a frank, open, and honest conversation about accessibility. No one wants to be heard saying “Accessibility is a pain” but if we don’t confront these issues, we’re not defining the problem. We now need to define it so we can solve it!