I often find myself in discussions with different people that are trying to understand the practicalities of accessibility and I must say that very often they think that accessibility is something that has to be fixed mostly with code. Some of them also consider design aspects, especially after experiences when developers were forced to take visual design decisions. Such occasions can make subtle negative impacts on the overall visible design of the product, especially when there are no clear rules or design systems that developers can check before making dirty fixes.
You have probably been in that situation. When even front-end developers make giant mistakes when trying to fix visual design problems with code alone. One example is inconsistent padding, margins, font-sizes, use of icons and the list goes on and on. When front-end developers have clear rule-sets, for example design tokens and scalable design patterns it is less frequent to “break” designs. When there are no rules and design decisions also fall on developers it may quickly escalate and end product gets some non-consistent parts that can effect whole products in very negative manners.
The same goes for content design. Should we trust a developer blindly when we need to present the content in the best way possible? It may work, if developer is “on the same page”. It may work if they bear the common responsibility for the product and if they were informed about the mission, vision and so on. I will not say it can not work. But to provide end users with premium content we should not push the responsibility to developers. It must be a team effort to be a success. Not a “developers will fix it” thing.
Code must respect content but content should also define code
Content is the main reason we are doing the code after all. Well, content and interaction of it, to be precise. So it must start with content. Content must be designed, before visual and code design. What information will be provided and how. Mainly texts and images but also videos, maybe also only audio with transcripts. “Content is king” does not only apply to search engine optimization. We are doing the whole process to get the content out, right.
Best to start with information architecture. How will we split the content that fits together, how will we link it together. Actually we can think of some kind of site map. They are still important because they make things more findable for the users. Also for search. So before we touch the HTML we need to define the conceptual structure of the content, right. Before we use ARIA to define collapsed or expanded parts we should think what can really be collapsed and hidden by default and what not. I do not like to think about “cost of click” and “cost of scroll” but there are others that like to think about it – users being users and that means probably lazy, do not want to click / tap, maybe even scroll. Scan the page, not read it and so on. This has to be taken into consideration before even touching the code. Code must support these decisions in an accessible manner. So again – it is not for developers to decide how to break content. When to use an accordion and when not. They need to support content and designers and make their code accessible.
Code must support alternative texts on non-text elements, so that editors and content providers have the possibility to use it. But they must actually know how to use it. And when. And what the meaning of them is. And that if they have a logotype wrapped in a link that alternative text must convey the destination. So again – a cooperation within the team. Content, design and development.
Everything starts and ends with content
The architecture, design, strategical visual elements, navigation, sections and document outline, help texts and labels, forms in general, and list goes on and on. When we start with content then design and development support the content and we get good results. To make this content accessible we must think in terms of text from start. It can make the process more effective. When we start with visual design we may have to invest more to make it really accessible.
Thinking of assistive technology from start can make our efforts for accessibility much easier. I like to think that we start with text only version. Like in the old days of computing when computers could only show text. It drills down to for example screen-reader design. Linear text blocks that can be read aloud. If we have our content in the raw text form it’s way easier to think about it and considering screen-readers. Linear, line-by-line interfaces. Like the old green-black displays in the times of Disk Operating Systems (DOS). When mouse was not there. Only keyboard. If I think about it – it drills down to that – to support the primary way of interacting with computers in these modern times of touch and even virtual reality.
The thing is that even when we start with content first, make accessible visual designs, accessible components that make accessible pages or applications, we can still make inaccessible products at the end. Because, again, of the content. If content creators does not know about their part in making things accessible we as a team fail to deliver accessibility. Some examples include:
- missing alternative texts where there really should be an alternative,
- alternative texts that are used wrongly,
- link texts that are not distinct for their destination (for example different articles using “Read more” links),
- incorrect heading levels,
- semantic elements used for styling (for example empty heading instead of padding or margin)
- parts of text in different language, not marked as such,
- sometimes even parts of text that needs to be explained but is not,
- abbreviations that are not explained and leave users wonder about multiple possible variations,
- videos without captions,
- podcast without transcripts,
- instructions that rely on color, shape, visual location etc. (for example: “Click on the red button on the right”),
- marking important text with red color alone,
- using poor contrast (yes, primarily a designer task, but in some rich text editors content creators may make color changes that break the rules designers made),
- using wrong page titles or maybe even no titles at all,
- not providing descriptive help, labels and error messages for forms…
As you probably noticed the list of potential errors includes items that sometimes span over to design and code, but I think we can agree that neither designers nor developers should have the sole responsibility to fix them.
I did not make up the list. If you check the Web Content Accessibility Guidelines and then filter them by “Content creation” (opens in new window) you will probably understand what I am writing about.
After all – when “content is king” – then the creator of it should also take the responsibility for the “kings actions” in regards with accessibility.
