Accessibility affects almost every stage in a project. This is usually explained as accessibility being necessary before, during, and after making the project. This is an elegant way to explain how accessibility needs to be considered in the planning phase, during development, and as part of Quality Assurance (QA) when the project is already live.
This simplification is useful for explaining that accessibility is not only a concern during implementation; like all simplifications, it’s wrong because it can be misleading. Let’s clarify some of these misunderstandings.
Accessibility in the planning stage is more than just visual design
Many guidelines apply specifically to visual design, such as those under the general rule of being Perceivable. But even these are intertwined with content architecture and writing.
To have a website that’s easy to understand, people usually account for text complexity using one of the existing models and formulas (like the Flesch–Kincaid readability tests, which rely on word and sentence length to assign a score between 0 and 100, with 100 being an easy-to-read text, and 10 or less being extremely hard to read).
This can also apply to navigation. A large number of very populated categories with several levels of sub-categories is harder to read than a simple one-level navigation.
It also applies to any process, like buying. It’s easier to let people ask for the minimum information necessary to make a purchase, and ask afterwards if they want to create an account with the data provided, than the other way around. This reduces friction, which helps with conversion, but making things easier also helps users who could otherwise feel overwhelmed.
It’s always worth keeping in mind that the steps we ask users to take do not necessarily correlate with the steps that take place in our company. We can often simplify the work required for users by focusing on what they want to achieve and managing other work internally.
Accessibility during development is more than just code
In the implementation stage, things start to galvanise. It’s easier in this stage to see when something stands out like a sore thumb. But also, just by being in context, components are easier to analyse.
If we have an overlay element (a button), regardless of where it appears on screen, its tab order depends on its position inside the HTML. If the button triggers a modal, the modal must be placed inside the DOM so its keyboard navigation order (commonly known as tab order) makes sense. Or, if it’s a full-screen modal, disable the rest of the navigation temporarily. Even if we designed the button and modal as a cohesive component, it may need to be implemented in different parts of the HTML for the keyboard navigation to work as intended.
This is more important when we use an atomic approach to design, where components are designed in isolation and may need adjustments when applied in different contexts. These adjustments can be visual variations or totally different code implementations.
An ongoing back-and-forth between designers and developers (which is always dreaded) is not necessarily what this entails. Just taking accessibility into account can smooth everything.
Accessibility after the project is live is more than just QA
After going live, if everything has been done correctly, we only need to look out for bugs, right? Not even close.
One of the main factors for accessibility is content, as digital projects are living systems that change, grow, and adapt. The beautifully crafted copy used to develop and launch the site will shortly live among new content or need an update when it becomes stale. And the accessibility of the new content requires the same consideration as the original content did.
New content keeps a project fresh, but it’s also a liability. Ongoing content for the company’s blog and social media presence is, at the same time, a way to build organically and a bottomless pit of entropy. New content means new perspectives, but also new problems. Something so simple as older content needing to be recontextualised when new content is added to the mix can be burdensome if we are not being methodical.
For example, if we want to widen our audience by creating informative or educational content about complex technical or academic topics, we have to find a way to include this next to the more accurate and technical content in a way that doesn’t collide or conflict with the voice and tone used in either of them. If we use very plain accessible content only in one part of the project, the other parts would be more confusing or, at worst, jarring for the users.
Each new piece of content needs to be consistent with its context, both in substance and tone, and also in its implementation. An image that beautifully summarises a complex topic may be suitable for certain platforms. But it needs to be adapted to a text-based or interactive element, depending on its context, for it to make sense to the user.
Conclusion
In the article Accessibility is not just good user experience, I wrote about how accessibility and user experience can’t just be considered in the same conversation. This doesn’t mean that user experience strategy and accessibility efforts have to be at odds. We need to understand how accessibility plays out in every aspect of a project to avoid the conflict.
This is sometimes misunderstood as being an ideal scenario, only possible if the company is doing very well and wants to pour some money into accessibility. The reality is that this is the efficient way to make projects accessible. What makes accessibility remediation overwhelming is usually that it’s disconnected from the well-known process. We already know what planning looks like, but what happens when an issue outside our original plan arises? It is always longer and more expensive, and usually has worse outputs than the alternative.
Fran Rosa. Senior Developer, Accessibility specialist, and people-first development advocate