digdir
Feedback from UXnorge article
Yesterday UXnorge posted an article on improvements we should do to Designsystemet concerning Accessibility. I created this issue so that we can investigate what points should have issues, if there is anything need to research more and what should be discussed more before fixing.
We want to thank Kristian Munter Simonsen for contributing to this design system by testing it for accessibility issues. You can read the full article on UXNorge: Universell utforming i Designsystemet 👏
Documentation
We have not prioritized documentation leading up to the release. This will be a priority moving forward.
Tabs
Here are the comments, this should be taken into account when writing guidelines for tabs
Det er ingen spesifiseringer rundt tilgjengelighet ved bruk av tab og tablist elementene. Dette er elementer vi i Inklud ofte ser at brukere av hjelpemiddelverktøy har utfordringer med. Samtidig opplever vi også ofte at slike elementer blir feilaktig rapportert som feil da man ikke kan tabbe til alternativene i tablisten. Det ville vært nyttig å forklare hvilke forventninger man skal ha for slike komplekse elementer. Bruk av tabindex burde også vurderes som et alternativ for å påse at alle brukere får tilgang til tab-elementene.
Input types
The comment here was that we implied that it was up to the developer what input types should be used when setting up a input field. But according to 1.3.5 Identify input purpose this is mandatory to use correct input type. ~~We will change our documentation now to be less vague about this.~~ I am not sure that this is correct. We will document what our conclusion is in #3373
Patterns
The collaboration on Patterns are time consuming and requires collaboration and resources from multiple government agencies. It might therefor be some waiting time for all the patterns we want to look at are finished. We hope that we can have more resources working on this in the future. We encourage everyone to vote, comment and create discussions on our discussions page regarding patterns. This will influence how we prioritize.
Updated patterns with feedback from article Login Confirmation page on forms
Technical issues
Link
Article proposes that we make href required for our link component. This makes sense as a link is only a link if this is present. But href is not required when using our Link component because some libraries or frameworks have their own links, in these cases you would use asChild on our link to get correct styling. Because of this we cant make href required as it would break this functionality.
Role over aria
The article says that aria-attributes have better assistive technology support then aria-roles (Roles can be seen as a bundle of multiple aria-attributes)
UUTilsynets article on 4.1.3 Statusbeskjeder uses both roles and attributes as example of handling this issue.
WCAG: 4.1.3 Status Message techniques also uses roles as examples on how to solve.
There is no warning on the documentation page for the role alert
This test shows some less support for JAWS but is 4-5 years old This article says the opposite
How is a developer to know what is the right choice? We went with roles when working on the systemalerts patterns and tried to be consistent in that choice. Our understanding was that both were supported. We need to know what the issue is and who it affects, is it just role="alert" or is this also an issue with others aria-roles?
I have started documenting this here: #3383
Error message read twice
When testing I found that error message when using max character function on text fields are read twice. (VoiceOver and Chrome) But I think the feedback is that we have error message connected to our input and the error message is accessible beneath the input. So if a screen reader goes element to element it will get the error message read both when the field has focus and when the error message beneath the field is in focus.
Issue here: #3374
Examples with WCAG errors
We have testing pages on our Storybook that is used for technical testing. For instance see that all components have correct height. In the future we will build our own Storefront for both components and examples. Storybook will be hidden and used as a developer tool.
We are discussing if we should hide the test pages while we wait for our own storefront or fix it in some other way.
Hello! Very happy to see that the issues highlighted has been documented here on GitHub 👍 @Febakke contacted me on the Designsystemet Slack channel and asked about the role/aria definition issues note.
TLDR: The role definition of status messages is not the worst offence when using roles in my book. Due to factors regarding implementation and adopters/implementers understanding of the Designsystemet components and complex accessibility aspects like dynamic announcement, it is my opinion that one should use aria-live in combination with other aria attributes like atomic over role alert and status. It also makes it less likely that status messages will be announced each time a page is loaded for screen reader users. The use of role is generally more reprehensible in other instances.
Preface: Let me elaborate my knowledge of the issue and you can yourself evaluate how you want to handle it (or hire me for a few hours to partake in some additional discussions. But let me first preface some stuff that is quite important that we are all on the same page about. What constitutes a breach of a success criterion depends and where and when you are (in time and space)… What I mean is that in Norway it is the national audit agency which dictates what constitutes a breach of requirement and what does not. Uutilsynet uses WCAG and its techniques to formulate their own interpretations of what they test for, which can change and be adjusted over time. What is legal and what is a robust and good user experience is overlapping, but you can be completely legal in many aspects of accessibility of ICT and not have an accessible ICT solution. Beyond the fact that there is no current legal requirement for font-size or size of interactive elements we must afford the effort of aiming to create something that works well and is robust, especially across assistive technologies, browsers and operating systems.
Role referred to as within the requirements Yes, uutilsynet and WCAG specifically reflects roles as a sufficient way to comply with the requirement. But note that both of them also include properties and aria as well.
Role and ARIA Once one starts using roles one should know all the values that are being set in the accessibility tree. One of the dangers with using role alert and status is that one does not acquire or can expect users to properly understand how one gets the role to behave exactly how one intends/wants to.
Support issues Yes, it is not the most updated test results. I would gladly preform some additional testing if requested 😉
I don’t believe the big issue here is the support alone. I have not recently been able to check the current state of role alert vs aria-live assertive. Support issues also hold true across native HTML5 elements, like
- ,
- etc. In the
- etc. case it is better to use more adopted elements like
- or
- .
When one gets into more complicated webcontent, like chatbots it is important to be able to segment each attribute, like with chatbots. If only roles are available that work will become very difficult.
Polite option To have the knowledge that role alert = assertive announcement and that there is an alternative role status = polite announcement is to expect a lot. It might just be a personal opinion, but I believe that one should explicitly choose to define live content like status messages. If not you run the risk of a status message or error message being used across pages and announced every time the pages loads. It might become more problematic when users might introduce dynamic content within the role definition. This can happened when one uses aria-live as well, don’t get me wrong, but once you allow and require users to take a stance on whether this content should be read out loud (aria-live or not), and what should happened if there is dynamic content within the live region you enable users of Desingsystemet a finer degree of nuance and understanding.
Personally damaged by rule #1 of use of aria I do quite a lot of audits and role is always a red flag when it comes to web accessibility. After further inspection it seems like one has in general avoided use of aria when possible. One instance of where it should be defined is for the search component, one of the few roles which cannot be defined through standard HTML5 elements. Please add a
- or
