My intention with this post is not to shame or blame anybody, but to explain the mistakes and to make it possible to avoid them in the future. So please consider this when reading. We all make mistakes and when we at least learn from them and improve ourselves based on them, then we are making progress.
Introductory clarifications
Both private and public sector websites and apps need to be accessible in Norway (there are exceptions but generally speaking). The Authority for Universal Design of ICT (opens in new window) is responsible for following up regulations on universal design of ICT solutions, linked to the Equality and Anti-Discrimination Act.
In Norway they are called UU-tilsynet where UU stands for universal utforming and tilsynet means the supervisory authority.
UU-tilsynet has the power to demand fixing accessibility barriers after they audit solutions, discover and report them. And they also have the power to issue fines if they are not fixed until deadlines also set by UU-tilsynet. Usually they concentrate on analyzing important services that have many users and have a huge impact on society, like for example online learning apps for schools. But they can also audit a solution if people report being discriminated because of inaccessibility.
Short description of the situation
Earlier this year UU-tilsynet found accessibility issues on 6 municipality websites and in 11 e-learning solutions (apps and websites) and demanded that they fix the issues. Recently they needed to escalate to 4 municipalities and issued decision on compulsory fines (in Norwegian, opens in new window) if remaining accessibility issues still aren’t fixed.
Municipalities (and indirectly their vendors) had 10 days to fix all accessibility issues reported, before daily fines would start. All issues were fixed except for one online learning app that wasn’t able to fix it’s issues in the defined time frame. Municipality then decided to stop using it until vendor fixes accessibility issues (in Norwegian, opens in new window).
Municipality reported quite soon that vendor fixed the problems and UU-tilsynet verified the fixes. So under some time pressure the app is again in use, with some improved accessibility.
Accessibility issues found
UU-tilsynet, as most of authorities, only test a part of all possible success criteria in Web Content Accessibility Guidelines (WCAG). In the case of this e-learning app they concentrated on alternative texts, color contrast, forms and keyboard navigation.
They tested following 6 (out of 47) WCAG success criteria:
- 1.1.1 Non-text Content (A) – basically checking for (correct) alternative texts.
- 1.4.3 Contrast (Minimum) (A) – checking text contrast against background.
- 2.1.1 Keyboard (A) – can user only use a keyboard to use the app.
- 2.1.2 No Keyboard Trap (A) – keyboard users must not be trapped in any way.
- 3.3.1 Error Identification (A) – is form validation accessible.
- 4.1.2 Name, Role, Value (A) – are things coded properly, with correct semantics.
They established that app failed 4 out of 6 success criteria:
- 1.1.1 Non-text Content (A).
- 1.4.3 Contrast (Minimum) (A).
- 2.1.1 Keyboard (A).
- 4.1.2 Name, Role, Value (A).
I’m not familiar with the application, but it seems like most issues were vendors responsibility. Besides maybe 1.1.1 that can be either vendor or content provider responsibility.
This unfortunately means that the app is probably still inaccessible in some parts that weren’t a part of the audit or failing other possible success criteria (as mentioned UU-tilsynet tested only 6 out of 47 WCAG success criteria).
Let’s hope that all critical barriers are now fixed and that vendor will also put into more resources and perhaps go through an audit of all applicable WCAG success criteria, react swiftly to remediate them and also improve their processes to prevent WCAG issues in the first place.
Municipality is responsible for choosing accessible solutions
I’m not a lawyer and this is not legal advice (this goes for all my posts), but UU-tilsynet makes this clear – it’s the municipality that is responsible when using inaccessible digital solutions. I hope that they at least did the right thing and made accessibility a clear requirement in their procurement process, so that fixes for issues originating from vendor won’t be charged to municipality. Because vendor should sell only accessible solutions in the first place, but it’s still best to specify it in the contract. And then content creators should do their part as well, of course. That is usually not on the vendor, unless vendor also provides the content, but as you probably understand it is often a team effort. Even more – it is customer and vendor that need to cooperate to make the final solution accessible.
Due diligence before you choose a vendor
I don’t know what level of due diligence was made when municipality choose the vendor. If any. It doesn’t matter now, but we can maybe learn from this experience and make sure we do a better job.
When searching for open information about the problematic native app I also discovered that a part of authorities that is responsible for special pedagogy actually noted some accessibility issues on their summary page (in Norwegian, opens in new window) but concluded that app is easy to navigate for most (except screen-reader users and people that need good color contrast). This may mean that municipality knew about existing issues but due to this ultimately positive meaning still chosen to use the app. Or that it didn’t really know about or check the info. I will not speculate but we can establish that this is not optimal and may point to lack of awareness of accessibility from all parts, publishing a positive opinion about accessibility could actually make the municipality to choose the app based on available info.
When doing the research I also found that the learning platform actually has an commitment to accessibility page that is unchanged from 2021. That was positive in a way. The problem is that such commitments are easy to write (often also copy pasted from others). Every vendor can make a statement about how much they care. I’ve even seen some very self-assured statements claiming AAA compliance and so on. Accessibility overlays often claim to automatically make a website compliant, so if customer doesn’t know better they can also make a statement based on that. And be totally wrong due to trusting untrue services. It was not the case here, but just to be clear about the possibilities and dangers.
Another potential issue is to use an automatic accessibility testing tool and expect it to give you the ultimate answer on how accessible your solution is. A lot of accessibility statements for websites still refer to “scores” reported by such solutions and it is a clear indication of misunderstanding of accessibility. Such statements would not be done if people understood the limitations of automatic accessibility testing, covering a smaller portion of all WCAG success criteria required for compliance.
Anyway, such statements are an indication of a deeper problem – when they are not backed by detailed information. What was tested, what does not work, when it will be fixed. We need to learn to require and check Accessibility Conformance Reports (ACR) that are detailed and using Voluntary Product Accessibility Template (VPAT) or similar. They need to be updated and I would also like to have a transparent list of items being worked on and their approximate estimates.
That is what we can call a much better commitment. Commitment needs to be transparent, if something is being hidden, then we can’t trust it. Vendors don’t need to reveal all the details, but they do need to reveal what they are really doing as a vendor and when are they planning to fix issues.
Procurement must acquire a lot of information before stakeholders approve and accessibility needs to be an extremely high on the list, just like privacy and security, otherwise we risk introducing inaccessible solutions that discriminate our own customers or in this example our citizens.
Informed customers need to make their vendors deliver accessible products
Ideally – both municipality and vendor – should consider accessibility before offering the app to pupils. Again – ideally – municipality should do proper due diligence about accessibility (and other important details, like security and privacy) before even considering the app. Maybe authorities on state level should do their own due diligence and suggest accessible possibilities from multiple vendors so that municipalities would be confident when choosing accessible e-learning applications.
A lot of hypothetical wishing, I know, but it seems that we have a huge gap in understanding and in awareness that needs to be filled with knowledge and proper leadership. Even if we have laws that make it clear that solutions need to be accessible and how we can check if they really are we still don’t practice it systematically.
It’s obvious that some awareness, training and integration of accessibility in procurement would save a lot of time, money and reputation. Or at least detect lack of vendors that produce accessible solutions and open the possibility to develop an accessible solution from scratch if remediation would take too much time and effort.
Media attention is probably a good thing here, to spread the awareness and I am happy to see that new about this situation were published on multiple main stream media, like national news (in Norwegian, opens in new window) and some that focus on digitalization and information technologies. This will for sure benefit awareness where it is still missing and hopefully start accessibility efforts like we had seen before.
Both customers and vendors are responsible for accessibility and it’s a fact that when talking about public sector as a customer we can quickly establish that accessibility is kind of politics as well. But let’s leave that for another time.
