Skip to main content
It looks like you are using Internet Explorer, which unfortunately is not supported. Please use a modern browser like Chrome, Firefox, Safari or Edge.

Is your digital service truly accessible? Focus on these 3 key points

Anna Salo sitting on the couch

Written by

Article

November 27, 2025 · 5 min read time

Companies could save a great deal of time and money in service development if accessibility issues were addressed right from the start, says Anna Salo, Software Developer at Nitor. But how can you ensure your digital service is genuinely accessible?

Imagine a web service you use frequently: an online shop, a government portal or perhaps your child’s hobby club website. How would you manage using it on a computer if you didn’t have access to a mouse or trackpad?

Accessible design ensures that everyone has equal opportunities to use websites and applications. This could mean enabling the use of assistive technologies such as screen readers, or simply building a clear mobile website that remains readable even in bright sunlight.

In recent years, accessibility has become one of the most essential aspects of digital service development. The EU accessibility directive, which came into force in June 2025 after a transition period, requires that websites and mobile applications of companies with more than 10 employees must be accessible. Technical implementation is monitored, for example, through WCAG standards.

Legislation and requirements promoting equality and inclusivity are encouraging companies and developers to consider how their services are truly usable by everyone – not just technically, but also in practice.

Consider accessibility from the very beginning

Anna Salo, who works as a software developer at Nitor, has been working on these issues for over five years. With a background in full stack development, she has recently specialised in frontend, user interface accessibility and design thinking.

Salo explains that good planning is a key enabler of accessibility.

“When keyboard users and technical limitations are taken into account already at the design stage, it becomes much easier for developers to make the interface technically accessible as well,” she says.

“With poor design, some functionalities may end up completely out of reach for keyboard users if it is technically impossible to access them without a mouse. A developer can make such a UI component accessible, but if the user cannot reach it, the work is pointless, and the component is not truly accessible.”

Accessibility requirements: 3 key starting points

  1. Keyboard navigation. All functions of the service must be usable not only with a mouse but also with just a keyboard, without visual guidance. Salo emphasises that this is a critical basic requirement for accessibility.

    “If keyboard navigation works, you’re already well on your way to accessibility. Every element must have a visible focus style and be logically organised,” she notes.

  2. Semantic HTML and use of native components. Always use native HTML elements and components, such as <button> and <a>. Avoid custom solutions unless absolutely necessary. Semantic structure helps screen readers and other assistive tools interpret the interface correctly.

    Native components are superior for accessibility. Custom components require special attention to ensure they work properly with assistive technologies. In such cases, achieving equivalent functionality and accessibility requires using ARIA (Accessible Rich Internet Applications) attributes.

  3. Colour contrast. Colour contrast directly affects how easily content can be perceived. Too low a contrast can make content hard to distinguish or even invisible. Contrast can also be too high – for example, jet-black text on a pure white background – which can make reading difficult for people with dyslexia. Tools like Wave are useful for checking contrast.

    “It is especially the responsibility of designers to ensure that the defined brand and content colours of the interface meet contrast requirements, and that the contrasts of each view, UI component or functionality are checked already at the design stage,” Salo reminds.

    In addition to colour contrast, design should consider font sizes and icon scalability, and ensure that all informative visual or multimedia content is accessible to screen readers in textual form.

Salo also calls for common sense and a broader perspective on accessibility. A service and its individual functionalities may meet the technical requirements of the law. Still, if the interface design or flow is so confusing that users cannot find the information they need, the overall experience may not be cognitively accessible.

Retrofitting is expensive

If companies overlook the needs of different users in the early stages of design and implementation, fixing accessibility later is often costly and time-consuming. Many organisations also have so-called legacy systems that no longer meet today’s requirements.

In service development, it is typical to focus on accessibility only enough to meet the minimum legal requirements. And for the systems not covered by legislation, it is rare to see accessibility noted at all, Salo notes. These systems may face major issues later if legal requirements become stricter. In some cases, those involved may not fully grasp the extent of what is needed to ensure accessibility: work might begin only shortly before the deadline, even though the process could actually have required months or even years.

At Nitor, Salo has worked with a client who needed to improve the accessibility of their large and complex management systems to meet new legal requirements. Such large-scale projects require special attention to the long-term maintainability of accessibility, which often goes hand in hand with code maintainability.

The solution for the client was to develop a dedicated design system that built accessibility into the components, practically forcing developers to use them correctly. With a design system, responsibility for accessibility does not fall on individual developers, and maintaining all systems becomes much easier.

“Technologies and requirements for digital services are evolving rapidly, and older systems can quickly fall behind. However, a lot of time and money could be saved in service development if accessibility was considered from the outset,” Salo reflects.

Better services for everyone

There is a common misconception that accessibility is only about catering to a small, marginal group. This is not true, Salo says.

“When you build an accessible service, you are genuinely making it better for all users,” she states.

Everyone faces accessibility challenges at some point in their lives. Ageing affects vision for almost everyone, and information processing speed can also change. If a healthy young adult breaks their arm in a cycling accident, that too affects their ability to use technology.

“Similarly, if you want to watch an HR training video on the metro during your commute, it’s much nicer if the video has subtitles,” Salo explains.

There are many ways to develop accessibility skills. Salo especially recommends that software developers working with frontend familiarise themselves with the WCAG criteria and, for example, complete the W3C accessibility certification. In Finland, Saavuta seminars and internationally the Digital Accessibility Conference offer great opportunities to learn more.

At Nitor, we have extensive expertise in accessibility. Do you need help developing your service? Get in touch – our experts are happy to help you move forward.

Written by