UX Caffè

Accessibility Is No Longer Something to Fix at the End

Contrast, focus states, forms, control sizes, and navigation are not last-minute technical fixes. They are design decisions that should be made from the very beginning.

2026-09-17

For a long time, digital accessibility was treated almost like a final quality check. First the interface was designed, then the product was developed, and only at the end did someone start asking whether colours had enough contrast, whether keyboard navigation worked, or whether a screen reader could correctly understand the page.

Today, the limitations of this approach are becoming increasingly obvious. Not only because the European regulatory landscape has become much more concrete, but especially because many accessibility problems begin long before development. They begin when we choose a visual hierarchy, decide to make a button extremely small, communicate an error only through colour, or remove a focus indicator because “it does not look good”.

Since 28 June 2025, the European Accessibility Act has made the topic even more relevant by introducing common accessibility requirements for several products and services marketed in the European Union, including e-commerce, banking and payment services, electronic communications, and various digital products. In September 2026, a new version of the European EN 301 549 standard was also published, incorporating WCAG 2.2 as its new technical accessibility benchmark for websites, software, and digital documents, although it is not yet the harmonised legal reference that automatically provides a presumption of conformity.

But the point should not simply be complying with legislation.

The point is designing products that can be used by as many people as possible.

Accessibility begins in the design file

When we think about accessibility, we often imagine technical activities: ARIA attributes, semantic HTML, screen readers, and keyboard navigation. All of these are fundamental, but they can make accessibility feel like something that mainly belongs to development.

In reality, many of the most important decisions are made much earlier.

The designer chooses the contrast between text and background. The designer decides how large a button should be. The designer decides whether a link can be recognised only because of its colour. The designer determines how an error appears in a form, how information is organised, how large text is, where labels are positioned, what focus states look like, and how a flow is structured.

If these decisions are wrong, developers can certainly try to correct them. But that means modifying a project that has already been defined, often when changing components and behaviours requires considerably more time.

Accessibility should therefore enter the process in the same way as responsive design, design systems, or usability.

Not as a final check.

As an initial requirement.

Contrast is not only about numbers

Contrast is probably one of the best-known aspects of accessibility. WCAG defines specific values to ensure that text and important elements remain readable.

But reducing everything to a numerical ratio would be a mistake.

An interface can formally pass a contrast test and still be difficult to use.

Text that is too small, weak visual hierarchies, excessive amounts of information, difficult typefaces, or surfaces that are visually too similar can all create problems even when colour contrast technically meets the required values.

The problem becomes even more evident when colour is used as the only means of communication.

Think about a form where incorrect fields are simply highlighted in red. Or a chart where two categories are distinguished only through green and red.

For some people, that message may be much less clear than we imagine.

The solution does not mean giving up colour.

It means avoiding situations where colour is the only element carrying information.

An icon, explanatory text, a label, or another visual difference can make the message much more robust.

Focus is not a visual defect

Another very common example concerns keyboard focus.

When designing interfaces, the browser’s traditional focus outline is still sometimes treated as something ugly that should be removed. The problem is that this outline communicates something essential: it shows which element is currently selected for someone navigating without a mouse.

WCAG 2.2 pays particular attention to this aspect. Keyboard focus needs to be visible and cannot be completely hidden by author-created content, while additional criteria address how perceivable focus indicators should be.

From a design perspective, therefore, the question should not be “how do we remove this border?” but “how can we design a focus state that fits our interface while remaining clearly visible?”.

Focus can look good.

It can use brand colours, a well-designed outline, or a meaningful change in the component state.

The essential condition is that users can recognise it.

Hiding focus does not make an interface cleaner.

It simply makes it harder to use.

Buttons should be easy to press

Accessibility also concerns something extremely practical: being able to activate the control we intended to activate.

Among its additions, WCAG 2.2 introduces a success criterion concerning minimum target size for pointer input. At Level AA, the general reference is at least 24 by 24 CSS pixels, or sufficient spacing between smaller targets.

The principle behind the specification is much simpler.

If we place two tiny icons next to each other and users need great precision to select the correct one, we have created a problem.

That can affect someone with a motor disability, but also someone using a smartphone while walking, an older person, someone with cold hands, or simply anyone using a small screen.

This highlights one of the most interesting principles of accessibility: many solutions created to address a specific difficulty improve the experience for everyone.

A larger target is not useful only to someone with a disability.

It is simply easier to use.

Forms reveal a lot about interface quality

Forms are probably one of the clearest areas where UX and accessibility meet.

Think about a registration form.

Do labels disappear as soon as users start typing because placeholders are being used instead? Is an error communicated only through a red border? After submission, is it unclear which field contains the problem? Does the user have to enter information again that was already provided earlier in the same process?

All of these decisions affect the experience.

WCAG 2.2 also introduces criteria addressing redundant entry and accessible authentication, recognising that apparently simple operations can create significant barriers.

For designers, this means designing not only the ideal version of a form but its entire behaviour:

• initial state;
• focus;
• input;
• error;
• success;
• disabled fields;
• required information;
• contextual help.

Designing only the “perfect” form, completely filled in and without errors, means designing only a small part of the real experience.

Accessibility and design systems

One of the most effective ways to integrate accessibility into the process is to bring it directly into the design system.

If every new project has to reinvent buttons, forms, focus states, colours, minimum sizes, and behaviours, the chances of errors inevitably increase.

An accessible component designed once and correctly reused helps address the problem at its source.

A design system can define:

• verified colour combinations;
• readable type scales;
• standard focus states;
• minimum control sizes;
• errors and validation messages;
• properly structured form components;
• behaviours for interactive elements;
• alternatives to patterns based exclusively on dragging.

This does not mean that a design system automatically guarantees accessibility.

An accessible component can still be used incorrectly.

But it moves many repetitive decisions away from individual projects and into a shared, controlled foundation.

Not everyone uses an interface the way we do

Perhaps one of the biggest problems in design comes from our natural tendency to design around our own experience.

We can see the screen clearly.

We use a mouse.

We understand digital conventions quickly.

We probably have a relatively modern device and a reliable internet connection.

But the user is not necessarily like us.

They may have a visual, motor, hearing, or cognitive disability. They may use assistive technology. They may have a temporary disability. They may be older. They may have limited familiarity with technology.

Or they may simply be using the product under conditions we did not imagine.

Sunlight may make the screen difficult to read.

One hand may be occupied.

A noisy environment may make audio content impossible to understand.

A slow connection may change the behaviour of the interface.

Thinking about accessibility means, in part, accepting that the way we personally use a product is not universal.

Accessibility does not mean designing ugly interfaces

There is still a perception that accessibility requirements limit creativity.

Larger buttons, stronger contrast, visible focus indicators, readable text: it may seem that all these requirements inevitably lead to standardised and visually uninteresting interfaces.

But good design does not depend on being able to use extremely light grey text on a white background or hiding information behind interactions that are difficult to discover.

Constraints are part of design.

We already deal with technical, financial, brand, content, and business constraints.

Accessibility is simply another set of constraints we need to understand.

And it often forces us to make better decisions.

If information can only be understood through colour, the communication system is probably fragile.

If a button can only be activated with great precision, it is probably too small.

If navigation works only with a mouse, an important mode of interaction is missing.

In this sense, accessibility does not limit design. It eliminates lazy design.

Test earlier instead of fixing later

The same principle applies to testing.

Waiting until the product is almost finished before checking accessibility turns every problem into a correction.

Changing the colour of one piece of text might be simple.

Discovering that the entire design-system palette creates contrast problems is very different.

Fixing one button is simple.

Discovering that none of the interactive components has a properly designed focus state requires much more work.

This is why progressive checks should be part of the project.

Designers can verify contrast, hierarchy, targets, and states during design. Developers can check semantics, keyboard navigation, and assistive technologies during implementation. User testing can reveal problems that no automated tool would ever identify.

Accessibility is not a checklist we complete once.

It is a process.

Conclusions

Digital accessibility has been treated for too long as something to verify when the product is almost finished. A check before launch, a list of errors to fix or, in the worst cases, an activity addressed only when a legal obligation appears. This approach is no longer sufficient. The European Accessibility Act has increased attention on accessibility across Europe, while the latest evolution of EN 301 549 confirms an increasingly clear direction towards WCAG 2.2. But stopping at compliance would mean missing the most interesting part of the issue.

Accessibility is, first and foremost, design.

When we choose contrast, size a button, design a focus state, organise information in a form, or decide how an error should be communicated, we are already making choices that can either facilitate or prevent people from using the product. Waiting until the end often means asking developers to correct problems that began much earlier.

Integrating accessibility from the start does not mean turning every designer into an expert in legislation. It means understanding some fundamental principles, incorporating them into design systems, discussing them with developers, and treating them as a normal part of product quality. Exactly as we already do with responsive design, performance, security, or interface consistency.

There is another important aspect. Many accessible decisions create better experiences even for people who do not have a permanent disability. Readable text, larger targets, clear navigation, understandable error messages, captions, and predictable interactions are simply characteristics of a good product.

Perhaps we should therefore stop thinking about accessibility as a special version of design intended for someone else.

It is design.

And when an interface excludes part of its audience because we chose a solution that was more elegant, more minimal, or simply faster to build, the problem is not that accessibility restricted our creativity. The problem is that we did not design well enough.

A good designer should not wait until the end to ask: “Is this product accessible?”.

They should begin much earlier with a different question:

“Who might have difficulty using what I am designing, and what can I do now to prevent that?”

It is a very simple question.

But it can completely change the quality of the result.