Empowering our authors and clients through Umbraco: A call to action

What is accessibility and why is it important to make accessible services?

First and foremost, accessibility is the principle of ensuring that no one is excluded from using something, especially those experiencing a disability or impairment. It means guaranteeing that everyone can do what they need to do, and to be given equal opportunities no matter their ability or circumstance.

It is estimated that 15% of the population is registered to have a disability or impairment. That is a high number that we shouldn’t ignore. Why? Let me tell you…

That 15%, and all their loved ones, have substantial spending power. The purple pound, which refers to the spending power of disabled households, is estimated at 249 billion pounds. Yet, research is showing that businesses lose approximately 2 billion pounds a month by ignoring accessibility. Ecommerce is one of the largest loses for this revenue, with currently every 2 out of 3 transactions online being abandoned by people who are blind, due to critical barriers.

Then there are the legal aspects. The EU directive for public sector services has been in place since 2019. The Americans with Disabilities Act (ADA) has been in place since the 90’s. With further legislation changes to EU and USA is expected in the next few years. In the meantime, this has meant limitations on who can work with public sector services and introduced an increase in lawsuits relating to services not meeting these standards. Ignoring accessibility doesn’t just mean you are excluding users; it could also mean excluding ourselves from working with many different industries.

But the fact is, we are all different, and we all experience the world in our own ways. But we all should have the same human rights.

In other words, it is simply the right thing to do. Access and inclusion are civil rights. With so much focus on open-source, sustainability and other ‘tech-for-good’ activities, accessibility should absolutely be a major focus for anyone wishing to make products for all.

What’s the current landscape for accessibility?

So how does this translate to our digital services, and what does the landscape look like for accessibility in 2022?

Well… it’s not great.

WebAim perform an annual million analysis which identifies the top one million sites based on several different demographics, such as location, industry etc. and runs its own automated accessibility tool (WAVE) to get a snapshot of the digital landscape. This tool is mapped to one of the largest frameworks for accessibility – the Web Content Accessibility Guidelines (WCAG).

From the most recent review, from the top one million home pages, 50,829,406 distinct accessibility errors were detected – an average of 50.8 errors per page.

Considering the best automated tools are estimated to account for only roughly 40% of all possible accessibility failures, it’s shocking to see such a high number compared to the top websites in the world.

From those issues, the most common issues (which accounts for 96.5% of all the issues found across the sample, and have been the same for the last 4 years) were:

1. 83.9% of homepages had low contrast text
2. 55.4% of homepages had missing alternative text
3. 50.1% of homepages had empty links
4. 46.1% of homepages had missing form labels
5. 27.2% of homepages had empty buttons
6. 22.3% of homepages had a missing document language

Whose responsibility is it?

In truth, accessibility barriers are nearly always created by the way we have designed and built our services. When we don’t have processes in place for accessibility within our project cycles, we introduce these issues and barriers within our services. Those 6 issues from WebAim’s research are all introduced by different teams and therefore responsibility for accessibility can’t fall to anyone individual or team.

Because accessibility is everyone’s responsibility.

Speaking to several developers on this, they often felt deflated regarding accessibility because it was often lumped on them as an extra development requirement. They were asked to take the full responsibility of it, and therefore had to put elaborate logic and code within their services to accommodate for issues that should be fixed by other teams.

Then we must evaluate the effectiveness of the software we are using. Especially for software that builds on top of the web (such as a content management system) as we are fundamentally giving direct access for organisations to create inaccessible services unless they are trained in producing accessible content.  

With the size, growth, and sometimes unpredictable differences in organisations, providing training during User Acceptance Testing (UAT) on producing accessible content isn’t enough. Instead, we need to be looking at Umbraco as a platform to empower, educate and embed accessibility processes for our agencies, clients, and authors.

We could ensure that there are none of those most common issues from WebAim’s research, and many other accessibility barriers are within any Umbraco instance. It really could be the most accessible and therefore single-friendliest CMS in the world (please see Joe Glombek's 2020 post on this which I absolutely loved).

How do we make Umbraco accessible to all, including our authors?

Thankfully, there are other guidelines available from the W3 (same people behind the introduction of WCAG). One of which is directly aimed at web authoring tools (such as content management systems) – fittingly called the Authoring Tools Accessibility Guidelines (ATAG).

However, ATAG cannot be met in isolation, and we must use some principles from WCAG to achieve it. For if WCAG is designed for the front end of our services, then ATAG is designed for the software and services that authors use to produce its contents. It is broken up in to two parts:

• Part A: Focuses on making the back office accessible through similar principles to WCAG. It should be perceivable, operable, understandable, and robust. This means we won’t be excluding anyone who wishes to be a user of Umbraco, especially those with disabilities and impairments.
• Part B: Focuses on ensuring authors are empowered to produce accessible content. It means accessibility can be checked, advised, and resolved within the content management system before the user publishes to live. This is a vital aspect to ensuring accessibility is continuously and consistently applied across a CMS ecosystem and across all sites using the platform.

So far, this work has largely been focused on by the Umbraco Accessibility Team, and the many community members who have contributed to making accessibility improvements to the core. And in the last 3 years since we started this initiative, we have made steady progress by conducting regular audits and nearly every version of Umbraco has had some accessibility fixes merged in.

But the Umbraco Accessibility Team has never, and will never, be able to do this incredibly important work on their own. The community is essential in continuing Umbraco through their accessibility journey.

What can we do?

First, if accessibility is new to you (and maybe your organisation) then I would implore you to run WAVE on your digital services today. Then ensure, as a starting point, you do not have those 6 issues from WebAim’s research. Because as stated in that report, addressing just those few issues would significantly improve accessibility across the web.

But don’t stop there, please do continue your accessibility journey. While WAVE provides nice breakdowns of issues and simple explanations, as mentioned, these tools only go so far. Look at manual processes (e.g., navigating with a keyboard only), and engage in usability studies that include real users with access needs – getting this type of feedback is essential to make an inclusive and accessible service.

However, assessing our live environments and retrospectively fixing accessibility barriers is one thing, but true inclusion happens much earlier in our processes.

So, I also request you shift accessibility to the left in your projects. Traditionally, accessibility is considered at the end of the project, if not after go-live. By making small investments, or by shifting left, you can reduce costs in the long term, increase efficiency and innovation, all while promoting accessibility from within.

And this is genuinely one of the hardest, but most necessary, cultural challenges and changes for any organisation. It is described as an ‘epiphany’ (by Gareth Ford-Williams, previous head of accessibility at the BBC) when the organisation realises that instead of building it and then trying to make it accessible, it would be more efficient and effective to incorporate accessibility foundations from the beginning. It takes minimal time to build it accessibly.

But please, also look to see how you can champion accessibility. We can’t be gate keepers, and we must shift our mindsets, reflect on our roles, and act. Of course, we may sometimes get it wrong on the way, but when we do, we must keep learning and growing so we can bring our best selves to our communities and our users. There is no quick fix for this, and true inclusion is always ongoing and continuous.

Lastly, please help us come together as a community in making accessibility a first-class citizen in Umbraco. For that landscape of accessibility to change, we need software that is responsible and helps share responsibility to its users. We can achieve this by empowering our authors through Umbraco. So please, engage with the Umbraco Accessibility Team and the initiative. Contribute through testing, pull requests, and help generate meaningful discussions on the dedicated Umbraco Accessibility GitHub board.

Within this board, there are dedicated tickets relating to accessibility features that we should look to include by default within Umbraco’s core (refer to Part B of ATAG). These features are based on an EU-commissioned project named, We4Authors cluster. These features include:

• Accessible tables template.
• Ability to set and change the language of the page or paragraph level.
• Advise, inform, or generate impactful alternative text for images during image upload.
• Ability to create clear and consistent forms that can be used with assistive technologies.
• Functionality to provide a title for video embeds.
• Short contextual information within documentation.
• Live testing while authoring.
• Live testing of documents.
• Testing the content of pages.
• Testing the whole website.

As mentioned, these types of mechanisms are essential to making a difference in the grand scheme. If implemented in the right way, they will make a difference to the landscape for accessibility and our users. Many of those top issues from WebAim’s research can be directly resolved in these features. Additionally, when the legislation for accessibility changes, we can already be in a position where we know all our services aren’t at least, starting from the beginning. Instead, we will have a solid foundation ready to build on.

And remember, the reason I am bringing this to you is that I truly believe that we are all part of a very special community, and we all have the power to the change the web using Umbraco.