Vägledningen för webbutveckling

Gratulerer, Sverige!

Skrevet av: Morten Tollefsen, 14.8.12

MTB: Dette er min personlige blogg, og artiklene er mer løse i stilen enn på f. eks medialt.no.

Sverige har fått offisielle retningslinjer for webutvikling, og i denne artikkelen skal jeg se litt nærmere på det som har med tilgjengelighet å gjøre. Jeg synes det står veldig mye fornuftig i disse retningslinjene. Men, litt synsing kommer jeg jo likevel med.

Du finner retningslinjene her

Retningslinjene gjelder offentlige institusjoner. Privat sektor kan også bruke retningslinjene, men dette er foreløpig ikke lovpålagt.

Seks prinsipper

  1. Tilgjengelig
  2. Anvendelig
  3. Förtroendeingivande
  4. Effektiv
  5. Teknisk uavhengig
  6. Åtkomlig över tid

Til hvert prinsipp finnes det retningslinjer med ulik prioritet: 1 (viktigst), 2 og 3. Retningslinjene kan knyttes til mer enn et av prinsippene. Dersom jeg klarte å telle riktig i farten er hele 33 av de 44 tilgjengelighetsretningslinjene også knyttet til anvendelig! Det er helt klart overlapp mellom tilgjengelighet og brukbarhet, men dette kan virke litt lite spisset synes jeg. Tilgjengelighetsretningslinjene er viktige, og 39 av de 44 retningslinjene har prioritet 1.

For hver retningslinje finner du:

  • Slik skal du gjøre.
  • Prioritet
  • Informasjon om hva som skal gjøres og hvorfor dette er viktig.
  • Konkrete tips (ofte med eksempler) på hvordan noe kan løses.
  • Fordypning (lenker til mer informasjon).
  • Målekriterier (sjekke om en retningslinje følges).

Tilgjengelig

Vägledning för webbutveckling: Webben ger stora möjligheter att tillhandahålla information och tjänster utan att diskriminera användare. Detta förutsätter dock att de utformas på ett korrekt sätt. Genom att väva in tillgänglighet i utvecklingsprocessen skapas förutsättningar för att så många som möjligt kan använda tjänster och information. Därmed bidrar tillgänglighet till ökad effektivitet för både den som tillhandahåller en tjänst och den som använder den.

Det innebär bl.a. att man utgår från de grundläggande principerna i WCAG 2.0.

WCAG 2 er et sentralt tilgjengelighetsprinsipp

R1 (Utgå från WCAG 2.0 nivå AA) sier at WCAG 2.0 nivå AA skal benyttes. Dette tilsvarer det som forventes i Norge når forskriften om web til Diskriminerings og tilgjengelighetsloven kommer. De 43 andre retningslinjene som hører til tilgjengelighet er delvis inkludert i WCAG (men da i form av suksesskriterier). I retningslinjene fremgår det at også organisasjoner må skaffe seg noe kompetanse om publisert innhold (dvs. ikke kun sette krav til publiseringssystemet): R25 (Förvaltningsorganisationen och dess kunskap ska stå i proportion till webbplatsens storlek och ambitioner). Denne retningslinjen er egentlig overflødig (siden alle andre retningslinjer jo skal følges), men det er helt OK som en påminnelse!

Pr. i dag er HTML det mest tilgjengelige, strukturerte filformatet. Jeg liker derfor følgende retningslinje: R88 (Publicera i första hand dokument i HTML)!

Visuell presentasjon

En god del retningslinjer omtaler utseende. I dette avsnittet tar jeg imidlertid kun de som mest direkte går på visuell presentasjon.

R39 (Ge webbplatsen en god läsbarhet): sier at det bør brukes relativ (em eller %) størrelser og at skrifttype/størrelse er viktig. Min erfaring fra brukertesting er at kontraster er enda viktigere, og det burde kanskje nevnes her? Kontrastkrav er angitt i WCAG, så forsåvidt dekkes det av de svenske retningslinjene.

R92 (Webbplatsen ska kunna användas även utan stilmallar): Nettsider skal kunne brukes også dersom stilark skrus av. Det kreves da selvsagt ikke at siden skal være "like pen", men siden skal presenteres på en måte som gjør at det er mulig å navigere, at informasjon kommer i en logisk rekkefølge og at informasjon kan leses. Et av rådene som står under retningslinjen er: "Undvik referenser som förutsätter att användaren kan uppfatta spatiala relationer eller färger, till exempel ”rutan till höger” eller ”den gröna knappen”." Se på nettstedet ditt, så finner du nesten helt sikkert slike forklaringer! Du bør absolutt unngå denne typen forklaringer, men det er ikke lett (hjelpeteksten du skriver skal jo være forståelig for alle)!

R103 (Markera citat i koden): begrunnes med skjermleser, men er vel i det praktiske liv mer en visuell sak. q for å markere korte sitater og blockquote for lengre sitater. Forresten det eneste "Prio 3" kravet (som jeg nettopp brøt, gitt)!

Feilmeldinger og tilgjengelighet i tilgjengelighetsstandarden

Selv i en veileder av denne typen er det lett å finne eksempler på tilgjengelighetsproblemer. Betyr det at tilgjengelighet er nesten uoppnåelig? Jeg synes denne veiledningen er veldig god, og jeg skal ikke problematisere tilgjengeligheten i denne artikkelen. Men et eksempel må jeg få komme med:

R2 (Gi forståelige feilmeldinger) inneholder mye fornuftig om hvordan feilmeldinger bør gis. Men eksemplet på hvordan gode feilmelinger skal utformes er et bilde uten alternativ tekst. Burde ikke dette ha vært HTML, som jo i de fleste tilfeller er det språket som brukes for å formidle websider inkludert feilmeldingene? Jeg som blind fikk i alle fall ikke noe eksempel på gode feilmeldinger.

Hjelp om nettstedet og definisjon av målgruppe

R19 (Skapa sidor med information om hur webbplatsen fungerar och vad den innehåller)er en retningslinje jeg har stor sans for! I retningslinjen legges det vekt på å forklare muligheter for tilpasninger. Etter min mening burde det her også stått mer om å gi en god forklaring av informasjonsarkitektur og intern sidenavigering (landemerker, bruk av h-tag'er osv). Web er et så kreativt medium, med så få standarder, at en slik overordnet forklaring kan være nyttig for mange brukere. I en slik hjelpetekst kan det til og med være aktuelt å gi enkelte tips til spesifikke brukergrupper, f. eks brukere som benytter talegjenkjenning, skjermlesere, tastatur uten mus osv.

R8 (bestem målgruppe, hensikt og sammenheng for teksten din) er etter min mening også en veldig fornuftig retningslinje. Alle som har jobbet med tilgjengelighet vet at ikke alt kan være for alle. Faktisk er det ingenting som er for alle. Offentlige nettsteder skal normalt ha en bred målgruppe, men likevel er det nødvendig å gjøre valg dersom informasjonen skal nå ut til de som kan ha nytte av teksten.

Språk

Veiledningen legger stor vekt på språk, og det er flere retningslinjer som handler om språk:

Språk er også med i andre retningslinjer enn de som står i listen over. Om disse retningslinjene faktisk burde stå under tilgjengelighet kan diskuteres, i alle fall dersom ordet brukes slik vi vanligvis benytter begrepet i Norge: tilgjengelig for mennesker med nedsatt funksjonsevne. Men under anvendelig skal disse retningslinjene selvsagt med!

R9 (Ge dokument tydliga filnamn) er et prinsipp det syndes mye mot. Filnavn til eksterne filer bør ha et forståelig navn, og det er ingen grunn til å utelate etternavnet ".pdf", ".docx" osv. For brukere med litt erfaring kan etternavnet gi nyttig informasjon, og for alle andre er det vel ikke så plagsomt. I tillegg går det selvsagt ann å ha et ikon som gjør det enklere for mange å skjønne hva slags fil det lenkes til.

En av mine "kjepphester" er å bruke gode overskrifter. Dette innebærer forklarende og korte tekster, og riktig html (h-tag'er). Heldigvis er følgende retningslinje med: R61 (Skriv tydliga och berättande rubriker), R105 (Skapa rubriker med h-element) og R98 (Använd tabellrubriker för att hjälpa användaren).

Lenker, hurtigtaster og eksterne tjenester

Lenker er selvsagt viktige på web, og flere retningslinjer omhandler lenker.

R5 (Skriv tydliga länkar) er nevnt under språk.

R34 (Gör länkar och klickbara ytor enkla att använda för alla) er at av de retningslinjene som har flest underpunkter. Primært går kravene på størrelse og synlighet/tydelighet. Her kunne det absolutt også stått noe om tab-rekkefølge, tydeliggjøres at alle klikkbare objekter også skal kunne nås med tastatur osv. Dette er forsåvidt dekket gjennom R1 (WCAG), men det samme er forsåvidt en del av punktene som nevnes helt eksplisitt.

R75 (Gruppera och skapa möjlighet att hoppa förbi delar på sidorna) går primært på interne hopp på siden vha. lenker. Heldigvis står det ikke noe om skjermleser, for det har vært en utbredt missforståelse at denne funksjonaliteten primært er beregnet for blinde. Derfor har også lokale hopp ofte blitt skjult fra den visuelle presentasjonen. Lokale hopp er viktige for tastaturbrukere, og for mobiler uten pekeskjerm. Det står at de lokale hoppene helst bør vises. Enig! Hvis de ikke kan vises bør de vises når lenken får fokus. Uenig! Skal det brukes lokale hopp må de vises. Ellers legges det alt for stor vekt på at brukere som trenger denne funksjonaliteten sitter og trykker Tab i tilfelle det skulle dukke opp en skjult lenke. Tenk om det hadde vært gjort noe tilsvarende for mus: pek på måfå på blanke deler av siden i tilfelle det finnes skjulte, klikkbare objekter! Egnet i dataspill, kanskje, men neppe på offentlige nettsider.

R74 (Presentera externa tjänster på ett enhetligt sätt)er et prinsipp det syndes mye mot (f. eks integrasjoner mot Facebook og Twitter)! Også de som ønsker veldig god tilgjengelighet har lett for å si: "Ja, men det er en ekstern tjeneste vi ikke får gjort noe med." Dette er nok riktig noen ganger, men da bør du vurdere å droppe tjenesten eller utvikle integrasjonen slik at brukere får en enhetlig (konsistent) opplevelse. Dette er muligens ikke aktuelt for større tjenesterr, men målet bør være at brukeren ikke merker at eksterne tjenester er annerledes enn resten av nettstedet. R67 Ta (reda på konsekvenserna av att använda externa tjänster i din webblösning) sier at det skal tas en vurdering av konsekvenser ved innføring av eksterne tjenester.

R68 (Skapa snabbkommandon för viktiga funktioner)oppfordrer til bruk av hurtigtaster. Den brukertestingen jeg har foretatt tyder på at hurtigtaster på web er lite brukt, men på nettsteder jeg selv bruker mye kjenner jeg hurtigtastene og benytter disse. Det foreslås å bruke et sett med standardiserte tastetrykk. Selv om hurtigtaster ikke brukes så mye av alle er de jo heller ikke i veien!

Skjemaer

Skjemaer er blant de vanligste tilgjengelighetsutfordringene på offentlige nettsteder. Veiledningen gir flere råd for å lage gode skjemaer:

R53 (Gruppera formulärets fält): sier at store skjemaer bør deles opp i flere sider eller felt som hører sammen skal grupperes på en side. Merkelig nok er ikke denne retningslinjen knyttet til anvendelig-prinsippet!

R55 (Skapa tydliga och klickbara fältetiketter): sier at label-tag'en skal brukes for å gi felt forståelige beskrivelser. Eventuelle forklaringer skal ikke ligge i selve skjemaet, men være plassert før feltene.

R58 (Ändra inte utseende på formulärelement): oppfordrer til å bruke standard input-felt. Hadde dette prinsippet blitt respektert hadde en god del tilgjengelighetsproblemer vært unngått, og ganske mye penger hadde vært spart! Alt for mange tror at det er imponerende å lage sine egne kontroller, men blir vi egentlig noe særlig imponert?

R63 (Hjälp användaren att förstå var hon befinner sig i en process): viktig retningslinje. Den brytes sikkert mange steder, men min erfaring er at mange prosesser på internett faktisk viser hvor du er. På intranett har jeg imidlertid sett mange ganger at lange prosesser helt mangler indikasjoner på hvor du er.

R70 (Skydda användaren mot att oavsiktligt förlora arbete hon påbörjat): prøver å gi råd for å minimere risikoen for å miste arbeid brukeren har gjort. Dette er vel noe alle har opplevd på web, og det er skikkelig irriterende. Løsningene som foreslås er tunnell (hindre brukeren i å forlate prosessen) og beskyttelsesnett (javascript som merker at brukeren avslutter nettleseren eller forlater prosessen).

R85 (Användning av knappar i formulär): sier at knapper skal være tydelige, og at det bør finnes en Avbryt-knapp. Et råd jeg synes høres fornuftig ut er å unngå "Rens skjema". Sjansen for at brukere trykker på denne knappen ved en feiltakelse er større enn behovet for en slik knapp.

Flash og annet stæsj

R86 (Basera inte viktig funktionalitet på format som kräver insticksprogram): sier at viktig funksjonalitet (f. eks navigering på nettstedet) ikke skal baseres på Flash, Silverlight, Quicktime osv.

R93 (Gör inte webbplatsen beroende av JavaScript): er ikke et forbud mot Javascript. Det står: "Observera att den här riktlinjen inte på något sätt ska tolkas som ett förbud mot att använda JavaScript. Tvärtom! JavaScript kan, rätt använt, öka både prestanda och användbarhet högst avsevärt för majoriteten av besökarna." Retningslinjen har vært der siden WCAG 1.0. Dette er en av de få retningslinjene som kun knyttes til prinsippet tilgjengelighet. Jeg er litt (eller mye, kanskje) skeptisk til en retningslinje av denne typen. Hvis det hadde blitt gitt konkrete eksempler på at hjelpemidler ikke takler JavaScipt hadde det kanskje vært mer forståelig for utviklere? Det er helt opplagt mulig å lage JavaScipt som fører til kjempeproblemer for hjelpemidler, men JavaScipt kan også brukes for å bedre tilgjengeligheten. Prinsippet bør kanskje flyttes til "anvendelig" hvis det i det hele tatt trengs i den formen det står nå?

Multimedia

Retningslinjene sier ikke så mye direkte om multimedia.

R11 (Kombinera skrift med ljud, bild och film): omhandler først og fremst hvordan bilder, lyd og film kan komplettere tekst. Her er det et konkret råd om å inkludere en syntetisk tale-funksjon på sidene. Interessant, for det er jo noe som diskuteres mye! Ellers er det mange gode råd her, som kanskje "Vägledningen för webbutveckling" selv burde ha implementert, hehe.

Godt håndverk

Noen retningslinjer er først og fremst god drift/koding. Disse retningslinjene kan forsåvidt også ha litt med tilgjengelighet å gjøre, men for å gjøre veiledningen enklere å sette seg inn i kunne muligens retningslinjene knyttes til andre prinsipper (alle disse hører til flere av kategoriene nevnt innledningsvis). På den annen side er det helt klart at f. eks det å følge standarder også er et godt tilgjengelighetsprinsipp!

Mange er opptatt av å ha stempler på at sidene deres følger wcag eller andre standarder. Jeg har opplevd mange ganger at et nettsted gjøres tilgjengelig og at det f. eks stemples med "Følger wcag 2.0". Fokus på tilgjengelighet er imidlertid ofte ikke en del av det løpende vedlikehold/driftsarbeidet, og ofte blir nettstedet mindre tilgjengelig etter hvert som tiden går. Datostempling for når et nettsted er sjekket kan derfor være nyttig, og jeg trodde R23 (Ange när informationen granskades) nettopp gikk på dette. Det står vel forsåvidt også litt om dette, men retningslinjen går hovedsaklig på at publiseringsdatoer skal være synlige.

Del på Facebook Del på Twitter Del på e-post