Universell utforming for web

I denne guiden tar vi for oss det du må ha på plass for å få universelt uformende nettsider og hva det er lurt å tenke på før du begynner å arbeide med det.

Innledning

Universell utforming på web oppnås ikke bare gjennom et webutviklingsprosjekt; det er en kontinuerlig prosess. For å lykkes må tilgjengelighet være en del av den overordnede webstrategien.

Universell utforming kan ofte bli forsømt i strategien til et nettsted. Den prosjektansvarlige har ofte for mye å gjøre, og universell utforming kan bli oversett. Av og til blir det antatt at det er for dyrt eller tidkrevende til å lønne seg.

Det blir ikke forsømt på grunn av mangel på interesse eller vilje, men fordi det ikke er nok gjennomsiktighet fra leverandørene. Mange bedrifter tar ikke med universell utforming som krav til leverandører som konkurrerer om å jobbe med nettstedet deres, eller til programvaren som leverandøren integrerer i ulike applikasjoner og nettsider. Dersom det inngår i kravene til tilbyderen, er det vanlig å anta at det vil bli gjort, men det er ikke alltid tilfelle.

Et annet problem er at mange webansvarlige ikke kan nok om universell utforming til å vite at ordentlig tilgjengelighet på nett er en vedvarende prosess, ikke bare en kodeoppgave i utviklingsfasen.

Universell utforming kan ikke bare legges til et pågående nettprosjekt og et nytt nettstedsbudsjett. Dersom du for eksempel ønsker å legge en video på nettstedet ditt, og du vil at den skal følge retningslinjene på AA-nivået, som er et krav mange steder, er det mye du må tenke på. Du må for eksempel tilby undertekster, lydbeskrivelser, m.m. Dersom du ønsker å følge retningslinjene på AAA-nivået, må du også tilby tegnspråktolking av innholdet. Har du det som trengs til dette hver eneste gang du skal laste opp en video til nettstedet ditt?

Universell utforming er viktig gjennom hele livsløpet til nettstedet. Hver gang du integrerer en tredjepartsløsning eller laster opp video- eller audio-innhold må du tenke på universell utforming. Redigeringsprosessen og CMS-et til nettstedet påvirker også situasjonen, og må noen ganger følges opp.

Det er lurt å lage en strategi for hvordan du skal nå tilgjengelighetsmål. Det er også lurt å ta inn tilgjengelighetskriterier i bedriftens kommunikasjonspolicy, designguide, innkjøpsregler osv. Skap et nettverk av interessenter og ambassadører blant kollegaer underveis i prosessen.

Viktige Ressurser

Når du vurderer om et nettsted følger WCAG-retningslinjene må du vite hva du har å tjene på både å kjøre automatiserte og manuelle tester, for å forsikre deg om at du tester nettstedet i forhold til relevante kriterier. Først må du få oversikt over roller og ansvarsområder i egne avdelinger, for å avgjøre hvem som skal bidra i vurderingen, og hvordan. Alle ressurser spiller en rolle, enten det gjelder testing og fiksing, eller ved å designe nettstedene slik at vilkårene blir oppfylt.

Det er mye bedriften kan gjøre selv. Men noe krever likevel hjelp utenfra, spesielt det som gjelder kode eller tillegg, som tekst på video. Se gjennom listen med problemer, og del dem inn i kategorier.

Husk at A- og AA-nivået er lovpålagte i Norge, men at AAA er valgfritt å jobbe med.

Roller og ansvarsoppgaver innen digital universell utforming

Det er viktig å fordele eierskap og etablere ansvarsoppgaver. Det er lurt å ha en tilgjengelighetskoordinator eller en ansvarlig som man kan rådføre seg med når det oppstår spørsmål eller behov for avgjørelser. Det kan handle om generell kunnskap om tilgjengelighet, restrukturering, nyinnkjøp og integrering, endring av eksisterende policyer og mer.

Det er også lurt å dele strategien inn i ansvarsområder og subsidiære mål:

  • Hvilke avhengigheter har vi i forhold til eksterne tilbydere, og hvem skal sette i gang en dialog med dem?
  • Hvem passer på at tilgjengelighet blir integrert i ulike interne policyer? (Kommunikasjonspolicy, design-guide, innkjøpspolicy, osv.)
  • Hvem tar ansvar for tilgjengelighet i design- og utviklingsfasen?
  • Hvordan følger vi med på utviklingen vår mot å bli mer tilgjengelig, og hvem skal holde oss ansvarlige?
  • Hvem organiserer opplæringen, ikke bare for web-avdelingen, men for hele bedriften?

Webansvarlige

Dersom du har ansvar for å gjøre et nettsted tilgjengelig, da er alle WCAG-kriteriene viktige for deg (oftest til AA-nivået). Du må ha en grunnleggende forståelse av emnet for å lede et prosjekt fra utvikling til evaluering og kvalitetssikring. Det er også viktig å forstå kravspesifikasjonene, i tillegg til lover for universell utforming som gjelder bedriften din. Du må også lære webredaktørene hvordan de publiserer universelt utformet innhold. Da kommer alt nytt innhold til å gjøre nettstedet ditt mer tilgjengelig, uten at det blir skapt nye tilgjengelighetsproblemer.

Det er også helt nødvendig å integrere tilgjengelighetskriterier i policyer og retningslinjer for merkevaren, og spre informasjon om eventuelle endringer til hele bedriften.

Husk at digital tilgjengelighet er en prosess, ikke et prosjekt. Dersom avdelingen din oppdaterer en eksisterende nettside, er spørsmålet ofte: "Hva er det mulig å få gjort noe med?" Begynn med å bruke verktøy som gir deg en rask oversikt over problemene. For større nettsteder må dette være en prioritert oppgave. Start med forsiden og et utvalg av template-sider. Det er ofte behov for mindre justeringer i CSS-koden eller i en template, så blir problemet også løst på alle sidene. Dersom noen av nettsidene inneholder spesielt innhold som video, dynamisk innhold eller interaktivt innhold som skjemaer, er det viktig også å inkludere disse sidene.

Det kan finnes områder der det ikke finnes noen rask løsning. Noter deg disse, slik at du ikke glemmer de, og ta det opp som et tema i det neste relevante møtet.

Lag en langsiktig strategi for jevnlig å evaluere tilgjengeligheten. Det kan være ukentlig, månedlig, hvert kvartal eller hvert halvår. Finn ut hva som er gjennomførbart og nødvendig for bedriften din.

Webdesignere

Webdesignere er arkitektene bak brukeropplevelsen. De tar viktige avgjørelser om layouten som skal bygges. Det er viktig for dem å tenke på universell utforming, og ta ulike behov og evner med i betraktningen, slik at ingen blir glemt.

Det er flere tilgjengelighetskriterier som er viktige for at du som webdesigner skal skape et nettsted som inkluderer så mange brukere som mulig.

Konsekvent design

Med tanke på tilgjengelighet og generell brukeropplevelse, er det viktig at designet er konsekvent på alle nettsidene dine. Globale elementer som menyer og hjelpeverktøy bør være ordnet i samme rekkefølge overalt på nettstedet. Det er også viktig at elementer med den samme funksjonen (som ikoner og referanser) blir ordnet og merket på samme måte på alle sidene. (Suksesskriterium 3.2.3 og 3.2.4)

Navigering

For at brukerne lett skal kunne finne informasjon bør det være mer enn en måte å finne spesifikt innhold på en nettside. Brukeren kan finne innhold ved å navigere seg gjennom det tiltenkte sidehierarkiet. Men det bør også være mulig å finne siden på andre måter, som gjennom et nettstedskart, en innholdsfortegnelse eller en søkefunksjon (Suksesskriterium 2.4.5). Dette gjør at besøkende som navigerer med tastatur på nettstedet ditt, kan finne det de leter etter uten å møte hindringer på veien.

Overskrifter

Når du designer et nettsted, og bestemmer hvordan det skal se ut og føles, er det viktig å huske at noen brukere ikke kan se siden; de må forholde seg til sidestrukturen. De som bruker skjermleser har ofte en snarvei-knapp som gjør at de kan høre alle overskriftene på siden, eller få opp en meny med en liste over overskrifter som de lett kan hoppe til.

Pass på at sidene er delt inn i logiske seksjoner, alle med en overskrift som forklarer innholdet, slik at hjelpeteknologier kan bruke dem som overskrifter til seksjoner. For å gjøre dette skikkelig, må seksjonene merkes med overskrifter som <h1>, <h2>, <h3>, osv.

Ønsker du å fremheve et område logisk og visuelt, ved å bruke fet skrift, stor skrift eller en annen farge, bør overskriften også fremheves i koden. På denne måten virker overskriften ikke bare visuelt, men også strukturelt. (Suksesskriterium 1.3.1 og 2.4.6).

Bruk av farge

En nettside med informasjon eller data som bare blir representert med farger er frustrerende og ineffektivt for brukere som er fargeblinde. Linker inne i teksten bør for eksempel fremheves med mer enn bare en annen skriftfarge. Feilmeldinger blir ofte uttrykt i en rød farge, og dette kan gjøre det vanskelig å lese for fargeblinde. Disse lenkene eller meldingene bør suppleres med understreking, et symbol, osv. (Suksesskriterium 1.4.1)

For at brukere med synsvansker skal kunne lese all tekst på nettsider, er det viktig at kontrasten mellom tekstfargen og bakgrunnsfargen er stor nok. Dette kan gjøres ved å benytte en kontrastvariasjon på 4,5:1 for vanlig tekst og 3:1 for stor tekst. Det finnes flere tilgjengelige verktøy som hjelper med å måle kontraster raskt. Siteimprove har en innebygget fargesjekk for å finne kontrastfeil. (Suksesskriterium 1.4.3)

Lenker

Når et element på en nettside er en link eller noe man kan trykke på, er det viktig at lenketeksten eller elementbeskrivelsen er forståelig når den blir lest uten kontekst. Skjermlesere kan lese en meny som lister opp alle lenkene på siden. Lenketekster som "les mer", "klikk her" eller "her" er eksempler på dårlige lenketekster. Dette fordi besøkende som bruker skjermlesere eller annen hjelpeteknologi umulig kan forstå hvor lenken leder uten den rette konteksten. Lenketekster skal være kortfattede og presise. Et eksempel på en god lenketekst er: "Trykk her for å laste ned sjekklisten for universell utforming." (Suksesskriterium 2.4.4)

Interaktive elementer

Når du designer interaktive elementer, må det være tydelig for brukerne hva som skal skrives inn, valgt, krysset av for, osv. Bruker du tekstfelter, nedtrekksmenyer, sjekkbokser og radioknapper, skal de alltid ha beskrivende tekst koblet til seg. Et tekstfelt som er merket "fornavn", må for eksempel kodes (med ARIA) slik at det blir assosiert med det respektive feltet. Ved å gjøre det slik, leser skjermleseren opp etiketten når brukeren flytter markøren til tekstfeltet med et tastatur eller en mus. (Suksesskriterium 2.4.6 og 3.3.2)

Webutviklere

Sidetitler

Sidetittelen er innholdet som dukker opp i tabben på en side i nettleseren. Den er ulik overskriftene du bruker på siden. Pass på at alle nettsidene har en tittel som er beskrivende for innholdet på siden. Pass også på at nettredaktører kan skrive inn sidetitler gjennom publiseringsløsningen (for eksempel CMS). (Suksesskriterium 2.4.2)

Overskrifter

Det er ikke alle CMS-er som legger til overskrifter automatisk, og da må man legge inn overskrifter manuelt i koden. (Dersom teamet ditt ikke kan gjøre endringer i koden, må du passe på at CMS-grensesnittet har et felt der du kan legge til overskrifter. Snakk med CMS-tilbyderen din.) Vær ekstra oppmerksom på overskrifter når dere lager templater. (Suksesskriterium 1.3.1 og 2.4.10)

Tastatur-navigering

Alt innhold skal være tilgjengelig både med en mus og med et tastatur. Dette gjelder blant annet skjemaer, knapper og lenker. (Suksesskriterium 2.1)

Noen brukere kan ikke benytte mus, og må i stedet bruke et tastatur eller en bryterkontrollenhet for å navigere gjennom innholdet på en nettside. Siden disse brukerne alltid må kunne se hvor de er på siden, bør markøren være godt synlig. (Suksesskriterium 2.4.7) De fleste nettlesere viser dette med en stiplet linje rundt det innholdet som er i fokus. Du kan også legge til din egen visningsmetode, men det er anbefalt at du beholder standardvisningen. IKKE legg til kode som fjerner den synlige indikatoren! Merk: Noen Reset Stylesheets fjerner merkingen, så var obs på dette inne i Reset CSS-en.

Skjemaer

Placeholder-tekst som forteller meningen med et skjemafelt er ikke nok informasjon til brukerne. Det kan være snakk om et eksempel på et telefonnummer som blir vist før brukeren skriver inn tallene. Så snart noe blir skrevet inn, forsvinner placeholder-teksten. Det er lurt å inkludere et eksempel i den synlige labelen over feltet. Da blir det også lest opp av skjermleserne.

For å forsikre deg om at brukere kan identifisere og bruke et skjema eller et søkefelt, må du legge tekst til feltet i form av en label. (Suksesskriterium 3.3.2)

Innholdssekvens

Når innholdet på nettsider er kodet, må du passe på at innholdet er logisk ordnet, ikke bare visuelt, men også i kodesekvensen. Noen brukere navigerer gjennom sider på denne måten. Pass på at innholdet er ordnet slik at det er forståelig også når det visuelle er slått av og man bruker tabulator-tasten til å bla gjennom innhold. (Suksesskriterium 1.3.2)

Forstørrelse

Pass på at nettsidetekst kan forstørres til minst 200 %, og fremdeles være forståelig og uten tap av innhold. Pass også på at innhold ikke er plassert i en ramme der brukerne må skrolle horisontalt for å se den forstørrede teksten. Nyere nettlesere kan zoome inn på innhold, og ofte er det slik hjelpeteknologier også virker. (Suksesskriterium 1.4.4)

Språk

For at nettlesere skal kunne gjengi innhold, og for at skjermlesere skal kunne fremføre innholdet på rett språk, er det viktig at nettsidene har rett språkdefinisjon i HTML-taggen. Språk-taggen bør være "no" for norske sider, "en" for engelske sider, osv. Husk også at på norskspråklige nettsider har vi to tagger, en for bokmål (nb-NO) og en for nynorsk (nn-NO). (Suksesskriterium 3.1.1 og 3.1.2)

CMS-en bør også også gjøre det mulig for nettredaktører å merke tekst som er på et annet språk enn resten av teksten på siden, og å velge rett språk til dette segmentet. Når man merker innhold som er på engelsk, skal lang="en" bli lagt til i koden.

Koding

For at en nettside skal vises like bra på ulike plattformer, som operativsystem og nettlesere, og for at hjelpeteknologier skal fremføre forståelig innhold, bør du følge standardformater. (Suksesskriterium 4.1.1)

Dersom du for eksempel publiserer i XHTML 1.0 eller HTML 5.0, må du følge syntaksreglene for dette formatet. Du kan se etter syntaksfeil på nettsidene dine med verktøy som Siteimprove Accessibility eller ved å gå til validator.w3.org.

Pass på at elementer blir merket med den koden som er ment for dette formålet. Det er dette semantisk HTML handler om. HTML-overskrifter bør for eksempel merkes med <h1>, <h2>, osv. (Suksesskriterium 1.3.1 og 1.3.2)

Datatabeller bør merkes som <table>, og nettredaktører bør kunne beskrive datatabellene med <caption>. Overskrifter på kolonner og rader bør defineres med <th> og kanskje "header id" og "scope". Dersom en kompleks datatabell skal forklares for brukere av skjermleser, da bør dette gjøres med "summary". (Suksesskriterium 1.3.1 and 1.3.2)

Når nettredaktører skriver tekst, bør de kunne fremheve med <strong> og <em>. (Suksesskriterium 1.3.1)

Når man bruker skjemaelementer, bør labelen være direkte knyttet til hver kontroll, og skjemaelementer som hører til den samme gruppen bør henge sammen. For eksempel bør en gruppe med radioknapper være gruppert med <fieldset> og <legend>, eller role=”group”/role=”radiogroup” og WAI-ARIA-labeler. (Success criteria 3.3.2 and 4.1.2)

Bruker-input

Dersom brukeren må skrive inn informasjon i et tekstfelt, må du forsikre deg om at de får beskjed om å skrive på rett måte (f.eks. telefonnummer med landkode). Da må du også forsikre deg om at brukeren får beskjed dersom noe blir gjort feil. Det er mye bedre for alle brukere å få beskjed med en gang, heller enn ved innsending. Husk å ikke bare bruke farge (som rød) i advarselstekst. Bruk ordet "Feil", eller beskriv tydelig at en feil har oppstått og hvordan den kan fikses.

Når man fyller ut skjema i forbindelse med finansielle transaksjoner eller juridiske forpliktelser, må inputen kontrolleres for å unngå feil, eller så må brukeren kunne se gjennom skjemaet før innsending. Som en tredje mulighet, bør brukeren alltid kunne reversere innsendingen. (Suksesskriterium 3.3.1, 3.3.2, 3.3.3 og 3.3.4)

Grafikk

Når nettsider inneholder element som ikke er tekst, som bilder, grafikk, tabeller, animasjoner eller innlagte rammer som inneholder videoer, er en av de viktigste reglene å tilby et tekst-alternativ som forklarer meningen med elementet. (Suksesskriterium 1.1.1)

Bilder bruker for eksempel “alt text”-HTML-attributtet alt=””. Det er viktig å merke seg at tekstalternativet gjenspeiler meningen med bildet, og ikke nødvendigvis hva bildet viser. (Du finner detaljert informasjon om bilder i kapittelet "Webredaktører og innholdsprodusenter".)

For at web-redaktører skal kunne tilby alternativ tekst på rett måte, er det viktig at publiseringsverktøyet, for eksempel CMS-en, tillater at man kan skrive inn alternativ tekst på bilder. Bilde-taggen skal alltid inneholde et alternativt tillegg (alt=""), uansett om det er behov for en billedbeskrivelse.

Dekorative bilder er de som blir brukt i den visuelle utformingen eller som gjentar informasjonen som er i teksten. Dersom bildet derimot gir en mening i seg selv, bør det ha en beskrivelse. Dersom webredaktøren sier at bildet bare er dekorativt, og ikke trenger en tekst, må de legge til en “null”-attributt (alt=””).

Alternativ tekst er kontekstavhengig, så dersom du skriver inn alternativ tekst for et bilde når du laster det opp til et mediebibliotek, må du se gjennom teksten om den blir brukt på flere sider. Du bør kunne skrive inn en ny alternativ tekst for hver gang et bilde blir brukt på en nettside. En tittelattributt gjør ikke samme nytten som en alternativ attributt, og bør ikke brukes som erstatning for "alt"-attributten.

Dersom en nettside inneholder en mediefil, bør denne også ha en beskrivende alternativ tekst.

Audio og video

Når audio- og videofiler blir publisert på en nettside, er det flere relevante kriterier, som det å tilby et alternativt format, undertekster og lydbeskrivelser. Dette blir beskrevet i detalj i kapittelet "Web-redaktører og innholdsprodusenter". (Suksesskriterium 1.1 og 1.2)

Gjennom utviklingsfasen er det viktig å forsikre seg om at alle knapper og kontrollere kan styres både med mus og tastatur alene. Samtidig må disse knappene og kontrollerne ha beskrivelser i tekst for skjermlesere. (Suksesskriterium 1.2.1, 2.1.1 og 2.1.2)

Når det gjelder videoer, bør det være mulig å legge til undertekster og å legge inn et dedikert spor for lydbeskrivelse. (Suksesskriterium 1.2.1 og 1.2.2)

Dersom et audio-segment starter automatisk, bør brukeren kunne trykke pause og stopp, og kontrollere lydnivået. (Suksesskriterium 1.4.2)

Brukerkontroll

Noen brukere trenger mer tid til å lese og navigere seg gjennom nettsider. Så dersom det finnes noen form for tidskontroll på sider, må brukeren kunne endre grensen, enten ved å justere den, forlenge den eller koble den ut. (Suksesskriterium 2.2.1) En vanlig løsning er å ha et dialogvindu som spør brukeren om det er behov for mer tid til å fullføre oppgaven. De bør ha mulighet til å si ja, og få mer tid.

Dersom bevegelig, blinkende eller scrollende innhold blir lagt til, er det også viktig at brukeren kan pause, stoppe eller skjule innholdet. (Suksesskriterium 2.2.2)

For at brukere med skjermlesere skal slippe å høre på det samme innholdet hver gang de laster en ny side, bør du tilby en måte å hoppe over innhold som går igjen. Dette kan være globale og lokale menyer og hjelpefunksjoner. Det finnes flere metoder å forsikre seg om dette på; det letteste er å tilby en lenke på toppen av alle sider som fører brukeren til hovedinnholdet på siden. (Suksesskriterium 2.4.1)

Når et element kan endres av brukeren, som med en nedtrekksmeny eller en radioknapp, er det viktig at den oppfører seg som brukeren forventer at den gjør. Elementer bør ikke reagere når brukeren lander på det fra tastaturet. De bør reagere når brukeren har fått tid til å velge og bekrefte. (Suksesskriterium 3.2.1 og 3.2.2)

Blinkende innhold

Innhold bør ikke blinke mer enn tre ganger i sekundet, ellers kan det forårsake anfall. (Suksesskriterium 2.3.1)

Web-redaktører og innholdsprodusenter

Sidetitler

I et CMS-system gir du navn eller tittel til en side når du lager den. Det er denne tittelen som dukker opp i nettleser-tabben. I noen systemer er det et spesifikt felt til dette som blir kalt "tittel". Det er viktig at denne tittelen beskriver hva siden handler om, for dette dukker opp øverst i nettleseren, og det er det første som leses av en skjermleser. Sidetitler blir også brukt i bokmerker og søkeresultat. (Suksesskriterium 2.4.2)

Tekst

Når du skriver tekst til nettsider bør du ta med i betraktningen at enkelte brukere bare kan få en strukturell oversikt over siden, ikke en visuell oversikt. Pass på at sidene er delt inn i logiske deler med beskrivende overskrifter. Du kan bruke flere overskriftnivåer: Overskrift 1, Overskrift 2, osv. (<h1>, <h2>, osv. i koden, slik at hjelpeteknologier kan gjengi dem som overskrifter). (Suksesskriterium 1.3.1)

Noen svaksynte brukere får et helt annet inntrykk av nettsider enn andre brukere. Derfor bør du ikke gi informasjon bare med farge eller med en beskrivelse som krever sensoriske ferdigheter. Unngå å skrive ting som: "Du kan lese mer om tilstelningen i den blå boksen på denne siden." (Suksesskriterium 1.4.1)

Det er ikke alle som ser en nettside slik du ser den. Samtidig som du tenker på ulike utfordringer, må du også huske at mange nettsider blir bygget med responsiv webdesign. Det betyr at elementer kan flytte seg avhengig av hvilken enhet siden vises på (mobil, nettbrett, PC) og hvilken nettleser som brukes. Derfor er det heller ikke lurt å gi informasjon basert på retninger, som for eksempel: "Du kan lese mer om arrangementet i boksen til høyre." Det blir meningsløst dersom sideelementene har flyttet seg.

Pass alltid på at du oppgir språket til innholdet ditt. I koden blir dette gjort ved lang=""-atributten. CMS-en din gir deg kanskje mulighet til å fremheve et tekstsegment og velge et språk fra en nedtrekksmeny. (Suksesskriterium 3.1.1 og 3.1.2)

Lenker

Når du legger til lenker på en side, bør du skrive lenketekster som gir mening når de leses utenfor kontekst. Unngå å bruke lenketekster som "Les mer", "Her", "Klikk her", "Publikasjon", osv. Skriv heller: "Her kan du lese mer om hjelpeteknologier." Da har du en lenketekst som i seg selv forklarer hva siden det lenkes til handler om. (Suksesskriterium 2.4.4)

Bilder

Når du legger bilder til en nettside bør du huske at noen brukere ikke kan se bilder. De trenger derfor et tekst-alternativ. I de fleste CMS-systemer kalles dette for "alternativ tekst" eller "alt-tekst". Teksten som skrives inn der er ikke synlig på siden, men er gjemt i koden, og blir brukt av skjermlesere. Den alternative teksten er ikke det samme som et tooltip, teksten som vises når pekeren holdes over et bilde. (Suksesskriterium 1.1.1)

Lukk øynene og se for deg hvilken informasjon du hadde trengt dersom du ikke kunne se et bilde. Beskriv funksjonen til bildet, og ikke nødvendigvis hva bildet viser. Dersom bildet lenker til noe, er det viktig å beskrive hva lenken leder til og hva som skjer når du trykker på den. Dersom bildet inneholder viktig informasjon, må denne informasjonen komme frem i den alternative teksten. Dersom bildet utelukkende er dekorativt, for å skape en stemning eller gi visuell kontekst, bør det ha en tom alternativ tekst. Men CMS-en din bør automatisk legge alt=""-taggen til bildet i koden, siden dette er viktig for dekorative bilder.

Unngå å bruke bilder av tekst. Dette betyr at du aldri bør skrive eller skanne tekst til et bilderedigeringsprogram og lagre det som et bilde. Det finnes ingen skjermleserteknologi som kan lese bilder av tekst, siden det er umulig å fremheve tekst inne i et bilde og få denne lest opp. Bilder av tekst har også en tendens til å bli kornete og uklare ved forstørring, noe som gjør det vanskelig å lese for de med andre utfordringer. For mange dyslektiske nettbrukere kreves det at de merker tekst manuelt for å få den lest opp av hjelpeteknologien. (Suksesskriterium 1.4.5)

Video og audio

Dersom du bruker video- eller audioklipp på en nettside, er det flere ting du må vurdere, som undertekster og lydbeskrivelse til videoer. En lydbeskrivelse er et ekstra spor som forklarer hva som skjer på skjermen til de med synsutfordringer. Dersom du ikke kan legge lydbeskrivelse til videoene dine, bør du tilby et alternativ i form av en transkribert tekst på eller lenket til fra siden. Men husk at uten lydbeskrivelser kan du ikke overholde AA-kravene, bare A-kravene. (Suksesskriterium 1.1 og 1.2)

Dersom innholdet bare inneholder lyd eller video, så er en tekstversjon et bra alternativ til begge.

Tabeller

Når du bruker datatabeller er det viktig å merke overskrifter til rader og kolonner. Måten man gjør dette på avhenger av CMS-systemet. I noen tilfeller tilbyr teksteditoren en tilgjengelighetsfane der denne informasjonen kan skrives inn når man jobber med tabeller. (Suksesskriterium 1.3.1 og 1.3.2)

Lister

Når du lager lister med objekter, må du forsikre deg om at du bruker den innebygde funksjonen i CMS-editoren. Dette gjør at universelt utformet kode blir brukt i listen. Unngå å bruke symboler som ser ut som listeobjekter, som kulepunkt, tankestreker, asterisker osv. (Suksesskriterium 1.3.1)

Dokumenter

Mange WCAG 2.0-prinsipper vedrørende nettinnhold, er også relevante for dokumenter, også PDF-er. Det finnes 32 PDF-teknikker som har blitt publisert av W3C. De fleste lovverk i verden stiller krav om tilgjengelige dokumenter for at et nettsted skal bli godkjent.

Guiden vår, hvordan lage tilgjengelige PDF-er (på engelsk), kan hjelpe deg på vei.

Utvikle eller redesigne et nettsted

Når du tenker tanken "nytt nettsted", bør du tenke "tilgjengelighet". Ved å ta hensyn til tilgjengelighet fra starten av, blir prosessen mye mer kontrollerbar enn om du begynner å tenke på tilgjengelighet sent i utviklingen eller i en redesign-fase.

Kostnadene ved å planlegge, samle ressurser og reparere etter at et nettsted har blitt lansert, er mye mer kostbart enn det å innlemme tilgjengelighetsrutiner i arbeidet. Blir det innlemmet på rett måte fra starten av, trenger du ikke bekymre deg for slike tilbakeslag.

Kravspesifikasjoner

Når du skriver kravspesifikasjonene til webutviklingsavdelingen, er det viktig å bruke de rette standardene, helst WCAG 2.0. I webdesignprosjekter er det vanlig at kjøperen stiller krav om at nettstedet skal designes i tråd med WCAG 2.0 på AA-nivået. Men dette kravet er ikke så enkelt som det kan se ut.

Hvordan finner du ut om nettstedet lever opp til forventningene, når du er midt i prosjektet? Bestem hvilke av suksesskriteriene du ønsker å oppfylle. Få webutvikleren din til å bekrefte om og når dette kan bli gjort. Du kan for eksempel lage en tabell eller en liste som skal fylles ut av deg og utvikleren:

Kriterium Beskrivelse Notater Utviklerløsning Påkrevd
1.1.1 Alt innhold som ikke er tekst og blir presentert til brukeren skal ha et tekstalternativ med samme mål, bortsett fra situasjonene som blir nevnt under.  Relevant for bilder, inputs, CAPTCHA og mer.    X

Det er også viktig at CMS-et hjelper webredaktører med å publisere tilgjengelig innhold. Velg de sjekkpunktene du trenger fra the Authoring Tool Accessibility Guidelines, som krever at verktøyet genererer tilgjengelig innhold, hjelper webredaktører med å publisere tilgjengelig innhold og at verktøyet i seg selv er tilgjengelig. Vær tydelig når det gjelder betingelsene for:

  • Hvordan man håndterer alternativ tekst for bilder
  • Hvordan man bruker overskrifter
  • Evne til å lage tilgjengelige datatabeller
  • Hvordan man siterer (<q> og <blockquote>)
  • Hvordan man skriver inn sidetitler
  • Hvordan HTML-kode som er laget i CMS-en oppfyller W3C-standarder
  • Hvordan man merker endret språk i teksten

Ta for deg bedriftens designmanual, og se om det er noe som bryter med retningslinjene for tilgjengelighet. Det finnes for eksempel krav til kontrast mellom bakgrunnsfarge og tekstfarge. Derfor er det viktig å bruke tilgjengelige fargekombinasjoner. (Suksesskriterium 1.4.3)

Design og utvikling

Når du starter arbeidet med å designe og lage maler, er det flere tilgjengelighetskriterier som gjør seg gjeldende. Tenk på navigering, bruk av overskrifter, farger, lenketekster, white space og beskrivelser, spesielt der brukeren skal klikke på, fylle ut eller velge innhold på nettsider.

I utviklingsprosessen er de fleste tilgjengelighetskriteriene relevante. Derfor er det viktig at de som arbeider med å utvikle løsningen virkelig forstår tilgjengelighet. Pass på at du tester løsningen gjennom hele prosessen, fra start til slutt. Venter du til slutt, er det nesten umulig å rette opp mulige feil og mangler før nettstedet skal publiseres. Det er spesielt viktig at templates blir testet så tidlig som mulig, før man bygger noe på dem, slik at man unngår å spre feil til hundrevis eller tusenvis av sider.

Publisering av innhold

Pass på at webredaktørene dine har fått opplæring i å publisere innhold på "den universelt utformede måten". Da vil innhold som blir lagt til, både i utviklingsfasen og etter lansering, gjøre nettstedet ditt mer tilgjengelig og ikke bidra til nye problemer.