In web development, designing an accessible loading button is a real head-scratcher. There's no easy one-size-fits-all solution, but understanding the various approaches improves your ability to make accessible experiences. So, how do we make a loading button accessible?

The Straightforward Approach

Let's begin with what seems the most straightforward: just slap on a spinner and call it a day.

There are multiple ways of implementing a loading spinner. Here I have implemented it using solely CSS, so the spinner is not detected by screenreaders. The details of the styling are not important, but I promise I’ll share with you the whole snippet at the end of this post. The most important thing is it hides the text for visual users and adds a spinner.

Here’s an abstraction:

This approach has its pitfalls. While visually it indicates loading, it does nothing to communicate this state to users relying on assistive technologies. The text is still available for screenreaders, but it only says “Submit”:

One easy way to improve this, is to change the aria-label of the button while loading:

Now a screenreader will read “Loading” if the loading status is changed.

We have actually made an accessible loading button!

We could end this article there, but one common issue for a loading button is to prevent users submitting while loading status is active.

But disabling a button has caveats you should be aware of.

The Disabled Attribute: A Common Misstep?

It might seem logical — disable the button while the action is in process:

This prevents any interaction with the button, so multiple requests won’t be sent. It also adds some styling, indicating for visual users the button is not interactive. For screenreaders, it will be read as “Loading, disabled, button”, which seems swell.

However, disabled may also be problematic for screenreaders. When a button is disabled, it's removed from the tab navigation. This entails if a keyboard user is tab-ing through a page, a disabled button will not be focused.

Not being able to find a button doesn’t sound too accessible to me — so what are the alternatives?

Aria-disabled: Interactivity Maintained

Here's where aria-disabled steps in. Unlike the traditional disabled attribute, it keeps the button interactive, allowing focus, but still telling a screenreader the button is disabled:

One important thing to remember, is that it’s an aria- property, so it only affects screenreaders. It does not affect styling or prevent submits.

To make aria-disabled also visible for sighted users, you can simply style the button if aria-disabled is set:

To prevent submits, you can do an early return on your submit function:

So now we have two possible implementations of a disabled, loading button.

But you may also have seen aria-busy — is that something you should be using?

Aria-busy: Maybe relevant?

aria-busy tells the screenreader an element is “busy”, which sounds suitable for a loading button:

But aria-busy might not work as you expect. After you press the button, it won’t immediately notify you about its busy-ness; it still reads “Submit” then “Loading”. You only get the word “busy” included with the screenreader if you enter the element from somewhere else, such as leaving the button and refocusing it. Then it will read “Loading, busy, button”. This shows the importance of updating the aria-label to communicate its state.

There’s also another gotcha with aria-busy you should be aware of. It hides the busy element’s children from screenreaders. This is by design, as aria-busy is intended to prevent the screenreader to read incomplete elements.

So in the case below, it would not read the loading text:

We have multiple implementations of loading now — what does the industry use?

Learning from the industry

It's instructive to look at how various UI libraries handle this issue. Here solutions vary from only setting disabled, only setting aria-disabled, only setting aria-busy or a mix.

Let’s first look at what some global libraries does it:

Atlassian: aria-disabled. https://atlassian.design/components/button/examples#loading

Material UI: disabled. https://mui.com/material-ui/react-button/

shadcn: disabled. https://ui.shadcn.com/docs/components/button#loading

In Norway, some of the biggest libraries also have a mix of decisions:

Common public library, designsystemet: aria-disabled. https://storybook.designsystemet.no/?path=/docs/felles-button--docs#bruk-av-spinner-til-å-lage-en-knapp-som-laster

Entur: aria-busy and aria-label. https://design.entur.no/komponenter/knapper/button

Vy: aria-busy and disabled. https://spor.vy.no/components/button

Nav: disabled. https://aksel.nav.no/komponenter/core/button#buttondemo-loading

Lets comment some of these choices.

Let’s just first comment the use of disabled — wasn’t that a misstep?

First of all, you should avoid the use of disabled, and instead use feedback text and early return. But in the case of a loading button, it is OK to use disabled, assuming the wait won’t be too long. For a loading button the user may already have focus on the button, and you can tell the user what’s happening by changing text from “submit” to “loading”.

With disabled the user may know that the button will be unavailable to tab for a little while, but it’s still possible to use voiceover-button + arrows to navigate to it.

If the waiting time is too long, e.g. more than 10 seconds, a user may be confused to what is happening. Nav suggests in this case to add more feedback with text, progress bar or use a loading skeleton.

Why might libraries have such a range of decisions?

One answer is simply that there’s not only one correct solution. There are multiple ways to understand a button is in a loading state. Some screenreader-users may be used to one way, and another group may be used to another way. You just have to user test with your audience.

Another aspect is that the above mentioned libraries use default values for loading state. But there may be situations where one method is better, and it’s possible for consumers to overwrite.

Conclusion

In summary, creating an accessible loading button requires a nuanced understanding of different attributes and their implications for accessibility. What a perfect solution is, has a boring answer: it depends. It depends on the context and the users' expectations. By examining various approaches and understanding their trade-offs, developers can make more informed decisions and create more inclusive web experiences.

As promised, here’s the implementation of the loading button:

How would you implement an accessible loading button?

Making an accessible loading button: Aria-disabled with friends

Fra kognitiv overload til et nyttig testverktøy – å komme i gang med VoiceOver trenger ikke å være vanskelig.

Jeg brukte lang tid på å komme i gang med skjermleser. Det første som treffer deg når du endelig har klart å skru den på er en evig strøm av prating. Mens det bables i vei skal du prøve å navigere deg rundt uten å bruke strategiene du er vant til – mus og tab er ikke venn med skjermleseren. Snakk om kognitiv overload!

Først en liten disclaimer. Å teste selv er ikke det samme som å teste med ekte VoiceOver-brukere som bruker skjermlesere i hverdagen. Men du får luka ut en del åpenbare feil og rariteter og disse er det ofte mange av. VoiceOver på Mac er bare en av mange skjermlesere, men det er et godt skjermleserprogram som er gratis og innebygget på Mac.

Før brukte jeg heller lang tid på å google hvordan forskjellige elementer blir lest opp med skjermleseren, i dag er det veldig naturlig for meg å bare skru den på og teste selv. Nøkkelen var tre enkle kommandoer som jeg håper kan hjelpe deg også over kneika.


1. Skru på, skru av (og hysj)

Det første du må lære deg er å skru skjermleseren på og av igjen. Her kan du enten bruke Ctrl + F5 eller Ctrl + 3 hurtige trykk på på-knappen.

Første gang du skrur på VoiceOver, kommer det opp en informasjonsdialog: huk av for at du ikke vil se dialogen igjen og gå videre.

Noe av det første du kommer til å oppleve er at skjermleseren begynner å bable i vei på et sted du ikke er interessert i, mens du prøver å konsentrere deg om å få navigert til stedet du hadde tenkt. Her er control-tasten din venn.

2. Navigering

Siden man ikke kan bruke mus, er det fort gjort å begynne å tabbe. Men da får du bare kommet deg til de interaktive elementene og du vil ikke få lest opp all relevant tekst. Får å navigere seg rundt med VoiceOver kan du bruke

Vent, hva er en VO-tast for noe? VO-tast står for VoiceOver-tast og denne kan man stille inn selv, ved å åpne VoiceOver-verktøy og gå til Generelt/VoiceOver-spesialtast. Et vanlig og enkelt valg er CapsLock. Inne i VoiceOver-verktøy/Tale kan du laste ned språkpakker, noe som trengs for å lese et annet språk enn språket du har på maskinen din.

3. Rotoren

VO-tast + piltastene funker ypperlig til å komme seg rundt og oppleve siden med skjermleser. Men det er slitsomt å hoppe gjennom alle elementene om du skal teste noe nederst på siden. De som bruker skjermlesere til daglig er helt rå på å bruke hurtigtaster for å komme seg kjapt rundt til ulike deler av siden. Et enkelt sted å starte er med Rotoren.

Rotoren gir deg lister over ulike elementer på siden, for eksempel alle overskriftene eller lenkene. Bruk pil opp og ned for å bla deg gjennom elementene og bruk pil til høyre og venstre for å bla deg gjennom lister med ulike elementer.

Lykke til!

Med disse tre kommandoene kommer du langt. Det er bare å begynne å teste!

Lær deg å bruke VoiceOver med tre, enkle kommandoer

VoiceOver clicks and mouse clicks are the same to the browser—so how can we differentiate them from each other?

The problem

A couple months ago I was coding away at some new dropdown components for our design system and came across an annoying issue. When using VoiceOver and focusing the input of my dropdown, VoiceOver announced: “… to display a list of options, press Control-Option-Space.” However, my dropdown did nothing when pressing Control-Option-Space—which obviously isn't good. 



My next issue then was: How do I know when the user presses Control-Option-Space? Some quick event investigation teaches me that Control-Option-Space sends out a normal click event. This means displaying my list with options when receiving a click event will work, but in my case I don't want to show the list when the user clicks with a mouse. 

My new issue now was: How do I know when the user clicks using VoiceOver? And this didn't seem to be as trivial. Web browsers can't detect screen readers[1] and VoiceOver sends normal click events … Well, after a lot of looking around I found one hacky way to solve my problem—it's not elegant but it works and is still better than nothing:

The solution

When sending click events with VoiceOver, the click position (i.e. the x and y coordinates) is always set to the center of the clicked element, halfway from the top and halfway from the left. An actual mouse click is very rarely placed exactly in the middle, so I used this to my advantage. I made a function that takes in a click event and tells me wether the click is within a small perimeter of the exact center or not. This tells me if the click was (most likely) a VoiceOver click or not. 



It's by no means a perfect solution and could break without notice, but for now it solves this very specific problem. 



A last notice

As a last notice, remember that VoiceOver isn't the only screen reader out there. This solution will likely not work for other screen readers and you should test your solution thoroughly. If you can solve your problem using traditional solutions you should always prefer that. In this case, the problem is VoiceOver-specific. The announced message did not reflect real usage, so we added extra functionality on top of an accessible component. Something like  isVoiceOverClick should never be used to build core accessibility functionality.

[1] Can you detect screen reader users



How to detect clicks from VoiceOver

Digital nudging can sure be used for great evil, but it can also be used to help your users. Ensure positive effects for all of your users by universally designing your digital nudges!

Digital nudging is explained as guiding a user's behavior and choices through user-interface design. It can be used for many purposes, e.g. making a user add the correct items to their online shopping cart or to make an application form easier to navigate. This could be accomplished by using for example wording, colors or placement and sizing of elements. Digital nudging can help the user reach better and faster decisions. It could also ease normally demanding tasks by for example reducing the completion time. It can therefore be of great value for the user to be nudged.

There are several ways to navigate online. Most common is seeing what is in front of you on the screen, and using your keyboard and mouse to navigate. Alternatives to visual navigation exist. For example will a user with vision impairments likely use a screen reader, which is used to interpret the information on the screen into audio. Not all visual information is possible to effectively or precisely interpret and is therefore not possible to pass on to the user. Consequently, digital nudges do not necessarily benefit all users if they rely on, for example, vision, to be effective.

Example

Imagine you are a designer in charge of a website that deals with several types of applications and forms. Then, imagine this hypothetical scenario:

There are three different applications that might be relevant for the user: application 1, application 2 and application 3.

It is difficult for the user to navigate and determine which application they should submit. In many cases, users submit the wrong application.

You have collected data which tells you that application 1 will be the correct option for 97.5% of the users.

Based on this, you would like to nudge the users towards application 1, and you start composing two different sketches. Disclaimer: you might find several choices that you, possibly an actual designer, would not make, but it will have to do for illustration purposes. Also, for the sake of keeping scope, this example will focus on screen readers and a limited amount of nudging techniques.

Sketch 1

Focusing on a screen reader as the mean to navigate the website, there are some things to take note of:

The application 1-button will be presented first for the user both visually and by screen reader.

Information about color will not be communicated by a screen reader. The user will not know that one button is greener and more inviting than the other.

We will have more of a listing of options, and there are few elements that separate the three options from a screen readers’ perspective. This means that the first button will not be much more prominent than the others.

The text itself could also be used to nudge, but seeing that it is a lot of text and all put together, it could lead to information overload or that the user does not bother to read all of it. 


Sketch 2

Some things one can take note of from sketch 2, also here from a screen readers' perspective:

The application 1-button is more separated from the other options by using text, which could make it more prominent. 

The text itself could also be used to nudge the user through wording and tone of voice. The separation of it might lead to the user not being as overwhelmed and taking the time to read it (compared to sketch 1).

The application 1-button is made visually bigger than the others. As with sketch 1, it is also here important to remember that a screen reader will not provide information about the size or color of the button.

Side-note: The order of the elements will for the screen reader depend on how the HTML code is structured. In these examples, it is assumed that the different elements (HTML-tags and other relevant attributes) produces the same order for the screen reader as described in the image caption. 

Conclusion

When not benefitting from the positive effects of nudging, some users might find themselves in additional shortcomings in their everyday lives compared to others. This highlights the importance of universal design also in the context of digital nudging - it is important to design nudges that will have favorable effects despite disabilities or impairments. 

To finalize, i would like to emphasize that the point of this article is not to tell you that you should not use colors or size to nudge; it simply means that it is important to be aware that for some users, wording, tone of voice and order would have greater impact. Hopefully, this new knowledge will make it somewhat easier to give this area some attention in upcoming projects. Good luck!

Digital nudging + universal design = <3

Når vi lager digitale tjenester må vi sikre at de kan oppfattes av alle! Det innebærer at vi gir tekst til blant annet bilder, lyd, inputelementer, knapper. Her dechiffrerer vi WCAG 1.1.1, slik at du slipper å tolke regelverket selv!

WCAG 1.1.1 sier "Gi brukeren et tekstlig alternativ for alt innhold som ikke er tekst!*"

Dette betyr at bilder må ha en beskrivende alternativ tekst, lyd må tekstes, inputelementer og knapper må ha beskrivende navn, og til og med CAPTCHAS trenger å ha tekst som identifiserer innholdet og beskriver formålet - og har du forresten tenkt på at du må ha alternativer til CAPTCHA som fungerer for alle? 

For de som bruker skjermleser, talestyring eller har tregt nettverk kan dette være viktig! Her er det noen situasjoner du kan ende opp i, og eksempler på hvordan man løser dette:

En beskrivelse gjør samme nytte som det ikke-tekstlige innholdet:

En illustrasjon av hvordan man strikker en maske, med en tilsvarende tekstlig beskrivelse på hvordan man gjør det samme.

En graf med salgsdata for oktober, med en kort beskrivelse av typen “Salgsdata for oktober”, og en lang beskrivelse som gir informasjonen som ligger i grafen.

Det er en knapp eller inputfelt:

En knapp med pil eller annet ikon må ha en tekst eller alternativ tekst som forklarer hva ikonet gjør

Inputfelt må ha tilknyttet tekst (holder ikke med placeholder-tekst, den forsvinner!)

Det er en test for å unngå spam-roboter:

En CAPTCHA som krever at man hører lyd og skriver vil ikke fungere dersom man er døv, derfor legger vi på tekst som forklarer testen og beskriver formålet, i tillegg til at vi legger inn en alternativ CAPTCHA som f.eks. viser bilder og lar deg bli testet på den måten i stedet.

Innholdet er en sanseopplevelse som ikke lar seg gjenskape i tekst:

Et musikk- eller kunststykke - vi legger på en tekst som identifiserer hva innholdet er.

Kart? Jeg har nettopp begynt på prosjekt i Kartverket, og der har vi interaktive kart der man skal kunne tegne opp grenser. Jeg lurer på om det går under her, men vet ikke. Hva tror du?


Det finnes en tekst som gir fullgod beskrivelse:

I tilfeller der tekstlig innhold er tilgjengelig er det unødvendig eller potensielt feil å bruke aria-label. For eksempel, en knapp med tekst trenger ingen ekstra aria-label, det kan føre til dobbelopplesing eller ulike tekster for seende og ikke-seende.

Til sist; det finnes ingen regel uten unntak. Se full liste av unntak fra regelen her: https://www.uutilsynet.no/wcag-standarden/111-ikke-tekstlig-innhold-niva/87

Gi et tekstlig alternativ for alt innhold!

Uutilsynet deler brukere med nedsatt funksjonsevne inn i 4 grupper: motorikk, syn, hørsel og kognisjon. Brukere med kognitive funksjonsnedsettelser har problemer med å ta til seg og bearbeide informasjon, og vil typisk slite med å

konsentrere seg

huske (korttidsminne)

lære seg hvordan noe virker

fullføre oppgaver

Oftest ser man på kognitiv funksjonsnedsettelse som permanent (autisme, ADHD, dysleksi osv.), men har du tenkt på at en midlertidig hjernerystelse, en fyllesyke eller en hektisk småbarnshverdag også kan skape tilsvarende utfordringer?



Hvordan kan du bidra?

Det kan være veldig vanskelig å vite nøyaktig hvilke utfordringer en løsning skaper for brukere med kognitiv funksjonsnedsettelse, men her er et par tips som kan være fint å huske på:

Tydeliggjør hva som er viktig funksjonalitet og i hvilken rekkefølge de eventuelt skal benyttes

Bruk bilder, illustrasjoner, video og lyd i tillegg til tekst da tekstlig innhold ofte kan være vanskelig å forstå alene

Bruk et enkelt og forståelig språk (https://www.sprakradet.no/Klarsprak)

Del opp lang og/eller komplisert informasjon i mindre biter

Nummerer stegene i en lengre prosess slik at brukeren enkelt kan se hvor hen befinner seg

Begrens hvor mye informasjon brukeren må oppgi



Har du lyst til å lese mer om dette?

https://www.uutilsynet.no/brukerutfordringer/kognisjon/160

https://www.kunnskapsbanken.net/kognisjon/

Ta hensyn til kognitive funksjonsnedsettelser!

Universell utforming. Vi vet alle hva det er, vi vet alle at det er superviktig - og riktig! - å få til, og vi snakker om det hele tiden. Og den aller vanligste måten å jobbe med det på, er fremdeles som tunge skippertak en gang i mellom. Hvordan får universell utforming til å bli en del av teamhverdagen? 

Det åpenbare svaret - som jeg også hører fra designere og utviklere når jeg spør om hvordan de håndterer uu i løsningen sin i hverdagen - er at "de må tenke på det på hver oppgave, og hver gang de slipper noe ut i prod: har vi sikret uu på dette?"

Og det høres så såre enkelt ut. Men hadde det vært så enkelt, så hadde vel ikke løsninger likevel vært så mangelfulle på når det kom til universell utforming? Så hva er det som kommer i veien for at vi faktisk sikrer det løpende?

Jeg har to hypoteser:

1. Tverrfaglighet smerrfaglighet
Det jeg synes jeg hører absolutt oftest fra designere når vi snakker om uu, er: "...men det er liksom utviklerne som må gjøre det". Og så vaskes det hender overalt ut i fra det. Og ja - opprettholdelsen av uu krever riktig koding. Men hva ved brukeropplevelse gjør vel ikke det?

Og så er jo tverrfaglighet i seg selv fremdeles vanskelig i mange team. Jeg ser fortsatt boards hvor design basically har sin egen kolonne, eller egne "brukerhistorier", og designere som sukker over at de blir sittende uten så mye å gjøre "fordi utviklerne utvikler". Det er ordentlig vanskelig å spenne over faggapet - eller egentlig å fylle det, sånn at det ikke oppleves som et gap. Måten man snakker sammen på, og deler ansvar og utfører ting sammen på, krever konstant øvelse. Og når det er vanskelig for oss i de fagene vi er så godt kjent med - da er det ikke så rart, kanskje, at det blir vanskelig med uu, som vi vel alle er ganske usikre på, alle sammen.

2. Universell utforming er et "sjekkpunkt"
Jeg tror uu er litt som måling: i et halvmodent team, så snakker vi om det, og minner oss selv på at "det må vi gjøre" - men så er det forbanna vanskelig å likevel gjøre det. Det blir stående som en egen oppgave eller aktivitet - og dermed kan den også prioriteres opp eller ned.

I et team som er modent på måling, er måling helt integrert i teamets hverdag. Da er det ikke et eget punkt på en liste, og hvert fall ikke en egen kolonne i et board - for teamet prater om det hele tiden, det er selvsagt at ting måles, og hver funksjonalitet bygges med målingsbehovet i tankene. Det blir en del av flyten. Det kan fortsatt prioriteres opp eller ned, men det prioriteres integrert med funksjonalitesprioriteringen. Jeg tenker at uu er litt det samme. I ordentlig modne team på uu, er ikke "uu" på et område en oppgave som må assignes noen. Det er ikke noe som må stå på en liste som må krysses av. Det er mer som måling eller sikkerhet - når du utformer løsningen som designer, er det en integrert del av arbeidet du gjør, og når det implementeres i kode, er det en integrert del av tankene du gjør deg. Og det diskuteres sømløst som en del av utforming og utvikling av funksjonaliteten - ikke som en separat greie.

Hva tror dere?
Stemmer hypotesene? Eller er det noe helt annet som kommer i veien?

Hvordan får vi universell utforming til å bli en del av teamhverdagen?

Tilgjengelighetserklæring sier du? La oss få oversikt først som sist.

La oss si at du jobber med at å lage selvbetjeningsløsninger, nettsider, apper, whatnot. Og så er det en prat i lunsjen om tilgjengelighetserklæringer og den nye uustatus-løsningen fra uutilsynet.

— Hvorfor tester ikke uustatus løsningen for oss? spør én
— Ja, hvorfor kan vi ikke konsentrere oss om å lage ting, ikke alle disse kravene? svarer en annen.

Hva svarer du da? Skumles nedover her, så finner du kanskje noen poenger å bruke 😄

Hva er disse tilgjengelighetserklæringsgreiene?

Så, Stortinget har sagt ja til å innlemme EU sine regler for økt tilgjengelighet av digitale tjenester. Dette heter Web Accessibility Initiative (WAI), og har fra 2016 inkludert et krav om at nettsider og apper fra det offentlige skal ha en såkalt Web Accessibility Statement.

På norsk kaller vi dette en tilgjengelighetserklæring. I Europa er disse reglene implementert på litt forskjellig vis. I Norge har en valgt å lage en sentralisert løsning der tilgjengelighetserklæringen for et nettsted fylles ut. Altså skal ikke hver offentlige virksomhet lage hver sin, med forskjellig oppsett og utseende.

Vent, jeg har ikke sagt ja til dette!

Vel, det er loven som bestemmer. Alt dette følger av EØS-avtalen, og i Norge har Stortinget valgt at det kun er offentlige nettsteder (altså, det offentlige er avsender) som må fylle ut skjemaet. Om en representerer det offentlige på nett må uustatus brukes.

Du fyller ut skjemaet, publiserer det, får en lenke, og legger dette i footeren på siden. Det er ingenting i veien for at private og frivillige virksomheter lager egne tilgjengelighetserklæringer. De får bare ikke gjort det via uustatus. Det er det Stortinget som har bestemt.

For å lage en ferdig tilgjengelighetserklæring må du gjennom seks steg. I filmen under får du en kort intro. (For ordens skyld: jeg har vært med og laget filmen.)



Hvorfor skjer disse nye tingene nå?

Dette er ikke nytt. Husk, EU sitt tilgengelighetsdirektiv ble lagt frem i 2016, vedtatt i 2019 og ble del av norsk lovverk i mai 2021, litt forsinket pga korona. Norge har underskrevet på EØS-avtalen og derfor blir gjerne EU sine regler til våre regler. Dette er altså en forutsigbar utvikling, ikke en overraskelse.

Vil du se hva fremtiden bringer for universell utforming? Sjekk hva EU skriver i deres Disability Strategy 2021—2030.

Men er ikke tilgjengelighetserklæringen bare et skjema da?

Mange tror det. De vil gjerne bare logge inn på uustatus og skrive inn “vi er gode på uu!”, trykke publisér og være ferdig med saken. OK, jeg overdriver litt. Men de fleste som kommer inn og ser på skjemaet blir straks klar over at dette er en stor jobb.

Skjemautfyllingen utløser nemlig et skred av oppgaver:

For å kunne fylle ut skjemaet på korrekt vis, må hele nettløsningen testes ordentlig. Her får mange seg en overraskelse. Det er jo ganske mange krav å fylle ut svar for, og for hvert brudd på kravene, må du beskrive hva som er feil, og forklare om det finnes tilgjengelige alternativer.

For å kunne vite hva uu-ståa er, og beskrive dette presist i skjemaet, må du kunne WCAG-kravene godt og vite hvordan du tester på korrekt vis.

For å holde oversikt over feilene du finner (alle finner feil, sånn er det) må du lage en oversikt der du samler, systematiserer og kategoriserer feilene du finner (tips: start med regnearket som uutilsynet har laget).

Deretter må en gå i gang med å rette opp feilene, teste dem, dokumentere at ting fungerer (eller ikke fungerer), legge det inn i oversikten, og så til slutt fylle det ut på korrekt sted i tilgjengelighetserklæringsskjemaet.

Og selv da, etter mye innsats, vil mange likevel oppdage at nettløsningen likevel inneholder brudd på kravene. Noe som er omtrent det første du ser i den ferdig publiserte tilgjengelighetserklæringen. Ikke all innsatsen dere har lagt ned. Ikke at det meste fungerer som det skal. Nei, for det er sluttbrukeren som tilgjengelighetserklæringen er til for, og hen lurer bare på: Hva er det som ikke fungerer her?

Men disse nye reglene gjelder vel ikke oss?

Hva da? WCAG-kravene? De er ikke nye, og de gjelder også deg (spesielt deg som tilbyr nettløsninger som brukes av det offentlige, da må du få orden i sysakene aller hurtigst).

I motsetning til fleste andre bransjer er ikke EDB-verden vant til at det finnes regler, forskrifter og lover som de må følge. For mange virksomheter var GDPR og de andre reglene som Datatilsynet følger opp en vekker. Men vi har hatt en egen forskrift om universell utforming av IKT-løsninger siden 2013, og diskriminerings- og tilgjengelighetsloven fra 2008 nevner IKT spesifikt.

For å overdrive litt, her er hvordan mye av IT-bransjen ser på regler: en holder seg for ørene, later som om de ikke finnes, og tenker at de forsvinner om en bare ignorerer dem.

OK, så hvorfor lage en tilgjengelighetserklæring?

Fordi forskriften sier at de skal lages for offentlige nettsider.

Greit, hva er denne tilgjengelighetserklæringen?

En kjapp måte for brukerne å sjekke 1. hva som ikke fungerer på en offentlig nettside og 2. om det finnes noen tilgjengelige alternativer for de tingene som ikke fungerer.

De nye reglene krever at de offentlige virksomhetene tester, og registrerer resultatene i et standardisert skjema på uustatus.no. Teksten en legges inn der, blir da synlig for brukerne. Tips: ikke skriv forklaringstekstene som om juristene i uutilsynet er mottakerne. Skriv til sluttbrukerne. Test gjerne tekstene med dem før du legger dem ut.

Hvorfor kan vi ikke lage vår egen tilgjengelighetserklæring?

Ideen er at brukerne av offentlige nettsider kjapt skal kunne sjekke “hva er det som ikke fungerer på denne offentlige nettsiden?” på en standardisert måte. Alternativet ville ha vært at de ville ha fått servert et utall forskjellige oppsett og utforminger på alle mulige offentlige nettsteder.

Hvorfor tester ikke uustatus nettsiden vår for oss?

Ønsket om at “uustatus-skjemaet fyller ut seg selv” er det mange som nevner. Men uustatus-skjemaet er ikke et testverktøy. Det er delvis et compliance verktøy, og delvis en løsning for å fortelle brukerne om hva som ikke fungererer. Ikke et testverktøy.

(Tips: NAV har en fin samleside om uu-testing)

Joda, det hadde vært supert om du bare kunne legge inn offentlignettsted.no i et felt på uustatus.no, trykke på en knapp, ta en kopp kaffe og være ferdig. Det er mye WCAG-testing som kan automatiseres, og de verktøyene bør du ta i bruk. Men mye må faktisk testes manuelt. Og i de kommende WCAG 3.0-reglene blir det større fokus på helhetlig testing med brukerne, ikke bare validering av formelle krav. Altså ville ikke en integrert, automatisert løsning ha sluttet sirkelen uansett.

Konsekvensene er det nye, ikke reglene

Det som er uvant for mange nå er at krav til universell utforming av IKT-løsninger som WCAG-kravene, standarder som EN 301 549, ISO 9241–210:20190, EUs Digital Markets Act, og selvfølgelig GDPR, now have teeth. En kan få (tidvis) store bøter for å ikke følge dem, og negativ oppmerksomhet.

Selv om det finnes mange offentlige virksomheter som har stålkontroll på uu (fx NAV) så er det mange som ikke har holdt oppsikt med uu-ståa og nå får sabla mye å kartlegge og rette opp i innen 1. februar 2023.

En nokså baklengs prosess for bedre tilgjengelighet

uustatus og tilgjengelighetserklæringene som offentlige tjenestefolk og konsulenter skal fylle ut er bare en anføring av uu-ståa, og i grunnen siste steg i prosessen. Men mange starter fra altså denne enden og velger å jobbe baklengs.

“Vi må få fylt ut dette skjemaet” sier folk. Og så oppdager de at det visstnok var ganske mange punkter de skulle gjennom, og ser at alt må testes, rettes, og dokumenteres før en fylle ut tilgjengelighetserklærinskjemaet og få null brudd. For de fleste vil dette ta lang tid å komme dit. Det ermye jobb i vente, men er det nok folk til å gjøre jobben?

Hvem skal egentlig fikse dette?

Sett opp mot behovet, er det for få fagfolk (frontendere, designere av alle slag, produktledere, backendutviklere, IT-arkitekter, the works) som i dag har nødvendig kompetanse om universell utforming. Altså løser en ikke dette ved å øke budsjetter. Det er et kompetanseløft i hele IKT-bransjen som må til.

Idé: vi kvalitetssikrer løsningen vi serverer til brukerne

At en har en løsning som bryter med WCAG-kravene er kjedelig, og må fikses. Og ja, det blir krevende å få tak i nok folk som kan fikse alt som bryter med forskriften.

Men det er nettopp dette som gjør tilgjengelighetserklæringer så bra.

Endelig må offentlige nettsteder si “Vi har sjekket uu-ståa, og her er hva som ikke fungerer per nå.” Det er vel bedre at avsender gjør det på en strukturert måte, og forteller det til brukerne, enn at brukerne får servert en nettside med udokumenterte feil og mangler?

Hva så om det finnes feil?

For de feilene har jo konsekvenser. Har du forsøkt å endre passtimen din hos Politiet? Nei, når dette skrives, går det går ikke an, fordi Qmatic-bookingløsningen de bruker har en kritisk feil. Jeg har forsøkt. Jeg har snakket med PIT. Når dette skrives er Endre time laget slik at du ikke får bekreftet endringene. Slett timen du hadde, og bestill en ny. Konsekvenser? Vel, om du trenger pass, og må flytte timen, er det upraktisk for deg, er det ikke?

Vent, må vi stå inne for det vi har kjøpt inn også?

Stemmer. Dere er også ansvarlige for at WCAG-kravene overholdes i løsningene dere har kjøpt inn, som opptrer på deres, som dere serverer til brukerne er universelt utformet.

Her vil de flinkeste leverandørene allerede har tatt hånd om dette, og levert en ferdig testrapport som dere kan bruke ifm utfylling av tilgjengelighetserklæring. Men om de ikke har kontroll, eller ikke har dokumentert, da har dere ansvaret overfor brukerne.

Må private følge uu-reglene?

Ja. Private virksomheter er underlagt de samme reglene. Forskjellen er at de ikke kan bruke skjemaene i uustatus-løsningen for å lage en tilgjengelighetserklæring.

Kompetanseheving neste!

Spørsmålene i innledningen er fiktive, men reflekterer innspill jeg har fått om tilgjengelighetserklæringer, WCAG-krav, forskrift om universell utforming av IKT-løsninger, m.m.

Enkelt sagt må alle vi som jobber med selvbetjening, nettløsninger, apper, osv heve vår egen kompetanse, lage gode rutiner løpende testing, dokumentering og forbedring av uu-ståa i løsningene vi lager.

Utfordringen da, er at det finnes for UX-/interaksjonsdesignere og frontendere, for få studieplasser til disse, for få som søker på disse plassene, knapt en god “overgangsutdanning” som gir folk med utdanning i andre felt en kvalifiserende vei inn i feltet, begrenset med etterutdanningsmuligheter og altfor få eksperter som kan undervise resten av oss i universell utforming, WCAG-reglene, forskriften, og mer til. Men, kanskje viser det seg at tilgjengelighetserklæringen var sparket bak vi trengte for å endre på dette.

Ser du fortsatt på?

I så fall kan du jo ta en kikk på denne tordentalen min fra Yggdrasilkonferansen 2022.



Jukselapp om WCAG-krav og tilgjengelighetserklæringer

På første møte med UU-faggruppen i Bekk var målet å bli kjent med de fire inndelingene av utfordringer som vi finner i samfunnet vårt. Vi var to stykker som kjørte en litt kreativ vri for å teste det å slite med motorikken, hvor kollegaen mi skulle navigere mens jeg ga henne ukontrollerte skjelvinger og bevegelser i hånda. Det ble fort tydelig hvor ekstremt vanskelig og ikke minst frustrerende det var å navigere seg rundt på nettsiden. Likevel har dette blitt en brukergruppe jeg tar meg selv i å glemme gang på gang. Jeg har det alltid i bakhodet at jeg skal hjelpe brukeren ved å beskrive en eventuell feil ved input, ha god nok kontrast og bruke enkelt språk… Men tenker jeg egentlig nok over hvordan jeg kan lage løsningen tilgjengelig for de med utfordringer med motorikk?









Hva innebærer det for brukeren?

Brukere med motorisk funksjonsnedsettelser vil typisk slite med skjelvinger, svak muskulatur og/eller mangler ved håndfunksjonen. Nedsatt motorikk påvirker hvordan en håndterer PC, nettbrett, telefoner og andre digitale dingser. Personer i disse målgruppene trenger ofte andre måter å styre og navigere digitalt utstyr enn med vanlig tastatur og mus. Det kan være skjermtastatur, joystick eller øyestyring. Mange kjenner på utfordringer med å navigere seg i det fysiske miljøet og internett kan da være en viktig kanal for å kunne delta i samfunnslivet på 

I et blogginnlegg på UU-tilsynet blir man kjent med Inge som for syv år siden ble lam i hele kroppen. Inge bruker hodemus for å navigere - den følger med når han snur på hodet og klikker i det han biter i en bøyle. For han ble spesielt nettsider med tidsbegrensning på input av informasjon en utfordring. Se for eksempel for deg billettbestilling. Ofte får du tre minutter på å fullføre alt, inkludert betaling før du «rykker tilbake til start». Nedtellingen vil nok sannsynlig være stressende for en med normal motorikk, men ekstra ille blir det for Inge som ikke klarer å bite tennene sammen fort nok til å rekke fylle ut skjemaet. For han ble autofyll-funksjonen på nettleseren en redder. Les mer om Inges bruk.







Hvordan kan vi bidra?

Som påpekt i Inges eksempel er tid et nøkkelord for å tilgjengeliggjøre siden. Brukeren bør få mulighet til å selv bestemme tidsbegrensninger og muligheten til å gjenoppta der hen falt ut. Det er også viktig å være bevisst om å begrense mengden informasjon brukeren må oppgi (ikke lovkrav, kun anbefalt). 

For andre er det vanskeligere å bruke mus, så derfor må alle nettsider kunne navigeres med tastatur. Å kunne bruke nettsider med tastaturet er både bra for en med nedsatt motorikk og for en med brukket arm etter et ambisiøst hopp i bakken. Kravene til tastaturnavigasjon innebærer logisk tastaturrekkefølge, at brukeren ikke skal bli stående fast i et element, å ha en snarvei som lar brukeren gå rett til hovedinnholdet og at det ikke skjer automatisk kontekstendring når brukeren navigerer med tastaturet. Når man skal bruke tastaturet for å navigere seg er det ekstra viktig med oversikt over hvor hen er. Mange brukere er avhengige av støtte for å forstå hvordan nettstedet er “skrudd sammen” - for eksempel bør menyvalget for den gjeldende siden markeres visuelt, men ikke være lenket. 

For både Inge, kollegaen min og meg er det tydelig hvor viktig store klikkflater har å si for at nettsiden skal bli brukbar. Det er både viktig på desktop og når man skal benytte seg av berøringsskjerm. Både størrelse på og avstand mellom objektene er viktig. Med korrekt kodet ledetekst blir både tekst og avkryssningsboks klikkbare. 







Jeg har også lyst til å tipse om en podcast jeg hørte på for en stund tilbake som jeg synes var veldig interessant


Tilgjengeligjør for motoriske funksjonsnedsettelser

Jeg leste en artikkel på Medium av Sheri Byrne-Haber som jeg syns var interessant og har lyst til å oppsummere noen av punktene hun skrev. Der diskuterer hun:

Hva er forskjellen mellom god (good) universell uforming og bra (great) universell utforming?
På norsk er ikke ordene like gode som på engelsk, men jeg håper forskjellen kommer frem.



1. God universell utforming handler om å oppfylle kravene. Bra universell utforming handler om empati

Hvis man skal lage systemer som har skikkelig bra UU så stopper man ikke får minimumskravene er oppfylt. Man gjør en ekstra innsats på å oppfylle enda strengere krav eller brukerteste med faktiske brukere, ikke bare en checkmark på en side. For eksempel er kontraktberegningen i WCAG 2 mangelfull. Bra universell utforming ville da vært å ta hensyn til flere faktorer som fargeblindhet, ikoner, fokus-states osv.Noe annet å tenke på er å ta like mye hensyn til internsider som eksterne. Ofte blir internsider nedprioritert siden det er færre brukere, men da kan man fort ekskludere arbedere i bedriften.



2. God universell utforming ser på produktet. Bra universell utforming ser på brukeropplevelsen

Brukeropplevelse er noe som er veldig viktig for at noen skal få lyst til å bruke ett produkt eller tjeneste igjen. En app kan oppfylle krav på papiret men likevel være vanskelig å bruke for noen med funksjonsnedsettelse. Bra universell utforming handler opp å teste hele brukeropplevelsen for flere typer brukergrupper. Og ikke bare kjernefunksjonalitet, men også mindre brukte funksjoner som ofte blir nedprioritert til slutten.



3. Bra universell utforming benytter også innsiktsarbeid fra brukere med funksjonsnedsettelse

Her ble det brukt et sitat fra USA som ble brukt for å få gjennom "Americans with Disabilities Act" som jeg syns var bra: Nothing about us, without us, is for us. Man skal aldri anta at man forstår behovene til andre, selv om man har egen erfaring. Skal man få til bra brukeropplevelse for folk med funksjonsnedsettelser må man spørre mange forskjellige type brukere under innsiktsarbeidet.



4. Spre ordet utenfor UU-sfæren

Det å delta/bidra på UU events eller konferanser kan være veldig lærerikt og givende, men man er allerede litt spesielt interessert hvis man først er på noe slik. Det er når vi tar opp emnet om bra universell utforming på andre typer konferanser og events at man potensielt får større spredning og konverer flere til formålet om bra universell utforming.

Hva er forskjellen mellom god og bra universell utforming

Create more efficient and accessible interfaces by adding visual redundancy to your UI components!

Image by Deepmind on Unsplash

Create accessible components by making them redundant

Several of the WCAG requirements are built on the concept of "redundancy" – repeating the same information several times through different means.

Redundancy can be providing the user with a text alternative for non-text content (1.1.1), an alternative for time-based content presented through video or sound (1.2.1), and captions for pre-recorded video with sound (1.2.2).

When users scan an interface to make sense of its contents, there are 5 visual "channels" that can be utilized to help in this understanding: shape, colour, texture, motion and depth.

"Visual redundancy" refers to the conveying of information by more than one visual channel, like displaying the meaning of a symbol through both shape and colour.


Example

Three relatively similar icons with different meanings

Redundancy with colour. Will not necessarily make a difference for those with impaired color vision or vision.

Redundancy with form. Will help those with impaired color vision to a greater extent.

Clarification with more color. Will to a greater extent help those with impaired vision.



Redundancy increases search efficiency

When we combine the features of several channels, we give users the opportunity to perform a visual search in more than one way. This allows the user to search more effectively with their eyes, see the difference between elements more clearly and find the information they are looking for more quickly.

Visual searches are fast, and redundancy makes a search go just a fraction faster. Meaning the effects of redundancy are more apparent when there are many elements to search, as in information-dense interfaces.

It is beneficial for those with impaired vision or colour vision to have alternatives that are comprehensible to them. Hence requirements 1.4.1 “Do not use presentation based solely on color”) and 1.3.3 “Instructions must not rely solely on shape, size, visual location, orientation, or sound to be understood”. Clarification also lowers the risk of errors due to cognitive load or cultural differences in colour perception.

So what are you waiting for?
Make your UI components visually redundant, today!
