role: alert when info-panel is used with dynamics

[Febakke]

Description of the bug

We have some situations today where apps use our panel component in combination with dynamics to create an alert component that triggers based on user input. This gives us an accessebility issue where this panel should have an aria alert role so that screen readers also can get this information.

conundrum

We cant just add an alert role on our panels because:

The most important thing to know about the alert role is that it's for content that is dynamically displayed, not for content that appears on page load.
Source

One of the main uses for the panel component is to highlight information on a page, and is often used so that is visible on page load. We need to seperate dynamic alerts and those that is only used to highlight static information.

Also, this is pretty similar to our soft-validation functionality. If we expand the functionality of our panels to handle this, we have to seperate components doing almost the same thing. This might be hard to comunicate the difference between the 2.

One solution is to in some way expand the soft validation so that it meets our appdevelopers needs. Then we can contain this to one consept that is easier to communicate. The other is to add some attribute to the panel that can be set by the app-developer when they use it with dynamics, but then we add alert functionality to a component that maybe should be used as a way of presenting static information, and by having another attribute the app-developer has to worry about, we increase the chance of accessebility issues in apps that use this feature.

Or maybe a developer have a better suggestion on how to solve this? 😇

Small example:

aria alert documentation

Specification

The documentation specifies that you need to be careful with the use of alert as it can be very intrusive for screen reader users. Is there a risk that it might be overused, should the developer be able to turn it of if the information is not that important.

• Look at relevant cases
• Define guidelines
• Added to all variants (info, success and warning)
• Consider adding the alert that is specified in the designsystem Issue

Steps To Reproduce

Go to an app with soft validation and test if it is read by the screen reader when it is triggered.

Additional Information

No response

[StianVestli]

org/ssb

[StianVestli]

Regner med at hvis man legger på aria-live på denne så vil dette være på alle varianter av denne boksen. dvs alle disse:
info
success
warning

[Febakke]

Ja, det tenker jeg. Oppdaterer issuet.

Det viktige her er at den kun får den når den følger alert mønsteret. Hvis det er en statisk melding, så burde den ikke ha den rollen, kun om den trigges av noe som brukeren må få med seg.

[StianVestli]

Med alert mønsert er det hvis vi legge den med vis skjul funksjonalitet ? At den bare at vil ha aria-live?

[Febakke]

Ja, kanskje best beskrevet i dokumentasjonen til ARIA: alert role

The most important thing to know about the alert role is that it's for content that is dynamically displayed, not for content that appears on page load. It is perfect for situations such as when a user fills out a form and JavaScript is used to add an error message - the alert would immediately read out the message. It should not be used on HTML that the user hasn't interacted with. For example, if a page loads with multiple visible alerts scattered throughout, the alert role should not be used, as the messages were not dynamically triggered.

[StianVestli]

Blir denne saken lagt til i noen sprinter i nær framtid?

[olemartinorg]

Diskusjon om denne, og hvorfor den er satt til blocked:

• https://altinndevops.slack.com/archives/C045EB3JA9X/p1681392993791739
• Kort oppsummert kan det vel sies at vi heller ønsker å bruke ekte validering for å få til slikt som dette, ikke hacke det til ved å bruke Panel som vises/skjules. Det vil si, implementere Validering ved hjelp av dynamikk #726

[tjololo]

Closing as we will resolve this in #726