UU-podcasten:Universelt utformet

Anders: Dette er to entusiaster som i løpet av 26 episoder skal diskutere 78 suksesskriterier på en forståelig måte. Dette er universelt utformet.

Erling: Da er vi klar for den tredje episoden i serien vår.

Anders: Det er vi.

Erling: I dag skal vi snakke om 1.3.1. Hva går den ut på?

Anders: For å sitere Difi, så sier de «Ting skal være kodet som det det ser ut som».

Erling: Som er en ganske fin beskrivelse av hva 1.3.1 er, selv om den ikke er presis så hjelper den godt med å forklare hva det dreier seg om.

Anders: Men den sier ikke alt.

Erling: Vi skal si litt mer.

Anders: Det er derfor vi er her i dag, Erling.

Erling: Nettopp. 1.3.1 er disse kodene som blir brukt. Det første ettallet, hva stod det for?

Anders: Det står for mulighet til å oppfatte.

Erling: Det som på engelsk heter perceivable. Og tretallet som vi er på i dag, hva står det for?

Anders: Det står for mulighet til å tilpasse. Og en skal huske på bakgrunnen her, weben i seg selv er veldig tilpasningsdyktig. Og vi som lager løsninger for web, vi skal ikke ødelegge det.

Erling: Vi skal ikke tukle med det.

Anders: Forskjellige brukere av forskjellige tjenester tilpasser nettsider på sin egen måte. Det skal være mulig uten at informasjon går tapt. Der har vi et ansvar.

Erling: Det har vi. Det siste ettallet, det som vi skal snakke om i dag, hva går det ut på?

Anders: Det står for informasjon og relasjoner. Ganske vagt. Du kan tenke på det som at en datamaskin skal kunne forstå koden eller meningen med koden. Kanskje ikke så oppklarende, men igjen …

Erling: Det er et konsept som er verdt å ta med seg. Se for deg at en datamaskin skal skjønne hvilken type innhold dette er, å kunne sett det i system, og kanskje gjør det om til noe annet. Rangere det i søkemotoren, for eksempel.

Anders: Når vi sier datamaskinen kunne vi like gjerne sagt program.

Erling: Eller Google. Eller Alexa. Hva det måtte være.

Erling: Hvorfor finnes disse retningslinjene?

Anders: De finnes fordi innhold skal gi samme mening hvis stilarket (CSS-en) endres på, tukles med eller byttes ut. Eller fjernes for den saks skyld. Eller om innholdet blir lest av en skjermleser. Det er et viktig kriterie her, at det vi lager skal kunne brukes av skjermlesere, og skjermlesere forholder seg kun til HTML og ikke CSS. Så derfor er det viktig at det fortsatt fungerer.

Erling: De to viktigste komponentene på web er jo HTML og CSS. Den viktigste forskjellen på de to er at i HTML beskriver vi hvilket innhold som brukes og CSS-en beskriver hvordan innholdet skal se ut. Så hvis noe skal oppfatte dette innholdet som ikke er i stand til å se, vi kommer tilbake til hvem det er, det er jo blinde og Google og lignende. Derfor finnes denne retningslinjen.

Anders: Når vi snakker om informasjon, for å være litt mer konkrete, så kan det være overskrifter. For at en datamaskin skal kunne forstå at noe er en overskrift, så holder det ikke bare at teksten er stor og tykk. Det må ligge noe i koden som sier at dette er en overskrift. På samme måte som celler i en tabell. En celle hører ofte til en radoverskrift eller en kolonneoverskrift. Det må være strukturelt kodet som det. Så derfor finnes de retningslinjene. Tar vi bort CSS-en, så skal det være forståelig.

Erling: Det skal fortsatt gi mening.

Erling: Hvem gjelder denne for?

Anders: Hvis vi tenker på brukere først og fremst, så er det viktig for blinde og svaksynte, spesielt de som bruker skjermlesere fordi skjermlesere må vite hvilken type innhold som blir lest opp. Og et eksempel på det, er at du kan få lest opp alle overskriftene. Husk at vi alle liker å skumlese tekst på nett for å finne frem til den informasjonen vi er på jakt etter, og da er det å få opplest overskriftene en fin måte å få et bilde av hvilket innhold som eksisterer på denne siden, slik at du kan begynne å skumlese teksten til en overskrift. Skjermlesere kan òg endre på lyd og tone, utheve ord, snakke litt senere eller høyere. Du kan tenke deg at du hører en lydbok, at den som leser inn tar ulike roller, det kan òg en skjermleser gjøre. Ikke helt på samme måte. Da må koden fortelle at det er en endring i innholdet. Så blinde og svaksynte er helt opplagt. Vi kan ta et annet eksempel med en type bruker som har fordel av å gjøre endringer i et stilark.

Erling: For å gå inn på akkurat det. Dette med å endre stilark, det du kan gjøre er i å definere ditt eget stilark i nettleseren som overstyrer stilen på alle nettstedene.

Anders: Det kan du gjøre på to nivåer. Du kan gå inn i innstillingene i nettleseren din og si at slik vil du ha det. Da må nettleseren forstå hva den skal endre på. Hvis du er veldig avansert så kan du bytte ut stilarket ditt og si at du ikke vil ha stilarket som nettsiden gir meg. Jeg vil ha mitt eget fordi jeg har dysleksi. Jeg har funnet den perfekte skrifttypen, så alt innhold jeg har skal vises med den skrifttypen som funker for meg. Og jeg blir veldig forvirret når det står innhold i flere kolonner eller spalter, så jeg vil alltid lese innholdet i én kolonne. Det skal jeg bestemme. Jeg bestemmer over min egen leseopplevelse.

Erling: Og hvis innholdet ikke er strukturert korrekt, da vil ikke det være mulig.

Anders: Da stikker du kjepper i hjulene til de som prøver på å tilpasse innholdet. Det er òg tjenester som tukler med stilarket. For eksempel jeg sliter litt med konsentrasjonsvansker, det tror jeg alle gjør i disse forstyrrelsestider. Så når jeg leser lengre artikler så bruker jeg tillegg i nettleseren min som heter Just Read som gjør at alle nettsider ser like ut. Jeg har funnet frem til den typografien som jeg liker og jeg slipper å bli forstyrret av for mye tivoli, for mye farger og elementer som sider som jeg ikke bryr meg hvis jeg skal forstå noe.

Erling: Da kan du skrelle vekk alt som ikke er relevant til hovedinnholdet hvis siden er kodet på en korrekt og semantisk måte. Viser kun innholdet på den siden.

Anders: Hvis innholdet ikke er kodet riktig, så blir – du hadde et godt ord på det tidligere – hvis du leser en tekst som ikke har typografi eller har kode som …

Erling: Definerer hva innholdet er?

Anders: Ja, hvis du ikke har punktlister, ikke har avsnitt og ikke overskrifter.

Erling: At det blir en flat struktur, var det det jeg sa?

Anders: Kanskje, en flat struktur. Og en viktig bruker her er Google. Dette med korrekt kode, eller semantisk kode, å følge webstandarder, det er noe som Google verdsetter og alltid har verdsatt.

Erling: Dette vektlegger de tungt i sine algoritmer.

Anders: De har alltid hatt dette med i sine retningslinjer. Hvis du ikke har forskjell på overskrifter og innholdet, hvis ordet spade står med 30 punkter stor skrift og har tykk tekst inne i en div, da tenker Google at her står det ordet spade. Dersom det står at dette er hovedoverskrift, eller h1, spade, så skjønner Google at hele siden handler om spade. Kall en spade for en spade.

Erling: Nå har vi snakket om brukere. Hva med produsenter? Hvem treffer dette?

Anders: Det treffer helt åpenbart kodere. De som skriver HTML. De må kunne dette. De må vite hvilke tagger de har i verktøykassen, hvordan de skal brukes og hva som er meningen med dem. Alle kodere bør ha lest Designing with web standards av godeste Zeldman. Jeg vil òg si at alle som jobber med innhold må tenke på dette, fordi selv om alt er kodet riktig, kan du putte innhold feil. Et eksempel er hvis du skriver en lang tekst og deler teksten opp i ulike overskrifter, men du bare setter fet tekst på overskriftene. Da bryter med dette. Selv om koden er riktig så har du her gjort et grep som gjør at det blir satt inn feil kode.

Erling: Så hvis skriver tekst og bare setter større font på og bolder det, så bryter du denne retningslinjen.

Anders: Det gjør du. Så, innholdsfolk, kjenn din HTML. Jeg vil si at det er ganske lite arbeid å sette seg inn i de grunnleggende taggene som vi har.

Erling: Jeg skulle til å si det, det skal veldig lite til for å kunne nok. Kunne nok til å levere ganske mye verdi, og lage mye bedre innhold. Se for deg et vanlig tekstdokument, et word-dokument, der har du forskjellige typer overskrifter, altså headings. Du har paragrafer, du har gjerne et sitat, du har gjerne noen lister. Det er ikke så mange element. Hvis du har kontroll på dem, og vet at de skal kodes på forskjellige måter, så har du kommet langt.

Anders: Dette eksempelet med word-dokument, hvis du i et dokument skriver og skriver, og det blir ganske langt. Hvis du da trenger en innholdsfortegnelse, hvis du da har gjort det riktig, å definert overskrifter i stedet for å endre på skriftstørrelsen, så vil Word hjelpe deg med det.

Erling: Da drar du nytte av den strukturen du har definert.

Anders: Da får du en automatisk innholdsfortegnelse som oppdaterer seg av seg selv, i stedet for at du skal lage den manuelt. Det blir kluss.

Erling: Det blir bare baddel.

Anders: Og så har vi en litt omdiskutert, nei kanskje ikke omdiskutert – en liten påstand. Designere må òg tenke på dette. Grunnen til at jeg sier dette er at designere bør tegne opp, eller definere hele mulighetsrommet innenfor typografi og struktur. Slik at ingenting blir glemt. Når innholdsprodusenten bruker det han har lært til å sette inn riktig overskriftsnivå, i sitt lange dokument setter inn en h5, så har ikke h5-en fått en formatering fordi det ble glemt av designeren. Da blir det heller ikke nødvendigvis kodet. Og da ble den så stygg, at innholdsfyren kan velge et annet nivå som bryter strukturen. Da er det på én måte designeren sin feil.

Erling: Jeg kjøper den. Som designere skal vi være bevisste på hvilke innhold nettstedet eller applikasjonen skal ha.

Anders: Når jeg tenker meg om har jeg kanskje snakket litt mye om overskrifter, men et bedre eksempel fra et designers ståsted er et blokksitat. Det er noe som designere sjelden definerer. Hvis du da ikke har definert hvordan det skal se ut, og stå frem. Hvis du ser dybdeartikler på nett, så har de ofte visuelle, flotte blokksitat.

Erling: Ofte med et innrykk og i en annen font, gjerne i italic. Det stikker seg ut.

Anders: Vi skal komme litt tilbake til slike blokksitat vår ris og ros-spalte. Å vite at det er noe som heter blokksitat, må en designere vite.

Erling: Og style og legge til rette for, slik at utvikler kan bruke den stylingen.

Anders: Og det ser bra ut, helhetlig.

Erling: Ellers står innholdsprodusenten uten de verktøyene han trenger for å kunne skrive tilgjengelig innhold. Da legger han heller inn en tabell med en celle som han klarer å lage padding på i wysiwygen, setter på italic og tenker at dette ser ut som et flott sitat. Så funker det ikke på noe som helst måte for verken Google eller skjermlesere.

Anders: Da har du det gående. Så, designere må våkne. Difi har en struktur som viser hvem som berøres av ulike kriterier, de har nok ikke definert designere som målgruppen for denne 1.3.1-en. Dette slår vi et slag for!

Erling: Hvordan kan vi fylle denne retningslinjen? Unnskyld, suksesskriteriet.

Anders: Suksesskriteriet, bra, hvis ikke kommer hele uu-eliten og arresterer oss. Hvis vi fortsetter slik. Det korte svaret er godt håndverk. Bruk HTML slik som det er tiltenkt. Det er jo et råd som ikke er konkret nok. La oss spesifisere det litt. Paragrafer, kanskje det mest elementære HTML-elementet, p-en. Bruk nå det på avsnitt.

Erling: Ikke bruk div og br. Div, for snakke litt om akkurat den. Det er jo et samleelement som har en spesiell oppførsel. Hva står det for? Division?

Anders: Nei, det står for …

Erling: Nå er vi ute på litt tynn is.

Anders: Det står for, diversi… nei.

Erling: Vi kaller det bare for div, det er godt nok.

Anders: Ikke klipp vekk dette Erling, for da viser …

Erling: Nei, vi er mennesker, vi kan ikke alt.

Anders: Jeg vet heller ikke hva span står for, det står kanskje bare for span?

Erling: Det som gjerne er en typisk feil er å bruke div og så hiver en inn to br, og br står for break, altså linebreak.

Anders: Nei, jeg tror faktisk det står for breaking ruler, eller?

Erling: Hehe, vi er ikke så flinke til dette. Vi kjenner til elementene men vi har ikke satt oss inn i hva de står for. Det er hvertfall br som gir en ny linje. Legger du inn to slike ser det ut som en paragraf. Hvis du kode det.

Anders: Diversitis tror jeg div står for, men jeg vet ikke hva det ordet betyr.

Erling: Hehe, det er fint. P ja. Heading har vi snakket mye om, overskrifter. Er det seks nivå? Det er ikke syv?

Anders: Nei, vi har bare seks.

Erling: Jeg har aldri sett mer enn seks.

Anders: Det holder.

Erling: Du begynner å gå ganske dypt dersom du har syv nivå.

Anders: Da bør du heller vurdere å dele opp siden din i flere sider.

Erling: Da må du revurdere valgene dine.

Anders: Du har lister.

Erling: I hovedsak to typer.

Anders: Nja, tre vil jeg si.

Erling: DL?

Anders: Ja.

Erling: Vi har UL, som er unordered. Altså ikke en spesifikk rekkefølge på innholdet. OL som er ordered, da er det en spesifikk rekkefølge. Og så har du DL som er definition list.

Anders: Et smalt eksempel på et HTML-element som ikke blir designet. Nå er det riktignok ikke vanlig å ha en knapp inne i CMS-et for å sette inn en DL, det er sjelden at du går på smellen der.

Erling: Hvis du har UL og OL, unordered og ordered list, da har du god dekning. De pleier også å ha grei nok default styling. Så lenge markupen, altså HTML-en, er bra, så vil det bli ivaretatt. Så har vi table, den har en litt stygg historie.

Anders: Table før det var god støtte for CSS i nettleserne så brukte man jo table til å lage layout, oppsett av sider. Skulle tro at det var slutt på det. Det er det ikke. Det dukker opp. Jeg var nettopp med på å lansere en løsning som dessverre brukte table til layout.

Erling: Ikke hele løsningen?

Anders: Neida, deler av den.

Erling: Som kom fra en tredjepart.

Anders: Dessverre blir det brukt.

Erling: Tipper noe som ikke er blitt oppdatert på 18 år eller noe. Eller så er det inkompetente utviklere som skriver denne koden. De har ikke vært villige til å oppdatere seg selv på 18 år.

Anders: Man sluttet ikke å bruke table på grunn av universell utforming, man sluttet å bruke det fordi det er nesten umulig å gjøre responsivt. Så å få ting til å kollapse med en table nesten umulig. Det var heldigvis mobilens inntog som gjorde at man begynte å bygge det slik det var meningen.

Erling: Table er et viktig element til den type innhold. Table bør brukes.

Anders: Det er ingenting i veien med table.

Erling: Tabelldata skal inn i en table.

Anders: Alle skjemaelementer som form, label, input og fieldset, et lite brukt element.

Erling: Legend. Og jeg lærte en ny her en dag. Datalist. Nå begynner vi å bli å ganske spisset inn mot skjema. Den visste jeg ikke om. Den er heller fullt støttet. Den er litt kul, jeg håper den blir støttet.

Anders: Nå begynner kanskje folk å bli sure på oss.

Erling: Ja, nå begynner vi kanskje å nerde litt mye på HTML-en her.

Anders: Poenget vårt er, bruk HTML og CSS slik som det er ment, altså skill struktur og presentasjon. Bruk òg de nyere, de er ikke så nye lengre, HTML 5-elementene som du kan bruke til å strukturere oppsettet ditt med nav.

Erling: Som står for navigation.

Anders: Du har main, som er hovedinnhold. Footer, aside, header. Det gjør at for eksempel Google kan forstå hva som er hovedinnhold.

Erling: Når du bruker Just Read, som kan ta utgangspunkt i at main, det er der innholdet ligger, så kan jeg sløyfe nav, header og footer og alt fjaset utenfor.

Anders: Helt riktig. Og der en ikke har HTML 5-tagger, der kan du bruke aria-attributter og roller. Det skal vi snakke om i dagens aside. Du skal ikke bruke tomme paragrafer eller tomme mellomrom for å få luft. Det er også noe vi ser blir brukt, men som heldigvis er litt utdøende, slik som tabellene.

Erling: Det er ansvar som ligger hos designerene, at det er god struktur på typografien og elementene, at innholdsprodusentene føler at de må legge til mer luft.

Anders: Kjempe poeng! Du skal si at at noe er en overskrift i stedet for å bolde det. Men òg andre veien, at du setter på en overskrift for å oppnå en visuell effekt. Her har jeg lyst å …

Erling: bolde skikkelig …

Anders: … da setter jeg på en h4, den er skikkelig fin.

Erling: Da får du en annen fonttype.

Anders: Noe annet vi skal unngå er å bruke blokksitat bare for å få innrykk. Vi har ikke tabulatorer i HTML, så derfor har det vært en vanlig praksis å bruke blokksitat, for den har som standard litt innrykk. Det er feil fordi da sier du at noe er et sitat, og det er det ikke nødvendigvis. Vi kommer òg i situasjoner der HTML-en ikke strekker til. Det finnes ikke tagger i verktøykassen som gjør det vi ønsker å oppnå. Da putter vi på aria, som vi kommer tilbake til.

Erling: Jeg vil òg nevne dette med WYSIWYG, som står for what you see is what you get, en type editor som gir brukeren, altså innholdsprodusenten, tilgang til en del forskjellig styling. En kampsak for meg er å aller helst fjerne den, ikke gi brukeren den fleksibiliteten. Hvis du trenger å gi innholdsprodusenten den fleksibiliteten, begrens muligheten. Begrenser du muligheten så øker du sjansen for at innholdet blir bedre og mer semantisk. Til dere kodere der ute som setter opp CMS-er og sånn, skru av muligheten til å style, men gi brukeren mulighet til å gjøre det de ønsker. Begrens dem.

Anders: Hvis vi drar en paralell der til sosiale medier, så har jo de veldig begrenset formateringsmuligheter. Nå begynner jo Facebook å gi litt flere muligheter.

Erling: De styrer de mulighetene. Nøkkelkonsept. Gi brukeren inntrykk av at de har fleksibilitet. Styr det. Ha kontroll på det.

Anders: Gir du for mye makt, så blir det lett tivoli.

Erling: Erfaringen tilsier at det nesten garantert blir tivoli.

Anders: Et eksempel der er dersom du gir muligheten til å sette på ulik farge på skrift, så setter de på ulik farge på skrift. Da overskriver de stilarket. Dersom noen endrer bakgrunnen sin, så vil teksten som innholdsprodusenten har satt til en spesiell farge, bli uleselig.

Erling: Er du helt nødt til å fylle denne suksesskriterien?

Anders: Ja, dette er en enkel A. Vi forklarte A, AA og AAA-strukturen i episode to. Dette er en enkel A. Det vil si at med dagens forskrift og morgendagens forskrift med det europeiske direktivet, WAD, så må du fylle dette. Uansett hvilket nivå du legger deg på, må du tenke på informasjon og relasjoner.

Erling: Så hvis du ikke gjør dette så bryter du loven.

Anders: Du havner i fengsel.

Erling: Eller en god bot, forhåpentligvis en gang. Får håpe at de snart begynner å håndheve det.

Erling: Så til dagen aside. Nå har vi teaset litt om aria.

Anders: Jeg kan si hva det står for, det er ikke så viktig, fordi det ga litt mer mening tidligere. Det står for Accessible Rich Internet Applications. Det kan du glemme. Tenk aria.

Erling: Tenk at Anders ikke sa det nettopp.

Anders: Aria står ofte sammen med WAI-ARIA. Det er en avdeling, eller et initiativ, hos W3C. Nå blir det veldig mange forkortelser. Jeg vil si, glem WAI òg. Dersom det er snakk om WAI-ARIA eller aria, så er det det samme.

Erling: Det er det viktigste å ta med seg her. WAI-ARIA er ikke noe annet enn bare aria.

Anders: Aria er attributter, altså HTML-attributter som er laget for å forbedre tilgjengelighet, spesielt for skjermlesere og tastaturnavigering.

Erling: Så dersom det er noe HTML har manglet, så har de aria som er litt mer fleksibelt, eller de har hatt mulighet å legge til den funksjonaliteten de trenger, som et attributt, og det har de gjort.

Anders: Vi skal kun bruke aria når HTML-en ikke strekker til. Fordi en kan lett gå bananas i aria-attributter og tro at en lager tilgjengelige løsninger, men så gjør du en bjørnetjeneste, fordi du øker kompleksiteten og variasjoner på tolkninger av aria er stor på ulike skjermleser og kombinasjoner av skjermlesere og operativsystemer. Det er en nødløsning kan vi si.

Erling: En nyttig nødløsning.

Anders: Det er viktig.

Erling: Skal ikke unngå å bruke det.

Anders: Skal ikke unngå å bruke det, men for eksempel en aria som heter role erlik complementary, den har nå blitt overflødig fordi vi har i HTML 5 noe som heter aside. Det vil si at dersom du setter role erlik complementary på en aside, så er det smør på flesk. Eller hvis du setter role erlik complementary på en div, så er det bedre å bruke en aside.

Erling: Samme med main og role main og lignende.

Anders: Vi har likevel plasser der vi ikke har HTML-elementer. Et eksempel er faner, som er mye brukt til navigasjon.

Erling: Tabs.

Anders: Der har vi aria, men ikke HTML. Vi har ikke et undernivå av nav som heter tab. I aria har vi tre forskjellige tab-elementer, tablist, tabpanel og … Det som er litt paradoksalt er at nettsider som bruker aria gjerne med gode intensjoner har mer feil. Flere brudd på WCAG.

Erling: Nå er det viktig at vi ikke misforstår. Det betyr ikke at hvis du bruker flere aria, så vil du automatisk få mer feil. Dette er noen som har gjort en undersøkelse.

Anders: Det er WebAIM som har kjørt en undersøkelse på de én million største nettsidene i verden. Veldig interessant undersøkelse, den referer vi til i fotnotene. Statistisk sett så viser det at jo flere aria-attributter, jo flere feil har de. Som jo er litt morsomt. Men det er jo to potensielle forklaringer til det, to hypoteser. Det er at folk har gått litt bananas, altså du har trodd at det funker for skjermlesere å klemme på noen attributter. Det er òg det at du ikke bruker aria før løsningen din er komplisert, og når du først har en komplisert løsning er det flere fallgruver å gå i.

Erling: Du har flere feil du kan gjøre.

Anders: Og er det flere feil du kan gjøre, så gjør du flere feil.

Erling: Det er ikke aria sin feil. Det er fortsatt en interessant tendens.

Erling: Da er vi på dagens ris og ros. Her er det lett å finne ris.

Anders: Det er veldig lett å finne ris.

Erling: En kan finne direkte uomtvistelig ris, men det er òg situasjoner der det blir en definisjonssak. Når skal det være en liste, når skal det være noe annet. Men vi har funnet noen ris, vi har to ris og én ros etterpå.

Anders: Den første risen går til Dagsavisen. De har en artikkel som heter Fikk ikke kjøre videre slik – fører anmeldt for flere forhold. En trailersjåfør som ikke har bilen sin, eller traileren sin på stell. Ingressen er satt til å være en overskrift nivå to, altså en h2. Heading 2. Vi som ikke kjenner løsningen vet ikke om det er innholdsprodusenten eller koderen som har gjort det. Det kan være at det står ingress i CMS-et, men at det står som h2 i malen slik at alle ingresser er det.

Erling: Det høres ut som en typisk feil hvor den som lager innholdet ønsker å style den delen litt tydeliger, og prøver å finne et element som gir den stilen som innholdsprodusenten ønsker å ha.

Anders: Ulempen med det er at, for eksempel, når du bruker en skjermleser kan du få lest opp alle overskriftene, det skal vi demonstrere, og hvis du da får lest opp en lengre ingress som en overskrift, så gir det ingen mening. Det hjelper deg ikke til å skumlese teksten.

Erling: Den fremstår ikke som en overskrift.

Anders: Det som òg kan skje er at Google ser at du har puttet inn mye innhold som en overskrift, og tolker det som en måte å påvirke søketreffene, noe du kan bli straffet for. Dette høres kanskje litt ut som en bagatell, men veldig lett å fikse.

Erling: En lett feil å ikke gjøre.

Anders: I tillegg har denne artikkelen her en kuleliste.

Erling: En UL. En unordered list.

Anders: Der er det bare masse stjerner. Det vil si at da har ikke innholdsfyren markert listen og trykket på knappen. Han har bare skrevet stjerne på tastatur. Dette er ikke et stort problem. Hvis noen har valgt å formatere lister på sin egen måte, så vil ikke den brukerendringen treffe den liste.

Erling: En skjermleser vil lese den stjernen.

Anders: Det er litt plagsomt, men ikke krise.

Erling: Det gjør ikke innholdet utilgjengelig. Litt ekkelt.

Anders: Stjerne. Stjerne. Stjerne. Og så skal vi litt ned i bagatellmodus. Det de òg gjør, som er en vanlig feil, de markerer ikke sitater. De bruker vanlig p på sitater. Du har to typer sitater i HTML, du har blockquote og q. De bruker ikke disse. Her vet vi ikke grunnen. Om det er innholdsprodusenten eller om det er koderen som ikke har tilgjengeliggjort dette. Det er som du sier, for en skjermleser byr det ikke på noen problemer. Men hvis designeren har gitt et spesielt uttrykk til sitat, for å øke lesbarheten og leseopplevelsen og den typografiske helheten, så vil ikke den CSS-endringen inntreffe her, som gjør at designet blir fattigere. Kanskje er vi pirkete nå?

Erling: Dette er jo konsekvenser. Hvis en designer vil endre på stilen til alle blokksitat, så vil han ikke kunne gjøre det, når det blir lagt inn som en p og får styling.

Anders: Her var det ikke lagt på styling heller. Det er et sitat, ikke blokksitat.

Anders: Aftenbladet, vår lokalavis. Akkurat nå fikk jeg litt dårlig samvittighet. De har laget en skikkelig god dybdeartikkel, eller artikkelserie, om Siw. Jeg har ikke lest den, dessverre. Men jeg liker godt å lese de dybdesaken til Aftenbladet. Høy kvalitet, journalistisk veldig bra. Denne har fått mye positiv oppmerksomhet. Det er en tragisk sak, men journalistikken og bakgrunnarbeidet har fått mye oppmerksomhet.

Erling: Nå har du pakket det godt nok inn.

Anders: Ja, og det er litt synd å rise Aftenbladet for dette.

Erling: Du riser dem ikke for innholdet.

Anders: Nei, vi riser dem for måten de har markert innholdet, med sin kode. Det de har gjort her, er at det har bygget egne maler på de XL-sakene.

Erling: Det er en sånn longread med eget design.

Anders: Det ser veldig bra ut.

Erling: Smashing!

Anders: Det kan se like bra ut, selv med riktig kode.

Erling: Der må jeg skyte inn for de gamle nerdene, CSS Zen Garden, det var gode tider. Det ble laget for å bevise at du kan lage nettsider nesten som du vil selv om du fyller semantisk HTML.

Anders: Dette er en innlogget artikkel. Det de har på første overskrift, på den viktigste overskrift, det er en div med klasse som heter mm-title. Nå har jo ikke vi laget dette, så vi vet ikke hva mm betyr.

Erling: Var det derfor du sa multimedia?

Anders: Hehe, nei. Varsellyset bør blinke når du putter title eller header i et klassenavn. Dersom du putter noe i et klassenavn som har en tagg, så bør du tenke deg om to ganger.

Erling: For eksempel h2 class h2.

Anders: Da har du gjort noe riktig, da har du brukt h2.

Erling: Div class h2, den er stygg.

Anders: Ja, den er stygg. Men denne er òg ekkel. Det de òg har gjort, de har visuelt fine blokksitater. De har trukket ut viktige sitater fra artikkelen og fremhevet det visuelt og typografisk. Du vil nesten ikke tro hvor mange brudd på suksesskriterier de klarer på ett sitat.

Erling: Det er nesten imponerende.

Anders: Det skal vi få demonstrert nå med en skjermleser. De bruker òg EM på sitater, nå snakker jeg ikke om blokksitat, men bare sitater.

Erling: Og EM er emphasis som ofte gir en kursiv.

Anders: Ofte en kursiv, men ikke nødvendigvis. Det har blitt standarden.

Erling: Og det er derfor de har gjort det her, fordi de ønsket at teksten skal bli kursiv.

Anders: Ja, de ønsker at sitatene skal være kursiverte, men det du skal gjøre her er å bruke q og sette den til å være kursiv i CSS-en. Og så er det mye rart i denne artikkelen, plutselig er det et kulepunkt som er enslig.

Erling: Helt ut av det blå?

Anders: Ja, en overskrift som har en kule foran seg. Det er en UL med en LI inni. Det ser kanskje bedre ut med en kule foran denne overskriften?

Erling: Det høres mer ut som en feil. Jeg vet ikke.

Anders: Uansett, jeg vil òg gi litt ros i risen, så er det plutselig en liste på hva Siw har stjålet. Den er kodet riktig. Akkurat på lister så har de gjort det som Dagsavisen ikke har gjort. Så nå skal vi prøve oss på skjermleseren. Det vi bruker da er VoiceOver på Mac. Jeg skal prøve å flytte mikrofonen. Som vi sa tidligere, dette er innebygget på Mac. Dette er ikke et tilleggsprogram.

Erling: Det er òg den folk flest bruker når de har Mac.

Anders: Ja, når de har Mac så er det det. Men markedsandel på Mac er ikke så stor. Markedsandelen på telefoner er større, og det er samme teknologi. VoiceOver på en iPhone er samme teknologi. Da skal vi starte …

VoiceOver: VoiceOver på Chrome. Jeg bare søker. Jeg vet godt at jeg ikke er en prinsesse. Stavanger.

Anders: Nå skal vi ikke høre så mye på hva hun sier nå. Nå startet jeg en liste som liste … Nå bruker jeg ordet liste.

Erling: Det er ikke en liste i artikkelen, det er en oversikt.

Anders: Oversikt over alle overskriftene. Og så begynner vi da fra toppen. Nå tenker vi oss at jeg vil danne meg et bilde av hva denne artikkelen inneholder. Før jeg begynner å gå i dybden, så vil jeg se hvilke overskrifter som finnes, fordi her er det mye tekst.

Erling: Du vil få et overblikk over hvilket innhold som finnes her.

VoiceOver: Overskrift nivå én, Stavanger Aftenblad.

Anders: Ja, Stavanger Aftenblad. Det er greit.

Erling: Du får vite hvor du er.

Anders: Det er omdiskutert om du trenger Stavanger Aftenblad som h1. Du har det i title, men vi skal ikke ta den nå.

VoiceOver: Overskrift nivå to, prinsessen ved Mosvannet.

Anders: Så nå hoppet vi rett til overskrift nivå to, prinsessen ved Mosvannet. Og det høres ikke feil ut.

Erling: Det hørtes jo greit ut.

Anders: Men Prinsessen ved Mosvannet er langt nede i artikkelen.

Erling: Ååh.

Anders: Å artikkelen heter jo ikke Prinsessen ved Mosvannet.

Erling: Nei, nettopp.

Anders: Vi har en hovedoverskrift her som er markert med div class mm-title.

Erling: Det som er fint er at jeg ikke har sett denne artikkelen. Du har sett den. Nå trodde jeg at dette var den første overskriften.

Anders: Her har informasjon gått tapt. Vi har et helt konkret brudd på dette suksesskriteriet. Fordi nå er jo du i den …

Erling: Nå ser jeg jo på deg, jeg ser ikke på skjermen. Jeg tror at artikkelen nå heter Prinsessen ved Mosvannet.

Anders: Det gjør den ikke. Denne delen av artikkelen heter noe helt annet, den heter «Jeg bare spøker». Nå klarer jeg ikke å se det helt.

Erling: «Jeg bare spøker, jeg vet godt at jeg ikke er en prinsesse», det er den første tittelen.

Anders: Visuelt sett står denne gigantisk over et stort fint bilde. For seende, vi skjønner at dette er overskriften. Men det kommer ikke frem.

Erling: Strengt tatt burde dette vært en overskrift en med en q. Fordi dette er et sitat i overskriften.

VoiceOver: VoiceOver av.

Anders: Under denne overskriften står det kapittel tre. Det er veldig viktig informasjon. Det ville jeg hatt med i første overskriften, i h1, at det er kapittel tre. For hvis du kommer direkte til denne artikkelen, hvis du lander her, fordi du har googlet at du vil lese historien til Siw. Med skjermleseren får du ikke beskjed at du er på kapittel tre, fordi den ikke er markert riktig. Og så skal vi ned til det kjekke. Nå skal vi høre et sitat. Nå skal jeg ikke si hva det står. Teksten er formatert som at det er noen avsnitt. Så er det trukket frem med store bokstaver et sitat fra teksten med et fint bakgrunnsbilde.

Erling: Med innrykk. Det ser veldig ut som et sitat.

Anders: Vi får først lest avsnittet før sitatet. Så kommer sitatet.

VoiceOver: sa.mnocdn.no/images/2a9bd664-68b2-4b56-8fab-e2432824f2f2?fit=crop&q=80&w=2048. VoiceOver av.

Erling: Oi!

Anders: Her har vi faktisk så mange brudd, vi bryter ikke bare 1.3.1, vi bryter flere. Jeg har ikke talt hvor mange.

Erling: Hva var det han leste opp nå.

Anders: Han leste opp filnavnet til bildet. Som vi lærte i 1.1.1, så skal vi ha alternativ tekst på bildet, men dette burde aldri vært et bilde i utgangspunktet.

Erling: Dette er et typisk dekorativt bilde, ikke et informativt bilde.

Anders: Nei, her er jo hele teksten et bilde, som er brudd på en annen som kommer i en senere episode.

Erling: Ahh, det la jeg ikke merke til.

Anders: Dette baller på seg.

Erling: Full bom.

Anders: Dette skulle vært et blokksitat, helt åpenbart, og det blokksitatet skulle hatt et bakgrunnsbilde definert i CSS-en. Det filnavnet skulle aldri vært synlig i tilgjengelighetstreet som det kalles. Det skulle aldri truffet skjermleseren i det hele tatt. I tillegg til filnavnet så er det òg parametre for hvordan det skal beskjæres og størrelse, så dette ble mega kryptisk. For seende så ser dette bra ut, et godt typografisk grep. For skjermleseren var det helt ubrukelig.

Erling: Jeg som front-end-utvikler og jobber med web, dette er enkelt å gjenskape med semantisk HTML og litt CSS. Det er ABC. Det er én null én. Det lærer du første uken på skolen.

Anders: Her er poenget som du sa tidligere, dette er større artikkelserie, masse innhold, masse slike sitater. Dersom de skal endre på alle disse sitatene samtidig. Nå må det sitte en fyr å lage alle disse bildene, og logge seg inn i CMS-et og bytte om på bildet. Kanskje har han ikke en god søkefunksjon for å finne alle stedene det er brukt. Mye vedlikeholdsarbeid.

Erling: Veldig kult for det var så veldig feil. Imponerende hvor dårlig de har klart å implementere det sitatet.

Anders: Den første fiksen ville vært å putte på en alt-tekst som sier det samme som teksten.

Erling: Det hadde vært litt bedre. Fortsatt ikke bra nok. Det ville fortsatt bryte denne retningslinjen vi er på i dag, 1.3.1. Fordi du koder det ikke som det det er.

Anders: Dersom du hadde kodet som et blokksitat med et bilde med en alt-tekst, så hadde du kommet unna med det.

Erling: Men det er ikke å anbefale.

Anders: Ikke god kodeskikk, ikke godt håndverk. Dette ble en lang ris dette.

Erling: Kjekt, veldig gøy.

Anders: Vi skal gi ros til et nettsted som heter Kode24, de gjør mye riktig. De gjør òg mye feil. Det skal vi ikke fokusere på nå. Vi ønsker å trekke de frem fordi de gjør mye rett. De er òg eksperimentelle, de har valgt et veldig annet uttrykk enn tradisjonelle nettaviser. Det er jo ikke en tradisjonell nettavis, det er jo en nettavis for nerder, kodere. De bruker overskrifter og uthevinger og lister, de bruker blokksitat. De har dessverre brukt tabell i kodeeksempelet, jeg klarer ikke helt å forstå hvorfor.

Erling: Eksempel på en kode, og så er det en tabell inni der?

Anders: Der mistenker jeg at de bare embedde fra en kodetjeneste, som Codepen.

Erling: Det er noen andre sin feil.

Anders: Kode24 har jo ansvaret.

Erling: Definitivt. Det er ikke unnskyldning nok, at noen andre har laget det.

Anders: Skal vi gjør den samme skjermleserøvelsen med Kode24?

Erling: Ja, det synes jeg.

Anders: Da prøver vi det! Da skal vi plukke opp Kode24, og putter jeg på VoiceOver.

VoiceOver: VoiceOver på Chrome.

Anders: Her får jeg demonstrert en annen artig detalj. Da begynner vi.

VoiceOver: Overskrift nivå 1, kobling, bilde. Kode 24.

Anders: Det vi hørte nå, det er overskrift nivå 1, det er en kobling, det er et bilde og teksten er Kode 24. De har en logo som rett alt-tekst. Vi nevnte i første episode at du kan òg ha intensjonen med lenken, men dette er godt nok. Som Aftenbladet, de har logoen sin som hovedoverskrift. Neste, jeg trykker pil ned. Nå er vi inne i oversikten …

Erling: Oversiktslisten over headingene.

VoiceOver: Overskrift nivå 1, slik skaper med kunst med ren CSS.

Erling: Her har vi to h1. Er det greit.

Anders: Det er omdiskutert. Vi skal ikke ta den nå. Det er ikke et brudd på WCAG å ha to h1. Det er lov i HTML5-standarden. Delte meninger, de lærde strides. Jeg synes at dette er bra. Nå har de sagt at hovedoverskriften er Slik skaper de kunst med ren CSS. Så har de delt opp resten av artikkelen sin i mindre overskrifter. Overskrifter av et lavere nivå. Nå skal vi høre hva neste overskrift er for å få et bilde av hva denne artikkelen handler om.

VoiceOver: Overskrift nivå 2, CSS hva kvinne som trekker på skuldrene.

Erling: Der var det noe om en dame som trekker på skuldrene. Rart.

Anders: Før vi snakker om hun damen så hører vi hører overskrift nivå 2. Det er riktig. Bra. Det neste klarer jeg ikke å høre, men jeg leser det jo, at det neste hun sier er CSS Hva. Når de bruker CSS og bindestrek hva, så sier du at det er ett begrep. Jeg vil jo si at gramatisk sett skal du ikke ha den bindestreken der, og da hadde jo VoiceOver tatt en pause, og det hadde vært lettere å høre. Så CSS Hva? Ikke sant. Så CSS-hva sier hun litt for fort og nå har vi skrudd ned hastigheten på VoiceOver bare for denne demonstrasjonen. Bruk et annet ord. Skriv det om, eller dropp den bindestreken. Men, kvinne som trekker på skuldrene? Hehe.

Erling: Du kan jo gjette hva dette er.

Anders: Nå gir vi lytteren fem sekunder til å gjette, klar, ferdig, gå! Det er en emotikon eller emoji. Jeg er ikke helt sikker på hva det riktige begrepet er.

Erling: Da gir det mening med en gang, kanskje.

Anders: Ja, det er en kvinne som trekke på skuldrene. Og jeg vil si at det er bra at VoiceOver formidle denne informasjonen, så får det være opp til Kode 24 om de vil ha den med for skjermlesere. Det er jo med å skape en stemning, at dette er noe Hæ? Ka? Jeg synes den er grei. Hvis vi tar neste (emoji) så gir den mindre mening, nå skal vi høre.

VoiceOver: Overskrift nivå 2, hvordan gjør de det, kvinne som ser rett frem.

Erling: Hmm.

Anders: Overskrift nivå 2, hvordan gjør de det. Dette gir mening. Altså her vet vi at vi er inne på en artikkel som handler om kunst og CSS. Hvordan gjør de det. Dersom du skal lære hvordan det blir gjort, så vet du at dette er relevant. Men kvinne som ser rett frem? Spesielt litt irriterende siden det blir opplyst så tett, det er ikke noe pause mellom hvordan gjør de det og kvinne som ser rett frem. Akkurat i denne overskriften så gir det ingen mening. Her mener jeg at de har to valg. Enten så bør de skjule …

Erling: emojien for skjermlesere.

Anders: Ja, da bruker du noe som heter aria hidden. Eller så kan de fjerne det for alle. For bidrar egentlig den emojien?

Erling: Jeg tørr påstå at dette er en del av uttrykket til Kode24, at de bruker emojier, så en kan argumentere for at dette er en viktig del av uttrykket.

Anders: Men da vil jeg tenkt at de skal sette aria hidden. Noen ganger gir det mening og andre ganger ikke. I dette eksempelet …

Erling: Så er det mer forvirrende enn det er nyttig.

Anders: Men det er jo viktig å vite, som sagt, du slipper å ha alternativ tekst på emoji, der ligge en mening bak dem.

Erling: Det jeg savnet litt var at skjermleseren betegner det som en emoji.

Anders: Ja! Godt poeng! Send det inn som et endringsforslag til Apple.

Erling: Er det Apple som bestemmer det?

Anders: Jeg vet ikke. Eller er det Emoji Incorporated?

Erling: Dette må vi finne ut av, etterpå.

Anders: Jeg skur av VoiceOver. Det var gøy.

Erling: Kjempekjekt å få et praktisk eksempel på hvordan det fungerer.

Anders: Vi har nådd slutten.

Erling: Hva har vi snakket om i dag? Bare ett suksesskriterie, men likevel ganske mye.

Anders: Dette er derfor vi har hatt denne som en egen episode, det er mye å ta tak i.

Erling: Det vi har snakket om, du må kode det som det det ser ut som. Det sier Difi. En annen måte å si det på, er å kode det som det det er. Bruk standarden, bruk semantisk HTML.

Anders: Bruk det slik det er tiltenkt.

Erling: I neste episode, hva skal vi snakke om da?

Anders: Den har vi kalt, Trykk på rundingen til høyre. Vi skal fortsatt være på 1.3. Det skal være mulig å tilpasse, fortsatte. Vi skal snakke om rekkefølge på ting. Jeg nevnte jo dette at noen foretrekker færre kolonner å lese i, da må rekkefølgen bli riktig. Vi skal snakke om sensoriske egenskaper, altså hvilken form ting har. Runding. Og så skal vi snakke om orientering. Ikke i skogen, men hvordan du holder mobilen din.

Erling: Landskap eller portrett.

Anders: Hvordan liker du å holde din mobil?

Erling: Den er nesten alltid i portrettmodus. Med mindre jeg ser en film.

Anders: Da putter du den i landskap? Putte? Du vrir den.

Erling: Jeg snur den til landskap.

Anders: Vi skal snakke om hva vi må tenke på der.

Erling: Det er den første retningslinjen eller suksesskriteriet som kommer i vår podkastserie som er fra WCAG 2.1. Denne er ganske ny.

Anders: Den ble offisiell anbefaling sommeren 2018. Det er den første som går direkte på mobil og nettbrett. Den er ikke gjeldene på større skjermer.

Erling: Og så vil vi jo si at dette er løpende serie som vi publiserer jevnlig. Vi vil gjerne ha kommentarer på det vi gjør. Arrester oss gjerne. Send en e-post til hei@universeltutformet.no, så lover vi at vi kommer til å takke til innspill.

Anders: Gi oss forslag til forbedringer.

Erling: Det var alt vi hadde for i dag. Mitt navn er Erling Håmsø, jeg jobber i Okse.

Anders: Mitt navn er Anders Ekkje Slettebø, jeg jobber i Webstep.

Erling: Adjø.

Anders: Adjø.