This content originally appeared on marcus.io and was authored by marcus.io
Many people are confronted with the topic of web accessibility for the first time as a result of the EAA (European Accessibility Act) (why this conftontation didn't happen much earlier is another matter...) and are downright afraid of the topic, its complexity and ‘conformity’ per se. And yet I think that this static state in fear is not necessary at all, and that the topic of accessibility, like so many things, follows the Pareto principle and is, in its vast majority, a low-threshold and actionable topic for which there is no need to have a paralysing respect towards.
Par-what?
The Pareto principle is also known as the ‘80-to-20 rule’ and generally states that 80% of the results can often be achieved with 20% of the total effort (more on the principle on Wikipedia). The remaining 20% of the results would require the most work with 80% of the total effort. But even if you simplify the principle established by Vilfredo Pareto to a mere 80-20 distribution, in my opinion there are still many striking parallels to accessibility.
In my consulting and testing practice, I come across all kinds of barriers and they can certainly be categorised into these two pots. So my observation is that 80% of the subject of accessibility consists of fairly simple basics that can probably be learnt in 20% of the time available. The remaining 20% are the difficult situations, edge cases, assistive technology support gaps and corners of specialised knowledge, but these are extrapolated to 100% of the subject, giving it a bad, anxiety-inducing and difficult reputation overall.
Eighty
Specifically, I feel 80% of the barriers found in, for example, an audit are aspects that are based on a few fundamentals on the one hand, but are also easy to fix on the other. Some examples:
alttexts or attributes for images are missing. The fact that an appropriate alternative text version must be provided for non-text content is, on the one hand, the very first success criterion of the WCAG and, on the other hand, a basic principle that is quite easy to understand in my opinion.- Contrasts do not fulfil the minimum requirements and therefore make the perceptibility of a user interface more difficult. While automatic checkers cannot recognise all cases (e.g. text on images) and in a few cases also misjudge things (false negatives, false positives), they are an (pun intended) accessible way to quickly identify potential accessibility problems and generally familiarise oneself with the topic and the requirements. Overall, there is probably an 80-20 distribution here too.
- The easy-to-learn basic principle of ‘Everything that can be operated with a mouse, for example, must also be operable with a keyboard’ is, in my opinion, easy to understand and easy to implement in the absolute majority of cases as well. This requirement means that keyboard users must always know where they are in the interface (keyword: focus highlighting). Of course, there are also 20% of special cases such as ‘Drag and Drop’, but if you internalise the following principle, you will have done everything right in the absolute majority of cases and - without realising it - made it keyboard operable:
- Another cornerstone of digital documents of all kinds is: Provide metainfos about an element as well, and don't rely on its appearance alone. Explain what an element is so that its role in the context of an overall document is clear. If the element is interactive, explain what it does when interacted with and what state it is in. And then style it (within the framework of contrast guidelines and conventions). This approach is called semantic HTML and almost always (I would even speak of a 95-to-5 distribution here) also has solid keyboard control built in ‘out of the box’.
Twenty
But I also want to give examples for the remaining, challenging 20%:
- Sometimes ARIA or ARIA patterns are at play and it's not always obvious exactly what the right approach is or how a particular technology is supported by assistive technology like screen readers. For help with this, I can recommend Adrian Rosselli's blog, which is rich in knowledge and a vast scope of all things web accessibility. He has a test-supported pool of many different articles on interface elements and situations of all kinds, and also explains how to use ARIA responsibly. The blog's search function is the be-all and end-all here.
- When it comes to concrete technical support for ARIA special cases, roles and properties, a11ysupport.io offers a first starting point for your own testing. It is not quite comparable to CanIUse , but it is the best overview of e.g. screen reader support that we currently have.
Another idea for the ‘problematic 20%’ would be to get (paid) help from those affected and/or specialised teams. But both groups would be happy if the organisation booking them already knew the basics, were mostly 80% of the way to accessibility and thus came into the project as specialists for the remaining, more difficult accessibility or UX headaches.
Conclusion
It's not worth not considering the problematic 20% or so of accessibility as the whole 100% and therefore call accessibility in total "super hard". On the other hand, it seems sensible to me to master and tackle the majority of simple basic principles in order to eliminate 80% of the barriers in your own digital interface. The 20% may exist in many cases, but should not be an obstacle to not tackling the issue out of fear or falling for snake oil services that promise you the blue sky.
Note
This article is a translation of a German-language one I posted earlier today.
This content originally appeared on marcus.io and was authored by marcus.io
marcus.io | Sciencx (2024-08-16T00:00:00+00:00) 80 / 20 accessibility. Retrieved from https://www.scien.cx/2024/08/16/80-20-accessibility/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.