Universelt utformet

Anders: Vi er 2 entusiasterster som snakkes gjennom hele WCAG på en forståelig måte. Dette er Universelt Utformet. Hei Erling!

Erling: Hei Anders. Må den her igjen.

Anders: Episode 29 av 26. Det er jo helt utrolig at man har klart det.

Erling: Det skulle ikke vært ganske mulig.

Anders: Nei, det er jo egentlig ikke mulig å gå over 100 prosent. Nei, vi fikk det til.

Erling: Vi har snakket om å lese en ny intro. Kanskje vi gjør det etterpå, kanskje ikke. Gjør vi det så kommer det nye introen før det vi nå har sagt. Ja.

Anders: Episoden i dag heter konsistent hjelp. I forrige episode hadde vi ulike talefeil, med meg og deg.

Erling: -Ja, stemmer det. Jeg så I LinkedIn-posten din. -Ja.

Anders: Så det vil jeg begynne med å si, er at jeg er inkonsistent på konsistens og konsekvens.

Erling: Ja, men betyr det samme?

Anders: Nei, det tror jeg ikke. Jeg har ikke forberedt meg om når jeg skal bruke hva, men jeg bruker de begrepene litt om hverandre. Så jeg kunne likt så godt sagt: konsekvent hjelp.

Erling: Ja, og det høres rett ut med konsekvent? Nei, for det kommer gjerne den meningsforskjellen inn. Konsekvent versus konsistent.

Anders: Konsistens?

Erling: Kanskje vi søkte opp dette før?

Anders: La oss holde oss til konsistent hjelp. For det er consistant help. For vi kan oversette konsistent hjelp med konsekvent hjelp. Nei? Kanskje. Så derfor må jeg bare advare litt at det kan komme noen flere feil her også.

Erling: Er de talefeil vi hadde i forrige episode viktig? Nei. Endrer ingenting.

Anders: Jo, det var en plass, nå klarer jeg ikke husker jeg, men det var en plass der vi sa noe som faktisk endret meningen på grunn av en talefeil.

Erling: Ja, det var snakk om ordet panere.

Anders: Ja, det var det.

Erling: Var det det?

Anders: Vi bruker ordet panere som en oversettelse for pan på engelsk. Og det er jo feil. Så kan man stille seg spørsmålet: Hva er det rette for to pan? Det vet jeg ikke. Men det er noe som heter å panorere. Det er noe du bruker i fototeknikk når du panorerer over noe. Altså du beveger kameraet for å få et større utsnitt.

Erling: Det er noe likt der.

Anders: Helt enig. Så om panorerer er det riktige? Er det som er mest brukt.

Erling: Ja, og faktisk skal vi se, nå jukser jeg litt her. Det første som står i det første forslaget er faktisk panorere. Så kan det være feil? Også refererte vi til Aaarc, da det egentlig var Aaardwark.

Anders: Så da har vi rett opp i det. I dag er det noen måneder siden jeg planla strukturen på disse episodene. I dag satt jeg og tenkte: Hvordan i alle dager skal vi snakke i en hel episode om ett suksesskriterie, som kan sies i én setning. Altså konsistent hjelp, når du har hjelpeinformasjon, så skal du finne det på samme sted, avhengig av hvor du er i tjenesten eller nettstedet.

Erling: Sånn, ferdig, takk for i dag.

Anders: Vi har jo en evne til å klare å utbrodere.

Erling: Snakke mye om lite.

Anders: Snakke mye om lite. Og det kan jo være bra? Det kan være bra. Ja, og det kan være at vi problematiserer det unødvendig.

Erling: Ja, hun kan jo ta det helt ned igjen. Ja. For dette er suksesskriterie 3.2.6. Hva står de tallene for?

Anders: 3-en er forståelig, understandable. 2-en er predictable, altså forutsigbart. Og da 6-en er konsistent hjelp. Så det at noe skal være forutsigbart, er nøkkelen her. Jeg kjenner at dette er et kriterie som er like godt.

Erling: Enig. Og dette er en enkel A. En enkel A.

Anders: Jeg tenker sånn: Dette er jo helt opplagt, det er ingen som bommer på denne. Så feil kan jeg ta. Det kommer jeg tilbake til. Hjelp er i denne kontekst et telefonnummer, en sånn snakke-widget. Finnes det et godt norsk ord for widget? Da kom jeg frem til Wikipedia sin artikkel om grafisk styreelement. Og der, selv om jeg er glad i det norske språket, tror jeg vi skal holde oss til widget.

Erling: Av og til er det engelske ordet best.

Anders: Lenke til kundesenter. Det er viktig å nevne at hvis du har et telefonnummer, skal det stå på samme sted. Høres logisk ut. Men dette suksesskriteriet krever ikke at du har kontaktinformasjon.

Erling: Og det er en veldig viktig presisering innenfor dette kriteriet. Hvis du har hjelp, så skal de ligge samme plassen. Det sier ingenting om at du må det.

Anders: Da kan man jo tenke seg at hvis noen bryter dette suksesskriterie og får varsler om bot, så kan de bare fjerne det.

Erling: Ja, sant.

Anders: Så har de fikset det, gjort det verre for alle.

Erling: Men de har fulgt 3.2.6.

Anders: Ja. Jeg satt og tenkte i dag, når er dette et problem? Og så tenkte jeg og tenkte: For det er jo veldig mye av det som finnes der ute i den store verden, som er malbasert. Og du bruker jo ikke så ofte ulike maler og ulike plasser, eller gjør du det?

Så tenker jeg at det gjør vi mange plasser. For eksempel, et nettsted, har du ofte en publisersløsning som ligger bak. Men så har du gjerne helt egne karrieresider og hjelpesider. De bruker ikke nødvendigvis samme mal. Det er hovedpunktet mitt.

Når du bruker forskjellige baksystemer, må du samkjøre de malene for å være i tråd med dette kriteriet. Det er ganske vanlig at organisasjoner anser ulike tjenester som litt separate. Og gjerne forskjellige folk i organisasjonen har ansvar for de forskjellige systemene. Men for brukeren er det bare en del av én brukerreise. Er du på jakt etter en jobb og kommer inn på Okse, og dersom vi hadde hatt en karriereside som lå på en Teamtailor-løsning, eller hva det måtte være, de driter i om det er en annen løsning. Hvis du vil finne …

Erling: Hjelp. Ta kontakt med oss.

Anders: Et godt prinsipp. Det er lettere å feile enn det jeg tenkte på umiddelbart. Det er også en viktig presisering. Når man sier at det skal ligge på samme sted, så gjelder det ikke ulike vindusstørrelser. Eller mobil, større skjerm osv.

Så dette er ikke noe som ødelegger for responsiv design.

Erling: Skjønner det er innenfor den samme skjermbredden at det skal ligge på samme plass.

Anders: Så hvis noen endrer størrelsen på vinduet sitt og ikke finner fram, så er det ikke avsendernes problem.

Erling: Men hvor nøye er det? Når vi sier samme plass, hvis du har lenke til kundesupport i footeren, så bytter du mal, så er det fortsatt lenker til kundesupport i footeren, men en litt annen plass …

Anders: Det er nok en gråsone og det er nok ikke et klart svar på det.

Anders: Det er et sånt eksempel i ris- og ros-spalten. Og jeg tenker at det må være ok.

Erling: Jeg òg. Jeg tenker at det dette handler om er at folk skal finne det igjen når de leter samme plassen.

Anders: Jeg synes det er et godt spørsmål. Dette er jo et kriterie som er mest tenkt på alle, men spesielt de med kognitive utfordringer. Altså, du har et problem og du vil finne det samme sted. Den trygge havn, der du fant det sist for eksempel. Men det er også et problem hvis du er svaksynt og har et veldig lite utsnitt av hele visningen.

Erling: Hvis du har byttet kolonne på kundesupportlenken.

Anders: Hvis du bytter kolonne så kan det være litt vanskeligere å finne det. Men jeg tenker at det må være greit så lenge du har det i noenlunde samme område. Men jeg tror nok at hvis du, for eksempel, bytter rekkefølge innen hovedmeny. Hvis du bytter rekkefølge på elementene der og plutselig hjelp er først eller kundeservice sist, så tror jeg nok at det kan anses som et brudd her. Det er ikke er konsistent. Du finner ikke hjelpen på samme sted. Alt i alt bør det være lett å forholde seg til.

Erling: Hva defineres som hjelp?

Anders: De eksemplene jeg har lest, er ofte stilt spørsmål, telefonnummer, e-post, kontaktinformasjon, lenke til et kundesenter, chatbot eller AI-bot, det er ofte to sider av samme sak i dag. Åpningstider, nevnte jeg det?

Erling: Nei. Nå ser jeg på listen over eksempel de har. Eller er det eksempel? Så det er ingen sære greier her. Det er ganske opplagt.

Anders: Det er ganske opplagt. Så da tror jeg egentlig vi har forklart suksesskriter 3.2.6 på en forhåpentligvis lettfattelig måte. Og da kan vi gå over til ris og ros.

Ris og ros

Anders: Da satt jeg og tenkte hvilke bransje eller hvilke selskaper skal jeg se på i dag. Så begynte jeg på Kakaodu. De skal vi komme litt tilbake til.

Erling: Si litt om Kakadu, hvem det er?

Anders: Ja, det er et selskap fra Stavanger som driver med digital inkludering. På en litt annen måte enn gjerne meg og deg gjør. Vi er gjerne litt mer nede i grøten, og de jobber gjerne litt mer sånn overordnet, altså hjelpe konkret mennesker som trenger det.

Erling: Ja, jeg vil og gjerne si det sånn at det vi fokuserer på er å fikse løsningene i seg selv. Det de fokuserer på er å lage hjelpemiddel som gjør at folk kan bruke løsningene som ikke er laget særlig bra.

Anders: Det kommer vi veldig tilbake til. I hvert fall så jeg øverst på deres veiledninger som var Amedia. Så jeg begynte med dem. Jeg begynte på Amedia, jeg havnet inn på Romerrike, hva het den avisen? Romerrike Arbeiderblad kanskje? Lokalavisen på Romerriket. Og så rullet jeg ned til bunnteksten. Der hadde de telefonnummer, litt lenker og greier. Så gikk jeg på min side, kom inn til et innloggingskjema fra Amedia, der det ikke var noen bunntekst. Det tenker jeg er et brudd her, fordi det er jo gjerne i en slik kontekst av en sånn handling man trenger hjelp, mer enn på en forsiden.

Erling: Enig.

Anders: I tillegg hadde de noen sånne videresendinger som ødela tilbakeknappen. Så hvis jeg da ville komme i kontakt med dem, så nytter de ikke å trykke tilbake. Det var ikke åpning i ny fane eller vindu.

Erling: Er det et kriterium på det? Et eller annet «don't brake the back button»?

Anders: Nei, eller, «don't brake the back button», det har jo vært en sånn W3C anbefaling lenge, men jeg tror ikke det er en del av WCAG.

Anders: Det er jo teknisk klønete, selvfølgelig, å gjøre det. Men i hvert fall så tenker jeg at det var et klart brudd. Ha kontaktinformasjon på innloggingssiden.

Erling: På samme sted.

Anders: Og vi vet jo at innlogging er jo en mareritt for folk.

Anders: Så tenkte jeg: Romerike, dere er ikke gode. Vi i Stavanger, vi kan det. Så jeg tok meg en tur til Stavanger Aftenblad. Der var det likt som Romerike. Masse kontaktinformasjon og personvern og vær varsomm-greier i footeren som forventet. Bli abonnent, brukte en annen mal med bunntekst og telefonnummer, men telefonnummer sto i en annen kolonne.

Anders: En slags gråsone. Det er jo ikke noe fasit her sant. Du vil aldri kunne lese i WCAG om du må de samme elementene inn i samme kolonne i en footer. Jeg tenker sunn fornuft er grønt lys.

Erling: Ideelt sett så burde footeren vært helt lik.

Anders: Ja, ideelt sett. Men Bli abonnent-løpet det bor gjerne hos Schibsted eller en annen plass. Hvem vet. På kundesentersiden til Aftenblad og innloggingssidene – ingen telefonnummer. Så på samme plass, I hvert fall. Så da tenker jeg at Aftenbladet òg bryter denne her. Så gikk jeg videre til Klassekampen. Jeg er ikke en hyppig leser av Klassekampen. Der fikk jeg en veldig ooo, dette var bare god design, behagelig. Altså veldig lite tabloid sammenlignet med mange andre. Det var ikke gul bakgrunn med store, svart tekst og noen sånne bevegelige marquees, er det det heter?

Erling: Ja, noe slikt.

Anders: Veldig behagelig å komme inn på Klassekampen. Ren design, fokus på rene overskrifter. Jeg likte førsteinntrykket. Men logg inn-siden, kontakt i topp, som en menyknapp. Så er det tydelig at de har et eget system, og da samkjøre de ikke designet. Veldig vanlig. Da tenkte jeg at dette er mye vanligere enn jeg hadde tenkt. Så tror jeg innom Subjekt, bare for å finne en alternativ avis. Jeg har ikke sterke meninger om Subjekt, om det er bra eller drit. Vet jo at det er litt omdiskutert.

Erling: Det skal ikke vi bry oss om.

Anders: Subjekt, designmessig, dritbra. De hadde kontaktinformasjon i tredje kolonne i bunnteksten. Det var konsistent på tvers av bli abonnent og logg inn. De brukte samme malverket på logg inn-siden.

Erling: Ja, det er kjempe bra. Ja. Hvis du snakker om Amedia, og Aftenbladet som er Schibsted. Så da kan man anta at alle Amedia-aviser og alle Schibsted-avisene har de sånne problemene?

Anders: Jeg antar det, at de bruker samme innloggingsløsninger.

Erling: Dette er jo og en type scenario på hvor en fort kan bryte dette suksesskriteriene. Når man bruker en tredjepartsløsning for å gjøre en oppgave.

Anders: Vet du ikke om Schibsted er en tredjepart? Det er jo en eier.

Erling: Andrepart? Det er en annenløsning du må innom.

Anders: Og det fører lett til som ansvarsfraskrivelse. Ja, det er et system som vi ikke har kontroll over.

Erling: Men det holder jo ikke vann i WCAG-verden. Neida. Du har ansvar for alle de tjenestene du bruker.

Anders: Så det var det. Hadde du noen sånne tanker, nå var det min kjeft som gikk i ett i dag?

Erling: Nei, jeg har egentlig veldig få tanker. Jeg har fått sagt de tankene jeg har tenkt. Jeg tenker dette er et litt sånn ganske fint suksesskriterie. For når du sier det, altså sier hva det er for noe, så er du jo helt opplagt ja, selvfølgelig. Dette gir mening.

Men det er fort gjort å glemme litt av, tror jeg. Når du skal lage et avis i Schibsted-systemet, og må bruke innloggingen deres. Da må du bare koble den på. Konge. Ferdig.

Å få en påminnelse gjennom dette. Ja, men vi må få inn den samme footeren der, sånn at det blir konsistent hjelp.

Anders: Ja, og ikke bare den. Men en skal jo kjenne seg igjen i den tredjeparten eller det systemet du går inn i.

Erling: Du skal ikke føler at du går inn i en annen verden.

Anders: Det er flere greier du skal tenke på. For eksempel, den trygge havnen, logoen. Hvis du er på et nettsted og kommer inn på karriesiden til det nettstedet, som ofte er en tredjepart – hva er da klikk på logoen?

Er det tilbake til forsiden av karrieresiden? Nei. Det er selvfølgelig. Men der feiler mange. Du går liksom til roten av subdomene du er på. Men for en bruker, så mener jeg i alle fall egentlig at du kommer helt fram til den aller første, forsiden.

Erling: Helt riktig. Og et annet eksempel som vi kom på nå, hvor dette nok ofte blir brutt, er i netthandel. Hvor du starter utsjekkingsløpet, og så har de en nedskrelt versjon der det er fjernet meny, footer og sånt. Da bryter de jo dette kriteriet.

Anders: Ja, ja. Og det er fordeler med å skrelle ned. Fjerne forstyrrelser, øke konverteringingsraten. Innenfor konverteringingsrateoptimalisering vil du fjerne støy for å få brukeren gjennom trakten. Men når brukeren er gjennom trakten, hvis hen, han, hun er usikker, så må hun finne hjelpen. Uten å måtte klikke seg 4 steg tilbake for å komme frem til en side som har en footer.

Erling: Også hvis du da klikker på logoen, så er du gjerne redd for at du har en helt annen plass og mister den progresjonen du har hatt i det utsjekkingsløpet. Og når jeg og tenker tilbake igjen på prosjekter jeg har vært på, så har jeg prøvd dette, eller nå er ikke det et kriterie da. Men jeg hadde brutt dette kriteriet som jeg hadde gjort det som jeg gjorde da nå.

Erling: Selv om dette er selvfølgelig helt opplagt. Dette må jo inn. Jeg kom bare ikke på det.

Anders: Så bra, da har vi et kriterie som vi begge er enige om. Tipper dere lite kontrovers rundt det egentlig.

Erling: Ja, hva skal innsigelsene vært?

Anders: Gjerne litt det som vi var inne på nå. Fjerne støy. Og jeg kan jo se for meg at en vet at det er mye trøbbel rundt innlogging, for eksempel. Så sier noen høyt oppe i systemet: vi kan ikke ha telefonnummer på innlogging, de ringer oss ned. Vi fjerner det.

Erling: Definitivt. Best måten å unngå henvendelser på er å fjerne måten å henvende seg på.

Anders: Og klart, det er ikke sånn meg og jeg jobber. Da må vi heller forbedre innloggingen.

Erling: Helt enig.

Anders: Jeg sitter og jobber med innlogging i dag, og det syns jeg er veldig fascinerende hvor stort det feltet er. Og egentlig hvor lite enighet det er om konvensjonenene der.

Erling: Ja, det er et område hvor, og jeg vet ikke hvorfor, men konvensjonenene har ikke satt seg. Det er så mange måter å logge seg inn på. Vi trenger nyansene for å bruke hver eneste måte. Men så er det jo også forskjellige typer innlogging fungerer i forskjellige typer situasjoner. Hvis du logger deg ofte inn, så er det gjerne bedre med brukernavn og passord. Så logger du deg sjeldent inn, så er gjerne bedre med SMS og en kode og så videre.

Anders: Veldig mange variasjoner. Blant annet dette, hvis du kan logge inn, og du kan velge selv om du skal bruke epost eller telefonnummer til å logge inn. Skal du da tillate det i samme felt? Så det har jeg lest meg opp på i går. Og jeg har konkludert med: Nei. Hold feltene rene.

Erling: Så begynner jeg å tenke: Hvordan skal jeg huske om jeg brukte telefonnummer eller om jeg brukte e-post?

Anders: Jo, jo. Men da lærte jeg om noe som heter Postels lov. Et UX-lov. Har du vært om den? Nei. Nå er jeg ute på tynn is, skal se om jeg klarer å gjenfortelle, men jeg klarer ikke å si hva loven er. Men det er å være tilgivende i måten du tar imot data på. At du aksepterer variasjoner og ikke skylder på brukeren, mens du vasker det i bakhånd og sørger for at lagringen blir bra.

Erling: Stemmer.

Anders: Typisk telefonnummer med og utenlandsskode.

Erling: Ja, kontonummer når du kopierer det fra en plass med mellomrom til et nytt felt, som fjerner de 2 siste siffrene.

Anders: Er utrolig ikke hvor mange nettbanker som fungerer på.

Erling: Jeg forstår det ikke. Nei. Det er så mange sånne ting som jeg bare føler er … Det er så grunnleggende. Du merker det så fort hvis du prøver å bruke det, eller brukertester. Dette handler også mye om, dette med å overstyre hvordan noe fungerer. Hvordan et inputfelt fungerer. Ja, du kan sette begrensning på antall tegn, men du bør ikke gjøre det med mindre du vet at det er noe som er nyttig. Sånn som i kontonummer. Du burde kunne legge inn hva som helst, og så vasker du det etterpå. Jeg har en veldig spesifikk måte å skrive min epostadresse, som bruker en makro. Jeg skriver EHG, og så en alfakrøll, og så blir det hamso@gmail.com, som er så langt å skrive hvis de skriver helt ut. Det funker ikke i Klarnas felter, fordi de overstyrer noe. For de skal kontrollere hvordan de skriver det inn, i stedet for å vaske det i bakkant, og kommer med gode feilmeldinger.

Anders: Og der, litt tilbake til en liten parallell til det vi har snakket om. Hvis du bruker Klarna som betalingsløsning, så bryter Klarna et viktig uu-prinsipp. Det at du ikke skal spørre om informasjon du allerede vet. Og hvis jeg er logget inn på en nettbutikk som bruker Klarna, som jeg allikevel skriver inn epostadressen min, fordi det er ikke en sammenheng mellom Klarna sin base og Min side.

Erling: Men det kunne det vært.

Anders: Det kunne det vært. Det er sikkert at det er mulig. Hvertfall opplever jeg det når jeg skal … Men dette er litt mer Flisespikkeriet.

Erling: Ja, ja. Jeg må bare ta en til ting her. Her. Glemt passord. Du skriver inn e-postadressen din, og så skriver inn passordet, så får jeg feil brukernavn eller passord. Okei, da trykker jeg på å glemt passord. I neste felt står det ingenting, i e-postsfeltet og jeg som nettopp skrev inn e-post! Hvorfor husker han ikke eposten som jeg skrev?

Anders: Og det har jo vært slik i 20 år.

Erling: Ja, og det blir faen ikke bedre altså.

Anders: Det er ikke bedre.

Erling: Hva er det som skjer?

Erling: Det er nesten som det blir bare blir verre. Hører ikke folk på oss?

Anders: Nei, jeg vet ikke. Kall det mikrointeraksjoner, det blir bare neglisjert.

Erling: Ja ja. Det funket når de selv gjennomgår det sånn som de ville gjort det fordi de har kodet det. Ja, nå funker skjemaet. Ja. Ferdig. Så tenker de ikke mer på det. Også er det så mange feller å gå i.

Anders: Ja, uendelig.

Anders: Skal vi lage intro?

Erling: Ja. Skal vi avslutte episoden først? Hvor pleier vi å gjøre det? Du er?

Anders: Jeg heter Anders og jobber i Okse.

Erling: Og jeg heter Erling og jobber også i Okse. Snakkes!