01 | 2025 Mikko Suominen, Lead Front-end Developer & Partner Kipinä
As a developer passionate about accessibility, it has been fantastic to be involved in building Otava's new digital learning platform. One of the most rewarding aspects of this project has been seeing how a UI that is more challenging than usual can be implemented accessibly.
At the same time, it has become clear how significant an impact an organization's full commitment has on a successful outcome.
Accessibility is a major focus at Otava and is regarded as an integral part of application development, no different from any other phase in the development process. As a result, accessibility is factored in proactively rather than requiring retrospective fixes, which are always more labor-intensive. Otava's services are used by elementary and high school students as well as teachers, whose technical skills may vary, whose reading proficiency may still be developing, or who may rely on various assistive technologies.
The accessibility statement for the service we developed states: “Otava aims to ensure that its digital services achieve at least the level defined in the WCAG 2.2 guidelines.” Accessibility requirements are also underpinned by the Act on the Provision of Digital Services, which obligates the public sector and certain entities in the private and third sectors to comply with accessibility standards. While this regulation establishes a solid foundation for our work, an organization's internal commitment is what makes it truly meaningful.
Accessibility challenges in digital exercises
Our team at Otava focused on implementing interactive exercises used within the service, such as drag-and-drop and fill-in-the-blank tasks. Both exercise types feature user interfaces that are unconventional for standard web pages. In a drag-and-drop task, the user connects related elements by dragging them, as the name implies—for example, matching a foreign word to its corresponding image when studying languages. A fill-in-the-blank task, on the other hand, consists of a text with missing sections or gaps that the user must complete with the correct words or phrases.
During the project, our team reviewed the latest version of the accessibility requirements, WCAG 2.2, and evaluated how its additions would impact Otava's service. One significant addition pertained to dragging gestures: according to the guidelines, any functionality that requires dragging must also be operable using simpler methods. This set a clear development goal for redesigning the drag-and-drop exercises, and the project team closely monitored the progress of this change. Such accessibility enhancements not only meet compliance requirements but also improve usability for all users.
Drag-and-drop functionality can surprisingly prove to be a challenging use case for many, particularly on school-issued Chromebooks where users may not yet be accustomed to using the touchpad. The situation can be further complicated if the user also needs to scroll the view while dragging an element.
In the new solution, Otava's drag-and-drop exercise enables users to connect elements via clicking: the user can first click to activate a draggable item and then select the corresponding target. While dragging remains an option, it is no longer the sole method available.
Bringing in a third party for auditing
To support the team, it was decided to bring in an external partner specializing specifically in accessibility, Q-Factory, tasked with evaluating the features implemented by the team and proposing improvements.
Although the team included developers proficient in using screen readers, their experience never fully matches that of visually impaired 'native screen reader users'—individuals who actually rely on a screen reader as their primary or sole interface.
It was particularly beneficial for the entire project that, in addition to the in-house developers, external experts were involved to validate the functionality of the accessibility features. Through Q-Factory's feedback, it was valuable to see that accessibility had already been at a higher-than-average level from the start. This confirmed that accessibility has been a core component of all development work from day one.
Do not rely on the accessibility claims of off-the-shelf libraries
The most crucial lesson learned from Q-Factory's testers concerned the keyboard and screen reader usability of drag-and-drop tasks. We had originally implemented the feature using an external library whose documentation promised support for both keyboard and screen reader interaction. The library's logic was designed so that once an element gained focus, the user activated it by pressing Enter or the spacebar, after which the element could be moved two-dimensionally using the arrow keys.
The screen reader support initially seemed promising. The user received audio feedback whenever an element could be moved; pressing the arrow keys also allowed the user to hear the element moving left, right, up, or down. However, testing revealed a fundamental problem: a user who cannot see has no way of knowing in which direction and by how much the element should be moved.
As a solution, we decided to drop the keyboard support provided by the library and simplify the implementation. The UI was modified so that when a user selects an element via the keyboard, they can subsequently navigate only to the targets with which the element can be associated. This change eliminated the need to freely drag elements with the arrow keys and made the functionality significantly clearer and more accessible.
The biggest takeaway from this example was definitely that the accessibility claims of ready-made libraries cannot always be fully trusted. In many cases, it is essential to verify that a component functions accessibly within your own service and to test its usage with real users.
A sighted developer is not the same as a native screen reader user
Initially, we assumed that implementing accessible gap-fill exercises would require complex code acrobatics. Presenting text fields located in the middle of a sentence to a screen reader user felt especially challenging, as the sentence context is crucial for understanding the task.
Tests conducted by Q-Factory's native screen reader user showed that the gap-fill exercise worked well right out of the box and no significant changes were required.
This experience taught us that a developer's own proficiency with a screen reader is not comparable to the fluency of native users. Although I know how to use a screen reader, I never use it in the same way as individuals who rely on it daily.
Accessibility sparks a desire to learn among developers
It has been inspiring to work on a project where accessibility is taken seriously across the entire project team. Accessibility, much like other areas of software development, is a skill where developers' proficiency levels can vary. However, when a project succeeds in conveying the importance of accessibility to all participants and instills a desire in developers to learn and improve in this area, the results are evident to all parties. Ultimately, this not only improves the service's accessibility, but the entire team evolves and becomes capable of delivering better, more user-friendly solutions.
Mikko Suominen, Senior Front-End Developer & Partner at Kipinä
Mikko is a front-end developer, UI designer, and accessibility expert with nearly two0 years of experience. Throughout his career, Mikko has worked on everything from conceptual design to heavy industrial data systems. To balance out desk work, he commutes by bicycle year-round and practices artistic gymnastics.