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
When remediating accessibility issues in an existing project, making additions is usually accepted without hesitation. If asked to add text alternatives, visual elements, instructions, or captions to a video, there is rarely a conflict. Even applying complex ARIA (Accessible Rich Internet Applications) patterns is never frowned upon.
However, sometimes remediation requires rethinking some components, altering them, or rejecting some existing implementation. And this causes more friction.
This is understandable, as remediation requires admitting that something is wrong (in terms of accessibility) and has to be done again. These types of changes can make a project go over its timeline.
Accessibility is all about meeting a standard, and some of the criteria are very specific and don’t allow discussion. So it’s not always just a question of “adding more.”
ARIA is a good example of this. There is a collection of attributes and existing patterns we can use, but in very specific ways. One principle is that “No ARIA is better than Bad ARIA,” meaning that a bad implementation can be worse for users than no implementation at all.
When planning accessibility from the start, a minimal approach is optimal. For example, some HTML elements have implicit ARIA roles and attributes. Native HTML form elements in the browser use implicit ARIA attributes like aria-checked. Using proper semantic elements (<head>, <main>, <footer>, <nav>, or <article>…) adds many implicit ARIA roles to the structure of a site.
It is an old joke that the first page ever on the World Wide Web was already accessible because it’s just plain HTML with no images or styles. As with most jokes, there is truth at its core. The way different browsers implement HTML components follows strict standards, so a consistent industry-wide implementation will likely improve a custom one (if it’s an option).
We can make complex interfaces with custom components and make them accessible. But we need to be aware of the trade-offs we are making and offer an alternative that is as good as the native components we are substituting. And according to the WebAIM Million 2026 report, “pages with ARIA present had significantly more errors (59.1 on average) than pages without ARIA (42 on average)”.
A minimalist approach is easier to maintain, usually more robust across browsers, and reduces the risk of errors. Complexity can be unavoidable for some projects, but it should never be the default.
Fran Rosa. Senior Developer, Accessibility specialist, and people-first development advocate
How we use colour in the design of a website can lead to accessibility problems. Although these seem easy to fix in principle, they can involve a lot of work if they were not taken into account from the very beginning of the design process.
There are two aspects that are most important when evaluating whether we have issues with colour: contrast and the use of colour.
Contrast
This is the most frequent issue, and we can find websites where almost no page is free of this type of problem.
The principle is very simple: the contrast between the text and the background must be at least 4.5:1 for body text, or 3:1 for large text (generally 18pt or larger, or 14pt or larger if bold, or equivalent sizes for Chinese, Korean, and Japanese alphabets) for Level AA, and 7:1 and 4.5:1 respectively for Level AAA.
It sounds as though choosing suitable colours for the design would be enough, but that is not always so straightforward.
The easiest problem to solve is to stop trying to hide or disguise certain parts of the content. For example, with legally required text or confirmations for accepting terms and conditions. We create an entire design thinking about what we want to communicate and we might fall into the temptation of using a less prominent colour for the parts we feel do not fit the general tone of our site.
If we do that, we are not removing the content or the obligation to have it; we are simply making it harder to read for aesthetic reasons. However, we must be capable of designing websites that are both visually appealing and functional at the same time.
Another problem that frequently occurs is that corporate or brand colours do not have good contrast. For instance, when we adapt colours from a brand that was designed for print to a screen, the colours are not always suitable. Print colours are subtractive, meaning that mixing colours results in a darker outcome, whereas screen colours are additive, and the opposite occurs. This is why trying to copy a colour exactly onto a screen does not always work, even if it does on paper. This error is easy to correct at a technical level, but it requires more work from a design perspective.
Use of colour
In addition to using colours with good contrast, we cannot use colour to convey information or distinguish elements.
For example, in a form. Marking a field in red if there is an error is fine, because we point out the error where it occurs, but we cannot use that red as the sole indication of the error. We must use text or other visual elements to indicate it.
Or if we have a list of options, indicating which ones are selected only with a change in background colour is not enough. We must use elements such as additional icons (for example) to be able to distinguish it even if we cannot perceive colour.
This rule is often a bit harder to understand because, sometimes, a change or information through colour is visually very clear and easy to perceive, and it seems obvious. But some people cannot perceive colour, or they do so differently, so the interpretation of the use of colour is not always as obvious as it might seem to us.
Conclusion
The use of colour affects the accessibility of a website both through the qualities of the chosen colours and the intentionality of their use to display information. Solving this involves, at times, rethinking which colours we use and how; this can be a complex task. But in the end, we always achieve a better design, which is more useful and appropriate for a wider section of our audience.
Fran Rosa. Senior Developer, Accessibility specialist, and people-first development advocate
No. Unfortunately, we cannot automate accessibility. And that is not likely to change in the future.
Tools already exist that automatically analyse the accessibility of a website. For example, WAVE is a suite of tools that helps us identify failures in compliance with accessibility guidelines. If we use one of its extensions for different browsers, we get a list of potential non-compliances while browsing the page, pointing out the specific point of failure with information on how to fix it.
Another example is Axe-core. This is an open-source tool that can be used to automatically analyse an entire website. We also get a list of non-compliances with precise information on how to locate them. These are just two examples of free tools, but many other paid tools and services exist.
So, why can we not automate accessibility on a website?
Firstly, because tools generally report a non-compliance, but are not necessarily capable of fixing it. The simplest example is with images. A tool tells us that an image has no alternative text, but it cannot assess whether that image is purely decorative or not, nor what alternative text would be appropriate.
And you might be thinking: Can an AI not see what is in the image? And the answer is yes, more or less. Because the alternative text of an image depends on an intentional human decision to use that image, one must know that intention to provide good alternative text.
An example: a member of a company’s team receives an award, and we publish a photo on the company blog. In that photo, we see “two people, one of them holding an award”. Would that be a good alternative text? Because if we publish it to announce that someone has won that award, we would need to include their name, mention that they are part of the company team, and, if the award is related to a company project, probably mention that as well. It all depends on the intention behind publishing that photo.
Another reason why automatic tools are sometimes insufficient is that there are errors (even those that are errors in the code) which are impossible to detect.
Another example: if we have tabbed navigation in one part of the website, the implementation requires relating each tab to its corresponding content, marking which one is active or visible at that moment, making it keyboard-navigable, and so on. You can see full examples of a tab pattern implementation in the Accessible Rich Internet Applications (ARIA) Authoring Practices Guide. If we have done the entire implementation correctly and have only forgotten to mark which tab is active, an automatic tool might recognise the implementation pattern and indicate the missing part.
But if we have only implemented it visually without adding any of the necessary parts in the code, how can the automatic tool know that we are implementing tabbed navigation?
These limitations mean that automating the detection of accessibility issues is very useful, but insufficient. It can help us detect oversights and improve the development and implementation of new content, but it cannot detect everything or offer solutions. And we might fall into the error of thinking that if an automatic tool does not detect any faults, it is because there are none, which is not necessarily the case. Tools help us, but they do not replace knowledge or human factors such as intention.
Fran Rosa. Senior Developer, Accessibility specialist, and people-first development advocate
The document that sets out the guidelines against which the accessibility of websites and mobile applications is measured is known as the “Web Content Accessibility Guidelines” (frequently referred to as WCAG).
This document is used as a reference for developing accessible digital projects and auditing the accessibility of existing ones. Consequently, to be included in the document, guidelines must meet two criteria:
- They must address significant access issues that particularly affect people with disabilities (meaning they go beyond the usability issues that affect everyone).
- They must be verifiable, so that compliance can be measured with a high degree of reliability.
The laws regulating sites that are required to be accessible are based on this document.
Something that occasionally causes a bit of confusion is that the guidelines are divided into three levels: A, AA, and AAA. These are cumulative, which means that to achieve Level AA (which is the standard recommendation and the one mentioned by law), all Level A and Level AA guidelines must be met. It is also possible that some may not apply; for instance, those referring to audio and/or video content do not apply if the site does not contain that type of content.
Levels are assigned based on how essential each guideline is, whether it is possible to meet it across different types of sites and content, and whether it is reasonable for content creators to comply with it. Thus, Level A guidelines are minimum requirements that remove basic obstacles; Level AA guidelines are the standard that improves accessibility for a wider range of people; and Level AAA guidelines represent the highest level of exigency, and it is not realistic to expect all types of content to meet them.
If we analyse the guidelines for interactive elements or forms, the expectation of coding knowledge is higher than for guidelines such as the use of images or colours, as it is reasonable to assume that whoever implements interactivity or forms on a website will have sufficient coding skills to meet the criteria.
The levels exist because the rigorous work involved in creating the guidelines focuses not only on how they affect the people who will use the website, but also takes into account the task of implementing them. Although we generally focus on the obligation to comply with certain guidelines, we have access to a broad list of meaningful and measurable criteria, and the levels serve as additional information for their fulfilment.
Fran Rosa. Senior Developer, Accessibility specialist, and people-first development advocate
In a recent conversation with an expert digital and UX designer, I mentioned that it is generally not a good idea to evaluate accessibility and user experience at the same time. Their response was that accessibility is just "good UX for everyone." While that is a poetic way to put it, I still believe it is a mistake to treat accessibility merely as a subset of user experience.
To begin with, how we evaluate each one is fundamentally different. Although best practices exist, UX is measured on a project-by-project basis depending on how a person perceives, uses, and completes specific tasks. In that sense, being satisfied with the outcome or achieving our initial goal is not necessarily the same thing.
Understanding the history of UX as a discipline is vital here. While we can look at early advances in ergonomics or psychology as precursors, it was in 1982 that the concept of Human-Computer Interaction emerged, focusing on making interaction possible and effective. Following the publication of Jakob Nielsen and Rolf Molich’s "10 Usability Heuristics" in 1989, the term "usability" gained popularity, focusing on error reduction and efficiency.
"User Experience" was a concept coined by Don Norman while working at Apple in 1993. It focused on analysing systems holistically, always from the user's perspective. This marked an essential shift in approach: what the user thinks, experiences, or feels became the primary metric of success. Throughout the first decade of the 2000s, the idea spread that all processes and decisions should be measured through the lens of UX.
This was revolutionary, especially from a commercial standpoint, but it also makes some conversations harder. For instance, a concept born from this design philosophy is the "optimistic user interface" (link to the article "True Lies Of Optimistic User Interfaces" by Denis Mishunov). This is based on the idea that when interacting with a mobile interface, instead of waiting for a server response, the UI should show that the task is already complete — even if it hasn't happened yet. This creates an illusion of instantaneity for the user; if an error eventually occurs, it can be reported later. We see this daily on social media when we "like" a post or add a comment; the UI updates instantly, even before the data has actually reached the server.
In this case, the interface is lying to sell us an illusion of speed. The logic is that the positive effect of instant feedback outweighs the negative impact if the interaction disappears due to a later failure. This illustrates how, by mixing so many disciplines in the same pot, UX always ends up being a negotiation between multiple factors.
When we talk about accessibility, however, the criteria are usually much more rigid. Is the component properly implemented for screen reader use? Can the user stop or pause videos and animations? Is there alternative text for images or multimedia? The answer is usually a "yes" or "no" — there is no room for negotiation. In accessibility, it is not acceptable to have an undersized button or poor colour contrast just because it might provide a different "emotional experience" for the user.
Therefore, while integrating accessibility into various stages of the process (such as design or development) helps a constantly evolving project remain accessible, we must understand that accessibility criteria are non-negotiable minimum requirements. They are not optional goals to be traded off against other design considerations.
Fran Rosa. Senior Developer, Accessibility specialist, and people-first development advocate