Universell utforming på bærtur!

Universell utforming er noe dritt som er lovpålagt i Norge. Mange tenker sånn, og de fleste verken gidder eller har forutsetninger for å skjønne hva tilgjengelighet og universell utforming betyr for oss med «spesielle behov». Jeg har nemlig «spesielle behov», skjønneer du, for jeg er stokk blind.

Godt det finnes eksperter som kan hjelpe deg! Ja, faktisk finnes det drøssevis med eksperter på brukskvalitet, brukervennlighet, inkluderende design, universell utforming – og fanden og hans oldemor! Hadde alle disse ekspertene hatt bedre fagkompetanse hadde jeg ikke giddet å skrive denne artikkelen ( jeg skrev den alt i 2010). Synd vi mangler en kvakksalverlov for web, for det er mange uu-kvakkere som utgir seg for å skjønne, uten at de egentlig kan noe som helst om menneskelige forutsetninger og behov, hjelpemiddelteknologi, viktige standarder og så videre. Noen av ekspertene har kanskje fått en introduksjon til WCAG eller lest standarden, men for mange stopper det der. Godt det også finnes dyktige fagfolk innen universell utforming, for det gjør absolutt det – og de bør du prøve å utnytte hvis du skal lage ting som er best mulig for flest mulig.

Jeg skal hjelpe dere litt. Jeg er nemlig veldig flink, hehe. Og det jeg skal hjelpe dere med i denne artikkelen er å trekke fram noen av de vanligste misforståelsene.

Jeg har brukt følgende artikkel som utgangspunkt, men lagt til, fjernet og synset en god del:

Web Accessibility Gone Wild Now even wilder!
Blant annet har jeg tatt bort noe av det som gjaldt WCAG 1.0, for det tror jeg strengt talt ikke er så utbredte misforståelser i 2016.

Jeg hater å skrive universell utforming

Universell utforming og tilgjengelighet brukes som synonymer. Det er dumt, men jeg skal ikke problematisere noe rundt forskjellen her. Litt flåsete sagt: tilgjengelighet betyr at ingen skal ekskluderes, universell utforming betyr bra for alle.

Grunnen til at jeg misliker å bruke begrepet universell utforming er at jeg må bruke det også når jeg vet at jeg mener tilgjengelighet. Ja, jeg må det, ellers skjønner jo enda færrre hva jeg snakker om.

Det finnes ikke et eneste nettsted som er bra for alle. Med andre ord finnes det ikke universelt utformede nettsteder. Det beste vi klarer er å lage nettsteder som er bra for så mange som mulig. Da er universell utforming et veldig godt utgangspunkt for den måten vi skal tenke og jobbe på.

Dett var dett, og resten handler rett og slett om tilgjengelighet og litt sunt folkevett!

Drit i blinde

Jeg mener ikke at du skal lukke øynene når du sitter på potta, hvis du trodde det, da. Noen mener at blinde får for mye fokus i forhold til tilgjengelighet og nettsider. Skivebom! Helt feil! De som mener det bør ta IT-utdannelsen sin på nytt. Selvsagt er det nettopp blinde det er viktigst å tenke på når du skal lage tilgjengelige nettsider!

Hvorfor? Rett og slett fordi det aldrig fokuseres på blinde når vi lager nettsider. Utgangspunktet for så og si alt som lages er et visuelt brukergrensesnitt. Det skal være pent. Siden skal struktureres så det er lett å se hva som hører sammen og ikke… Jeg skal ikke ramse opp viktige egenskaper for menneske- maskin interaksjon, men så og si alt går på visuell presentasjon og kognisjon. Når vi så fokuserer på tilgjengelighet er det selvsagt viktigst å ta høyde for de som faktisk ikke ser det visuelle brukergrensesnittet. Det er jo helt opplagt at blinde kan trenge noe ekstra for å få en sammenliknbar brukeropplevelse? Det som derimot er helt riktig er at tilrettelegging for sterkt synshemmede veldig ofte resulterer i løsninger som er bedre for alle.

Synes du at mye av det jeg nevner under har med synshemmede å gjøre, så er det altså 100% naturlig.

Grafikk

Det at grafikk skal ha en alternativ tekst er sannsynligvis det aller mest kjente tilgjengelighetskravet. Blinde kan ikke se grafikk, og derfor kan du beskrive bilder uten at dette vises i det visuelle brukergrensesnittet. Hvordan du legger til alternativ tekst kan du lese her: Alternativ tekst til bilder.

Er alternativ tekst til grafikk bare en blinde-greie? Tja, Bing og Google er blinde, og bruker den samme teksten for å forbedre søketreff. Bing og Google er faktisk døvblinde. Og nettopp derfor er tilgjengelige sider også god SEO, det vil si en ekstra gevinst, altså.

For å validere er det mange rare krumspring som legges inn som alternativ tekst. Et eksempel er filnavn. Det gir som oftest liten merverdi (særlig fordi skjermlesere ofte viser filnavnet dersom den alternative teksten mangler). Andre eksempler er å putte inn en bindestrek, et punktum eller noe annet helt håpløst. Har du en sånn strategi bør du slutte å lage nettsider, for da demonsterer du jo rett og slett at du gir blaffen i folk – men vil likevel vise at du følger forskriften til diskrimineringsloven.

Håpløse alternative tekster finnes det mange eksempler på, kanskje aller mest for pyntegrafikk: transparent giff, grønn pil, stiplet linje, mennesker, … Støy, både for blinde og søkemotorer de tekstene der!

Noen få tommelfingerregler, i stedet for å ramse opp alt som gjøres feil med alternative bildetekster:

  • Pynt trenger ikke alternativ tekst.
  • Grafiske lenker skal alltid ha alternativ tekst, og teksten skal beskrive målet (dvs. ikke bildet).
  • Ikke start den alternative teksten med «Bilde av», «Grafikk», … «Type bilde» skal bare beskrives hvis det er viktig.
  • Avansert grafikk trenger vanligvis noe mer enn en alternativ tekst, for eksempel en lenke til et mer omfattende alternativ.
  • … og vil du vite mer om alternativ til ikke-tekstlig innhold kan du søke på web …

Og på tampen av dette avsnittet: faktisk er det også noen som bruker for mye tid på alternative bildetekster. Min personlige mening er at det ofte er vanskelig å formidle verdien av foto og komplisert grafikk. Gjør det derfor enkelt. Men, dette handler om krativitet, nettstedets art og så videre, så standardsvar finnes ikke. Er målet for eksempel å gi blinde et inntrykk av Munch sin kunst, som jo er en del av kulturarven vår, ja, da må nesten bildene forklares ganske godt.

Tilgjengelighetsfunksjoner er pysete

Har du sett de tre A-ene på noen nettsteder for å endre skriftstørrelse? Hvor mange bruker A-en for å gjøre skriften mindre, tror du? Det er helt unødvendig å duplisere nettleser-funksjonalitet: de som trenger forstørring vet hvordan de zoomer.

Valg for kontrast er det også en del nettsteder som har. Det er et tydelig tegn på at kontrasten er for dårlig i standard-designet. Jeg vet at noen liker å kunne bytte kontrast fullstendig (dvs. velge om bakgrunnen skal være lys eller mørk), så det kan kanskje ha noe for seg. Imidlertid er det desidert viktigste at kontrasten er god i standardoppsettet, og her har WCAG klare krav. Er standard-kontrasten for dårlig risikerer du til og med at de som trenger bedre kontrast ikke ser nok til å velge det fine kontrast-alternativet ditt.

Hva med talende nettsider, da? Prøv, sjekk hvor mange som bruker det. På noen nettsteder kan en opplesingsfunksjon være til hjelp for noen, men langt fra alle nettsteder har slik funksjonalitet. Mange av de som må ha teksten opplest har derfor syntetisk tale lokalt på PCen eller mobilen.

Mer funksjonalitet betyr større kompleksitet, og skal du øke kompleksiteten med tilgjengelighetsfunksjoner bør det ha mye for seg!

WCAG-kompatibel

Gjett om de som har fokusert på tilgjengelighet er mest opptatt av brukervennlighet for funksjonshemmede eller validering mot WCAG? Svaret er selvsagt at du finner eksempler på begge deler. Alt for mange er opptatte av validering, og med en lov som pålegger oss å følge WCAG på nivå AA er det forståelig.

WCAG er bare et hjelpemiddel. Du kan ha helt ubrukelige sider som validerer mot WCAG. Det kan du for så vidt også hvis du kun validerer mot andre standarder, for eksempel HTML. En HTML side med svart forgrunn og svart bakgrunn på tekst er for eksempel nokså ubrukelig for alle som bruker skjerm. For meg som bruker tale derimot kan siden være så fin som bare det. WCAG garanterer altså ikke tilgjengelige nettsider, men prinsipper, retningslinjer og suksesskriterier kan bidra til at nettsidene blir tilgjengelige. For stort fokus på suksesskriterier kan i noen tilfeller til og med gjøre webinnhold mindre tilgjengelig.

Tekniske standarder er viktige, og du bør prøve å forstå WCAG. I den standarden finner du mye som er ganske opplagt, eller burde være det for profesjonelle utviklere og designere. Det er likevel mennesker som skal bruke den teknologien vi lager, og da er det faktisk viktigere å fokusere på hvor bra ting funker for folk enn om du får poeng av en validator.

Hurtigtaster og tabindex

Hurtigtaster eller accesskey er stort sett unødvendig. I verste fall kan de komme i konflikt med andre tastetrykk. Det finnes ikke etablerte standarder, og derfor må eventuelt tastene læres for hvert nettsted. Tror du mange gidder det? Når dette er sagt: Jeg har sett eksempler på at hurtigtaster er brukanes på intranett.

tabindex er et attributt som bestemmer rekkefølgen for hvor du havner når du trykker Tabulator. Hvis tabindex ikke brukes, og det er nesten alltid best, blir tabulatorrekkefølgen identisk med den rekkefølgen HTML-koden ligger i. Brukes tabindex blir veldig ofte tilgjengeligheten dårligere. Men, selvsagt, ingen regel uten unntak. Attributtet kan for eksempel brukes når du utvikler «widgets» (egne kontroller), eller hvis du faktisk vil ha tabstopp på noe du ellers ikke stopper på med Tab.

Glem begge disse attributtene, du, så kan du heller lære deg å bruke de den dagen du finner ut at de kan øke tilgjengeligheten. Kan bli lenge til, hehe.

Skjult innhold for skjermlesere

Innhold skal vanligvis ikke skjules. Da er det vel bedre å fjerne innholdet?

Skjult innhold som vises for skjermlesere kan brukes noen ganger for å forbedre tilgjengeligheten. Vær imidlertid veldig forsiktig med dette. Skjult innhold blir fort glemt, og det blir derfor ofte feil på sikt. Sider oppdateres, men skjult innhold glemmes. Et eksempel på fornuftig bruk av skjult innhold kan være ledetekster til felt, som kan være helt opplagte visuelt. Søkefelt med en Søk-knapp er kanskje det aller vanligste eksemplet. Feltet skal ha en label, og labelen er nyttig for skjermlesere, men det ser feil ut å vise teksten «Søk» i det visuelle brukergrensesnittet.

Lokale hopp

På noen nettsteder finner du lenker for å sette Tab-fokus til ulike steder på siden. Typiske eksempler: Hopp til hovedmeny, Hopp til søk og Hopp til hovedinnhold. Noen tror at slike hopp er for de som bruker skjermleser: derfor skjules lenkene fra det visuelle brukergrensesnittet. Hva med å lese seg opp litt? Få blinde bruker lokale hopp, spesielt hvis siden er bra strukturert med overskrifter og/eller semantisk sideinndeling. Lokale hopp kan være fornuftig for de som bruker tastatur (eller hjelpemidler som simulerer tastatur), men da må lenkene være synlige. Det har blitt en slags defacto-standard at lenkene vises når de har Tab-fokus. OK for de som bruker mus, for de slipper å se den ene lenka (eller har du kanskje flere lokale hopp). Usynlig funksjonalitet er teit, og selvsagt er det en dårlig ide å bare vise lenker når de har Tab-fokus. Tenk om det samme hadde vært gjort for mus-brukerne: flytt pekeren rundt på skjermen, hvis du er heldig kan det jo hende du finner noen spennende greier hvis pekeren tilfeldigvis står på riktig sted.

Mange lokale hopp har nesten aldri noe for seg. Det øker kompleksiteten og gir liten merverdi. Begrens deg derfor til «Hopp til innhold», og kanskje trengs ikke dette heller.

En feil jeg ser ganske ofte er at lokale hopp blir stående i responsive design. Hoppene er laget for den største skjermflaten, men fjernes ikke for mindre skjermflater, og da funker de ofte ikke lenger. Hvorfor blir dette glemt? Jo, lenkene er usynlige, utviklerne bruker ikke tastatur når de navigerer på nettsiden, og da er det fort gjort å glemme det som ikke synes. Enda en grunn til å droppe lokale hopp eller i det minste alltid vise lenkene.

Skjemaer burde være enkelt, men akk sann

Vis Skjermlesere og skjemamodus


Hvis du skjønner hva radioknappene over brukes til er du et geni. De som bruker skjermleser burde ofte ha vært genier fordi det er umulig å skjønne hva skjemafelt er assosiert med. Eller kanskje det ikke hjelper å være genial heller: det som trengs er vel å være synsk. Radioknappene over trenger fieldset og legend.

Trenger radioknappene fieldset og legend



Sjermlesere leser legend før hvert element i fieldset. Det er derfor viktig at legend er kort og tydelig.

Skjermlesere har som regel en egen skjemamodus. I denne modusen leses kun skjemafelt og assosiert label. Ledetekster og annen informasjon som ikke er med i label og fieldset/legend leses vanligvis ikke opp. Se eksemplet nedenfor:


Viktig: Du skal ikke bruke ditt ordentlige navn. Lag et kallenavn.

Den «viktige» informasjonen leses ikke opp i skjemamodus. En metode er å bruke aria-describedby

Informasjon om format, viktige instruksjoner og så videre skal enten legges før skjemaet eller i label og/eller fieldset/legend.

Title-attributtet

title kan brukes for å gi veiledende informasjon, ikke noe annet. title skal::

  • Ikke inneholde essensiel informasjon eller informasjon som er nødvendig for tilgjengelighet.
  • Ikke repetere informasjon som finnes som vanlig tekst eller alternativ tekst til bilder.
  • Ikke inneholde helt opplagt informasjon. Bedre å fjerne attributtet da.
  • Brukes med stor forsiktighet på små elementer (tittel-boksen kan dekke elementet eller viktige elementer i nærheten).
  • Ikke brukes som erstatning for alternativ tekst, skjema label, rad eller kolonneoverskrifter i tabeller og så videre.
  • Bruk alltid titleframe-elementet (rammer).

Er det noen som bruker rammer, da? I alle fall iframe, men der er title diskutabelt

Layout-tabeller

Vis Skjermlesere og tabeller

Layout-tabeller er uprofft, men ikke på grunn av tilgjengelighet. Hvorfor er det uprofft, da? Bruk Google, Bing eller andre søke-ting, så får du alle argumentene du trenger. Layout-tabeller er nesten aldri noe problem for skjermlesere, altså. Unntaket er hvis leserekkefølgen blir helt ødelagt.

Ikke bruk caption på layout-tabeller. Det du imidlertid skal er å legge til attributtet role="presentation".

Synlig fokus er stygt

Noen mener at pene sider er viktigere enn brukbare sider. Design er interessant, men også krevende fordi «alle» – med eller uten – fagkompetanse mener veldig mye. En ting som har blitt vanlig er å fjerne synlig fokus: det er jo så stygt, atte! Synlig fokus er den stiplede rammen rundt lenker, knapper og så videre. Skal det være mulig å bruke nettsider med tastatur må du nødvendigvis se hvilken knapp eller lenke du velger med Enter. Utrolig nok sitter dette med synlig fokus langt, langt inne: det er jo så stygt, atte. Dette burde ikke være tema for diskusjon i det hele tatt. De som vil ta bort visuelt fokus tar feil. De som vil forsterke det visuelle fokuset (gjøre det tydeligere enn nettlesernes standar) fortjener derimot en ekstra flaske rødvin til jul.

HTML-validering

Alle som jobber med web bør være opptatte av standarder. Det å følge HTML-standarden med tilhørende beskrivelser er for eksempel et godt utgangspunkt for at innhold vises bra på tvers av nettlesere (med eller uten hjelpemidler for funksjonshemmede). Også WCAG krever at HTML etc. validerer (SK 4.1.1).

Ser vi kun på tilgjengelighet er det imidlertid litt mer vrient. En side med massevis av feil kan godt være tilgjengelig. Det er heller ikke umulig å finne sider som validerer, men som absolutt ikke er tilgjengelige. Vær derfor forsiktig med å påstå at en side er elendig og utilgjengelig selv om validatorer rapporterer feil. Og bare for å gjenta meg selv, så artikkelen blir ulidelig lang, ikke vær så sikker på at siden er tilgjengelig selv om validatoren konkluderer med 0 feil.

Tilgjengelighetsuttalelser

Tilgjengelighetsuttalelser er så teit at det nesten ikke burde nevnes her i det hele tatt. Funker ting for brukerne, ja da er alt bra! Funker ting dårlig hjelper det lite å si at nettstedet følger WCAG, at nettstedet er tilgjengelig eller noe i den gata! Det dummeste av alt er at det ofte er de minst proffe nettstedene som har sånne uttalelser. De som er ordentlig flinke trenger ikke å si det, for brukerne liker nettstedet: hipp hurra, og alt er bra.

Tilgjengelighetsuttalelser pleier til alt overmål å bli plassert i topp eller bunnteksten (header/footer). Så disse irriterende lenkene gjentas på hver bidige side. Med andre ord: Økt kompleksitet uten annen verdi enn å gjøre sidene teite.

OK, da var artikkelen mye lenger enn noen gidder å lese, så dett var dett.


2 Responses to Universell utforming på bærtur!

  1. Hva med role-attributtene? Her er det et lass med muligheter, men har det noe hensikt? Eksempelvis role=main og role=navigation? Benytter skjermlesere disse? Er det ikke bra nok med å benytte html-elementene main og nav?

    • Det er helt riktig at wai-aria definerer roller for semantisk sideinndeling. I tillegg finnes det massevis av andre roller.
      Som du sikkert vet kan wai-aria benyttes på alle markup-språk, også de som ikke har semantisk sideinndeling (eks. html4). Hovedregelen er at du ikke skal bruke wai-aria dersom et språk har den samme funksjonaliteten. I utgangspunktet skal du derfor bruke «main», ikke «role=’main'» i HTML5. I noen tilfeller kan det ha noe for seg å bruke begge, pga. kompatibilitet med skjermlesere/nettlesere, og det skader for så vidt ingenting å bruke «main role=’main'». Det er heller ikke 100% overlapp mellom html5 og wai-aria. Derfor kan det f. eks. være lurt å bruke «asside role=’complementary'», «footer role=’contentinfo'» etc.
      Når dette er sagt er det riktig at skjermlesere bruker den semantiske sideinndelingen. God sideinndeling kan gjøre det mye raskere, og mer forståelig, å skjønne en side. Jaws har kommandoer for å hoppe fra seksjon til seksjon, og i tillegg hurtigtast for å hoppe til main (‘q’).