I saw a post on LinkedIn about how some modal accessibility is broken because they trap focus, failing the Web Content Accessibility Guidelines (WCAG) success criterion 2.1.2 No Keyboard Trap. This is wrong, but it’s easy to understand how someone would reach this conclusion.
When talking about accessibility, we often cite WCAG because they lay out the criteria in a comprehensible way.
But practising accessibility (whether by developing accessible websites or apps, analysing or auditing accessibility on existing projects, or fixing these problems) usually requires going deeper.
First, we have the WCAG Understanding Documents. These help developers to better understand each criterion with background information and technical details, including sufficient techniques with examples.
Then, we have the Accessible Rich Internet Applications (ARIA) Suite. It defines how to make web content and web applications accessible to people with disabilities. The Authoring Practices Guide (APG) explains in detail how patterns and practices should be implemented.
We also have EN 301 549, which is the harmonised European standard for Accessibility requirements for ICT products and services. This norm specifies how WCAG applies to web content, documents, and apps.
So many materials can be overwhelming. But this means they go into very specific detail on what to accomplish and how.
Let’s start with criterion 2.1.2 No Keyboard Trap. The WCAG definition is: “If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.”
Seems pretty straightforward. If you navigate with the keyboard, no component should trap you in a way you can’t get out using the keyboard.
But let’s explore the ARIA Dialog (Modal) Pattern. The ARIA documentation clarifies: “A dialog is a window overlaid on either the primary window or another dialog window. Windows under a modal dialog are inert. That is, users cannot interact with content outside an active dialog window. Inert content outside an active dialog is typically visually obscured or dimmed so it is difficult to discern, and in some implementations, attempts to interact with the inert content cause the dialog to close.
Like non-modal dialogs, modal dialogs contain their tab sequence. That is, Tab and Shift + Tab do not move focus outside the dialog. However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.”
There is no ambiguity. A modal (or dialog) should prevent the user from going outside the modal until it’s closed. Does this contradict the WCAG criterion?
If we take a look at the Understanding Document about success criterion 2.1.2, in the intent section, it explains: “The intent of this success criterion is to ensure that the content does not ‘trap’ keyboard focus within subsections of content on a web page. This is a common problem when multiple formats are combined within a page and rendered using plug-ins or embedded applications.
There may be times when the functionality of the web page restricts the focus to a subsection of the content, as long as the user knows how to leave that state and ‘untrap’ the focus.”
Everything seems to boil down to two considerations: if the exit method is standard, and if the application of the modal pattern is appropriate.
The first is easy to solve, as using the Esc key or a close button is mentioned in the ARIA Dialog (Modal) Pattern.
The second is where the important decision is. Why are we using a modal? This pattern is used to present information or a decision that has to be shown and acknowledged before the user can continue with their task.
If we go back to the post on LinkedIn, we now know that a modal where the user can move past it without acknowledging it is an incorrect implementation. So, where does the confusion come from? Probably the person posting this was thinking of a non-modal dialog where the user should be able to navigate outside the dialog. But naming it a modal and using it as an example of a failure to meet WCAG success criterion 2.1.2, they were just making a misleading claim.
The problem exists because modal is loosely used as a broad concept, encompassing several types of interface components with different behaviours and implementations. However, in the documentation, the modal specification is clearly defined and different from similar concepts.
Accessibility needs a more specific and rigorous use of language than other disciplines. Some may think this rigidness is unnecessary, but we are talking about standards. The rigour and reliability of the different documents and norms are a big part of what makes them valuable.
The WebAIM Million 2026 is a report that takes data from the top one million websites every year. The home page of each site is analysed automatically, which doesn’t produce a full picture of all possible accessibility issues. But it is reliable because it removes human biases and returns raw data that allows us to make comparisons and spot trends.
This year, the main takeaway is that accessibility on the most prominent websites is getting worse. The average number of accessibility errors per page has gone up 10.1% (from 51 to 56.1). Related to this, the complexity (measured by the number of elements on the page) has increased 22.5%. 95.9% of the pages analysed have some failure to comply with Web Content Accessibility Guidelines (WCAG) 2. Considering that automated tests can’t find all accessibility issues, this figure is astonishing.
Some of the most frequent errors haven’t changed: insufficient colour contrast, images without alternative text, and links with non-descriptive texts (like “click here”). These are still prevalent, even if they are easy to find with automated tools. For example, 83.9% of the pages have insufficient colour contrast. But it’s no surprise. In the article The use of colour is a frequent cause of accessibility issues, I wrote about some of the causes.
In the report, we also find that “Home pages with ARIA present had significantly more errors (59.1 on average) than pages without ARIA (42 on average).” As the World Wide Web Consortium (W3C) points out, “No ARIA is better than Bad ARIA.” ARIA allows for the development of accessible custom interactive components, but this type of complexity is (according to the data) giving a worse output for accessibility. In the article A minimal approach to accessibility, I wrote more in-depth about this same issue.
A good example of how badly implemented simple accessibility measures are is the skip button. Also known as skip navigation or skip to content, it’s used to skip repeating elements on the header of the site, so people using keyboard navigation (or other assistive technologies) don’t have to iterate over the whole menu every time they go to a different page. This is now implemented in 17.1% of the pages. This is surprising, because it’s something really easy to implement. But what’s more important is that one in ten of these existing skip buttons was broken.
It’s not surprising that the category with a higher percentage of pages containing no errors is government. But what’s shocking is that the second category with more compliant pages is non-profit, and the second-to-last category is shopping. Not only do non-profit organisations usually not have big budgets (as the government does), but shopping seems to be one of the categories with the biggest incentive to make their platforms accessible and easy to use.
The main trend observed in this report, year by year, is that accessibility has not been a priority in the industry for a long time. There was a very small incremental improvement before this year, but even with that, no significant change in the trend can be observed. Some insights are very valuable, as they are actionable and backed by data. The big picture is a clear call to action (and business opportunity) for a company that wants to lead instead of following.
Fran Rosa. Senior Developer, Accessibility specialist, and people-first development advocate
Accessibility is often treated as something companies do when they have budget left over or want to improve their public image. This frames it as an expense with no return, but data suggest otherwise.
According to a 2023 report by Accenture and Disability:IN, companies that lead on disability inclusion criteria generate 1.6 times more revenue, 2.6 times more net income, and twice the economic profit compared to other participants in the study. They are also 25% more likely to outperform industry peers on productivity, measured as revenue per employee. This is not a marginal difference. It suggests that accessibility, when approached seriously, functions more like an investment than a line item to cut.
Accessibility as a business opportunity
The first argument is reach. Approximately 1 in 6 people worldwide live with some form of disability, according to the World Health Organisation. An inaccessible platform excludes a significant portion of potential customers, while an accessible one directly expands market reach.
The loyalty argument is less obvious but equally relevant. A customer who has no disability themselves will still notice and value accessibility if someone close to them does. Inclusion increases loyalty, and not only with users who benefit directly. According to an article by Software Advice, 60% of retailers that provide digital accessibility features on their website report seeing increased customer loyalty as a result of making the improvements.
Accessibility also pushes innovation. Designing for accessibility requires questioning assumptions about how people use a product. Testing edge cases, reducing friction, and simplifying flows produce improvements that benefit all users, not just those with disabilities. A checkout process redesigned to reduce cognitive load (for example) is almost always a better checkout process for everyone.
The risk of inaction
Beyond the opportunity cost, there is compliance. The European Accessibility Act (EAA) and its corresponding national legislation make a sufficient level of digital accessibility mandatory for businesses operating in the European Union (EU). This is no longer a future concern. Vueling has already been fined for their website failing to meet accessibility standards.
Remediation (fixing accessibility issues) is also significantly more expensive than building accessible from the start. This applies to most quality standards: addressing a structural problem late in a project costs more in time and money than accounting for it during planning. Accessibility is not an exception to this.
Conclusion
The business case for accessibility is not a moral argument. Revenue data, compliance, and cost of remediation all point in the same direction. Treating accessibility as optional is, at this point, a business risk rather than a neutral position.
Fran Rosa. Senior Developer, Accessibility specialist, and people-first development advocate
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