Case Otava: Full organisational support for accessibility
01 | 2025 Mikko Suominen, Lead Front-end Developer & Partner Kipinä
As a developer passionate about accessibility, it has been great to be involved in building Otava's new digital learning platform. It has been especially rewarding to see how a more challenging interface can be made accessible.
At the same time, it has become clear how important the full commitment of the organisation is to a successful outcome.
There is a significant focus on accessibility, and it is seen as an equally important part of application development as any other aspect of the development process. It takes a proactive approach to accessibility, rather than having to fix problems after the fact, which is always more work. Otava's services are used by primary and secondary school students and teachers, who may have varying levels of technical skills, may be developing literacy skills, or may use a variety of assistive devices.
The accessibility statement of the service we are developing says: "Otava's goal is to strive to achieve at least. WCAG 2.2 guidelines." The accessibility requirements are also based on the principle that the OTA should aim to meet the minimum standards for accessibility in accordance with the guidelines of the OTA. Digital Services Act, which obliges the public sector and some private and third sector operators to comply with accessibility standards. This regulation provides a strong basis for our work, but it is the organisation's own commitment that makes it truly relevant.
Accessibility challenges of digital tasks
Our team at Otava has focused on implementing the tasks used in the service, such as the drag and drop task. Both types of tasks have a user interface that is not very common for a website. In a drag and drop task, the user has to connect related elements by dragging, as the name suggests. For example, in language learning, a word in a foreign language is linked to a corresponding picture. A gap task, on the other hand, consists of a text with blank spaces, i.e. gaps, in which the user must enter the correct words or sentences.
During the project, we went through the latest version of the accessibility requirements with our team, WCAG 2.2, and considered how its additions would affect the Otava service. One significant addition was the one on drag and drop: the guidelines state that all operations that require drag and drop must be able to be performed using simpler methods. This set a clear development goal for the redesign of the racking tasks, and the project team closely monitored the progress of the change. Such accessibility improvements not only meet the requirements, but also improve usability for all users.
Drag and drop can be surprisingly challenging for many, especially on school-issued Chromebooks that may not be used to the touchpad yet. This can be further complicated if the user has to scroll the view while dragging an element.
In the new solution, Otava's dragging task allows the user to combine elements by clicking on them: the user can first click on the item to be dragged to make it active and then select the appropriate item. Although dragging is still possible, it is no longer the only option.
Involving a third party in the audit
It was also decided to bring in an external partner, specialised in accessibility, to support the rest of the team, Q-Factoryto evaluate the features implemented by the team and suggest improvements.
Although the team included developers who were proficient in screen reader use, their experiences will never fully match those of visually impaired 'native screen reader users' - people who actually use a screen reader as their primary or only interface.
It was particularly useful for the project as a whole that, in addition to the internal developers, there were also external experts on the project, who were able to provide a stamp of approval through the functionality checks of the accessibility features. It was valuable to see through Q-Factory's feedback that accessibility was already above average from the outset. Information that shows that accessibility has been a key part of all development work from the start.
Don't trust the accessibility promises of ready-made libraries
The key lesson from the feedback from Q-Factorys testers was related to the keyboard and screen reader use of the tracking task. We had originally implemented the function using an external library whose documentation promised support for both keyboard and screen reader use. The library logic worked in such a way that once an element was in focus, the user had to activate it by pressing Enter or space bar. The element could then be moved two-dimensionally using the arrow keys.
The screen reader support seemed promising at first. The user received audio feedback whenever an element could be moved; when arrow keys were pressed, the user also heard the element move left, right, up or down. However, the testing revealed a fundamental problem: there is no way for a user who cannot see to know which direction and how much to move the element.
As a solution, we decided to abandon the keyboard support provided by the library and simplify the implementation. The user interface was modified so that when the user selects an element with the keyboard, he can then navigate only to the items to which the element can be linked. This change eliminated the need to move elements freely with the arrow keys and made the functionality much clearer and more accessible.
The biggest lesson from this example was definitely that you can't always trust the accessibility promises of existing libraries. In many cases, it is important to check the functionality of a component in an accessible way in your own service and to test its use with real users.
A visible developer is not the same as a native screen reader user
Initially, we assumed that implementing the gap task in an achievable way would require complex code acrobatics. Presenting the text fields in the middle of a sentence to the screen reader user seemed particularly challenging, as the context of the sentence is important for understanding the task.
Q-Factorys native screen reader user tests showed that the gap task worked well from the outset and no significant changes were needed.
Experience taught me that my own screen reader skills as a developer are not comparable to those of native users. Although I know how to use a screen reader, I never use it in the same way as people who rely on it every day.
Accessibility makes developers want to learn
It has been inspiring to work on a project where accessibility is taken seriously at the level of the whole project team. Accessibility, like other aspects of software development, is a skill in which the level of expertise of developers can vary. However, when a project succeeds in conveying the importance of accessibility to all participants and instilling in developers a desire to learn and improve in this area, the results are visible to all involved. The end result is not only improved accessibility of the service, but also the whole team develops and is able to deliver better, more user-friendly solutions.
Mikko Suominen, Senior front-end developer & Partner Kipinä
Mikko is a front-end developer, user interface designer and accessibility expert with almost twenty years of experience. In his career, Mikko has worked on everything from concept design to heavy industrial data systems. In addition to his sedentary job, he commutes by bicycle all year round and practices scaffolding gymnastics.