UU-podcasten:Universelt utformet

Introduksjon

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: Anders, er du klar?

Anders: Jeg er klar.

Erling: Episode 21. I dag skal vi snakke om noe som treffer oss veldig ofte, tørr jeg påstå. Hva skal vi snakke om i dag?

Anders: Feil feil feil.

Erling: Feilmeldinger spesifikt i skjema, stemmer det?

Anders: Det stemmer. Ikke tekniske feilmeldinger. Skjemafeil.

Erling: Skjemafeil. Og spesifikt, hvilke suksesskriterier og retningslinjer og prinsipp snakker vi om i dag?

Anders: Vi er på 3.3. Den første treern er forståelig. At vi skal klare å forstå det vi holder på med. Og den andre treern, altså retningslinje 3, der har vi tatt Difi sin oversettelse som heter «Inndatahjelp». Og inndata er altså det du skriver i et felt. De to suksesskriteriene vi skal ha i det, det handler om identifikasjon av feil, altså å vise hvor det skjer en feil, av de feilene oppdages automatisk, og forklare feilen. 3.3.3 er forslag ved feil. Altså, hva skal brukeren gjøre når han får en feilmelding.

Erling: Dette må jeg jo si er noe som meg og deg er veldig opptatt av.

Anders: Ja.

Erling: Og har jobbet mye med. Og rådgitt mye på.

Anders: Og samtidig står det ganske dårlig til i den store verden. Folk er dårlige på skjemadesign.

Erling: De er det. I dagens aside, hva skal vi snakke om da?

Anders: Da skal vi snakke om et filosofisk konsept som heter veil of ignorance.

Erling: Et tankeeksperiment.

Anders: Som vi lærte denne uken, vi var begge på et foredrag.

Erling: En sint amerikaner.

Anders: Som heter Mike Monteiro. Vi skal snakke litt om hva vi lærte der, som er veldig overførbart til universell utforming.

Erling: Absolutt. Og i dagens ris og ros. Det er mye rising i dag.

Anders: I dag er det rising. Det er lydboktjenestene.

Erling: Det er litt kult, fordi lydboktjenester leverer en tjeneste som gjør bøker mer tilgjengelig.

Anders: Og de er òg det som vi kaller digitalt innfødte, de startet digitalt, de har ikke nødvendigvis så mye morro.

Erling: Det er mye grums forstår jeg.

Anders: Overraskende mye.

Hvorfor?

Erling: Jeg får begynne med hvorfor. Hvorfor har vi disse suksesskriteriene?

Anders: Vi har dem fordi vi skal tenke på blinde og svaksynte. Hvis du har for eksempel en blind, og det oppstår en feilsituasjon, der den blinde ikke får beskjed om det, så har ikke den noen mulighet for å gå videre.

Erling: Da feiler den blinde.

Anders: Ja. Òg svaksynte som bruker skjermleser, så vil det samme bli et problem.

Erling: Andre?

Anders: Dette med kognitive utfordringer, du skal prøve å gjøre det så brukervennlig som mulig. Ikke gjør det vanskelig å forstå hvordan et skjema skal brukes, og når det feiler, gjør det så lett som mulig å korrigere den feilen.

Erling: Det er snakk om tydelighet. Vær tydelig på hva som skjedde, hva du må gjøre. Andre?

Anders: Litt under den kognitive paraplyen, så har vi jo lese- og lærevansker. Det går jo på dersom det er dårlig forklart, hva er det som har skjedd, så får folk problemer, hvis vi ikke klarer å forstå meningen med det. En viktige gruppe er de som har motoriske utfordringer, som bruker lengre tid. Hvis det er vanskelig å rette feil, og du må prøve og feil mange ganger, så er det mer frustrerende for de som bruker lengre tid. For noen episoder siden så møtte vi han Christopher Hills. Når du har én knapp, ingen mus, og du skal opp og ned, og skrive og endre på flere skjemafelter, så …

Erling: Da er det veldig greit at når det oppstår en feil så får du beskjed om hvilke feil som har blitt gjort.

Anders: Men dette er jo kriterier som er direkte overførbare til god brukervennlighet. Gode prinsipper for skjemadesign.

Erling: Dette treffer veldig, veldig mange. Alle som bruker skjemaer treffer dette.

Anders: Her er det 100 % overlapp med god brukervennlighet. Dette gjør du for å tilfredstille alle.

Erling: Hvis du løser disse suksesskriteriene godt, så lager du mye bedre skjemaer.

Hvem?

Erling: Hva med produsenter, hvem må tenke på dette?

Anders: Designere og kodere.

Erling: Hvordan må designere tenke på dette?

Anders: De må tenke på hvordan feilmeldinger skal fremstilles, hvor de skal legge seg, hvordan de skal se ut, hvilken farge de skal ha. Hvilke ekstra identifikasjon de skal ha, annet enn farge og tekst. Om du skal ha en varseltrekant eller utropstegn.

Erling: Og så sier du kodere?

Anders: Ja, for du bør legge inn noen kodesnutter som knytter en feilmelding opp mot et spesifikt skjemaelement. Der kan vi si at egentlig handler denne identifikasjon av feil, det er egentlig et suksesskriterie for det visuelle, men det vil være dumt å ikke inkludere kodere her òg. Der gjør Difi en god jobb. De to hjelpesakene til Difi om skjemadesign og feilhåndtering, er gode. Så hvis du er usikker på dette, så er det gode ressurser.

Erling: Og Difi er generelt flinke på mye av dette, så vi kan anbefale dem varmt. Innholdsprodusenter?

Anders: Ja, hvertfall de innholdsprodusenter som har et skjemaverktøy. I dag er det slik at noen skjemaer kodes fra A til Å, og noen har et skjemabyggeverktøy inne i publiseringsløsningen sin. Hvis du har det, og du har påvirksningskraft på feil og valideringene, så har du et ansvar.

Erling: Og jeg tror at innholdsprodusenter er i en posisjon hvor de kan påvirke ganske mye. For gode feilmeldinger, forståelige feilmeldinger, er viktig her. Og innholdsprodusenter forstår gjerne det.

Anders: Men de ligger jo ofte nede i et kodelag.

Erling: Men kanskje en burde involvert en tekstforfatter eller noe, når en skriver disse feilmeldingene, for å få dem best mulig. Og så har vi en ny kategori i dag.

Anders: Hvis du har gode skjemaer og god feilhåndtering, så blir datakvaliteten bedre. Designere og kodere bryr seg kanskje ikke så mye om datakvalitet. Men de som eier produktene, eller skal viderebehandle det som kommer inn, de er glad i at ting stemmer.

Hvordan?

Erling: Hvordan kan vi lage gode feilmeldinger?

Anders: Først må vi si at det beste er jo å unngå feil.

Erling: Når du sier det, er det opplagt. Prøv å unngå feil. Men feil oppstår. Hvordan skal vi håndtere dem?

Anders: Vi skal markere, vise visuelt, hvilke felt som feiler.

Erling: Hvis vi tar en rød border rundt, er det greit da?

Anders: Nei. Det treffer både denne og én av de tidlige kriteriene vi hadde, at du kan ikke bare la farge alene forklare en mening. Så kun å endre farge på kantlinjen til rød, er ikke godt nok. Men det er fint å bruke rød. Rød farge er bra for feilmeldinger.

Erling: Det er en sterk indikator på at noe er galt.

Anders: Men bare gjør noe mer. For eksempel uttropstegn. Varseltrekant.

Erling: Hva er det vanligste mønsteret her? Eller det beste mønsteret, er kanskje bedre å stille?

Anders: Jeg synes utropstegn er fint. Du skjønner at det er noe. Det er en sterk konvensjon i trafikken.

Erling: Tenker du tre ting da. Rød kantlinje, tekst under og varseltrekant.

Anders: Ja. Og varseltrekanten kan godt stå i forbindelse med teksten. Og teksten står ofte på rød bakgrunn, eller er teksten rød i selv. Begge de to er fine.

Erling: Bare vært obs på kontrast.

Anders: Det kommer vi tilbake til. Kontrast. I tillegg bør du markere feltet med feil i koden. Og én måte å gjøre det på, det er å ta det som en del av ledeteksten, altså labelen i skjemaet.

Erling: Dette må du forklare litt tydeligere. Hva mener du med markeres i koden?

Anders: At du knytter …

Erling: Element og feilmelding i sammen? Er det det du mener?

Anders: At feilmeldingen har en programmatisk tilknytning til det feltet som feiler. For bare det at det står under, det er ikke nødvendigvis godt nok. Hvis det står under, og du i tillegg har god fokushåndtering, at du putter fokus til feilmelding, så vet du jo ikke om feilmeldingen hører til skjemafeltet før eller etter, så du må i tillegg knytte det programmatisk til, på samme måte som du knytter en label til et inputfelt, som vi har snakket om tidligere, med for og id, så må du knytte en feilmelding til et skjemafelt.

Erling: Og denne er satt i parantes?

Anders: Ja. Nå tenkte jeg at feilmeldingen stod i parantes. I juksenotatene vår, så står dette i parantes.

Erling: Hvorfor?

Anders: Hvis du tolker 3.3.1 bokstavlig, så trenger du ikke å gjøre dette programmatisk, men hvis du tenker på brukerene dine, så gjør du det.

Erling: Videre?

Anders: Vi er fortsatt på teknikker. Det vi skal gjøre er å være spesifikk per feilmelding. Ikke bare dette feltet feilet, dette feltet feilet, dette feltet feilet. Men en skal være løsningsorienterte, og du skal gi kundene/brukerne dine en hjelpende hånd. Og du skal ha gjør det per feil. Og der er det slik at dersom du bruker riktig inputtype, og du lar nettleseren håndtere valideringen av feilene, så vil da nettleserne ha gode feilmeldinger, de vil gjøre det som du sa nå. Hvis du prøver å skrive inn en e-postadresse uten krøllalfa i Chrome, så får du beskjed om det, du må ha en krøllalfa her. Det leder oss inn til neste punkt, dette med, dette med konkrete korrigeringer. Det er ikke presist nok å si at feltet er obligatorisk. Da er det bedre å si at du må oppgi e-postadresse slik at vi kan kontakte deg. Intensjonen med …

Erling: Jeg skulle til å spørre om det. Er det bra å ha intensjonen i feilmeldingene?

Anders: Ja.

Erling: Det kan være at de utelater det fordi de ikke ønsker å gi det fra seg.

Anders: Ja, så da øker du forståelsen og motivasjonen.

Erling: Bra.

Anders: To fluer i én smekk. En annen teknikk er å ikke være så hard på hva du akseptere av input, men òg vaske data som kommer inn, slik at det blir riktig i bakhånd. Men å være tilgivende på det som skrives inn. For eksempel hvis du skal skrive inn fornavn, og brukeren skriver inn fornavn med liten forbokstavn, så vasker du det i bakhånd, i stedet for å skrive en feilmelding som sier at vi foretrekker i våre systemer å ha navn med stor forbokstav. Og så er det noen navn som skal ha liten forbokstav, slik som Anders von Håmsø. Da er det av og til liten v der. Det er veldig fint å lage smarte løsninger på innskrivingsfelter. Den type vasking kan òg hjelpe hvis du bruker dataen til andre oppslag, API-oppslag (programmeringsgrensesnitt), for eksempel hvis du skriver inn en adresse, og du skriver inn 2B uten mellomrom, og du skal bruke den adressen til å gjøre et kartoppslag, og du vet at det API-et, det forventer et mellomrom mellom 2 og B, at du tar den vaskejobben i stedet for å gi en feilmelding til brukerne.

Erling: Ja, å be de om å vaske sine egen data. Unngå det.

Anders: Vask, vask.

Erling: Men er det nok å si at dette feltet har feilet?

Anders: Nei.

Erling: Er det noe mer vi må gjøre.

Anders: Ja, vi bør ha en liste over alle felter som feiler før skjemaet.

Erling: En oversikt.

Anders: Det som er en god praksis er å liste ut dette, dette, dette feltet feilet. Spesielt viktig på mer kompliserte skjemaløsninger. Slik at brukeren kan danne seg et mentalt bilde av hvor mye arbeid som gjenstår. Og så er det veldig fint, dersom du i den listen lager lenker, altså ankerlenker rett ned til de respektive feltene, slik at det er bare å hoppe.

Erling: Selvfølgelig. Det har jeg ikke tenkt på før. Det gir veldig god mening.

Anders: Det er noe jeg vet han godeste Luke Wroblewski, han har jo skrevet en egen bok om skjemadesign. Uten å bli gammel nå, men mange av prinsippene står seg fortsatt.

Erling: Jeg føler at mange av anbefalingene vi har nå, er de samme vi hadde for 10–15 år siden.

Anders: Ja. Det er lite som har endret seg, derfor er det dumt at så mange er dårlige på det.

Erling: Det er så mye som er skjemabasert.

Anders: En innlogging er et skjema.

Erling: En utsjekk i en nettbutikk, det er skjema.

Anders: I aller høyeste grad.

Erling: Et ganske komplisert skjema.

Anders: Alt det offentlige, Nav-ditt, Altinn-datt. Det er mye skjema.

Erling: Videre, det er flere ting, vi har en lang liste med teknikker.

Anders: Når det oppstår en feilsituasjon, så må du skrive hvilke obligatoriske felter som ikke er fyllt ut. Ganske åpenbart, men ikke alle som følger det. Så har vi litt kodeteknikker. I en feilsituasjon så kan du bruke aria-invalid, satt til true. På selve feilmeldingene bør vi bruke aria-live, slik at de faktisk leses opp skjermleseren.

Erling: Angående aria-invalid erlik true, hva er det det hjelper med? Hva fører det til?

Anders: Det hjelper dersom du har en skjermleser som kan liste ut alle feltene som har en feil, for eksempel hvis en da ikke har den listen som vi akkurat anbefalte at du skal ha.

Erling: Fordi HTML mangler en måte å indikere at felt har feilet. Det passer kanskje ikke inn i HTML-ens natur, å ha det?

Anders: Har ikke tenkt på det.

Erling: Derfor kommer aria inn og hjelper med denne aria-invalid, slik at skjermleseren kan liste de ut. Gjør de det?

Anders: Støtten for det har jeg ikke peiling på.

Erling: Så lurte jeg på aria-live, litt det samme, hva fører den til?

Anders: Den leser innholdet selv om det ikke har fokus. Så hvis du har dårlig fokushåndtering, og det plutselig oppstår en tekstoppdatering en annen plass enn der brukeren har fokus …

Erling: Dette er veldig relevant i disse one page application, single page application-tidene, hvor en validerer skjemaene på frontenden, så er dette veldig relevant.

Anders: Veldig relevant. Så hvis det skjer noe i grensesnittet som er vekke fra der brukeren er, teknisk sett …

Erling: Hvis skjemaet som feiler er utenfor der du er, spesielt hvis du bruker en skjermleser, hvis du ikke ser det feltet som feiler, så vil du ikke få noe indikasjon på at det er en feil, når du trykker send, som i praksis validerer frontenden.

Anders: Du kan sette fokusen til feilmeldingen eller du kan òg ha aria-live.

Erling: Kult.

Anders: Så hvis du feilmeldingene lastes dynamisk, så er det spesielt viktig, at du bruker aria-live. Har du mer om den liven?

Erling: Nei, jeg skulle si at vi har enda flere. Dette må være rekord på teknikker.

Anders: En skal unngå å bruke modaler til feilmeldinger.

Erling: Hvorfor det?

Anders: Fordi en ønsker alltid å gjøre en visuell tilknytning mellom en feilmelding og der feilen skjer, og det får du ikke nødvendigvis til med en modal. I tillegg er det generelt mange fallgruver med å bruke modaler.

Erling: Du vil kanskje at den listen med alle feilene skal være der mens folk fikser feil, ikke at den forsvinner når du lukker modalen. Og så sier du fallgruver?

Anders: Ja, det er for eksempel lett å havne i en tastaturfelle med modaler.

Erling: Modaler i seg selv er et lite uu-helvete, hvis du ikke gjør det rett.

Anders: Men det går an å gjøre det rett.

Erling: Definitivt. Men da må de som implementere dem, være bevisst på en del av disse suksesskriteriene.

Anders: Men her er det ingen grunn å gjøre det her. Modaler bruker du hvis du er rett for at brukeren skal forsvinne fra den konteksten han er i. Her ønsker du at brukeren skal forbli i den konteksten, du vil ikke ha et lag på toppen her, du vil at brukeren skal være nede i grøten.

Erling: Hva med når du har fyllt ut et skjema, du har fyllt ut mye, så trykker du på send. Og så skjer det en feil, og så fjerner den alt. Er det bra?

Anders: Nei. Da må du gjøre alt på ny.

Erling: Det er en teknikk, ikke fjern alt det andre.

Anders: La det gyldige bli værende.

Erling: Der kan jeg se for meg at i innlogging, så kan dette feile. Du trykker på innlogging, så feiler du på det, alle feiler på det hele tiden, så nullstiller de brukernavn for eksempel, som jo er dumt.

Anders: Ja, det som er enda mer vanlig, som ikke er relatert til dette, er at hvis du har prøvd å logge inn tre ganger, og trykker glemt passord, så kommer du inn i et nytt skjermbilde hvor du skal skrive inne e-postadressen din, og den e-postadressen har du akkurat skrevet inn tre ganger, så må du skrive den inn på ny. At den ikke klarer å huske det fra forrige steg.

Erling: Det er så irriterende. Jeg blir så sint. Unødvendig sint.

Anders: Det er litt i samme gate.

Erling: Men når vi har forklart dette?

Anders: Gi beskjed og være overtydelig på at brukeren har klart å gjennomføre oppgaven sin.

Erling: Nå funket det, må du gi beskjed om.

Anders: Din bestilling er sendt. To tomler opp. Vi det. Vis et stort smil, vis en dansende pingvin.

Erling: Konfetti. Fyrverkeri. Hele pakken. Men når du logger inn da?

Anders: Der er det mer omdiskuert. Der vil jeg si at nå konvensjonen er at du blir sendt rett til der du skulle.

Erling: Jeg støtter den, det blir snodig dersom du skal legge et lag i mellom der. Gratulerer du klarte å logge inn, klikk her for å komme deg der du egentlig ville.

Anders: Det er på ingen måte vanlig, men det er vanlig når du nullstiller passord, ditt passord er nå nullstilt. Jippi. Og så blir du overlatt til deg selv. Hva nå? Hvorfor er du ikke bare automatisk innlogget? Vi kan ha en egen innloggingsepisode, Erling, når den tid kommer.

Erling: Hvis du ikke kan vaske?

Anders: Da kan vi prøve å være smarte. Det vi har lyst å vaske, men ikke får til. Så hvis du i et felt, hvis du skal taste inn måned, og du skriver d e s, og du egentlig skulle skrive 12, så kan vi si «Mente du 12?» i stedet for å si ugyldig verdi.

Erling: Skriver du det i feilmeldingen da?

Anders: Ja.

Erling: Så du foreslår hva de skal skrive inn?

Anders: Ja. Her skjedde det en liten feil, det er jo en feilmelding.

Erling: Det er en hjelpende feilmelding. Du sier jo at det du skrev ikke aksepteres. Men kanskje du mente … Ja. Og hva med aria-required?

Anders: Der er det kanskje litt kjøtt på flesk, fordi vi har et HTML-attributt som er required. Der er jeg usikker på om vi trenger det, om HTML-attributtet er godt nok. Men det er nå skrevet som en teknikk da.

Erling: Det kan være at det henger igjen fra pre HTML 5. Sannsynligvis ikke nødvendig.

Anders: Med prøver oss på og si at du skal bruke required-attributtet og hold deg til det.

Verktøy

Erling: Det var langt. Det var mange teknikker. Hva med verktøy?

Anders: Før vi går videre med verktøy må jeg si at vi har egentlig blandet litt beste praksis og normative teknikker for disse suksesskriteriene, men det er litt vanskelig å holde dem strengt adskilt, spesielt i denne, vil jeg si. Vi har nå gitt gode teknikker for god feilhåndtering, men det er ikke nødvendigvis at alle er knyttet til 3.3.1 og 3.3.3. Så en liten unnskyldning der.

Erling: God feilhåndtering i skjema er kjempeviktig, så hvis du sitter som designer, utvikler, produkteier eller innholdsprodusent, les deg litt opp på dette. For det er gode beste praksiser på det. Så var det verktøy.

Anders: Der er det jo bare å prøve. Prøv deg frem, send inn, se om du forstår det. Test med skjermleser. Gir det mening der? Klarer du å sende inn et skjema med skjermleser?

Erling: Brukertest på folk med funksjonsnedsettelser. Og uten.

Anders: Har du et viktig skjema i løsningen din, og vi skal på viktig skjema i ris og ros i dag, så brukertester du dem.

Erling: De vi skal rise i dag hadde oppdaget enormt mistenker jeg, hvis de hadde giddet å brukerteste.

Andre situasjoner

Erling: Andre situasjoner der dette er bra?

Anders: Det blir å gjenta det vi sa tidligere. Dette er god brukervennlighet.

Erling: Det har veldig mye med brukervennlighet å gjøre.

Anders: Og da har det òg med, det forferdelig vanskelige ordet, konverteringsrateoptimalisering.

Erling: Hvis vi ikke substansifiserer det, kan vi si optimalisering av konverteringsraten. Blir litt kortere, men likevel lange, vanskelige ord. Hvor mange som klarer å fullfører du vil de skal gjøre? Den raten kan du forbedre med å ha god håndtering av feilmeldinger.

Må du?

Erling: Må du? Bryter du loven?

Anders: I dag må du dette. Dette er enkel og dobbel A.

Erling: Så du må vise hvor feilen har oppstått og gi en tekstbeskrivelse av den feilen. Og du må gi forslag ved feil om hvordan folk kan rette denne feilen. Det må du gjøre. Hvis du ikke gjør det, så bryter du loven.

Aside

Erling: Så til dagens filosofiske hjørne, til dagens aside. Vi skal snakke om veil of ignorance. Kjør Anders.

Anders: Hvor skal vi begynne? Vi kan begynne med å si vi ikke skal snakke om albumet til det svenske band Raised Fist, de har et album, et album jeg liker veldig godt. Det er ikke det vi skal snakke om.

Erling: Vi kan sikkert snakke om det òg, men ikke i uu-kontekst.

Anders: Vi skal snakke om et eldgammelt filosofisk prinsipp fra 1700-tallet som ble brukt av noen av de store, viktige filosofene da.

Erling: Jeg så at Immanuel Kant var inni der en plass. Kan du ikke bare si hva det er?

Anders: Jo. Det er når du lager noe, når du designer noe, en løsning, så skal du ta valg ut ifra at du kan havne på andre siden av bordet.

Erling: Nettopp. Du kan være brukeren av systemet.

Anders: Vi skal se litt større på det. Vi har vært på et veldig fint foredrag, av Mike Monteiro, som snakket om dette. Han brukte Mexicomuren som et eksempel.

Erling: Trump sin build the wall.

Anders: Hvis du lager den skal du lage den ut ifra at du ikke vet hvilken side av muren du selv havner på.

Erling: Du vet ikke hvilken aktør i det du designer, du blir.

Anders: Og i Mexicomuren er det opplagt, at du ikke kan designe den.

Erling: Du vil ikke havne på feil side.

Anders: Og i kontekst av uu så synes jeg denne tanken her er veldig fin. Og det er at du kan ikke ignorere ulike brukergrupper, hvis du ikke kan akseptere den ignoransen, dersom du blir en del av den gruppen selv.

Erling: Nettopp. Og du sa det så fint. Hvis du skal ta et valg, og gjøre noe tilgjengelig for blinde, så kan du spørre deg selv, hvis jeg hadde blitt blind i morgen, hadde jeg syntes det var greit at vi ikke gjorde dette.

Anders: Og av og til tror jeg faktisk at svaret på det spørsmålet er ja. Ok, greit, jeg forstår det. Men i mange tilfeller her så vil jo svaret på spørsmålet nei, det kan ikke jeg stå inne for. Og der har vi som designere.

Erling: Utviklere, produsenter.

Anders: I vid forstand, design er å lage løsninger som løser problemer.

Erling: Skape noe med intensjon.

Anders: Vi har da et ansvar, lager vi noe vi ikke kan stå inne for, dersom vi havner på andre siden av bordet. Dersom vi blir kunden/brukeren innenfor en gitt målgruppe i morgen, kan jeg stå inne for det? Ja, kjør på.

Erling: Og som du sier, det kan være situasjoner hvor det kan være greit, det er ikke kritisk.

Anders: Grunnen til at jeg vil snakke om dette er fordi jeg har havnet i en del problemstillinger i det siste, der jeg siste, der dette tankesettet, dette prinsippet, hjelper veldig på problemløsning.

Ris og ros

Erling: Vi kan nesten stryke over ros i dag?

Anders: Vi vet ikke. I dag har vi gjort noe nytt. Vi skal snakke om lydboktjenester. Vi har forberedt oss på to, så skal vi ta den tredje på direkten, uten forberedelse.

Erling: Oi, det gleder jeg meg til.

Storytel

Anders: Og vi begynner med, vi har jo avslørt at vi har så vært imponerte, men Storytel, de er på hogget. De er ute og markedsfører seg mye. Jeg liker godt kampanjene deres.

Erling: De har jeg ikke sett.

Anders: Når du skal bli kunde av Storytel, så har de en opprett bruker, nå er du på Fabel Erling. Vi snakker om Storytel. Det er den tjenesten som har en oransje snakkeboble. De har en knapp som er første knapp i menyen, som er bli abonnent.

Erling: Vi trykker på den.

Anders: De har et skjema, og det er jo skjema vi snakker om i dag. De har et skjema som heter opprett konto. De har et skjema i to steg. Det synes jeg de skal få lov til.

Erling: De indikerer at det er to steg, de viser hva brukeren kan forvente, så det er fint.

Anders: De har seks felter i steg én. Da skal jeg forklare de seks feltene først, dere som sitter på bussen nå har ikke nødvendigvis plukket opp Storytel, så vi prøver å gjøre dette litt radiovennlig. E-postadresse står som en placeholdertekst med utrolig lav kontrast. Her er det så mye feil, at det er vanskelig å holde oss til dagens suksesskriterier. Fordi nei, du skal ikke gjøre det.

Erling: Men det ser jo fint ut?

Anders: Nei, for det er vanskelig å lese. Og når du begynner å skrive, så forsvinner teksten, og hvis du har dårlig korttidshukommelse, så glemmer du kanskje hva du skal skrive.

Erling: For å oppsummere, det er ikke label, men de har placeholder som erstatning for label. Og placeholderteksten har alt for dårlig kontrast.

Anders: Og ingen visuell fokus. Utenom den blinkende markøren.

Erling: Hva heter det? Glem det, gå videre.

Anders: Neste felt er bekreft e-postadressen. Nei! Jeg vil ikke bekrefte e-postadressen.

Erling: Vet vi det?

Anders: Ja.

Erling: Bra. Hva om de skriver feil i det første.

Anders: Ja, du er gira på å komme raskt i mål, så du skriver kanskje feil i første og så kopierer du den adressen du har skrevet og limer inn i neste, så er du like langt. Dette er ingen garanti for at de får bra datakvalitet.

Erling: Og hvis du skriver rett i første og bommer på alfakrøllen i andre, så feiler feltet hvis de har god feilhåndtering. Vi konkluderer, ikke ha bekreft e-post. Neste.

Anders: Passord. Det er forsåvidt greit det. Bekreft passord. Nei. Hvis du driter deg ut, og skriver et passord som du ikke husker, så bruker du glemt passord-funksjonen i etterkant. Du trenger ikke å be alle som registrerer seg til denne tjenesten om å skrive passord to ganger. Og nå har jo jeg blitt en, nå beveger vi oss vekk fra dagens kriterier.

Erling: La oss kose oss litt med misnøyen.

Anders: Det var fire felter som burde være to.

Erling: For det eneste de ber om er e-postadresse og ønsket passord.

Anders: Og tenk hvis du har vært flink og har et veldig vanskelig passord, så må du skrive det to ganger, og hvis du har motoriske utfordringer. Christopher Hills.

Erling: Skamdrid.

Anders: Og så havner vi rett i to sjekkbokser, og dette er en påstand, dette er et dark pattern. Det de gjør her.

Erling: Jeg har ikke sett på dem, så nå er jeg spent.

Anders: Den ene må du hake av for å fortsette og den andre er et samtykke til markedsføring fra Story og Storytels samarbeidspartnere. Og grunnen til at jeg mener at dette er et dark pattern, er fordi her går folk på autopilot, du vet at i slutten av skjemaer, der skal du hake av ting, hvis du ikke haker av ting, så kommer du ikke videre, så her får de samtykker uten at folk vet at de har gitt samtykke.

Erling: Det er et teknisk samtykke, ikke et faktisk samtykke. De sier egentlig egentlig ikke ja.

Anders: Juridisk så står dette seg.

Erling: Dessverre. Jeg har hatt lyst å utfordre jussen på det. Tror ikke det kommer på toppen av listen.

Anders: Her ville jeg, helt klart, fjernet sjekkboksen på den første, den som heter vilkår. Jeg ville hatt en tekst som sa «ved å sende inn dette skjemaet, aksepterer du Storytels vilkår.» Det er implisitt, og det holder vann juridisk, sist gang jeg sjekket. Riktignok lenge siden. En annen fordel er at, og nå hopper jeg nedi nerdegryta, en annen fordel er at det er lettere å lenke til vilkårene, fordi at det er ikke akseptert å ha en a inne i en label. Fordi hva klikker du da på? Klikker du da på labelen eller a-en? Det de har gjort her, siden du ikke har lov å ha en a i en label, så er det ikke en label. De har to sjekkboksen. Den med vilkår og lenker i, det er ikke en label, de har bare … det ser helt likt ut men de har helt forskjellig HTML bak.

Erling: Interessant.

Anders: Her bryter de òg 1.3.1, fordi de bruker ikke riktig HTML-elementer. Og så ser du at det er jo bare en span rundt vilkår og personvern. Her har de to sjekkbokser. Jeg ville hatt en overskrift over samtykke, som heter «Samtykke til markedsføring», for å kort forklare hva det dreiser seg om. At det ikke er en bekreft vilkår-boks. Den teksten deres er lang, så vi vet at ingen leser den.

Erling: De leser kanskje det aller første, skummer det første.

Anders: Ja, «jeg vil gjerne at Storytel sender meg personlige anbefalinger» bla bla bla. Men så kommer det på én, to, tre, fire, femte linje, samarbeidspartnere.

Erling: Og jeg lurer jo veldig på hvem disse samarbeidspartnerne er.

Anders: Ja, og de skriver ikke hvem de er.

Erling: Nei.

Anders: Og jeg vil jo ikke at de sender ut e-postadressen min til masse samarbeidspartnere.

Erling: Det kan ikke være helt lovlig? Det jeg tenker, for disse har to steg. Ideelt sett burde de ikke hatt den sjekkboksen for samtykke til markedsføring på dette steget i det hele tatt. Her bør de fokusere på at folk skal få opprettet konto på enklest mulig måte.

Anders: Ja, ikke stikk kjepper i hjulene mine.

Erling: Ikke be om mer enn du burde, her.

Anders: Men så kan vi stille oss spørrende til, burde et samtykke ligge på neste steg, som handler om betaling? Kanskje ikke?

Erling: Jeg vet ikke hva som er neste steg.

Anders: Vi har enda ikke snakket om feilmeldinger. Siste da. Knappen. Dette har jeg aldri sett før, Erling. Det de har gjort i knappen. De har puttet teksten i knappen, utenform button-elementet.

Erling: Hæ?

Anders: De har brukt button-elementet som aksepterer en tekstverdi, og så har de CSSa seg ut av det på en helt tullete måte. Jeg forstår ikke hva de har holdt på med.

Erling: What?

Anders: De har et tomt button-element, uten noe indikasjon på hva knappen skal gjøre. Og under der, så har de en opprett konto. De har stylet diven rundt til å se ut som en button, og så har de en tom button inne som har en klasse som heter button hidden. Og vet du hva, jeg forstår ingenting.

Erling: Dette var veldig rart.

Anders: Dette kan jeg si til Storytel. Design og kode er gjort som ikke vet hva de holder på med. Det er ikke ofte jeg er så hard.

Erling: Du pleier jo å være litt sånn, tenk om og hvis … men jeg er helt hjertens enig. Her er det mye inkompetanse.

Anders: Her ville jeg hatt pengene mine tilbake.

Erling: Her måtte de ha opprettet sak. Dette er totalt. I alle dager. Det må være en feil.

Anders: Men vi er stygge nå.

Erling: Nei, vi er ikke stygge. Vi er konkrete og gir oppriktige tilbakemeldinger.

Anders: Du har nå prøvd å sende inn et skjema, der feltene ikke er fyllt ut. Og det som skjer er at, det første vi ser, for oss som er seende nå, er at ikke feilmeldingene ser like ut. Den ene er mye bredere enn den andre, og hopper utenfor. Det er litt teit av oss å nevne, for det er bare en feil, en glipp.

Erling: Den påvirker nok ikke muligheten til folk, altså.

Anders: Nå har du åpnet koden for vilkår, og der ser du at det er div div, det er strong. Hvorfor er det strong? Jeg vet ikke. Men det er ikke noe label her.

Erling: Nei.

Anders: De har selvfølgelig, de bommer på alt de kan bomme på. De har ikke god nok kontrast i feilmeldingene sine. De har en rødoransje bakgrunn og hvit tekst. Den er ikke programmatisk knyttet til feltet. Den har ikke noe aria-live på seg. Kanskje ikke forventet, men de har andre aria-attributter her og der, så de har prøvd på noe.

Erling: Havner de i den gruppen med folk som har aria og feiler mer enn de som ikke har aria?

Anders: Ja, nå har jeg ikke sett på effekten av de ariaene de har, så det skal jeg ikke påstå. Så var det noen h4-er inni der.

Erling: Jeg må bare kommentere at de inputfeltene der oppe, ligger ikke inne i en form. Formen kommer først her nede, rundt de to sjekkboksene, og så kommer knappen utenfor formen igjen. Her er det en ekstrem mangel på semantikk.

Anders: Det er ikke flere former da?

Erling: Det var det jeg så etter, jeg skummet bare over. Ingen form, ingen form, ingen form her. Masse inputfelt, de flyter i løse luften, semantisk sett. Av en grunn har de en form rundt vilkårene, og så kommer knappen hvor teksten er utenfor. Jeg forstår ingenting. Igjen, nå er vi utenfor.

Erling: Det vi skal gjøre nå, Anders, hva er det?

Anders: Nå skal vi være blinde litt, det gjelder deg og, altså deg som på andre siden av radioapparatet.

Erling: Det er jo her podkastformatet kommer virkelig til sin rett.

Anders: Vi skal jo veldig lyst å høre alle lydbøkene til Storytel, vi skal bli kunde, bli abonnent, opprette en konto. Vi har kommet oss inn til rett skjema, og tabber oss til første skjemafelt. Da skruer du på Nora.

Skjermleser: Voiceover på Safari. Lydbøker og bøker på mobilen. Vindu e-postadresse tom. Redigerbar tekst har tastaturfokus.

Anders: E-postadresse, vi stod i rett felt. Da kan du skrive inn en adresse feil med overlegg.

Skjermleser: F. E-postadresse.

Anders: Ja, tabber oss videre.

Skjermleser: Bekreft e-postadressen. Tom. Redigerbar tekst.

Anders: Så kan vi skrive inn noe annet der.

Skjermleser: F. Bekreft e-postadressen.

Anders: Ja, neste.

Skjermleser: Fire objekter. Safari. Password for this website.

Anders: Det som skjedde nå var at Safari foreslår å sette inn et sterkt passord til oss.

Erling: Som egentlig er en veldig fin funksjon.

Anders: Veldig fin funksjon. Hvis folk bruker den, det vet jeg ikke, da er jeg òg helt unødvendig med gjenta/bekreft passord-felt.

Erling: Her må jeg nevne at den fyllte ut begge feltene, som jo er bra ting. Det betyr at noe rett har blitt gjort. Vi trykker på at vi ikke skal bruke den.

Skjermleser: Password. Passord. Passord.

Anders: Passord, da kan du skrive noe der. Ja, og bekreft passord.

Skjermleser: Bekreft.

Erling: Da skriver jeg det samme, slik at det … ja.

Anders: Og så tabber du videre.

Skjermleser: Jeg godtar Storytels vilkår om personvern. Ikke markert. Jeg godtar Storytels vilkår om personvern.

Erling: Da leste den det etterpå, selv om det ikke var en label.

Anders: Ja.

Skjermleser: Marker jeg godtar Storytels vilkår om personvern. Tikkboks.

Anders: Det gjorde den.

Erling: Tabbe?

Anders: Ja, men ta den vekk igjen.

Skjermleser: Opphev markering. Jeg godtar Storytels vilkår om personvern. Tikkboks.

Erling: Nå er jeg spent på om vi kommer til de lenkene, eller om vi kommer til neste felt.

Anders: Men de er ikke lenker, så du kommer til … jeg trenger ikke å røpe det. Så med tastatur nå, så har ikke vi å lese vilkårene.

Erling: Vi klarer ikke å lese det vi skal akseptere.

Anders: Og hvis du hadde åpnet rotoren nå, og åpnet en lenke liste, så hadde ikke de dukket opp. Så vi kan vite hva vi nå aksepterer.

Erling: Det er ingen måte vi kan gjøre det på, som blinde?

Anders: Kunne kanskje ha søkt oss frem til dem.

Erling: Da måtte vi jo vite at de finnes. Og jeg vet ikke om vi hadde klart med tastaturet å få tak i dem.

Anders: Drit i.

Erling: Da går vi videre til neste. Skal vi se.

Anders: Nå byttet skjermleseren stemme.

Erling: Og leste med engelsk aksent. Hva har skjedd nå? Skal vi inspekte, eller gå videre?

Anders: Min hovedhypotese er at de har et lang-attributt på labelen, men jeg tror ikke det.

Erling: Det skal sies at vi har jobbet litt med skjema og skjermlesere i det siste, og oppdaget litt merkelig oppførsel i Safari.

Anders: Det har kanskje litt med at du har engelsk i OS-et ditt. Men jeg har litt lyst å se om det er noe rart i koden.

Erling: Jeg kjører en inspekt på den for å se. Jeg ser ingenting.

Anders: Ikke jeg heller. Jeg vet ikke hvorfor det skjer.

Erling: Nei.

Anders: Men, vi er klare til å sende inn.

Skjermleser: Button.

Anders: Yes, button! Så det er en button her. Og vi som ser, ser at det står opprett konto, men det vet ikke du som hører på.

Erling: Det er ingen fokus-styling.

Anders: Ingenting. Vi vet ikke hva vi gjør. Men prøv å trykk på den.

Erling: Kan jeg prøve noe annet først. Jeg vil trykke tab én gang til.

Skjermleser: Button.

Anders: Yes. Button button. Vi har to button og vi vet ikke forskjell på dem. Ikke nødvendigvis en showstopper, for hvis du legger godviljen til, du er i et skjema, og du kommer ned til en button …

Erling: Så kan du anta at det er submit.

Anders: Det er ikke en total stopper. Men trykk på den nå.

Erling: Enter.

Skjermleser: Application password. Vindu button.

Anders: Det som hadde skjedd nå dersom Erling ikke hadde hatt en passord …

Erling: Dersom jeg ikke hadde vært opptatt av sikkerhet og sterke passord …

Anders: Så hadde det skjedd ingenting. Nora hadde ikke sagt noe. Ingenting.

Erling: Det hun sa nå var bare button.

Anders: Men når du trykker på den button, så hadde det skjedd null og niks. Jeg prøvde det selv.

Erling: Og du er ikke opptatt av passord.

Anders: Jeg er ikke opptatt av passord. Men vi som ser dette nå, vi ser at det har dukket opp noen feilmeldinger. To stykker. Vi har skrev feil i e-postadressen og vi har ikke godtatt vilkårene. Så da kommer vi ikke videre.

Erling: Blinde folk stopper her.

Anders: Ja, og hvis du nå tar shift tab. Og shift én gang til.

Skjermleser: Jeg godtar Storytels vilkår om personvern, ikke markert.

Anders: I teknikker så sa vi at feilmeldinger bør være programmatisk knyttet til labelen. Hvis det hadde vært det her, så ville den blitt lest opp nå. Men vi går til feltet som har en visuell feilmelding, men skjermleseren leser det ikke opp, fordi det er ingen tilknytning. Det samme hvis vi går opp til e-posten.

Skjermleser: Innhold markert. E-postadresse.

Anders: Hun sier e-postadresse uten å si feil i e-postadressen. Så her er det veldig vanskelig å komme i mål hvis du har gjort en feil.

Erling: Hvis du har gjort en feil, så får du ikke beskjed om det. Du vet ingenting.

Anders: Da skal du være ganske interessert i å bli Storytel sin kunde, hvis du skal klare dette.

Erling: Er det en segway? Nei. Skal vi gå videre med Storytel?

Anders: Vi skal fortsette med Storytel. Skriv inn en adresse, hvilken som helst.

Erling, Anders og VoiceOver snakker i munnen på hverandre.

Skjermleser: E-postadressen.

Anders: Nå har Erling fyllt ut alt han skal, uten samtykke, og trykker på opprett konto. Det som skjer her er at nå har vi plutselig kommet til steg to av to. De har et skjema som har fem felter. Fire knyttet til kortbetaling. Og én ny godtakelse av vilkår. Nå skal du plutselig noen andre vilkår enn de du ikke fikk lese i forrige. De heter nå tilleggsvilkår for unlimited.

Erling: Unlimited?

Anders: Det står det. Jeg vet ikke hva det er. Det som er rart nå, er at, for det første så er skjemadesignet annerledes. Det er plutselig grønn kantlinje rundt feltene, i stedet for grå som var tidligere. Og hvis du tabber nå.

Erling, Anders og VoiceOver snakker i munnen på hverandre.

Anders: Der fikk vi en tastaturfelle. Vi kommer ikke forbi siste elementet i hovednavigasjon som heter mine sider.

Erling, Anders og VoiceOver snakker i munnen på hverandre.

Anders: Da jukser vi. Da trykker vi før skjemaet, og så tabber vi videre.

Erling: Nå har vi tabbet videre?

Anders: Nå har vi tabbet inn på et felt, og vi hørte ingenting. Det vil si at de feiler på ny. Her blir jo nå visuelt sett kantlinjen på skjemafeltet, endres fra grønt til rødt som en fokusmarkering, som indikerer at det er noe feil. Det er det jo ikke, vi har jo ikke begynt å skrive.

Erling: Vi vet jo ikke hva vi skal skrive.

Anders: Tabb deg videre.

Skjermleser: Gyldig til med mer.

Anders: Der fikk vi noe. Gyldig til med mer. Det er jo fordi de har brukt en placeholdertekst uten å si hvilken forkortelse det er. Så «med mer» er faktisk m m. Dette var et supert eksempel på det vi snakket om i episode 17, det er at en forkortelse kan være tvetydig. Det hadde vi ingen gode norske eksempler på, før nå. M M er jo måned.

Erling: Måned måned.

Anders: Måned måned. Skrevet med store bokstaver. Det betyr jo at du alltid skal ha med null. Det vet jo ikke folk.

Erling: De tror jo det er med mer.

Anders: Hvertfall nå. Og så videre, tabber du?

Skjermleser: Å Å Å Å. Redigerbar tekst.

Erling: Hehehe.

Anders: Her får vi ingen indikasjon på at vi skal skrive inn årstall, som kortet utløper på.

Skjermleser: Sikkerhetskode punkttegn punkttegn punkttegn.

Anders: Punkttegn punkttegn punkttegn. Det er fordi placeholderen nå har noen punkter.

Skjermleser: Ikke markert.

Anders: Da kommer vi til noe som ikke markert. Ingen fokus eller label. Det er sannsynligvis godkjennelse av vilkår. Og videre?

Skjermleser: Start abonnementet.

Anders: Start abonnenementet sa han. Her har de plutselig laget knappen rett. I steg to er den rett. I steg én har de teksten utenfor button-elementet. Her skjer det noe. Nå kan du prøve å trykke på den knappen, Erling.

Erling: Jeg trykker enter.

Anders: Her er det ingen passordfelt, så jeg håper ikke at den lastpass-greiene går amok.

Erling: Nå trykket jeg. Dette er ikke en redigeringsfeil. Nå skjedde det ingenting.

Anders: I grensesnittet skjedde det noe. Og her skjedde det noe merkelig. Her har vi konkrete brudd på begge kriteriene som vi har snakket om i dag. Nå vet jeg at i ris og ros-spalten, så har vi gått på kryss og tvers, vi har hoppet langt utenfor 3.3.1 og 3.3.3, men å er vi der! Det som har skjedd nå er at vi har feil i fire av feltene, fordi vi ikke har fyllt dem ut, fordi alle er obligatoriske. Vi har ikke sagt nå at vi har glemt å fylle ut de obligatoriske. Det ene feltet har fått en annen markering med rød kantlinje, som betyr at det er feil i det, selv om fokusmarkeringen òg var nesten lik. Det var en liten annen skygge der. Så har vi nå brutt den «bruk av farge» i tillegg. Og så har de gjort et veldig rart designvalg. De har en feilmelding over skjemaet med blå bakgrunn som glir veldig inn i resten. Og der står det «beklager, det ser ut til å være feil i opplysningene du har skrevet inn.» De sier ingenting om hvilke felt som feiler, eller hva du har gjort galt. Ingen forslag til forbedring.

Erling: Jeg tørr påstå at et stykke ovenfor skjemaet, altså det er mange elementer mellom, en strek, hvorfor trenger du kortopplysningene dine, noen bilder.

Anders: Vent nå! Teksten under feilmeldingen er skrevet i rødt. «Hvorfor trenger vi kortopplysningene dine?» Det første jeg tenker er at det er jo feilmelding. Her er det noe som har feilet. Eller det vet ikke vi med en skjermleser. Men visuelt er det noe som har feilet. En rød tekst med en spørsmålstegnboble. Jeg tror jo at jeg må klikke på den for å finne ut hva som feiler. Jeg står med lommeboken min åpen.

Erling: Har lyst å hive penger på Storytel.

Anders: Dette er et kroneksempel på rævva skjemadesign.

Erling: Skikkelig smekk på pungen til Storytel.

Anders: Altså, sikkerhetskode har de faenmeg klart å skrive på to linjer, med e-en stående alene. Du har ikke lyst å fremstå som en useriøs fjott når du skal be om kortopplysninger. Dette er jo direkte tap.

Erling: Hvis noen der ut bryr seg om Storytel, ta en telefon til dem, og si at dette er så dårlig at de burde skjemmes.

Anders: Jeg tror vi gå videre. Blodtrykket er i ferd med å …

Fabel

Erling: Når denne brukeren nå har feilet, så tenker han, jeg får det ikke til, hvilke andre konkurrenter finnes?

Anders: Fabel. Jeg hadde notert meg noe ros til Storytel, men vi kan gå videre.

Skjermleser: Registrering. Opprett ny konto.

Anders: Akkurat det samme. Vi er på Fabel og vi ser et skjema. Heldigvis færre felter. De ber mobilnummer og e-postadresse, ikke e-post og passord. Men de har ikke noe bekreft-tull, så de har gjort noe riktig. De har en stjerne etter mobilnummer og e-postadresse. Det er en konvensjon at det er påkrevde felter. Så kan en diskutere om det er nødvendig.

Erling: Om det er påkrevd som burde markeres eller om det er valgfri som bør markeres, det er utenfor disse kriteriene.

Anders: Uansett så gjør de samme tabbe her, de har ikke noe label, de bruker kun placeholder. Det er ikke godt nok, det vet vi. De gjør akkurat det samme, som jeg mener er et dark pattern, de kjører to sjekkbokser, én vi ønsker nyheter fra Fabel på e-post. Litt bedre, fordi det er en tekst som er mulig å lese på et sekund. Og det står ikke noe om at de skal sende ting til samarbeidspartnere. Og den andre er å godta Fabels vilkår. Så ikke bra, men bedre. Det var en ting på Storytel jeg glemt å si. De hadde skrevet med alt for dårlig kontrast og dødsliten tekst under den siste send inn-knappen at dette bare er gratis så og så lenge, og etter så og så lenge så begynner du automatisk å betale for det.

Erling: Når vi snakker om dark patterns, dette høres ut som et dark pattern.

Anders: Yes.

Erling: Jeg må bare kommentere på Fabel her, de har litt krøll med linjehøyden. Med de sjekkboksene der nede. Som er brudd på andre kriterier.

Anders: Og her er det veldig rart at ikke tekstene har samme innrykk.

Erling: Slurv. Skal vi tabbe oss videre.

Skjermleser: Mobilnummer stjerne. Redigerbar tekst.

Anders: De bruker mobilnummer stjerne. Og de bruker ikke required-attributtet i HTML som hadde resultert i at hun her damen, Nora, hadde sagt «påkrevd felt». Så her må jeg tolke at stjerne betyr påkrevd. Og kanskje gjør jeg det. Legger jeg vondviljen til, så gjør jeg ikke det. Skriv inn et mobilnummer med ni tall.

Skjermleser: Ett hundre og tjuetre millioner fire hundre og tolv tusen tre hundre og førtifem.

Anders: Videre. E-postadresse.

Skjermleser: E-postadresse stjerne tom redigerbar tekst.

Anders: Skriv hva som helst.

Skjermleser: S F. Jeg ønsker nyheter fra Fabel på e-post. Ikke markert.

Erling: Skal jeg velge den?

Anders: Nei trenger ikke det.

Skjermleser: Jeg har lest og godtatt Fabels og til. Kreves ikke markert.

Erling: Hæ?

Anders: Kreves. Så her har de tatt required. De har brukt required på vilkårene.

Erling: Hvorfor sa hun kreves ikke markert.

Anders: For boksen er ikke markert. Men feltet kreves.

Erling: Kreves?

Anders: Required.

Erling: Kreves pause ikke markert?

Anders: Ja.

Erling: Jeg trodde det var «kreves ikke», «markert». Det kan være at de som er drevne i å bruke skjermleser er med på det.

Anders: Ja, jeg tror ikke de kunne gjort det annerledes.

Erling: Her har de gjort noe rett. Skal jeg markere den? Eller skal vi prøve uten?

Anders: Her er det noe kjekt som jeg ble nysgjerrig på. Ta shift tab og tab ned til sjekkboksen.

Skjermleser: Jeg har lest og godtatt Fabels og to til.

Anders: Jeg har lest og godtatt Fabels og to til?

Erling: Ja, det var det jeg reagerte på. For vi ser hva som står. Det som står er «Jeg har lest og godtatt Fabel vilkår».

Anders: Og da tipper jeg at siden de ikke har … nei, jeg vet ikke. Du får inspekte denne. Dette må vi finne ut av.

Erling: Dette ser greit ut.

Anders: Jeg aner ikke hvorfor dette skjer. Fant ikke ut av det. Hvis noen forstår hvorfor Nora sier «og to til». Det står ingenting om det i koden. Greit. En til videre.

Skjermleser: Fortsett.

Anders: Og hun sa ikke at det var en knapp. Så de har ikke laget det som en knapp. Dette er ikke en knapp. Ser ut som en knapp. Brudd på 1.3.1.

Erling: Enter.

Anders: Ja.

Skjermleser: Enter emailaddress.

Anders: Her skjedde det noe. Her sier de «enter an email address» men de har ikke sagt at vi har skrevet en ugydlig e-post. La oss gjøre det da. Skriv inn asdf at.

Erling: Skal jeg trykke enter på direkten, for å se om det fungerte.

Skjermleser: Select this tikkboks.

Anders: Select this tikkboks, uten å si hvilken tikkboks det. Nå er vi helt ut av kontekst, men det er jo den som er required. Men det er jo en veldig dårlig feilmelding.

Erling: Nå lurer jo jeg på hvor tabfokuset er. Hvis jeg trykker på tab nå, kommer jeg ned til sjekkboksen?

Anders: Nei, jeg vet ikke hvor fokuset er. Den er på teksten i feilmeldingen.

Skjermleser: Fortsett. Button.

Anders: Ja.

Erling: Hva skjedde nå?

Anders: Nå er vi på tabben.

Skjermleser: Jeg har lest og godtatt Fabels og to til. Kreves ikke markert.

Anders: Så markerer du den.

Skjermleser: Marker. Jeg har lest og godtatt Fabels og to til. Tikkboks.

Erling: Det «og to til»-greiene krøller det til.

Anders: Hvorfor kaller hun det tikkboks?

Erling: Jeg vet ikke.

Anders: Er det noe de … er det en input sjekk, dette? Det er nok ikke det.

Erling: La meg inspekte den. Det er rett, det er en sjekkboks.

Anders: Det er bare den engelsk som kaller det det, de har gjort det riktig. Videre. Vi har nå skrevet inn et ugyldig telefonnummer, en gyldig e-postadresse og vi har godtatt vilkår. Vi går ned til det som ser ut som en knapp, som ikke er det, som heter fortsett og tar enter på den.

Stillhet.

Anders: Ingenting.

Erling: Ingenting skjedde.

Anders: Nei.

Erling: Noe skjedde. For siden lastet så jeg. Så siden laster.

Anders: Men her er det ingenting, ingen visuell og ingenting til skjermleseren som sier at dette er …

Erling: Men du!

Anders: Har du sett et spøkelse, Erling?

Erling: Se!

Anders: Jeg ser hva som har skjedd! Plutselig har jævelen haket av samtykke til markedsføringsboksen av seg selv.

Erling: Hekkan. Skulle ha meldt dem til GDPR-politiet. Det som skjedde nå. Den lasted lenge. Så valgte han det første elementet på siden som er skip to content.

Anders: Det jeg la merke til med mine haukeøyne her i sted, det var at i URL-strukturen deres så har de et parameter for feilmelding som sa hva som var feil. Så Fabel vet at jeg har skrevet inn feil.

Erling: For det står i URL-en.

Anders: Prøv å gjør det samme, og se på adressen før feilmeldingen.

Skjermleser: Voiceover av.

Erling: Skal vi se. Du mener at det står i URL-en her.

Anders: Nå står det at noe annet er feil. MS ISDN. Erlik 1. Send det inn én gang til, og så gjør du det samme før han laster på ny. Nå så vi at det var Wordpress. Ok, jeg fikk opp en feil …

Erling: Jeg fikk ikke til det samme.

Anders: Uansett, de vet at det er en feil. Det står invalid i URL-en, men de forteller ikke noe til oss, om at det er feil. Nå har jeg skrevet inn feil telefonnummer, men jeg har ingen begrep om at dette er feil selv.

Erling: Verken for seende eller ikke-seende.

Anders: Da sier vi adios til Fabel, vi ble ikke kunder heller.

Erling: Jeg er litt paff.

Anders: Er det mulig? Dette er nye, moderne tjenester. De har brukt shitloads med penger på å utvikle det. De sperrer inngangsdøren for oss. Alt. De sperrer kassaapparatet.

Erling: De setter opp en sperring foran kassaapparatet.

Anders: Men drit i de. Nå skruer vi av Nora litt.

Erling: Så ble jeg ekstra paff av at de sjekker den jeg ønsker nyheter-greiene.

Anders: Sinnsykt suspekt.

Erling: Jeg sjekker den vekk, trykker fortsett …

Anders: Når det oppstår en feilsituasjon, så setter de på …

Erling: Dette er så skittent. La oss gå videre.

Anders: Fabel, der mistet du meg som kunde. Skru av nå, nå må vi samle oss litt.

Erling: Skal vi snakke om den siste?

Norsk Lyd- og Blindeskriftbibliotek

Anders: Det som vi har gjort nå. Av ren kuriositet, skal se på Norsk Lyd- og Blindeskriftbibliotek. Det er to grunner til det. Én, de dukket opp når jeg søkte etter lydbok på Google, og to, vi nevnte de i forrige episode når vi snakket om medlemmer i W3C.

Erling: De er det?

Anders: Nå sa jeg i forrige episode at de var den eneste norske medlemmen jeg fant, og det er ikke sikkert det stemmer. Men, så nå er vi her. Og dette er ikke en løsning vi har testet. Vi har ikke forberedt oss, vi tar det på direkten.

Erling: Hvordan skal vi gjøre det? Skal vi bruke skjermleser?

Anders: Ja, er ikke det kjekkest for folk?

Erling: Jo, jeg synes det. Jeg fyrer opp Nora.

Skjermleser: Voiceover på Safari. NLB. NLB. Vindu. NLB. NLB har tastaturfokus.

Anders: Vi snakket i episode 17, grunnen til at jeg husker det er fordi jeg nettopp har jobbet med den. Vi ligger jo litt på etterskudd. Nå har vi kommet inn på en side. NLB NLB NLB NLB fire ganger. Og de har ikke sagt hva NLB er for noe. Så de antar at vi vet hva NLB er.

Erling: Og det gjør vi ikke.

Anders: Ikke nødvendigvis. Ikke hvis du kommer rett fra et Googlesøk etter lydbok og kommer inn på NLB.

Erling: De kunne godt hatt NLB, gratis utlån av lydbøker.

Anders: Ja. Gå videre.

Skjermleser: Søk.

Anders: Vi skal finne et skjema.

Skjermleser: E-postadresse. Tom. Redigerbar tekst. Content informasjon.

Anders: De har nå hijacket tabindeksen vår, og dette vet vi fordi vi ser.

Erling: Det hadde vi ikke visst om vi ikke hadde sett.

Anders: Det som skjedde var at vi hoppet over hele hovednavigasjon, hoppet over hele hovedinnholdet, vi hoppet rett til footer, der de har en påmelding til nyhetsbrev.

Erling: Det eneste vi fikk beskjed om fra skjermleseren var e-postadresse.

Anders: Helt uten kontekst. Skivebom. Men vi må komme oss videre.

Erling: Jeg vil bare trykk tabb her.

Skjermleser: Abonner. Back. Skjold.

Erling: Vi jukser litt.

Erling: De har en enormt dårlig kontroll på tabindeks.

Anders: På fokusrekkefølge og fokushåndtering.

Erling: Da skal jeg bla videre.

Anders: Nå jukser vi litt, tar en Ingrid Espelid. Trykk på bli låner.

Erling: Det var det jeg stusset over. Jeg var på jakt etter bli kunde, eller opprett konto eller noe.

Skjermleser: Bli låner. Link. Navigation. E-postadresse tom. Redigerbar tekst. Content informasjon.

Erling: Kommer den alltid til å være et problem, mon tro? Skal vi se.

Anders: Vet ikke.

Erling: Ja, da har jeg trykker på den, meld deg inn.

Skjermleser: Jeg søker. Tom. Search text. Field søk. Black circle. Bokmål main.

Anders: Hæ? Black circle? Her har de to radiovalg. Men de har ikke brukt semantisk kode, så skjermleseren vet ikke at det er en radioknapp, de kaller det bare black circle.

Erling: Det er sannsynligvis navnet på giffen eller bildefilen.

Anders: Lol.

Erling: Det er lol.

Anders: Denne siden er så dårlig på tastatur at vi må nesten bruke mus for å komme oss inn i skjemaet, for det er jo ikke tastatur vi skal teste her.

Skjermleser: Fornavn stjerne. Fornavn.

Anders: Her har de tilsynelatende fine … vi er nå inne i påmeldingsskjemaet. Det første vi ser er at her skal de jo vite hvor vi er vokst opp, og hva vi liker å spise på skiven. De har mange flere felter enn Storytel og Fabel.

Erling: Og bare for å nevne, de har fornavn, etternavn, adresse, postnummer, poststed, telefon, e-post, eventuell annen kontaktinformasjon.

Anders: Eventuell annen kontaktinformasjon? Hvilken annen kontaktinformasjon kan du ha enn telefon, e-post? Skal de kontakte meg på Instagram?

Erling: Jeg vet ikke. Morse?

Anders: Jeg har en liten hypotese. De har en cookiebanner i bunn. Jeg lurer på om den føkker litt tastaturhåndteringen vår. Bare en tanke.

Erling: Skal jeg akseptere den? Jeg vet ikke hva jeg aksepterer. Jeg trykker OK. Nå skjedde det noe i skjemaet. For du har jukset bittelitt?

Anders: Ja, bittelitt. Det eneste jeg har jukset på er, når du har stått i et felt, og beveger deg bort fra feltet, uten å ha gjort noe med det, så endrer de fargen på feltet, på hele feltet, fra hvit til lys knæsj grønn.

Erling: Hvorfor?

Anders: Jeg vet ikke, men jeg tror at det er et signal om at du har glemt å fylle ut noe som er et obligatorisk felt. Jeg tror det er en slags form for 3.3.1 feilidentifikator.

Erling: Skal vi prøve å fylle inn disse feltene, og se hvordan det går?

Anders: Ja.

Skjermleser: Asdf. Etternavn stjerne. Adresse stjerne f.

Anders: Her har de ikke brukt required-attributtet, de har kun forholdt seg til …

Erling: Det har labels her ser det ut som.

Anders: Ja, det har de.

Erling: Da går jeg videre.

Skjermleser: Postnummer stjerne.

Erling: Skal jeg prøve å ikke fylle inn denne, bare for å se hva som skjer.

Skjermleser: Poststed stjerne.

Erling: Da skjedde det som din hypotese, den stemmer fortsatt.

Anders: Nå driter vi i resten, nå vil vi bare komme rett inn til … ja! Her! Nå rullet du litt ned.

Erling: Se der ja.

Anders: Det vil si at den fargen som endres, den indikere plutselig at helt nede i bunn, så kommer det opp feilmeldingen. Dette har jeg aldri sett før. Jeg har aldri sett at en feilmelding så langt i fra feilsituasjonen som her. De har puttet den helt i bunn. I tillegg har de tatt stegindikatoren sin helt i bunn. Det har jeg heller aldri sett. Du ønsker jo å så en forventning om hvor mye arbeid dette her, så i tillegg til at de har shitloads med felter, så har de òg tre steg.

Erling: Får du dårlig samvittighet nå?

Anders: Nei, nei. Vi har jo begynt på en UX-evaluering av skjemaet, vi har glemt ut litt hva oppgaven vår her er i dag.

Erling: Akkurat det vi snakker om nå er jo en del av oppgaven.

Anders: Ja, det er det. Jeg tar det tilbake.

Skjermleser: Telefon. Fødselsdato.

Erling, Anders og Voiceover snakker i munnen på hverandre.

Anders: De gjør det vi sa som en teknikk, at du skal en liste, et sammendrag av de feilene som har oppstått. Nå gjør de dette on the go.

Erling: Fullfør resonnementet, for jeg har et lite innspill her.

Anders: Og dette leses jo ikke opp av skjermleseren, og du vil jo aldri fått med deg dette, hvis vi ikke hadde hatt en stor skjerm.

Erling: En positiv ting her er at når jeg går helt ned og skal til å fylle det inn, så får jeg dem. Så da er de der plutselig. Det er positivt. Det er et argument for at de skal komme under.

Anders: Jeg kjøper den.

Erling: Så får du informasjon om hva som mangler. Nå skal det sies at alt dette er grønt. Profilen til NLB er grønn, så det ser ikke ut som feilmelding. Når du kommer ned der virker det som om det bare er en sjekkliste.

Anders: Grønne feilmeldinger, NLB. Men de bruker utropstegn. De sier jo heihei, stopp opp!

Erling: Men nå er det fem felt som feiler. Jeg har lyst å trykke på gå videre.

Anders: Do it man.

Skjermleser: Gå videre. Group.

Erling: Der sa Nora gå videre. Det var en group.

Anders: Hvorfor er det en group? Jeg vet hvorfor. Fordi de har … skal jeg fortelle det?

Erling: Ja.

Anders: Det er fordi de har puttet stegknappene og gå videre-knappen inn i …

Erling: colgroup?

Anders: Nei, jeg tror ikke det er en colgroup, for dette er jo ikke en tabell. Det er nok en fieldset tipper jeg.

Skjermleser: Group content main.

Erling: Skal vi se? Da skjekker vi koden her. Finner ingenting umiddelbart. Drit på.

Anders: De bruker ikke button, de bruker en vanlig lenke på den.

Erling: Jeg trykker på den med muspekeren.

Skjermleser: Gå videre. Group. Main.

Anders: Skjer ingenting.

Erling: Ingenting.

Anders: Så her får vi ingen indikasjon om at vi har gjort feil.

Skjermleser: Postnummer postnummer.

Anders: Men det vi kan prøve nå, det er jo å skrive feil postnummer, for eksempel fem siffer.

Skjermleser: 12 tusen. Poststed. Stjerne. Telefon. Et tusen to hundre og trettifire.

Anders: Å å å!

Erling: Hva nå?

Anders: Det som skjedde nå, var at vi skrev inn postnummer 12344. Vi har jo en liste i bunn som lister opp alle feilene. Og postnummer forsvant fra den listen, som indikerer, hvis vi har tolket riktig at det var en feil, så indikerer dette at du har gjort det riktig kjære kunder.

Erling: Spennede hva som skjer når vi trykker videre.

Anders: Veldig spennende.

Erling: Klarer knapt å vente.

Skjermleser: Fødselsdato. D D med mer. Å å å å stjerne.

Erling: Ja, for her ber de om spesifikt format. Skal vi tulle med det formatet?

Anders: Ja, tull. abc.

Skjermleser: Tolv tolv. Fødselsdato. 12. desember 1999.

Erling: Det var litt interessant.

Anders: De spør etter 1999.

Erling: Jeg skrev 99. Men Nora sa 1999. Så her er det kilde til.

Skjermleser: E-post. Stjerne. F.

Erling: Så skriver jeg e-post feil bevisst.

Skjermleser: Eventuell annen kontaktinformasjon.

Erling: Å ja, se her.

Anders: Se hva som skjedde! Når du skrev inn fødselsdato tolvte i tolvte nittini, nettleseren tolket det, men de fjernet det. De blanket det ut, de var ikke fornøyd med inputten vår. Det er det vi sier, vær nå smart med vasken din. DD MM ÅÅÅÅ, det kan ikke folk. Skriver du 12 12 99, da lagrer du det i databasen som 12 i 12 1999, og så gir du tommel opp til kunden din. Takk for at du skrev inn fødselsdatoen din.

Erling: Det var det de prøve å gjøre.

Anders: Bommert.

Erling: Tenk så drit å ha motoriske utfordringer å skrive det én gang til, helt fra starten av.

Anders: Du vet jo ikke at det har forsvunnet. Det ble jo grønt. Hele driten er jo bare blitt grønn.

Erling: Vi har skrevet inn telefonnummer med kun fire siffer, vi har skrevet inn postnummer med fem siffer, vi har skrevet inn postnummer som ikke finnes, asdf, men når jeg tar e-post og skriver asdf. Ingen alfakrøll, ingen punktum, så trigger den.

Anders: Det har de validering på.

Erling: E-post er ugyldig. I kontekst av e-post. Konge.

Skjermleser: asdf. Markert. Krøllalfa.

Erling: Jeg skriver inn korrekt.

Skjermleser: Eventuell annen kontaktinformasjon.

Anders: Det er jo ikke en presis … du har ikke fyllt ut feltet.

Skjermleser: Gå videre.

Erling: Nå feiler den for at jeg ikke har fyllt ut feltet fødselsdato.

Anders: Men det gjorde vi nå. Fyll inn det skikkelig da.

Skjermleser: Tolvte desember nitten nittini. asdf krøllalfa dot no. Markert e-post stjerne.

Anders: Det som skjer nå er at alle feilmeldingene i den lange listen er borte borte.

Erling: Ingen grønne felt. Altså deres indikator på at det har skjedd noe galt. La meg trykke med muspekeren for å gå videre. Nå skal det jo fungere.

Skjermleser: Lydbøker ikke markert.

Erling: Validerte ikke postnummer, ikke poststed, ikke telefonnummer, men at du skrev 12.12.99, det fikk du ikke lov til.

Anders: Nå har du en brukerprofil med særdeles dårlig kvalitet.

Erling: Ja. Og nå er vi på steg to av tre. Og her er det en, to, tre, fire, fem, seks, syv felt i praksis. Jeg talte ikke hvor mange det var på forrige, men det var ganske mange.

Skjermleser: Punktskriftbøker ikke markert.

Erling: Her er det rett semantikk.

Anders: Nei.

Erling: Er ikke dette rett respons på sjekkboks?

Anders: Nja. Ta én tilbake.

Skjermleser: Black circle bokmål.

Anders: Ta en ned.

Skjermleser: Lydbøker ikke markert.

Anders: Dette er ikke rett semantikk i det hele tatt, Erling.

Erling: Beklager.

Anders: Det vi får opp er lydbøker ikke markert. Hva da «lydbøker ikke markert»? De har en overskrift som burde vært i et fieldset. Det er en legend. «Ønsker å låne» skulle vært en legend. Hvis det hadde vært i en legende, så hadde vi nå fått lest opp «Ønsker å låne lydbøker». Da hadde du skjønt konteksten av valget i sjekklisten.

Erling: Bra.

Anders: Så «lydbøker» gir ingen mening, for du vet ikke at spørsmålet er hva du ønsker å låne.

Erling: Helt enig. Men det var ikke black square. Ikke markert. Jeg gir jo beng i dette, så jeg hopper forbi alle.

Skjermleser: Gå videre.

Anders: Øøi! Hehe. De har tre grupperinger med sjekkbokser og nå kom det en grønn kantlinje rundt alle.

Erling: Skjermlesermessig skjedde det ingenting nå. Ingenting. Jeg vet ikke hvordan jeg kommer meg videre.

Anders: Og visuelt sett er ikke dette tydelig i det hele tatt.

Erling: Nei, det kom bare masse grønne rammer. Kantlinjer.

Anders: Nå vet vi jo at de bruker grønn som en signalfarge for at noe er feil, det har vi lært oss, vi som er heldige og visuelle.

Erling: … og ikke er fargeblinde.

Anders: Det hadde jo vært en fordel faktisk her i dag. Er du grønn-rød-fargeblind her så er det lettere å bruke dette.

Erling: Du hadde lært at dette er feil, for det ser ut som rød. Skal vi sjekke dem, for å gå videre? Jeg tar én av hver. For det må jeg gjøre.

Anders: Det som skjedde var at den grønne linjen forsvant.

Erling: Litt morsomt at når jeg velger sjekkboksen, så blir det en grønn hake, det som tidligere har vært indikatoren på feil. Vi prøver igjen.

Anders: Så har de jo òg samme farge på primær og sekundærknapp. Gå videre og tilbake.

Erling: Gå videre.

Skjermleser: Ja, jeg bekrefter at opplysningene jeg har gitt er korrekte. Stjerne. kreves ikke. Markert.

Anders: De har visuelt en stjerne, men ikke kodet det som påkrevd.

Erling: Skal jeg prøve å sende inn skjemaet uten å velge noen. Her er det fire valg. Jeg prøver bare for å se … åkei.

Anders: Da skjedde det samme, men litt styggere. Her glir linjene inn i hverandre.

Erling: Her er det ikke gruppert.

Anders: Nei.

Erling: Hver for seg. Det følger egentlig mønsteret fra forrige.

Anders: Grønn kantlinje på det som er feil. Vi fikk ingen opplysning om det. Men hak av de som du må hak av.

Skjermleser: Marker hake. Ja, jeg bekrefter at opplysningene jeg har gitt er korrekte. Stjerne. Tikkboks.

Erling: Sånn, så sender vi inn.

Anders: Også her, så kan vi nå ikke tabbe oss til lenken til vilkår, fordi de bruker lenke inne i en label, som er no go.

Skjermleser: Tilbake. Group.

Anders: På send skjema, så sa hun tilbake?

Erling: Nei.

Skjermleser: Tilbake. Group. Send inn skjema.

Anders: Ja, jeg så feil. Beklager.

Erling: Da trykker jeg på den. Enter. Nå trykker jeg på enter, ingenting skjedde.

Anders: Joda, den er bare treg.

Erling: Nå har de … «Takk for din innmelding. Nå er asdf meldt inn. Med 12344 som postnummer og asdf som poststed.»

Anders: Men vi har ikke fått noen indikasjon på at dette gikk i boks. Visuelt sett så ser vi det.

Erling: Leser den opp den første som er fokusert nå?

Anders: Nei. Nå leser den opp, «Gå rett til innhold». Det gjør den nå. Hvis du trykker på den nå, så skal vi se …

Erling: Det har kanskje med at vi ikke har …

Anders: Nå forholder vi oss bare til interaktive elementer. Det er greit nok. Det de dummer seg ut på her, som vi ikke har snakket om enda, tror jeg, det er at de ikke har endret tittelen på fanen. Verdien på title-taggen er fortsatt «Meld deg inn», men burde vært «Takk for din innmelding», for dette er det første holdepunktet du har.

Erling: Spennende. De òg krasjet. Og det visste vi ikke.

Anders: Som det sang. Nå lurer jeg på, du skulle jo svare på om du var på jakt etter punktskriftbøker, så her skriver de at når søknaden din er godkjent, vil du motta et velkomstbrev med lånenummer og pinkode. Jeg lurer på om brevet er i punktskrift.

Erling: Jeg har mine tvil.

Anders: Jeg tror faktisk det. Vi er på Norsk lyd- og blindeskriftbibliotek.

Erling: Men jeg fikk så liten tillit til dem etter å ha vært gjennom denne skjemaflyten.

Anders: Blinde er her i målgruppen og de som har laget skjemaet vet ikke hva de holder på med.

Erling: Verken på Storytel, Fabel eller NLB. Dette er veldig overraskende. Og veldig trist.

Anders: Dette er terningkast 1 i skjemadesign.

Erling: Jeg vet ikke om de fortjener et terningkast engang.

Anders: Det ble en ris og ris-spalte i dag. Skru av Nora, så skal vi avslutte.

Avslutning

Anders: Jeg har hatt det kjekt i dag.

Erling: Jeg òg. Det er jo kjekt når ting feiler monumentalt. Dette er jo noe som begge synes er et veldig kjekt emne. Skjema, feiling og.

Anders: Så får vi håpe at lytterne har klart å følge oss i dag. Det er jo en liten fallgruve, å se på en skjerm, å ikke hele tiden være bevisst på at lytterne ikke ser det samme som oss.

Erling: Og vi vil gjerne ha tilbakemeldinger på akkurat det. Vi er litt nysgjerrige på det konseptet. Det formatet, om vi kan sitte og snakke om tjenester, og at klarer å følge med og oppfatte det som interessant og få noe ut av det. Den tilbakemeldingen kan du sende til hei@universeltutformet.no. Men tre ting som du skal huske fra dagens episode, hva er det?

Anders: Vis feil og gjør det både visuelt og ikke gjør det med grønn. Det har vi ikke nevnt, det kom frem fra siste eksempelet. Vær konkret og høflig og direkte og entydig og presis i feilmeldingene dine. Ingen vil klage over at du du er for forståelig der. Og prøv å bruk dette prinsippet «veil of ignorance», hva om det var du som stod over det valget som du nå tar for dine kunde og brukere.

Erling: Veldig bra. Neste episode? Vi er ikke helt ferdige med feil.

Anders: De to neste episodene skal vi snakke om feil. I neste episode er jo mest forhindring av feil. Hva kan dere gjør for å unngå at alle de episodene vi har snakket om i dag, skjer?

Erling: Veldig spennende. Da Anders, jeg har ikke sett hvor lang episoden ble, men den ble lang.

Anders: Nå er det god natt.

Erling: Da sier jeg, takk for oss. Jeg er Erling fra Okse.

Anders: Jeg er Anders fra Webstep.