Hopp til hovedinnhold

Design og UX / 5 minutter /

Universelt utformet kode

Norske nettsteder er for dårlige på universell utforming. Det er det vi som jobber med systemutvikling som kan gjøre noe med. Morten gir deg tipsene og eksemplene!

Difi har målt status for universell utforming norske nettsteder og de er ikke fornøyde:

Dei vanlegaste feila vi finn er feil i kodegrunnlaget, mangel på tekstalternativ til bilete og illustrasjonar, feil bruk av lenker og dårleg kontrast
Difi

Brukere som benytter tekniske hjelpemidler som skjermlesere og leselister, vil merke stor forskjell på god og dårlig kode. Sørger du for å skrive ryddig og semantisk HTML er du langt på vei mot universelt utformet kode.

Hva er ryddig og semantisk HTML

All HTML vi bruker er med på å beskrive innholdet og det er da svært viktig at den er benyttet riktig. God HTML-markup er en stor del av det å utvikle et universelt utformet nettsted eller applikasjon.

Søkemotorer er også veldig glad i ren og ryddig HTML, så dermed slår du to fluer i en smekk - du gjør nettstedet mer synlig og mer tilgjengelig. Husk at Google, som konstant leser, tolker og indexerer nettsider, er den blindeste brukeren av dem alle.

Her er noen enkle leveregler:

Tabeller

Aldri bruk tabeller til layout! Nok om det.

"Nye" HTML5-elementer

Bytt ut mange av dine div'er med HTML5-elementer som for eksempel main, article, nav, header, footer og figure. Alle disse som er med på å tilføre mer semantikk til innholdet vårt, men kun hvis de brukes riktig.

Overskrifter

Header-tags (h1, h2, h3, h4, h5 og h6) skal brukes til å strukturere innholdet, ikke til å bestemme størrelsen på teksten.

h1 er den overordnede overskriften til innholdet og skal på en tydelig måte forklare hva det dreier seg om. En side kan godt inneholde flere h1, men da må de være innenfor hver sine HTML5 seksjonerings-elementer, som for eksempel article, footer eller section.

De ulike h-taggene forholder seg også til hverandre. h2 er en underoverskrift av h1, h3 er en underoverskrift av h2, osv

Overskrifter bruker vi til å skumme gjennom innholdet, og synshemmede og blinde kan få lest opp alle overskrifter og hvilket "nivå" de har.

Title

En sidetittel skal på en kort og tydelig måte fortelle hva siden handler. For brukere som benytter seg av skjermlesere er sidetittel (noe av) det aller første som blir lest når siden er lastet.

Sidetittelen skal være unik innenfor et hvert webområde for å unngå forvirring. Hvis man har to ulike sider som for eksempel heter "kontakt", men inneholder henholdsvis adresseinformasjon til bedriften og et kontaktskjema, vil brukeren lett å miste tråden.

Gode sidetitler er også nyttig for de som liker å benytte seg av faner i nettleseren. Man vil enklere kunne navigere fra fane til fane hvis tittelen er godt utformet. Dette hjelper spesielt brukere med kognitive utfordringer forbundet med hukommelse og konsentrasjon. Et favicon hjelper også her.

Navnet på nettstedet kan godt være en del av sidetittelen, men da på slutten. De som navigerer seg til siden fra eksterne kilder som sosiale medier eller søkemotorer, vet da hvor de er kommet.

  • Eksempel på en god sidetittel med det viktigste først:
1<title>Gode brukeropplevelser – Kantega.no<title>
2<link rel="shortcut icon" type="image/png" href="favicon.ico">

Tekstalternativer til lyd og bilder

Informasjon som bilder, illustrasjoner og videoer skal ha et tekstalternativ i form av et alt-attributt som beskriver innholdet. Bilder og grafikk som kun brukes som dekorasjon skal legges i CSS'en, men hvis det av en eller annen grunn ikke er mulig må du legge til et tomt alt-attributt (alt=""). Utelater du alt-attributtet vil noen skjermlesere lese opp filnavnet, noe man ikke ønsker.

Et tekstalternativ til en video vil typisk være underteksting eller en transkripsjon. Dette vil ikke bare være til nytte for blinde og svaksynte med skjermlesere, men også for en pendler på toget som har glemt ørepluggene. YouTube og Vimeo gir brukerene sine mulighet til å legge inn tekstinnhold til sine videoer selv.

Navigasjon med tastaturet

En nettside eller applikasjon skal være mulig å benytte kun ved hjelp av tastaturet.

Den vanligste måten man navigerer en nettside på er ved hjelp av tab og shift+tab. Denne måten fungerer veldig bra out-of-the box hvis du har en god dokumentstruktur.

Vær forsiktig med å mikse og trikse altfor mye med egendefinerte navigeringstaster og snarveier. Dette kan fort skape konflikt med brukerens eller nettleserens egne innstillinger.

Hvis man skal manipulere den rekkefølgen som brukeren tabber seg igjennom innholdet på, benytter man html-attributtet tabindex.

Bruk av lenker

En lenke skal beskrive hva brukeren kan forvente å finne på "den andre siden". Aldri forklar hvor brukeren skal trykke - gjør du det betyr det at nettstedet ikke er intuitivt nok.

"Les mer" og "klikk her". To svært populære lenketekster som også er svært elendige. Slike lenker sier ikke noe om hva brukeren kan forvente å navigere til. Forestill deg en skjermleser som hopper rett til en link som sier "les mer". Les mer om hva da?

Synshemmede brukere kan også hente ut en liste over lenkene for å få en oversikt over hva nettstedet inneholder og hvilke sider det er mulig å navigere seg til. Gode lenketekster gjør en dette mye lettere.

Skjemaer

Skjemaer er noe av det vanskeligste og viktigste å gjøre riktig. Mange bedrifter og organisasjoner er helt avhengig av at skjemaene deres fungerer og at flest mulig kan benytte de. Enten det er at brukeren gjennomfører en betaling, en påmelding eller noe så enkelt som å logge inn. Jo flere som klarer å benytte et skjema, desto større blir konverteringen.

  • Benytt riktig input type. På en smarttelefon vil disse input typene gi brukeren det tastaturet som trengs for å fylle inn feltet. tel viser kun tall og email har @ lett tilgjengelig.
  • Ta i bruk fieldset med legend på større skjemaer
  • Bruk label til hvert input eller på en annen måte gi inputen et "accessible name" - mer om det senere.
  • Ikke bruk placeholder attributtet som en erstatning for label
  • Styr unna hjemmesnekrede skjemaelementer som fancy sjekkbokser og radiobuttons som krever ekstra JavaScript for å fungere. Hvis du absolutt må gjøre det blir du nødt til å tilføre og endre semantikken til HTML-elementer.

Noe som bringer meg til neste punkt.

WAI-ARIA

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) handler om tilgjengelighet og er en stor del av universelt utformet kode. Det er en spesifikasjon som beskriver hvordan man kan endre og supplere semantikk og metadata til HTML-elementer.

WAI-ARIA er med på å gjøre komplekse webapplikasjoner forståelig og brukbare for de som benytter tekniske hjelpemidler som for eksempel skjermlesere. Jeg nevnte tidligere at semantisk HTLM-kode gjør mye av jobben når det kommer til universell utforming, men i noen tilfeller vil det ikke finnes HTML-tager eller attributter for å beskrive alt innhold i en webapplikasjon eller nettside.

Hvordan kan man for eksempel, med kun HTML, fortelle at innhold er skjult men kan vises ved å trykke på en tab? Eller hvilket innhold som akkurat der og da er mer viktig enn alt annet og krever brukerens umiddelbare oppmerksomhet? Visuelt kan alt dette oppnås ved hjelp av CSS og JavaScript, men semantisk beskrives dette med WAI-ARIA.

Role, name og state er tre stikkord du må merke deg.

Role

Role brukes rett og slett for på beskrive innholdet: "Hva er det?". Under ser vi et eksempel på hvordan vi kan tilføre semantikk til en tab-meny ved hjelp av rollene tablist og tab:

1<ul role="tablist">
2<li id="tab1" aria-controls="kontakter-tab-content" class="active">Kontakter</li>
3<li id="tab2" aria-controls="instillinger-tab-content">Innstillinger</li>
4</ul>
5 
6<div id="kontakter-tab-content" aria-labelledby="tab1" role="tabpanel"></div>
7<div id="instillinger-tab-content" aria-labelledby="tab2" role="tabpanel" class="hide"></div>
8

Name

Alle elementer som brukeren benytter seg av i grensesnittet skal ha et "accessible name". Dette skjer som regel automatsik så lenge du benytter semantisk HTML. For eksempel blir navnet til et inputfelt satt av tilhørende label, og en input type="button" vil ta navnet sitt fra attributtet value.

Når ikke HTML gjør jobben kan du ta i bruk WAI-ARIA attributtene aria-label eller aria-labelledby.

1<button aria-label="velg dato">
2  <img src="calendar.png" alt="">
3</button>

State

En state er tilstanden til HTML-elementet, for eksempel om innholdet er skjult eller utvidet. I motsetning til role og name, vil state kunne endre seg etter hvert som brukeren klikker seg rundt. Dette må du altså sørge for å styre med JavaScript.

Er noe skjult for brukeren beskrives dette med aria-hidden="true". aria-hidden vil IKKE visuelt skjule elementet fra siden, det gjør man med css.

11
2<p id="msg_success" aria-hidden="true" class="hide">Suksess!</p>
3

Hvis en tabell laster inn ny data vil man typisk legge til en aria-busy="true".

1<table>
2  <thead>
3    <tr>
4      <th>Id</th>
5      <th>Navn</th>
6    </tr>
7  </thead>
8  <tbody aria-busy="true">
9    <tr>
10      <td colspan="2">
11        <img src="images/loading" alt="laster data">
12      </td>
13    </tr>
14  </tbody>
15</table>

Landmark roles

For å beskrive de ulike delene i et grensesnitt bruker man WAI-ARIA landmark roles. Dette er med på å strukturere innholdet og gjør det enkelt for brukeren å hoppe direkte til dette innholdet.

Skal man logge inn vil dette typisk ligge i headeren øverst på siden, der blant annet logo og hovednavigasjon ligger. Da ser man gjerne etter role="banner":

<header role="banner"></header>

Ute etter copyright-info og kontakt-info? Dette finner man vanligvis i footeren:

<footer role="footer"></footer>

Footer-eksemplet over virket litt overflødig, men er slett ikke feil. Dette bringer oss til et viktig poeng...

WAI-ARIA vs HTML5

Det er i utgangspunktet ikke nødvendig å kombinere WAI-ARIA og HTML som gir den samme semantikken. W3C kaller dette "a waste of time". Men med tanke på bakoverkompatibilitet kan det uansett være en ide å legge til WAI-ARIA der man kan. Dette gjelder kun de "nye" HTML5 elementene hvis støtte ikke er 100% utbredt ennå. Vurder dette opp mot hvilke nettlesere og devices dere skal støtte.

Det vil ikke være nødvendig å gjøre følgende med en vanlig punktliste: 

1<ul role="list">
2<li role="listitem">Stark</li>
3<li role="listitem">Lannister</li>
4<li role="listitem">Targaryen</li>
5</ul>

WAI-ARIA er et fint hjelpemiddel, men bruk det kun hvis du absolutt må. Hvis det finnes et HTML-element eller attributt som gjør det samme så bruk dette i stedet!

Lyst til å lære mer om universell utforming:

Difi: Hva er universell utforming

W3C Accessibility