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: Klar, Anders?

Anders: Jeg er klar, Erling.

Erling: Har du det bra forresten?

Anders: Oi. Ja.

Erling: Er det lov å spør om?

Anders: Ja. Jeg har det bra. Jeg er veldig motivert for å snakke om uu. Har mye i toppen om dagen. Begeret er nesten i ferd med å renne over.

Erling: Så lenge det ikke renner over …

Anders: Det har det ikke gjort hittil. Jeg har det bra.

Erling: Jeg har det tipp topp. Nesten perfekt.

Anders: Oi.

Erling: Det har jeg hatt ganske lenge òg.

Anders: Er det noe som har skjedd med deg siden livet er perfekt? Har du truffet noen, Erling?

Erling: Nei, har ikke truffet. Kanskje det er derfor det er så perfekt? Jeg har full kontroll på alt. Og alt jeg gjør er kjekt, nesten. Er ikke det bra? Inkludert dette?

Anders: Dette er jo veldig kjekt.

Erling: Det er sykt kjekt. Men i dag, hva skal vi snakke om?

Anders: Vi skal snakke om WCAG 2.4. Toen har vi holdt på med en stund, den betyr at det skal være mulig å bruke.

Erling: Den opererbare.

Anders: Der rattet vårt er faktisk mulig å svinge på. Firen er ny i dag, den skal vi snakke om nå og neste gang. Den handler om navigerbert, at det er mulig å finne frem. Så hvis du har rattanalogien vår, så har du gjerne en GPS i tillegg, som hjelper deg å finne frem.

Erling: Spesifikt, hvilke suksesskriterier er det vi snakker om? I dag har vi tre som er forskjellige.

Anders: De handler alle om navigasjon, men de er veldig separate. De har ikke mer relasjon enn at de tilhører navigasjon. Så derfor skal vi prøve å være litt tydelige på det vi snakker om – hva som tilhører hvilket suksesskriterie. Den første er en som heter hopp til innhold. Hopp over-lenker blir det kalt. På engelsk skip links. Det er ofte usynlige lenker. De kan være synlige òg, for de som virkelig tar uu på alvor, så har vi eksempler på at de er synlige. I de fleste tilfeller er de usynlige. Det er lenker som hjelper deg å hoppe over alt som gjentas på hver side. Og vi skal snakke om sidetitler.

Erling: Her er det en definisjonsgreie.

Anders: Vi skal ikke blande overskrifter, altså headings. h1, h2, h3, helt til seks. Tittel eller title. Da snakker vi om taggen, ikke attributtet. Der er det forskjell.

Erling: Den blemmen gikk jeg på i dag.

Anders: Så title-attributtet som vi ikke skal snakke om i dag, det er noe du setter på elementer for å gi mer informasjon. Title-taggen er noe du for eksempel setter på en side, for å fortelle hva den handler om. Du kan sette den på andre ting òg, men det er veldig få plasser utenom selve siden man bruker den.

Erling: Et eksempel er SVG.

Anders: Der bruker du title-taggen.

Erling: Title-taggen brukes vanligvis i head.

Anders: Den må være i head. Du kan ikke ha title i body. Body er alt det som er innenfor visningen. Titlen er ikke med i visningen, det er mer metadata. Den vises i for eksempel i tabben. Når jeg sier tabben mener jeg fanen.

Erling: Nå var det du som brukte det engelske ordet først.

Anders: Der må vi òg passe oss, for vi har jo en tabb-tast.

Erling: Tab-rekkefølge.

Anders: Det skal vi òg snakke om i dag, tabb-rekkefølge, som leder oss til neste suksesskriterie, 2.4.3, fokusrekkefølge som òg kalles tabb-rekkefølge. Da snakker vi om tabb-tasten, ikke fanerekkefølge.

Erling: Nå har vi gjort en god jobb med å forvirre folk her. Det er ikke så avansert, jeg har nok tillit til lytterne til at de forstår det. I dag har vi en veldig kjekk aside. Vi har hatt besøk av en som er blind. Han har faktisk vært på besøk her hos oss. Det var veldig kjekt.

Anders: Hentet han på flyplassen. Nå skal det være sagt at han ikke kom ens ærend for å besøke oss, men det var veldig bra at han tok seg tid til å ta en prat.

Erling: En ordentlig prat. Kjekt, gled dere!

Anders: Aside med Lars Bjørndal.

Erling: Og dagens ris og ros, hvem skal vi piske i dag?

Anders: I dag skal vi snakke om oppslagsverk, litt sånn wiki, leksikon og ordbøker.

Erling: Hvorfor har vi disse suksesskriteriene?

Anders: Da må vi begynne med den hopp til innhold. Det er fordi irriterende og tidkrevende for de som bruker skjermlesere eller tastatur og måtte tabbe seg, eller høre, på de samme lenkene om og om igjen.

Erling: Nå gikk det opp for meg at jeg bruker en slik skip link veldig ofte.

Anders: Å ja?

Erling: Det er når jeg ser på serier, nå jeg skal binge serier, da har Netflix en lenke som heter skip intro. Det er jo litt dette.

Anders: Det er det samme.

Erling: Dette har jeg sett før, så jeg vil hoppe til det faktiske innholdet.

Anders: Og der lærte jeg noe nytt av en kunde eller kollega som heter Ola som har sin egen Fiffig-podkast.

Erling: Veldig kjekk podkast.

Anders: Han nevnte at han hadde en podkastapp der han per serie kunne velge hvor mye han skulle skippe i starten. Hvis han hører på Universelt utformet, og vet at hver episode har 30 sekund med teit intromusikk, så kan stille inn det. Aldri hør på den teite intromusikken. Det er dette prinsippet vi snakker om i dag. Nå burde jeg husket hva denne appen het, men det husker jeg ikke.

Erling: Et googlesøk vil sikkert avsløre det.

Anders: Det er fryktelig irriterende når du har klikket deg på en lenke, funnet frem i navigasjonen og skal lese om et tema, så må du da høre på hele navigasjonen som kan bestå av titalls lenker, på ny. Nå er det jo sånn at for de som bruker tale, lyd, så har du masse andre måter å hoppe over navigasjon og gjentagende elementer enn disse hopp over-lenkene, men det er et veldig godt hjelpemiddel. Og det samme gjelder tastatur, hvis du har disse, vi skal demonstrere dette i ris og ros-spalten, så er det mye smidigere å bruke nettet. Altså, blinde og svaksynte og folk som må eller vil bruke tastatur, så er disse lenkene viktige.

Anders: Da skifter vi kriterie. Da går vi over til title-taggen. Altså sidetittel. Den skal beskrive innholdet på siden. Det er viktig fordi det er ofte den første indikatoren både seende og ikke seende får, for hva en side inneholder. Google digger det jo, det er et av de viktigste rangeringskriteriene til Google. I sidetittelen bør du beskrive innholdet og du bør få med naturlige søkeord. Når du gjør et søk i Google så er title-taggen den første linjen som vises i et søketreff. Det er title-taggen!

Erling: Det er jo et eksempel på når en WCAG suksesskriterie og treffer alle. Altså en beskrivende sidetittel gjør det lettere for alle å finne den rette informasjonen.

Anders: Dette er viktig for de som bruker bokmerker. Eller favoritter som det kalles i noen nettlesere. Nå vet jeg ikke hvor utbredt det er. Jeg bruker det, men kanskje jeg er gammeldags. Jeg har en følelse at bruken av bokmerker har gått ned.

Erling: Jeg bruker de, men jeg refererer aldri til dem igjen. Det er viss trygghet i å vite at jeg har lagret en side. Det er nesten som om Google er dagens bokmerke. Du googler deg bare frem til det du skal ha, i stedet for å lete gjennom bokmerkestrukturen. Det var en liten avsporing.

Anders: I nettleseren er det title-taggen som brukes oppe i fanen. Det er vanlig i dag å ha ufattelig mange faner. Så hvis du skal finne tilbake til den rette fanen, så hjelper title deg. Hvis du har for mange faner vises ingenting, da ser du ikke tittelen, det er ikke plass. Hvis du ikke har så mange, at du ser noen av de første ordene. Det treffer òg de med dårlig korttidsminne, hvis du skal finne tilbake til noe du holdt på med, hva er tittelen på dette?

Erling: Da er et relevant innspill. Hvis du starte hvert title med navnet på siden, så kan alle se like ut. For eksempel Universelt utformet, hvis vi hadde startet title med det, nå husker jeg ikke hva vi gjør, så vil du bare få mange faner hvor det står Universelt ut… eller lignende.

Anders: Det er et viktig prinsipp her, at du tar sidens innhold før nettstedets tittel. For eksempel en episode på universeltutformet.no så bør vi ha episodenavnet først, og så Universelt utformet til slutt.

Erling: Og jeg kan bekrefte at vi har det.

Anders: Det var tittel. Hvorfor har vi det? Jo, det er en viktig indikator på hva siden inneholder. Så går vi videre til den som heter fokusrekkefølge.

Erling: Men denne har vi snakket om før!

Anders: Ja og nei. Den er veldig knyttet til en vi har snakket om før, men det er en liten forskjell her. For vi har snakket om koderekkefølge før. Nå snakker vi kun om fokusrekkefølge, og du har kun fokus på interaktive elementer. Vi burde slått dem sammen, men de tilhører og helt forskjellige retningslinjer. Så OCD-Anders hadde hatt litt problemer med å slå dem sammen.

Erling: OCD-Erling òg.

Anders: Fokusrekkefølge er viktig for de som navigerer sekvensielt. Det er et viktig konsept å forstå. For dersom du bruker telefon med hånden eller en PC med mus, så navigerer du ikke sekvensielt, da hopper du på kryss og tvers med øynene dine. Men for de som navigerer sekvensielt så er fokusrekkefølge viktig. Da er det viktig at den ikke hopper på kryss og tvers. Rekkefølge bør være der du forventer den skal være.

Erling: Det er vel rekkefølge både i koden, at det gir mening når du hører det, men òg visuelt, når du navigerer visuelt, så skal ikke fokuset hoppe rundt forbi.

Anders: Grunnen at den er spesifisert som fokusrekkefølge er at du kan spesifisere fokusrekkefølge selv om koderekkefølgen er bra. Det skal vi komme inn på når vi snakker om teknikker. Dette høres avansert ut, å få en korrekt fokusrekkefølge er veldig lett. Ikke bli skremt av denne.

Erling: Faktisk alle de tre i dag er lette å følge. Hopp til innhold, ekstremt enkelt teknisk å legge inn. Veldig få som gjør det, selv om det er lett å gjøre. Det tyder på at folk ikke er klar over det.

Anders: Dette med tittel er det mange som gjør. Det gjør de fleste i dag, riktig, fordi en får det gratis av publiseringsløsningen. Publiseringsløsningen fikser dette for deg. Fokusrekkefølgen er vanskelig å gjør feil.

Erling: Du må aktivt gå inn å tulle med fokusrekkefølgen.

Anders: Hvem må tenke på dette når vi lager løsninger?

Erling: Vi er jo opptatt av flest mulig har et begrep om de store linjene i disse suksesskriteriene. Hvem er det av produsentene, som må høre litt ekstra etter nå. Vi har snakket om forskjellige typer produsenter i tidligere episoder. Vi snakket litt om designere.

Anders: De blir ikke direkte truffet i dag.

Erling: Det er ikke de som blir truffet hardest, men de har òg et visst ansvar. Designer-koder-forholder er slik at kodere har en tendens har til å kode det designeren tegner. Dersom designeren ikke tegner en hopp til innhold-greie, er det ikke sikkert at koderen koder det.

Anders: Og hvis designeren har glemt det, og koderen er så flink at han kan universell utforming, så må han spørre designeren om hvordan dette skal se ut og fungere, og dersom designeren ikke vet hva det er snakk om, så kan det bli stygt.

Erling: Hva med nettredaktørene?

Anders: De må bare forholde seg til title-taggen og forstå at den har begrenset antall tegn, det har vi ikke snakket om. Og at du inkludere de viktigste ordene først, og at du er veldig konkret og beskrivende.

Erling: Viktigheten av å skrive gode titler, det må de tenke på.

Anders: Kodere må forholde seg til alle disse tre. Det som er verdt å nevne på hopp til innhold-lenkene er at de kan kodes med ren HTML og CSS, du trenger ingen logikk. Du trenger ikke programmering.

Erling: Enkelt sagt, så når den får fokus skal den vises, ellers kan den være skjult.

Anders: Den kan vises hele tiden, men det er vanlig å skjule. Men òg sidetitler må kodes som title, og det gjør alle i dag. Fokusrekkefølge, der må koderne ha et bevisst forhold, men det er ikke så mange som driter seg ut der.

Erling: De må ha et ekstra bevisst forhold til det, dersom de velger å tulle med det.

Erling: Hvordan? Teknikker rundt dette.

Anders: De hopp-lenkene, der vil jeg referere til Difi, de har kodeeksempler på dette som du enten finne ved å google det, eller gå på våre episodelenker. Det tar veldig kort tid å kode det. Jeg vil påstå fem minutter, jeg er tidsoptimist, og det er nyttig for mange. Så, gjør det! Og du kan òg gjør det litt mer kreativt. Den vanligste måten å gjøre det er å ha én lenke som sier hopp til hovedinnhold eller hopp til innhold. I komplekse grensesnitt har du flere seksjoner hvor du du vil tilby flere snarveier, og da kan du løse det mer kreativt.

Erling: For du kan ha flere lenker i den der hopp til-greia.

Anders: Ja, du kan ha flere. Da kan du for eksempel si dersom du har en hovedmeny og en produktmeny, i en netthandel. Da vet du at den menyen om oss, retur, betingelser er ikke så mye brukt. Produktmenyen er mer brukt. Da kunne du hatt hopp til produktmeny og hopp til hovedinnhold.

Erling: Hopp til produktinformasjon, hopp til produktomtaler, eller drar en det litt langt da?

Anders: Det blir kanskje en bjørnetjenestene, fordi hensikten med dette kriteriet er å hoppe over gjentagende innhold, og hvis du har for mye innhold i snarveiene, så blir de òg gjendtagende …

Erling: En mer naturlig måte å strukturere det på er å ha produktdetaljer og produktomtaler som headings.

Anders: Ja, fordi dersom du har kodet dette riktig, som alle nå har, fordi dere har hørt episode 3, så har du kodet landemerker, main, du har brukt overskrifter, h-tagger, da har du òg mulighet til å hoppe til innhold. Det er slik for eksempel blinde navigerer seg på en side.

Erling: Som du får høre at Lars gjør i asiden.

Anders: Her har jeg en liten brannfakkel. Vi fikk jo main-elementet i HTML 5, og det er ikke alle som bruker det. Dersom alle hadde brukt det, kunne disse skip-lenkene vært overflødige. For da kunne vi lagt det ansvaret over på nettleserne. Da kunne vi sagt til Chrome, lag en fast hurtigtast for å gå til main og ikke lagt det ansvaret hos produsenter. Jeg har jo den meningen om mye – det som kan standardiseres, bør standardiseres. Kanskje en dårlig sammenligning, men det er ikke vits å ha en printknapp på en nettside, som et eget interaktivt komponent.

Erling: Det er jo en annen brannfakkel du har, som vi ikke skal snakke om.

Anders: Ok, la oss ikke spore av. Bruk landemerker som main og section og disse her. Aside. Og overskrifter. Så har du dekket hoppkriteriet.

Erling: Fokusrekkefølge og sånn og modaler. Hva er ståa der?

Anders: Grunnen til at vi snakker om modaler, det er et godt eksempel hvor man kan feile på fokusrekkefølgen.

Erling: Og hvor mange sannsynligvis feiler òg.

Anders: Ja. Når du åpner en modal, når du har den visuelt åpent, så ønsker du kun å interagere med det som er innenfor modalens rammer. Det vil si at dersom du tabber deg gjennom innhold i modalen, så skal aldri fokuset gå utenfor modalen. Og det skjer ofte. Det vil si at dersom du har en modal med en overskrift, tekst og en knapp, tre komponenter inne i en modal. Når du kommer ned til knappen skal du ikke gå ut av modalen hvis du tabber deg videre.

Erling: Du skal ikke gå til det neste elementet i DOM-en, du skal holde deg i kontekst av modalen.

Anders: Det kan vi se, at plutselig tabber du deg, så kan det se ut som om fokuset forsvinner, men så er det bak på det som er dysset ned i bakgrunnen. Så hvis du bruker modaler, så er det lurt å sjekke hvordan fokusrekkefølgen er.

Erling: Når en da lukker modalen, som en forhåpentligvis har lagt til rette for at en kan gjøre med tastatur, med escape eller en annen måte, så skal du fortsette på elementet i DOM-en som kommer etter modalen. Bra. Og når vi snakker om DOM-en. Én ting er DOM-en, en annen ting er hvordan ting ligger visuelt. Det er et poeng å tenke på. En kan ikke bare belage seg på at DOM-en er i riktig rekkefølge. Den visuelle rekkefølgen betyr òg noe.

Anders: Det skal vi se på på Wikipedia som har prøvd å være litt kreative her. Det skaper litt utfordringer der det ikke er samsvar mellom det vi ser og DOM-en. Når vi sier DOM-en så mener vi koden, kan vi si. Den ferdig renderede koden.

Erling: HTML-en.

Anders: Vet ikke om det gjorde det bedre.

Erling: Hvordan kan vi feile i disse suksesskriteriene.

Anders: Vi har et attributt i HTML som heter tabindex. Det generelle rådet er å ikke bruk det. Når det blir det brukt er ofte intensjonen god, men det feiler fordi det er vanskelig å håndtere. Å ha kontroll på. En mister lett kontroll. Det du kan bruke det til er å markere ting som du ikke ønsker skal ha tastaturfokus, fordi det gir ikke mening. Eller å gi tastaturfokus til et element som ikke har det, fordi det ikke er interaktivt. Da bruker vi 0 og -1 som verdi. -1 for å skjule det. Er ikke det riktig?

Erling: Det vet jeg ikke. Jeg har jobbet lite med tabindex.

Anders: Det kan være jeg blander. Jeg står for det jeg sier, så får vi heller bli irettesatt. Hvis du skal ta noe vekk fra tastaturfokuset, setter du -1. Du kan gi det hvilken verdi du vil. Du kan si at en lenke i footer skal være den første lenken, da sier du tabindex=1. Det vil være forvirrende. Ingen vil hoppe rett til footer.

Erling: Hvis du begynner med tabindex, så prioriterer du det foran alt annet, altså rekkefølgen i DOM-en.

Anders: Og slik det fungerer, så tabber du deg først til de som har tabindex på seg. Så hvis du har to lenker med tabindex, 1 og 10 som verdier, så vil en da tabbe seg til den med 1 først, så den med 10, og til neste interaktive element som ikke har tabindex.

Erling: Neste etter den som har 10, eller neste fra starten av dokumentet?

Anders: Fra starten av dokumentet.

Erling: Da kan det bli mye baddel.

Anders: Når vi bruker vi litt mye tid på tabindex, og det er lite brukt, så la oss gå videre.

Erling: Hvilke verktøy er det som gjelder her?

Anders: Nå skal jeg si at her er tabtasten et viktig verktøy, i den grad du kan kalle det et verktøy. Så nå kjære lytter, nå åpner du et nettsted som du selv eier er ansvarlig for eller har vært med på, eller der du jobber, eller ditt private. Trykk på tab én gang og se hva som skjer. Kommer det opp noen snarveier, så er det bra. Hvis ikke er det ikke bra. Veldig lett å teste. Veldig lett å implementere. Veldig viktig for mange.

Erling: Det er jo typisk når en kjører en evaluering av en side, åpner siden og trykker tab. Hva skjer? Da er det mange som får beskjed om at her skulle du hatt en skip-lenke.

Anders: Et annet verktøy er jo rett og slett å prøve dette med skjermleser. Da kan vi si VoiceOver dersom du har iPhone eller Mac. Hvis du har Windows kan du bruke en gratis skjermleser som heter NVDA. Du kan bruke en innebygget i Windows òg som heter Narrator. Den har jeg tidligere fått beskjed om at vi ikke bør bruke, den er for dårlig. Men i følge vår gjest Lars, så har denne blitt bedre. Når det gjelder title så kan en bare klikke seg gjennom de ulike sidene sine og se om tittelen er bra eller dårlig. Det jeg kan anbefale er å bruke et SEO-verktøy til dette. Mitt foretrukne verktøy er Ahrefs. Du finner lenke til det i episodelenkene. Det går gjennom hele nettstedet ditt og gir deg tilbakemeldinger hvilke sider som mangler, hvilke sider som har duplikater.

Erling: Hvilke sider som mangler?

Anders: Ja, hvis det er noen sider som ikke har innhold i title.

Erling: Ahh, hvilke sider som mangler title!

Anders: Ja, dårlig spesifisert av meg. Hvilke sider som mangler title, hvilke sider som har duplikate title. Det er noe som Google ikke er så glad i, for da blir Google forvirret. Og hvilke sider som for lang title. Da kan jeg si at en title skal ikke være lengre enn ca. 60–70 tegn. Det er fordi Google begrenser det. Hvis du skriver for mye …

Erling: Hvis du bruker for lang tid å komme til poenget i title så vil ikke folk kunne se hva siden din handler om i resultatet.

Anders: Og Ahrefs er et godt verktøy. Ganske dyrt, nå husker jeg ikke om de har en gratisversjon. Det er jo ikke et verktøy bare for å evaluere title, det er et veldig kraftig SEO-verktøy.

Anders: Det var verktøyene.

Erling: Så er det store spørsmålet her. Må du? Bryter du loven? Her har vi en trippel A. Ikke i den forstand.

Anders: Oi, Erling.

Erling: Tok du den?

Anders: Ja, jeg tok den.

Erling: Du måtte tenke i et lite sekund der. Vi har tre suksesskriterier i dag, og vi har tre A-er. Det betyr at hvert suksesskriterie er en enkel A. Dette er forskriftsmessig en no brainer. Er det alt vi trenger å si?

Anders: Ja. Gjør dette.

Erling: I dagens aside har vi en veldig spesiell gjest, og denne gangen er han faktisk fysisk tilstede, i motsetningen til de andre asidene. I dag har vi med oss Lars Bjørndal. Hei Lars.

Lars: Hei hei.

Anders: Hei og velkommen, Lars. Utrolig kjekt å ha deg med. Før vi begynner, i dag har vi laget en slags plan. Men nå klarer jeg ikke å holde meg lengre. Nå kommer jeg med et dumt spørsmål som jeg har lurt på – hvorfor har du på deg klokke?

Lars: Hehehe. Jeg er helt avhengig av å vite hva klokken er? Akkurat den klokken her, hvis vi skal grave oss ned i den, så er den slik at, de fleste blindeklokkene er slik at du åpner glasset på, og så har du tallskive med punkter som du kan ta på med fingen og du har visere du kan ta på med fingen. De punktklokkene er det veldig lett å komme borti og da flytter du på viserne. Det gjør jo ikke vi som er vant til dette. Men den klokken her, når jeg trykker på knappen og fører hånden rundt slik, så vibrerer den på timeviseren, og da vibreren den på minuttviseren. Så dermed vet jeg hva klokken er gjennom vibrasjon. Den kan jeg òg bruke som alarm. Det er jo alarm. Det er jo genialt, for det er jo ingen andre som hører på alarmen, den bare vibrerer på armen.

Erling: Der fikk du den, Anders.

Anders: Wow. Nå har jo du implisitt sagt det, men du er blind. Og jeg har aldri hørt at det finnes blindeklokker. Det er helt åpenbart at det gjør det, men når jeg sitter og ser på deg Lars, så hadde jeg aldri tenkt at det var en blindeklokke. Den ser helt vanlig ut. Det er til og med et vanlig merke, er det ikke det?

Lars: Tissot, ja.

Anders: Så Tissot, de har satset på universell utforming?

Lars: Den lages ikke lengre. Spørsmålet er om de har gått bort fra det igjen.

Erling: De satset på det tidligere.

Anders: OK. Nå må vi bli litt kjent før vi hopper i detaljene.

Lars: Jeg er Lars Bjørndal, jeg er født blind i 1962, så har du alder på meg også.

Anders: Du holder deg godt.

Lars: Takk. Spring mye vet du. Jobber i Statped. Statped er et statlig støttesystem i utdanningssektoren. Driv med spesialpedagogikk. Jeg jobber da med å følge opp elever som er blinde, og en av mine hovedaktiviteter på jobb er å lære lærere til elever som er blinde, hvordan datautstyr kan brukes når du ikke ser. Altså skjermleser på forskjellige plattformer. Og hvordan du kan tilrettelegge opplæringen slik at de som er blinde kan henge på.

Anders: Legger dere føringer på elevene, hvilke utstyr de skal bruke, eller får de fritt spillerom?

Lars: Det er ikke tvil om at i enkelte situasjoner, eller i mange situasjoner, så er PC med anerkjent skjermleser det beste alternativet. Men det er klart at når eleven blir større, når de kommer på videregående, så bruker de det de vil uansett. Da forholder vi oss til det. Men for eksempel, hvis du skal lage en stor oppgave, så kommer du lengst, der du skal ha innholdsfortegnelse, du skal ha overskrifter, du skal kanskje ha attributter som kursivert og fet skrift og sånn, og du skal ha kontroll på dette, så kommer du lengst med Word og PC. Hvis ikke du gjør som meg, jeg er jo litt nerdete, så jeg bruker Linux til veldig mye og bruker da for eksempel ting som Emacs og Org mode. Det er sært da, det er det nesten ingen som gjør.

Anders: Det var en elegang overgang til neste tema, for du er nerd.

Lars: Det vil jeg påstå. Jeg bruker Linux til alt jeg kan bruke det til. Samtidig bruker jeg en del Windows, fordi jeg må bruke litt på jobb. Det er jo det elevene bruker, for å si det slik. Siden overgangen DOS til Windows, så har jeg brukt mye Linux, fordi jeg synes det grafiske grensesnittet er mindre effektivt enn å bruke tekstkonsollet. I tekstkonsollet gjør jeg så mye som mulig, blant annet lese e-post, går mye på nettsider, bruker til og med Facebook fra konsollet fra en nettleser som heter Elinks.

Erling: Hvor godt er Facebook tilpasset?

Lars: Med den løsningen bruker jeg mobilløsningen, altså m.facebook.com, og den kan brukes med tekstbasert nettleser. For hvis du har en artikkel i Dagbladet, så kan jeg fint lese den, bare med å følge lenken.

Erling: Kan jeg spør, for datteren min har Chromebook på skolen, har du erfaring med den?

Lars: Den er nok litt prematur i forhold til skjermlesere. Den har ChromeVox som er en skjermleser, og den har fått nå norsk tale, det hadde den ikke for kort tid siden.

Anders: Du sa Chromewok?

Lars: ChromeVox er skjemleseren til Chrome.

Anders: De bruker ikke TalkBack?

Lars: TalkBack brukes på Android, men ikke Chromebook.

Erling: Da lærte vi det.

Anders: Jeg har lært mye i dag allerede.

Erling: Vi har jo snakket en hel del med Lars på forhånd. Vi må virkelig holde igjen, for her er det mye interessant.

Anders: Det er litt vanskelig å ikke ta helt av, å vite hvor vi skal begynne og stoppe.

Erling: Men du har skrevet en liste?

Anders: Ja, jeg har skrevet en liste. Du har fortalt at du bruker Linux og mange verktøy som jeg ikke har hørt om før, og at du bruker Facebook med Elinks. Det at du bruker mobilversjonen – prøver Facebook å tvinge deg over til desktop-versjonen?

Lars: Nei, Facebook gjør ikke det. De respekterer mitt valg. Ordnett hadde en mobilside tidligere, ordnett.no. Den var fullt tilgjengelig med tekstbaserte verktøy, men så lagde de da en mer moderne versjon som jo er skalerbar. Når du bruker den på mobil, så fungerer det også. Men den siden fungerer nok ikke med tekstbaserte verktøy, dessverre. Oppslag blir …

Erling: For den fungerer ikke i det hele tatt?

Lars: Nei.

Erling: Er det på grunn av JavaScript?

Lars: Ja.

Erling: Det er jo viktig poeng.

Anders: Når vi bruker JavaScript så har vi to valg, nei tre valg – bruke det, ikke bruke det og sist, det som på utenlandsk heter progressive enhancement. Det betyr at vi tilfører funksjonalitet med JavaScript, men at det òg fungerer uten. Slik at du har en tilbakefallsløsning. Har du noen råd her? For vi vet at det er mange JavaScript-utviklere som lytter. Finnes det en tommelfingerregel?

Lars: Altså jeg vet at det er litt kontroversielt å si at, jeg er helt enig at dersom vi bruker JavaScript så bør vi bruke progressive enhancement, men jeg ser at det er JavaScript-biblioteker som brukes, som lever sitt eget liv, som vi ikke har så god kontroll på. Spørsmålet er, kan du kalle noe universelt utformet dersom du har brukt JavaScript på feil måte? Og det er hvertfall en ulempe for meg som bruker det verktøyet jeg gjør. De siste punktene i WCAG går jo på dette med robusthet, der det står at du skal kunne bruke nåværende og fremtidige nettlesere. Og Lynx og disse nettleserne blir jo faktisk utviklet stadig vekk, slik at de vil nok aldri bli en moderne nettleser. Spørsmålet er om alle nettsider burde være mulig å bruke i disse nettleserne? Difi vil nok si at det kan vi ikke kreve. Og det kan jeg forstå, men tenker samtidig, hvis det er mulig, så er det en stor fordel. For det er jo også slik at JavaScript i mange tilfeller kan ødelegge opplevelsen også på vanlige nettlesere, selv om det ikke skjer så ofte i dag som det gjør før.

Erling: Kan vi snu på det og kreve at disse nettleserene burde støtte JavaScript bedre?

Lars: Det de sier når noen spør om dette er at det å implementere DOM, altså Document Object Model, det er ikke realistisk å få til, det er avhengig av det grafiske, så det er tvilsomt om det kommer til å skje.

Erling: Interessant.

Anders: Godt spørsmål, Erling. Tidligere var det slik at ett av argumentene mot å bruke JavaScript, var at Google ikke kunne lese JavaScript.

Erling: Som i søkemotoren.

Anders: Som i søkemotoren. Så hvis du brukte progressive enhancement eller holdt deg borte fra JavaScript, så var du i utgangspunktet mer søkemotorvennlige. Men i nyere tid så har Googlebot lært seg JavaScript. Jeg synes det var godt spørsmål. Kan Lynx og Elinks …

Erling: Finne en løsning i sin ende. Det er ikke svart-hvitt dette.

Anders: Nei, og JavaScript er kommet for å bli.

Lars: Absolutt.

Anders: Vi kan ikke gå tilbake.

Erling: Argumentet er ikke godt nok til å si at ingen skal bruke det.

Anders: Bevisstheten er kanskje det viktigste.

Erling: Vær bevisst på dette med tekstbaserte nettlesere.

Lars: Bare for å si det, det er veldig ofte at vi ser menyer som er lukket i utgangspunktet, når du trykker på dem så åpner de seg, og da er jo konvensjonen heldigvis, og det skjer jo ved hjelp av JavaScript, men da er konvensjonen heldigvis nå at du bruker funksjonaliteten til å skjule ting, men ikke til å vise ting. Slik at du må ikke ha JavaScript for å følge denne menyen, det er bare det at hele menyen vises hele tiden. Og det er helt greit.

Erling: Slik at elementene i menyen er en del av DOM-en når siden lastes, og så bruker en JavaScript til å skjule det. Da er det tilgjengelig for de tekstbaserte nettleserne. Bra innspill.

Anders: Du nevnte Ordnett at du ikke var helt fornøyd med dem, det var vanskelig for deg å slå opp der?

Lars: Med Windows og en grafisk skjermleser går det greit, men i og med at du kunne det tidligere, når de hadde den mobilversjonen sin, og når du plutselig ikke kan lengre fordi de gjør om på nettsiden sin, så kjenner jeg at jeg blir litt småirritert. Det må jeg få lov å si.

Erling: Hvor mange som er helt blinde foretrekker tekstbasert nettleser?

Lars: Jeg vil tippe at vi er kanskje to stykker. Vi er ikke en stor gruppe.

Erling: De fleste bruker skjermleser i et grafisk miljø?

Lars: Helt klart.

Erling: Hvilke fordeler har du av en tekstbasert nettleser?

Lars: Akkurat på nettlesing spesielt, det er kanskje ikke der jeg har den største gevinsten, men på alt som går på dokumentproduksjon, e-post, så er det veldig mye raskere og smidig å ha tekstbasert. Bare det når jeg er i en editor for å redigere en tekst, med tekstbasert verktøy så kjenner du at du har tatt to mellomrom for å starte et avsnitt, hvis du har gjort det, så vil det vise på leselist, jeg vet akkurat at jeg har tatt to mellomrom. I et grafisk miljø, hvis du har tatt to mellomrom, så aner du ikke fordi det er pikselorientert, det er pikselbasert, så skjermleseren forholder seg ikke til mellomrom. For eksempel hvis du skal programmere så har vi jo indentation som vi kaller det på engelsk, veldig viktig, ikke sant. Det er rett og slett mer effektivt.

Erling: Fordi du foretrekker det miljøet i utgangspunktet, så er det enklere å bruke en tekstbasert nettleser, når du først er i det miljøet? Det blir som å skifte fra Linux til Windows fordi du skal lese nyhetene, det blir for nye å be om. Skjønner.

Anders: Har du noen du har lyst å skryte av, som er en fryd for deg å bruke? Apper eller nettsider, tjenester?

Lars: Ruter Billett, det er genialt. Flytoget kjøpte jeg billett på i dag. Begge de to faktisk.

Anders: Nå er det en som sitter og smiler veldig stort. Én av våre faste lyttere som har vært en pådriver for universell utforming av Ruter Billett i flere år.

Erling: Var det han som etter vi tok den om stående eller liggende, som hadde fått gang på støtte for det.

Anders: Ja, vi fikk tilbakemelding fra Ruter Billett at dette har de nå sendt en endring på.

Erling: Da er det greit å gi litt skryt.

Anders: Klapp til dem. Det var gøy. Det var ikke planlagt.

Erling: Ikke i det hele tatt.

Anders: OK. En liten potensiell brannfakkel. Vi har jo sagt at universell utforming ofte forbindes med tilpasning for blinde. Og i en tidligere episode snudde vi litt på det, og sa at blinde er en liten del av den totale gruppen med funksjonsnedsettelser. Hva tenker du når du hører det, Lars?

Lars: Da vil jeg starte med å si at når jeg var liten så tenkte jeg at når alt ble digitalt, det var det jo snakk om når jeg var 10–12–15 år. Da tenkte jeg at når vi begynner å skrive alle avisinnlegg og sånn på tastatur, så kan vi faktisk med teknologien få lest alt dette i stedet for at det kun er på papir. Nå den muligheten kommet, at det er blitt en realitet, at alt i dag er digitalt. Og da er det ille hvis informasjonen lages på en måte som gjør at den ikke er maskinlesbart, og dermed tilgjengelig for meg som blind. Det vil jeg vi si om dette – for vi som er blinde er det fundamentalt, enten får vi lest siden eller får vi ikke lest den i det hele tatt. Enten virker den med skjermleser eller så virker den ikke. Det kan være hele siden eller en innloggingsprosedyre eller et felt du ikke får tak i eller noe sånn. Hvis du ikke får tak i det feltet, så får du heller ikke brukt dette her, slik at det er rett og slett mer slik at dersom det ikke … konsekvensene er så store, at du kan risikere at du ikke får brukt det i hele tatt.

Erling: Det synes jeg var et veldig godt argument. Veldig ofte når vi snakker om funksjonsnedsettelser, så prøver vi å belyse bredden av funksjonsnedsettelser, vi som til vanlig er funksjonsfriske har i visse situasjoner funksjonsnedsettelser. Men når en er blind så er det en enten-eller-greier. Enten får du tilgang til informasjonen eller får du ikke tilgang til informasjonen eller systemet.

Lars: Veldig riktig. Spørsmålet er litt sånn. Ja, vi snakket om forlagsbransjen som må komme med nye læreverk på grunn av ny læreplan som kommer. Det blir veldig spennende. De har nå krav på seg. De ble innlemmet i diskriminerings- og tilgjengelighetsloven i utdanningssektoren, dermed må forlagene forholde seg til at digitale læreressurser skal være universelt utformet. I dag er det faktisk slik at de færreste av plattformene blir brukt, lar seg bruke med skjermlesere. De har kanskje innlest tekst i en bok, men du får ikke tilgang til knappen du skal trykke på for å høre.

Erling: Konsekvensen er stor, for da får en ikke tilgang til, det stopper. Veldig sant. Når dattera får Chromebooken tilbake på mandag, så skal jeg rett inn i disse læreverktøyene og sjekke hvor tilgjengelige de er.

Lars: Det må du gjøre.

Anders: Kanoninteressant. Det er så mye jeg har lyst å spørre om, men nå er det slik at du sitter med noe på fanget som vi må nevne. Du har nå en bærbar PC foran deg, som du sikkert har fått av jobben din. I tillegg har du noe greier så du kanskje har fått har jobben, men som du sikkert har hatt mer innflytelse på. Du har en borrelåsinnretning og noe Reodor Felgen-opplegg her. Du har et bærbart tastatur som du har festet på en leselist. Vi kan jo begynne med å fortelle kort, hva er en leselist.

Lars: Det kalles på engelsk brailledisplay og er ei linje med punktskrift, og når jeg skal lese neste linje, trykker jeg på en knapp, så får jeg lest enten slutten av linjen, hvis det var for kort, eller neste linje hvis linjen var slutt.

Anders: Og punktskrift er slik folk kjenner igjen fra offentlige skilter og heiser og, disse prikkene. Blindeskrift. Og den leselisten, dette skal vi ta bilde av. Der bevegerer det seg, de popper opp og ned, disse prikkene. Eller stavene, punktene.

Lars: De kommer gjennom hull i overflaten.

Anders: Hvorfor trenger du da et helt tradisjonelt, et helt vanlig qwerty-tastatur oppå der igjen?

Lars: Det er mange leselister som ikke har punkttastatur, nå har denne forsåvidt det, så jeg kunne klart meg uten. Jeg synes det er mye mer komfortabelt å skrive på et vanlig tastatur, så det gjør vi. Og dessuten har det piltaster og sånn som et vanlig tastatur har. Da bruker jeg å sette det opp på kanten av leselisten, så det ikke skal bli for lang avstand fra tastaturet, rett og slett mer ergonomisk. Og så bruker jeg borrelås for å holde det fast, slik at jeg kan sitte med det på fange på bussen eller hvor det måtte være.

Anders: Dette er tips til utstyrsprodusentene, få nå en litt mer integrert løsning, slik at avstanden slipper å bli så stor.

Erling: Men leser du fortere på leselisten enn du gjør med en skjermleser?

Lars: Bare for å rydde i begrepene her, skjermleseren er det programmet som forteller talen hva den skal si, og fortell leselisten hva den skal vise. Skjermleser er felles, det er et program som brukes av både leselisten og talen. Så spørsmålet ditt er egentlig om jeg leser raskere med punkt eller tale. Der er svaret helt klart at jeg leser raskere med tale. Likevel så bruker jeg mye punktskrift, særlig på Linux, der bruker jeg bare punktskrift.

Erling: Hvorfor det?

Lars: Egentlig kanskje fordi jeg føler at jeg har mer kontroll. Det er å lese på en annen måte. Jeg føler at jeg …

Erling: Du leser med fingrene, slipper å lytte med ørene, slipper den irriterende stemmen i øret?

Lars: Samtidig ser jeg at dersom jeg skal lese store mengder så er jeg avhengig av tale, så da blir det til at jeg åpner en maskin med et grafisk system og får det lest opp.

Anders: Kan vi som lager løsninger, være trygge på at løsningene fungerer med leselist, så lenge vi tester med en skjermleser, så lenge skjermleseren er kilden til leselisten.

Lars: Ja, men.

Anders: Åh, jeg håpet ikke du skulle komme med et men der.

Lars: Jo, fordi at det er enkelte ganger, jeg har vært borti det på noen læringsplattformer og Sharepoint og sånn, som er slik at du har en lenke og så står det en beskrivelse ved siden av lenken som blir lest av skjermleseren sammen med lenken. Da har jeg sett at dersom jeg bruker pil ned for å lese neste linje, så leser talen men leselisten viser fortsatt den øverste linjen i dette. Så det er ja, men det er ikke alltid at det er kodet på en slik måte at det likevel blir riktig. Jeg vet ikke hvorfor, jeg har ikke sett på koden, jeg vet ikke grunnen til at det blir slik.

Anders: Hvis det er noen som vet det, som hører på, fortell oss. Jeg vet ikke. Å teste med en leselist, det krever av du kan blindeskrift.

Lars: Svaret mitt er grovt ja, det er veldig mye bedre å teste med skjermleser enn å ikke gjør det i det hele tatt.

Anders: Å, takk.

Anders: Men nå er jeg nysgjerrig, du har dette utstyret, vi skal kjøre en liten demo. Vi har valgt å legge oss for hogg, hva heter det? Vi har jo nettsider som tilhører denne podkasten, som heter universeltutformet.no. Så vi har prøvd. Vi har lagt litt energi i det, nå får vi se om vi har lagt nok. Så jeg tenkte at vi skulle gi Lars en liten oppgave. Så får vi da demonstrert hvordan hans oppsett fungerer. Siden vi er et lydbasert medie, må vi bruke skjermleser, det gir ikke så mye mening å bruke leselisten. Så da sier vi litt på sparket her – finn episodelenkene til episode 4.

Lars: Nå står jeg øverst på siden om univesell utforming, så da prøver jeg å trykke h for å komme til en overskrift.

Skjermleser: Podkasten universelt utformet overskriftsnivå 1.

Anders: Da fikk vi opplest at vi hadde en overskrift nivå 1.

Lars: Ja, og det var uu-podkasten.

Anders: Var det en god overskrift.

Lars: Bortsett fra at to store u-er, sier Språkrådet eller noe sånn, at det står for utriket uran eller noe sånn. Så de foreslår at det skal skrives med med små bokstaver.

Anders: Å, der åpner du et tema, jeg tror vi skal hoppe over det. Vi har fått kommentarer på dette òg av Ingeborg som var vår første gjest. Jeg mener vi kan gjøre det. La oss ikke, hehe. Ok.

Lars: Nå tar jeg pil ned, da sa den list of two items. Jeg trykker h én gang til, så ser jeg hvor jeg kommer.

Skjermleser: Hva er det på dette bildet?

Anders: Her har jeg et spørsmål. Fordi jeg la merke til at du fikk opplest med to elementer og så gikk du inn på den første og så sa skjermleseren Spotify og ta tenker jeg, han sa et engelsk ord med norsk aksent. Betyr det at vi har glemt lang-attributtet på den lenken?

Lars: Jeg tenker at det ikke er viktig. Det kan være litt irriterende at den skal hoppe over til engelsk, bare for å si et ord slik, men hvis du hadde hatt en hel side med engelsk tekst, eller en lengre tekst, så burde det stått på engelsk, altså med riktig attributt.

Anders: For det er jo et WCAG-kriterie som heter språk på deler av innhold, og vi prøver å bruke lang-attributtet så mye som mulig, men du sier at det kan være irriterende?

Lars: Ja, for hvis den bare skal si Spotify. Nå husker jeg ikke om jeg bruker språkdetektering, av og til bruker jeg det. For det kan jeg bestemme om skjermleseren skal gå over til det andre språket eller ikke. På Android for eksempel vet jeg ikke om jeg kan gjøre det. Med TalkBack, så der vil den plutselig snakke engelsk. Det er ille hvis det er feil, hvis det er faktisk er norsk, og leser det med engelsk stemme. Det er kjedelig.

Anders: Ok, jeg har avbrutt deg nå, du skal få lov å fortsette.

Lars: Ok, hva er det på dette bildet? Skal vi se.

Skjermleser: Hva er det på dette bildet.

Anders: Det går ganske fort dette, hvilken hastighet har du?

Lars: Det er ganske høy hastighet, jeg er vant til denne talen, så jeg trenger ikke å ha det så langsomt?

Anders: Er vi på 200 %?

Lars: Jeg tørr ikke å si hvor mange prosent? Det varierer. Disse tallene sier ikke så mye. Ganske mye raskere enn du ville gjort.

Erling: Kan jeg få skru opp lyden på den maskinen din?

Lars: Absolutt. Vet du hvordan du gjør det? Fn og F3 tenker jeg.

Skjermleser: Overskrift nivå 2 lenke trykk på rundingen til venstre.

Lars: Der ja.

Skjermleser: 3 2 1 3 2 3 3 2 4

Anders: Der så jeg en tydelig svakhet.

Erling: Få høre.

Lars: Nå er jeg spent.

Anders: Her var det vanskelig å høre at det dreide seg om tre ulike suksesskriterier, fordi det kommer ni tall på rappen, så skjermleseren leser opp de ni tallene, og det er helt umulig å tyde at det er tre grupperinger av tall, selv om det står komma mellom, så stoppet ikke skjermleseren opp på det kommaet.

Lars: Jeg vil si at dette er et skjermleserproblem og ikke et designproblem.

Anders: Takk!

Erling: Vi flyter fortsatt.

Lars: Jeg er helt enig med deg. Men hvis designeren begynner å lage, gjør noen krumspring for at skjermleseren skal lese dette riktig så blir det feil på andre måter, så jeg ville tenkt at her er det skjermleseren som dummer seg ut, for å si det sånn.

Anders: Takk, takk.

Lars: Da tror jeg at jeg er på episode fire.

Anders: Du sier du tror?

Lars: Ja, fordi jeg trykket bare h mange nok ganger til at jeg talte fire. Jeg ser ikke akkurat om det står episode 4 her, så jeg prøver å gå inn på lenken.

Erling: For du har en antagelse om rekkefølgen?

Lars: Ja, jeg har antatt at første episode er først, men jeg kan jo ta feil.

Anders: Nå kan jeg røpe at du har helt rett, men visuelt sett så er det veldig tydelig at det er episode fire. Her har designeren av denne siden har valgt at det viktigste elementet i boksen vi ser på nå er fire, og det fikk ikke du i din skjermleser.

Lars: Hvor står det, står det under overskriften?

Anders: Visuelt sett står det til høyre.

Lars: Da kan jeg prøve å ta pilen ned, så skal jeg se hva som skjer.

Skjermleser: Lenken episoden handler om å ha logisk rekkefølge på innhold og ikke referere til karakteristikker som plassering og farge tredje juni 2019. 34 minutter. Article én. Blank. Article.

Lars: Skal vi se, kan det være over overskriften?

Skjermleser: Lenke fire. Article.

Anders: Lenke fire ja. Den burde jo hatt tittel. Title-attributt episode fire. I designet for seende vil jeg si det gir mening at det kun står fire. Det er veldig tydelig at det er snakk om episode fire. Men når du fikk den på skjermleseren, hadde det vært et title-attributt som heter episde fire, så hadde det vært mye tydeligere.

Lars: Nå trykker jeg på den. Jeg skulle finne lenkene, ikke sant.

Skjermleser: 3 2 1 3 2 3 3 2 4. Til høyre, liste.

Lars: Hvor er jeg nå? Fordi når jeg trykker på lenken er jeg nå usikker på hvor skjermleseren havner når vi kommer inn på den siden her. Og det har ikke noe med deres design å gjøre, det er jeg litt usikker på at den havner et sted mitt på siden og noen ganger øverst, men sånn er det.

Anders: Det kan vi overstyre. Det handler om fokushåndtering. I moderne nettsider, når vi lager sånn fullstendige JavaScript-sider, så da må vi definere hvor fokuset skal være etter en sidelastning som ikke er en sidelastning.

Erling: Som er én av de tingene du får gratis hvis du ikke belager deg på JavaScript i bunn.

Lars: Han sa main region og han sa artikkel, så jeg vet at jeg er i nærheten av noe bra her, holdt jeg på å si.

Anders: Tampen brenner.

Skjermleser: Overskrift nivå to, WCAG.

Lars: Ja, så står det overskriften. Så nå vet jeg ikke hvor jeg skal finne dem. Jeg trykker h, for jeg regner med at dere har satt en overskrift på lenkelisten eller lenkene som hører til episoden. Jeg prøver det. Nei, det gjorde jeg ikke.

Anders: Hva skjedde?

Lars: Det som skjedde nå er at jeg trykket h. Da kom den ned til spill av på itunes, og så trykket jeg en gang til og da gikk den til toppen fordi da fant vi ikke flere overskriften, da spratt den opp. Så nå kom jeg helt til toppen, til overskrift én. Så nå trykker jeg h igjen. Nei, da får jeg trykke tabb, og se om jeg kommer til den lista da.

Erling: Går det et lite sukk i deg nå? Jeg skulle ha kunne navigere med h? Er det det du defaulter deg til når du skal navigere på en side?

Lars: Det er nok det. Jeg bruker veldig mye overskrifter og ofte så stemmer det. Veldig ofte blir det riktig. Vi kunne også tenkt at det var en region eller noe annet. Men i og at jeg ikke har vært inne på denne siden med Windows og Chrome før, så vet jeg ikke hvordan dette er satt opp.

Anders: Her får vi virkelig tydeliggjort viktigheten av semantisk kode, som vi snakket om i episode tre. Marker overskrifter som overskrifter.

Erling: Og viktigheten av overskrifter. Altså som orienteringselement.

Lars: Nettopp, det kan du si. Samtidig vil vi jo at en overskrift faktisk skal være en overskrift for alle, ikke bare for oss som bruker skjermleser. Så hvis dere ikke mener at det skal være en overskrift der, så synes ikke jeg at dere skal bruke elementet til det. Da burde dere heller bruke noe annet.

Erling: Det var godt du sa, for nå gravde jeg med ned i dette overskriftsgreiene.

Anders: Men jeg mener at på denne siden er det helt naturlig òg for seende at episodelenker er en overskrift. Nå røpte jeg at det heter episodelenker for deg som har en oppgave å gjøre. Men her kom det en ny forbedring.

Erling: Hvis du fullfører oppgavene, så kan jeg kommentere hvordan vi har kodet det opp.

Lars: La meg fullføre oppgaven først. Nå trykker jeg tabb, da kommer jeg til spill av på itunes.

Skjermleser: Spotify lenke. Tekstversjon, sammentrukket.

Lars: Tekstversjon og den er sammentrukket, det er fint, for da vet jeg at jeg slipper å forholde meg til det. Nå tar jeg pil ned.

Anders: Her vil jeg si at den var sammentrukket, det er fordi vi har brukt aria-expanded på den. Det er ikke noe du får gratis. Hvis du skal lage en trekkspillmeny, så må du til med aria for at det skal være bra for en skjermleser.

Lars: Men det har dere gjort, det er fint. Så tar jeg pil ned.

Skjermleser: Detaljer knapp article én.

Anders: Nå har vi gitt deg en lureoppgave her.

Lars: Jeg vet ikke hvor disse er.

Anders: For de finnes ikke.

Lars: Akkurat.

Anders: Det var bare en glipp, det var litt dårlig forberedelse. Så da …

Lars: Skal jeg gå tilbake til nyere episoder da kanskje?

Anders: Ja. Du kan gå til, jeg tror dette er den eneste vi har uten episodelenker.

Lars: Hva sa du? Skal jeg prøve den da? Da trykker jeg h for å komme til … og så tar jeg tabb. Nå trykker jeg tabb fort fordi jeg vet at Spotify og iTunes og dette her …

Anders: Det har du nå lært deg.

Lars: Og tekstversjon sammentrukket, og nå tar jeg pil ned.

Skjermleser: Episodelenker, sammentrukket.

Lars: Ja! Da sa han episodelenker sammentrukket. Yes. Så det er en sånn expandable greie det ja.

Erling: Og det jeg kan røpe der er at du nevnte aria, men det vi faktisk har gjort er å bruke et HTML-element som heter details, med summary under. Vi har ikke brukt aria. Det er en ren HTML-kode. Det var bra at det faktisk fungerte. Den oppdaget jeg litt tilfeldig, for jeg har ikke hørt om den før.

Anders: Kan du gjenta den, det er en HTML-tagg som heter?

Erling: Details. Og innholdet, det som blir sammentrukket er summary. Da får du treffspilleffekten gratis. Jeg tror ikke støtten er 100 % i alle nettlesere, men så godt som.

Lars: I en tekstbasert nettleser så vil disse lenkene vises uansett?

Erling: Nettopp, fordi det er en del av DOM-en.

Anders: De ligger der hele tiden.

Lars: Hvis jeg trykker mellomrom på denne.

Skjermleser: List of four items.

Lars: Her var det fire stykker. Ja, sier bare punkt.

Skjermleser: Lenkepunkt.

Anders: Oi.

Lars: Hvorfor gjør den det? Her er det noe rart.

Anders: Her er det rusk.

Lars: Han har skilt på en måte lenkene og punktet. Og det lurer på om kan være fordi dere har, hvordan det er kodet, det burde vært slik at … Hvordan burde det være? Punktet hører jo ikke til lenken. Jeg synes det er rart at skjermleseren …

Anders: Det virker som om vi har feil nøsting.

Erling: Nå sjekker jeg opp på direkten.

Lars: Work in progress.

Erling: Sånn det er kodet, så er det UL, så er det LI med start og slutt og så er det en a inni der.

Anders: Det er sånn det skal være.

Lars: Da er det bare skjermleseren som vil vise meg at det er et punkt og det er ikke en del av lenken, så derfor leser den først punktet. På leselisten så vises det på samme linjen. Jeg tenker at vi sier at det er fint, jeg.

Erling: Når du sier det, så ser jeg at du bruker leselisten samtidig. Nesten som om du dobbelsjekker.

Lars: Jeg hører en del. Jeg kunne klart meg uten leselist, men det er veldig fint å kunne lese, og dobbelsjekke og ofte så leser jeg kun begynnelsen av linjen med tale, så stopper jeg talen med kontroll og fortsetter med leselisten nedover, ikke sant.

Erling: Jeg lurer på om jeg kan sammenligne med når jeg ser på film, så liker jeg å ha undertekster på, selv om jeg forstår hva de sier. Det er lettere å tilegne seg informasjon, når jeg leser i tillegg til å høre det.

Anders: Ok, så du fant episodelenkene. Og hadde vi ikke gitt deg en lureoppgave så hadde vi fått godkjent. Men vi fant to forbedringspunkter, så dette var en veldig nyttig øvelse.

Erling: Konge.

Anders: Jeg er fornøyd. Jeg har 100 flere spørsmål. Jeg tror vi skal runde av.

Erling: Det må vi.

Anders: Jeg vet at du Lars har en middagsavtale som vi ikke skal ødelegge ved å stille deg nye spørsmål.

Lars: Glad for det.

Anders: Har dere noe dere har lyst å nevne på tampen?

Erling: Vi har snakket om spinnoffs, og nå vet jeg ikke hvor lenge vi snakket før vi gikk i gang her, men vi måtte stoppe oss selv, så jeg tror en spinnoff, en Lars-spesial i tre deler, det kan fort bli aktuelt hvis Lars har lyst å komme tilbake igjen.

Anders: Det lå godt i munnen det, Lars-spesial.

Erling: La oss lage det.

Lars: Det hørtes veldig artig ut, la oss gjøre det. Jeg er ikke på Stavanger-kantene hver dag, men det hender av og til, og så har vi jo nettet, så det går ann å få til noe der.

Anders: Hva er din foretrukne tjeneste til å kommunisere over nettet med tale?

Lars: Selv bruker jeg mye mobilen, på jobben har vi noe som heter Cisco Meeting, og det synes jeg fungerer fint. Fungerer i Chrome og Skype for Business hvis du bruker den. Ja, så. Jeg har òg brukt den på Linux, i grafisk miljø selvfølgelig.

Anders: OK, Lars, igjen, tusen takk for at du kom. Jeg har lært mye i dag. Og jeg er veldig glad for at du tok kontakt, og for at du stilte opp. Veldig sporty.

Lars: Jeg må få si at jeg synes det er så fantastisk med disse podkastene, det må jeg få lov å si, veldig hyggelig at dere tok kontakt. Jeg er også veldig glad for det, jeg har lært mye, det har vært utrolig artig.

Anders: Sjøl takk. Jeg er en tøff gutt, men nå rødmer jeg.

Erling: Glimrende. Takk skal du ha!

Erling: Det var så sykt kjekt, nå har jeg faktisk frysninger. Det å treffe Lars, en høydar. Det er kanskje litt av grunnen til at jeg er på en 9 av 10. Det var så kjekt. Jeg merker det når jeg forteller det til familien min, å fortelle hvordan han kontroll på omgivelsene, han hadde kaffekoppen på bordet, og da han tok opp maskinen et kvarter senere, og fortsatt visste hvor kaffekoppen stod, det var så gøy å se.

Anders: Ja, men jeg ble òg overrasket, for når vi skulle gå ut visste han ikke hvor skoene stod.

Erling: Nei, jeg trodde det, og han kunne late som, han kjente et par med sko og spurte om det var hans sko. Veldig kult. I dagens ris og ros er litt inspirert av Lars, med kunnskaps, hva kalte du det. Oppslagsverk. Fortell litt om hva vi har gått gjennom.

Anders: Vi har sett litt på Store norske leksikon og litt på ordboken til Språkrådet og UiB, litt på Wikipedia. Og NDLA som kanskje ikke alle kjenner til. Og der jeg begynte, med Store norske leksikon, der tenkte jeg at de har kontroll på alt. De er flinke digitalt. Jeg vet at de gjør mye riktig. Så ble jeg litt overrasket, fordi de hadde ikke disse hopp over-lenkene. Det er litt ris, men det kan godt være at det er bevisst. Det har jeg lyst å si, fordi deres grensesnitt er jo veldig enkelt, de baserer seg i veldig stor grad på et stort søkefelt, som er helt naturlig for et leksikon. Og det er veldig få gjentagende element. Men de har jo logoen sin, og de har søkefeltet sitt, som en da potensielt sett må høre gjennom hver gang en følger en lenke. Så de kunne hatt det. Til deres forsvar, så bruker de main, de bruker disse landemerkene som òg er mulig å bruke som hopp. Men de har eksplisitt disse lenkene.

Erling: Og en kunne kanskje argumentert med at tiden det tar å prosessere skip til-lenkene er lenger enn å bare hoppe forbi logo og søkefelt, før en kommer til main, altså innholdet.

Anders: Men så har de òg en brødsmulesti som ligger mellom hovedoverskriften og hovedinnholdet, og den har òg ganske mange nivåer, så den må du òg høre på, potensielt sett hver gang. Jeg tenker at jeg ville nok flyttet brødsmulestien før overskriften, som egentlig er den vanlige måten å gjøre det på, og hatt hopp til-lenker for å slippe den, og gått rett til første overskrift. Men her kjenner jeg at jeg ikke vil være veldig bastant.

Erling: Her ville det vært interessant å fått Lars til å prøve, og høre hva han synes.

Anders: Det hadde det. Bittelitt ris til Store norske leksikon, men vi skal òg ta de frem igjen i ros-spalten.

Erling: Hvem andre?

Anders: Ordbok fra Språkrådet og UiB, de mangler titler.

Erling: Som i sidetitler?

Anders: Jeg sa jo det at det er veldig få som feiler, og her letet jeg ganske lenge etter å finne noen som feiler. I denne ordboken så kan en diskutere hvor utstrakt bruk av titler de skal ha. Og med det mener jeg at hvis du i ordboken søker etter Sandnes, så får du jo et treff. Nei, Sandnes var dårlig, det er jo et egennavn. Hvis en søker etter tannkost.

Erling: Et bedre eksempel.

Anders: Så har de et treff på tannkost. Og da tenker jeg at det kunne stått tannkost i title. Det gjør det ikke.

Erling: Nå er jeg spent.

Anders: Jeg vet ikke hvor viktig det er, fordi du, ehm. Hvis vi tenker på SEO, så vil jo ikke de ha treff på søk etter tannkost.

Erling: Hvorfor ikke? Hva med søkefrasen tannkost definisjon?

Anders: Den ville de gjerne hatt treff på. Jo, ok, jeg kjøper den.

Erling: Da er det greit at title i søkeresultatet er definisjonen av tannkost eller noe annet.

Anders: Det kan godt være at det er bevisst dette, men de har heller ikke title på innholdssider. Som på hjelpesidene sine, så har de heller ikke title.

Erling: Har de ikke, eller er det den samme overalt?

Anders: Det var bra at du spurte om. Det er den samme overalt. Det står Bokmålsordboka | Nynorskordboka på alle sider. Så det vil si at dersom du har hjelpesiden oppe og søkesiden oppe i to ulike faner, og du har flere faner, så ser de helt like ut.

Erling: Da er det vanskelig å navigere.

Anders: Det er jo det vi snakker om i dag. Så en liten ris til ordbok fra Språkrådet og UiB, et samarbeidsprosjekt.

Erling: Flere?

Anders: Så er det litt ris til Wikipedia, og det er litt farlig fordi at det er ris som kan være bevisst fra deres side. Det går på fokusrekkefølge. Her har de gjort et grep i HTML-en, så her bommer de både på fokusrekkefølgen og koderekkefølgen. De har et kolonnedesign, Wikipedia har en venstrekonlonne, de har en midtkolonne og en høyrekolonne. De har mange maler, men i mange av malene er dette strukturen. Og venstre kolonne ligger etter midtkolonnen i DOM-en. Og de har en venstrekolonne som er absolutt posisjonert, som i et uu-perspektiv alltid kan være litt farlig. Men det som skjer da, når du begynner å tabbe, så tabber du deg i midtkolonnen først, som jo er den viktigste. Så det gir jo på én måte mening, men det er ikke det du forventer det.

Erling: Og skal jeg gjette, så er dette i forbindelse med responsiv design, altså når du åpner en Wikipediasiden så skal du slippe å bla forbi hele navigasjonen i venstremenyen før du kommer til innholdet.

Anders: Det kan godt være.

Erling: Vi vet ikke.

Anders: Men det er hvertfall en ulogisk fokusrekkefølge at du når du er ferdig med midtkolonne, så hopper du til venstrekolonne.

Erling: Enig. Basert på det lille vi har snakket om nå, vi snakker jo bare, vi ser det ikke, så høres dette ut som om de kunne ha løst dette på en bedre måte.

Anders: En Wikipedia-side har jo veldig mange lenker. Og i og med det at selv om fokusrekkeølgen er unaturlig, fordi den ikke følger det visuelle designer, så har de jo en veldig kreativ bruk av hopp over-lenker som vi kan hoppe rett til i rosen. Det som skjer på Wikipedia, hvis vi åpner den norske Wikipedia. Nå er jeg på forsiden. La meg gå inn på en artikkel om skogbrann. Nå har jeg åpnet Wikpedia, jeg er på en side om skogbrann. Det første tabbe, dette er òg egentlig brudd på fokusrekkefølgen, fordi den første tabben min tar meg rett til søkefeltet. Og søkefeltet er ganske lite borte i høyre hjørne, det er ikke der jeg forventer at den første visuelle fokusen skal være, jeg forventer at det skal skje i øvre venstre del av siden. Men, når det er sagt så er jo dette en avveining. Fordi Wikipedia ser sikkert på statistikken sin, på loggen, at x antall prosent, sikkert skyhøyt, av de som kommer inn på en Wikipedia-siden, starter med å gjøre et søk. Det er jo en veldig kort vei til den viktigste brukeroppgaven.

Erling: Hvis du som blind går inn på Wikipedia ofte, for å søke frem til, så er det nok veldig behagelig å gå inn, trykk tabb, skriv inn og enter.

Anders: Da er vi litt tilbake til at det er brukertester som skal bestemme hvor fokusrekkefølgen skal være, det er ikke nødvendigvis WCAG.

Erling: Men jeg så òg på Store norske leksikon at når du åpner siden så hadde søkefeltet fokus, du kunne begynne å skrive rett i søkefeltet. Jeg vet ikke om det teknisk sett hadde fokus da, eller om du kan skrive i et felt som ikke har fokus.

Anders: Nei, du kan ikke skrive i et felt som ikke har fokus.

Erling: Bra. Det får fokus med én gang, du trenger ikke å tabbe til det engang. Hva synes du om det forresten?

Anders: Det gir spesielt mening på forsiden, men ikke så mye på en artikkelside. For artikkelside har kommet til fordi du ønsker å lese artikkelen.

Erling: De har ikke automatisk fokus i søkefeltet på en artikkelside.

Anders: Det er derfor jeg ikke har fanget opp dette, for jeg har jo nå testet en artikkelside, på Store norske leksikon.

Erling: Da er jeg med på notene.

Anders: Det er det jeg mener, Store norske leksikon, de har et bevisst forhold til dette. Vi setter automatisk fokus i søkefeltet på forsiden fordi 99,9 % av alle som kommer til våre forside skal ikke lese om historien til Store norske leksikon, de skal søke etter noe. Vi er på Wikipedia. Første tabb er visuelt sett rar, men ut ifra en brukeroppgave, og det er jo brukerne som er de viktiste her, det er ikke WCAG.

Erling: Fuck WCAG.

Anders: Så gir det mening. Og dette har de nok løst, tror jeg, med tabindex. Det kunne vi ha sett på. Neste er et pluss-ikon, som jeg ikke vet hva er for noe. Det er òg helt i høyre, så jeg forventer ikke at det er det neste fokuspunktet mitt. Så jeg er usikker på hva det pluss-tegnet er.

Erling: Nysgjerrig på om en skjermleser hadde lest opp noe.

Anders: Det hadde det nok.

Erling: Hva sier title-attributtet.

Anders: Det sier at dette er en anbefalt artikkel. Det forvirrer meg, for pluss, når det er fokuserbart og interaktivt, så tolker jeg det som om at jeg kan legge til noe her eller åpner noe. Dette er altså en indikator at det er en anbefalt artikkel, og det bør ikke vær prioritert. Hvis du klikker på det, så kommer du inn på en side om anbefalte artikkel, du kommer ikke inn på Wikipedia sine anbefalte artikler, du kommer inn på en side som forklarer hva anbefalte artikler er, at det er et prosjekt. Dette er så sekundært, så tertiært, det er så uviktig for meg som som skal lese om skogbrann.

Erling: Snodig.

Anders: Vi er jo inne på ros nå, og dette ble en ris.

Erling: Hva var det egentlig vi skulle rose her?

Anders: Vi skulle rose dem for kreativ bruk av hurtiglenker. Så hvis ikke dette hadde vært en anbefalt artikkel, hadde vi gått rett fra søkefeltet til hopp til navigering. De har snudd på det, de gjør det andre veien.

Erling: Interessant.

Anders: Det er jo bevisst, og forhåpentligvis med brukeren i fokus.

Erling: De har ikke implementert skip lenker blindt, de har ikke brukt den vanlige måten, de har snudd på det.

Anders: For alle som vil navigere på siden, de kan hoppe til navigering. De har òg gjort det som du var inne på, de har ikke bare én lenke i skip.

Erling: Nå ser jeg kun hopp til navigering.

Anders: Jeg kan òg nevne at de bruker to visuelle indikatorer for å vise at noe er i fokus, de bruker nettleserstandarden, som i mitt tilfelle er en blå kantlinjen og de bruker understrek på lenken. Og så har de òg hopp til søk, som òg er naturlig.

Erling: Nå tabbet du igjen. På samme linjen endret det seg til hopp til søk.

Anders: Og så videre, hoppet jeg til bildet som er til høyre i artikkelen, og heller ikke det er naturlig fokusrekkefølge. Dette er tydelig, nå ligger bildet før hovedinnholdet i DOM-en, i koden. De har sikkert hatt en float right på bildet, en CSS-egenskap. Da får det bildet fokus før første lenke i teksten, som er unaturlig for meg som tastaturbruker.

Erling: Det bryter med den visuelle rekkefølgen av elementene.

Anders: Jeg vil si at når Wikipedia har disse to skip-linkene sine, så bør de få ros for det, for de har løst på en bevisst kreativ måte. Så det var egentlig det. Og så vil jeg òg ta frem NDLA, som òg er et viktig oppslagsverk.

Erling: Hva er det, det har jeg aldri hørt om.

Anders: Det er skolenes svar på Wikipedia. Eller på leksikon. Det vil si at det er en enorm innholdsbase skrevet for elever, så det er knyttet opp til ulike linjer på videregående skoler. Du kan lese en artikkel om noe, så står det at den tilhører VK2 matte nivå 2.

Erling: Kult. Det hadde ikke vi i min tid.

Anders: Så NDLA, et vanvittig bra verktøy.

Erling: Nasjonalt Digitalt Læringsarena står det for.

Anders: Hvis vi ser her på NDLA, som en liten notis, så har jeg jobbet litt med NDLA tidligere, gjør det ikke nå lengre, jeg har ikke behov for å si det er bra. Jeg er ikke ansvarlig for noe av dette.

Erling: Du kan ikke ta æren for det.

Anders: Men jeg liker initiativet. Nå var jeg på forsiden, og det er ikke den jeg har testet. Dette er bra! Her har de ikke skip link, fordi det gir ikke mening på forsiden, det er jo egentlig ikke noe hovedinnhold. Hovedinnholdet er jo navigasjonen.

Erling: De har ikke bare klistret på alle templatesene sine, de har bevisst ikke implementert det på forsiden.

Anders: Hvis jeg går inn på naturfag, der vil jeg lære om ernæring og helse. Nå er jeg inne på emneside om ernæring og helse. Jeg trykker på tabb, og det kommer opp en stor, blå knapp, midt på skjermen som sier hopp til innhold, som gjør at jeg hopper forbi meny, jeg hopper forbi søkefeltet, jeg hopper forbi logo, jeg hopper forbi brødsmulestien slik som Store norske leksikon ikke gjorde, eller de har jo ikke skip-lenker. Dette er bra av NDLA. De har det der en trenger det. En trenger det ikke på forsiden, for der er hovedinnhold navigasjon. Hovedinnholdet er søkefeltet, det er unaturlig å hoppe forbi der.

Erling: Jeg må bare kommentere noe som forvirret meg, for jeg var inne på, en total avsporing, dette går mer på konvensjoner, inne på forskerspiren, en emnesiden, jeg skal gå tilbake til forsiden, jeg gikk opp i venstre hjørne. Hmm, hvordan går jeg tilbake til forsiden. Trykket på meny, nei ingenting der. Så har de lagt logoen helt til høyre. Det forvirret meg. Det går jo på konvensjonen om at logoen og hjemlenken skal være oppe til venstre. En lite rompeklaps til NDLA på å bryte den konvensjonen.

Anders: Så kan vi òg nevne at NDLA, Store norske leksikon og Wikipedia, alle disse gjør det riktig med title. Eller titler. Det er vanskelig å finne noen som bommer der. De finnes. Det er en av fallgruvene med å bruke SPA, Single Page Application. Hvis du ikke er bevisst på unike titler per side, så kan det gå i glemmeboken.

Erling: Og tabindex gå i feller.

Anders: Helt riktig.

Erling: Veldig, veldig bra Anders. Bra episode!

Anders: Det er håndfast, men òg litt rom for tolkning her og der. Men mer håndfast enn mye annet.

Erling: Og alt er enkel A, så bare gjør det. Hvis lytteren skal ta med seg tre ting fra dagens episode?

Anders: Lag disse hopp til innhold. Det er enkelt og det hjelper de som trenger det. Google og andre vil digge deg hvis du har gode titler per side. Prøv så sant det lar seg gjøre å la DOM-en ha samme rekkefølge som det visuelle designet, så får du fokusrekkefølgen gratis.

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

Anders: Det blir mer navigasjon. Vi skal snakke om noe som kanskje er, kontroversielt er en overdrivelse, men lenketekster som les mer, klikk her og så videre. Og at ikke alle liker å finne innhold på samme måte, så det bør være flere måter å navigere seg på, flere veier til Rom bør du ha.

Erling: Spennende. Gleder meg. Og som vanlig, vi får fortsatt gode tilbakemeldinger og innspill. Vi får mye skryt, ikke så mye ris.

Anders: Nå har vi fått litt sånn ris.

Erling: Det er noen som har utfordret det vi har sagt.

Anders: Ja, jeg har lyst til det.

Erling: Vi setter jo umåtelig stor pris på det.

Anders: I én episode nevnte jeg at du ikke skal tenke på at du skal koble tastatur til en mobil. Det var dårlig formulert. Poenget mitt var at på akkurat det suksesskriteriet som vi snakket om, så gjaldt det tastaturbruk på desktop.

Erling: Det du kunne har sagt, som denne lytter presiserte, hva var det?

Anders: At veldig mange kobler til tastatur til mobil. Han har helt rett, og han henviste til en veldig fin undersøkelse fra WebAIM, det er et viktig hjelpemiddel for for eksempel blinde, som òg bruker touchtelefon og ikke må bruke tastatur, men kan bruke det som et ekstra hjelpemiddel.

Erling: De kan foretrekke det.

Anders: Og det kan jeg godt si, at når en blind bruker mobil, å ta i mot informasjon fungerer bra, navigasjon og finne frem, men å gi input å skrive med et skjermtastatur, det er et mareritt. Så derfor, hvis du bare skal surfe rundt og lese artikler på Store norske leksikon, så trenger du ikke tastatur. Skal du skrive en e-post, så er det veldig nyttig.

Erling: Takk for kommentaren.

Anders: Nå er det litt flaut, for vi nevner ikke navnet, og jeg husker det ikke.

Erling: Det er takk til Nicklas Svendsrud. Der fikk du kredden òg, Nicklas. Han er da front-end-utvikler i Inmeta.

Anders: Som en liten kudos til ham, så er han òg uu-sertifisert og vi har startet en liten dialog om det. Veldig kjekt at folk blir engasjert.

Erling: Arrester oss gjerne masse, Nicklas. Og dere andre, måten dere kan arrestere oss på eller rose oss på, det er å sende en e-post til hei@universeltutformet.no. Og så liker vi det veldig godt når folk legger igjen stjerner og kommentarer på iTunes. Det var dagens episode. Jeg er Erling, ikke fra Webstep, men fra Okse. Og du er Anders?

Anders: Og jeg er fra Webstep, ikke Okse. Hade!