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: Da er vi på episode 23.

Anders: Fredags kveld her i Stavanger.

Erling: Hver fredag, Anders.

Anders: Vi har holdt det jevnt.

Erling: Vi skal bli ferdige til jul. Det tror jeg vi klarer med glans. Vi er strukturerte og gode, altså. I dag skal vi snakke om WCAG 3.3.5. Ett suksesskriterie. Og la oss gå gjennom én gang til. Hva står den første treen for?

Anders: At det vi lager skal være forståelig.

Erling: Og den andre treen?

Anders: Det vi har kalt inndatahjelp, eller det Difi har kalt for inndatahjelp som vi har stjålet.

Erling: Det går på hjelp til for eksempel sette data inn i et skjema, skrive inn et skjema.

Anders: Vi holder oss til skjema.

Erling: Og 3.3.5 spesifikt, det ene suksesskriteriet vi skal snakke om dag.

Anders: Det handler om å tilby hjelp og instruksjoner for de som skal fylle ut skjema når, og dette er en viktig avklaring, når ledeteksten ikke er tilstrekkelig. Har du et felt som heter navn, så er det mer enn godt nok. Du skal ikke trenge ikke å forklare det. Og det så vi et eksempel på forrige episode, noen som hadde hjelpebobler der det stor navn i label og hjelpeboble med fyll ut ditt navn.

Erling: Det gjør ting bare mer komplisert og vanskeligere.

Anders: Helt unødvendig. Vi skal tilby hjelp når folk virkelig trenger det.

Erling: I dagens aside, hva skal vi snakke om da?

Anders: Det er noen som har gjort noen hypotetiske utregninger på hvor mye dårlig kode, eller mangel på universell utforming, kan koste i tapte inntekter. Et lite tankeeksperiment. Vi skal se på den meksikanske restaurantkjeden Chipotle.

Erling: Kult. Alltid kult å få det økonomiske perspektivet her. I dagens ris og ros da?

Anders: Da skal vi se på rekrutteringsbransjen, eller bemanning. Det er visstnok et klart skille mellom rekruttering og bemanning.

Erling: Og det var jo du som valgte kategorien i dag, men det var en hypotese om at de har ganske avansert skjemaer.

Anders: Ikke nødvendigvis avanserte, men de har mange felt, de spør om mye. Og da tenkte jeg at de sikkert spør om noe som ikke er så klart. Men vi har ikke sett de helt store skjemaene. Men vi har nå funnet litt ris og ros likevel.

Erling: Så vi kommer tilbake til det i ris og ros-segmentet.

Hvorfor?

Anders: Erling, hvorfor har vi 3.3.5? Hvorfor skal vi tilby hjelp til folk?

Erling: Det er for å unngå at de gjør feil, for det er lettere å gjøre feil for folk med funksjonsnedsettelser, og vanskeligere å forstå hva som er rett.

Hvem?

Anders: Og hvem gjelder det?

Erling: Det treffer spesielt de med funksjonsnedsettelser, med kognitive utfordringer og sånn, men dette er noe som treffer alle. Er det et vanskelig felt, er det noe som er vanskelig å forstå, så er det vanskelig å forstå, så da trenger folk hjelp. Eller folk har nytte av hjelp.

Anders: Og av oss som lager dette? Eller oss som lager løsninger. Designer …

Erling: og/eller utvikle. Vi har skrevet alle. Designere, kodere og innholdsprodusenter. For en må designe hvordan hjelpeinformasjonen skal se ut og fungere.

Anders: Når skal de dukke opp? Skal det står statisk? Skal det dukke opp med klikk? Hvor skal det plasseres? Til høyre? Under? Over? Og kodere må jo gjøre hjelpeteksten tilgjengelig, spesielt hvis den er skjult.

Erling: De må implementere driten.

Anders: Og innholdsprodusenten må jo sørge for at den hjelpeteksten som skal forklare det som er vanskelig, er enkel.

Erling: Ja, og jeg tror òg at, det står ikke i listen vår, type produkteiere tror jeg òg er en produsent som er aktuell her, for det er jo snakk om hvilke data skal vi egentlig be om. Det å ta stilling til det er veldig viktig i dette. Hvis vi ber om data som er vanskelig for brukeren å forstå, burde vi egentlig be om den? Som egentlig ikke treffer dette suksesskriteriet når jeg tenker meg om, men er likevel et godt perspektiv.

Hvordan?

Erling: Hvordan kan vi være i henhold til dette suksesskriteriet?

Anders: Der har vi i dag egentlig mange teknikker på et ganske lite, eller burde det kanskje bare vært én teknikk, dette er den beste, men vi tar litt forskjellige. For det er forskjellige typer skjemaer. Og hvis du har et felt som bør forklares, så kan du lenke til informasjon om det feltet i ledeteksten.

Erling: Ja, nå ble jeg usikker. Jeg kunne gjerne ha tenkt disse tankene når vi gikk gjennom det. For noen episoder siden, så snakket vi om sjekkboksen på slutten av et skjema hvor du skal akseptere vilkår, hvor du gjerne lenker til vilkårene i ledeteksten, så det å ha en lenke i ledeteksten er vel ikke så bra?

Anders: Nei.

Erling: Som teknikken her sier.

Anders: Det er jeg enig i, for da har du to klikkbare elementer i ett.

Erling: Men dette er en teknikk som står i WCAG?

Anders: Ja, dette er en offisiell teknikk, så det er derfor vi har den med. Det er en lite brukt teknikk, og det kan jo være grunnen.

Erling: Skal vi gå videre på teknikker?

Anders: Og du kan ha en generell innledningstekst som forteller hvordan du skal fylle ut skjema, innledningsvis eller å lenke til, ikke per felt men mer overordnet. Og i stedet for at du lenker til noe, så kan du òg bruke slike hjelpebobler. Det er forklart ganske grundig hos Difi, og jeg synes den forklaringen er god. Hjelpebobler er ikke en offisiell WCAG-teknikk, men jeg oppfatter Difi sin som mer moderne, og det er òg en sterk konvensjon.

Erling: Det er det jeg tenker på når jeg tenker hjelpetekster i skjema, da tenker jeg på sirkel med et spørsmålstegn inni. Og vi kan diskutere om det er en god eller dårlig konvensjon, men det er en nokså etablert konvensjon. Videre.

Anders: Hvis vi går på felter som er søkefelter, så er autoforslag et godt hjelpemiddel. Både for de som skriver feil, men òg for å slippe å skrive alt. Da ser du raskt hvordan det bør skrives, det du søker etter. Og du er kanskje usikker på det. Du begynner å skrive, og så dukker det opp. Autoforslag er bra. Og òg sånn «mente du?», altså begge disse er teknikker som Google bruker i stor grad. Der en aksepterer skrivefeil, at du ikke gir null treff, at du har en feilskrivingsordbok i bakhånd.

Erling: Når du bytter om på to bokstaver, så får du forslag til hva du egentlig mente. Et spørsmål, litt på sidelinjen. Placeholder, hvordan treffer placeholder denne suksesskriterien? Er det hjelpetekst?

Anders: Det kan være hjelpetekst, det vil si at du kan putte hjelpetekst i et skjema og det er verken rådet eller frarådet offisielt i WCAG, men hvis vi hopper litt på siden, og ser på gode retningslinjer i skjemadesign, så er det frarådet, fordi at, 1, du skal jo opprettholde kontrastkravene, og hvis du har for sterk kontrast i en placeholder, så ser det ikke ut som en placeholder lengre, og da tror du at den er ferdig utfylt. Du kan tror hvis det ikke er et viktig skjema for deg, hvis du bare skal komme i mål, få greia sendt inn. Å ha verdifull informasjon i en placeholder, anser jeg som en dårlig praksis.

Erling: Og så når du begynner å skrive inn i feltet, så forsvinner den teksten, skriver du ett tegn, så har du ikke hjelpen lengre. Bare for å ta det, har du eksempel på en situasjon hvor placeholder er nyttig?

Anders: Ja. Du kan bruke placeholder til å vise hvordan du vil ha dataen din. Formatteringen. Og der sa vi sist gang, maskering, i stedet for å bruke reelle data, så bør du bruke underscore. Hvis du vil ha telefonnummer på tre to tre-måten, så skriver du underscore tre ganger, mellomrom …

Erling: Og gjerne i passordfelt, nei, dum idé.

Anders: Og så kan du bruke placeholder som gjøres i Google Material. At labelen står der men hopper opp, noe som de nå har åpnet for to varianter av, at du kan ha fast på toppen.

Erling: Jeg har aldri likt det mønsteret der.

Anders: Ikke jeg heller, men jeg har tenkt at du begynner å bli gammel, Anders.

Erling: Nå trodde jeg du skulle si at nå begynner du å bli gammel, Erling, som òg stemmer forsåvidt.

Anders: Vi hopper videre. Vi kan bruke title-attributtet til å gi mer informasjon. Og title-attributtet vil i de fleste nettlesere bli en liten tooltip som hopper opp, og som hjelper. Det som er litt dumt med det, er at du ikke får noen indikator på at det ligger mer informasjon bak det du stiller deg spørrende til. Så hvis du ikke hovrer over det du lurer på, så får du ikke den informasjonen, så den er litt vel skjult.

Erling: Og her går det an å kombinere ting, altså du kan legge en indikator på de feltene som har et title-attributt, for å vise at det er mer informasjon. Da er du behjelpelig til de som bruker skjermlesere og de som ser det.

Anders: Og så har vi dette med gjenbruk av informasjon. Eller hente informasjon automatisk. Hvis du skriver ut poststed automatisk når brukeren har skrevet inn postnummer. Dette er en hjelpende hånd, men ikke en offisiell teknikk.

Erling: Og det treffer ikke strengt tatt dette suksesskriteriet, men det er ikke i dette kriteriets ånd. Det samme med autocomplete.

Anders: Det samme med å bruke informasjon som du har. Hvis du er innlogget som bruker, og skal fylle ut et skjema, så forventer du som bruker, at det som kan fylles ut automatisk, er fyllt ut automatisk.

Verktøy

Erling: Verktøy, kan vi automatisere dette? At vi bare kjører det gjennom, å finner ut at her er det noe som ikke forstås?

Anders: Nei. Dette er én av mange kriterier som vi ikke kan få opp svar fra en automatisk tjeneste. Her må du manuelt gå gjennom. Det er jo en subjektiv sak, for tolkning. Krever dette feltet ekstra forklaring eller ikke?

Erling: Igjen, brukertest.

Andre situasjoner

Erling: Er det andre situasjoner hvor dette her er bra?

Anders: Det å ha fokus på å hjelpe folk gjennom et skjema er jo generell god brukervennlighet. Det å hjelpe folk gjennom et skjema, gjør jo òg at flere klarer det, og da øker konverteringsraten.

Erling: Hvis du vil at folk skal fylle ut skjemaet ditt, så er det nyttig å fylle dette suksesskriteriet.

Må du?

Erling: Er dette lovpålagt?

Anders: Nei, dette er trippel A.

Erling: Hvorfor er den trippel?

Anders: Det er fordi at … nå er det jo bare litt spekulasjoner, men hvis det er noe som du ikke forstå, så kan du spør folk eller undersøke mer eller grave litt og så komme i mål.

Erling: Det er ikke noe som stopper deg 100 prosent.

Anders: Så hvis et skjema spør deg etter kundenummer, og du ikke har kundenummer, og du vet ikke hvor du skal finne det, så kan du likevel tenke deg til det, selv om det ikke står noe hjelpeinformasjon. Kanskje jeg skal gå, jeg har fått et brev fra disse en gang, kanskje jeg skal se på det brevet, om det står der hva som er kundenummeret mitt. Kanskje jeg skal logge inn, kanskje står det der.

Erling: Det krever litt mer av deg, men det stopper deg ikke.

Anders: Kanskje derfor er dette en trippel.

Erling: Men selv om du ikke må, så bør du.

Anders: Ja.

Aside

Erling: Så til en feil som er verdt mye penger.

Anders: Potensielt. Det er jo hypotetisk dette her. Det er fra en ganske ferske sak, på et nettsted som heter Cloud Four. Det er en fyr som heter Jason Grigsby som har laget en sak der han skulle bestille noe mat på Chipotle. Det er ikke en matkjede jeg har spist hos.

Erling: Nei, vi har den vel ikke her i området.

Anders: Det som skjer er at han finner de lekreste retter, sender inn en bestilling, kommer til kredittkortinformasjonen og fyller inn alt han har, og han får opp en feilmelding. Den er veldig generell, så den bryter de kriteriene vi har snakket om i de forrige episodene. We ran into an error submitting an order, please try againt. Når du får en slik feilmelding, så blir du sur, fordi du vet at det ikke funker å, sannsynligheten for at du har gjort en feil, og at det ikke hjelper å prøve igjen, er ganske stor. Men han her er en utvikler, så han gir seg ikke. Han går ganske dypt, han tar på seg detektivhatten, og han ser at det er et attributt på input-taggen som heter ui-mask, som ikke er et offisielt attributt. Det er et attributt som brukes av Angular som maskerer fire tall til to. Det vil si at i utløpsdato for kredittkortet sitt, så har han skrevet inn fire siffer, et årstall.

Erling: 2019 for eksempel.

Anders: I dette tilfellet 2023. Så har Angular maskert til kun 20. Men da blir kortet feil. Naturligvis, det er jo 23. Og det får jo ikke han beskjed om. Han får ikke beskjed om at utløpsdatoen som er feil. Han prøver flere ganger, og det samme skjer jo. Så går han litt i dybden, og ser at her har de brukt javascript til å gjøre noe som HTML 5 har. De kunne har brukt to attributter som heter pattern og maxlength. Og de kunne ha brukt et regulært uttrykk i pattern, backspace d, backspace d for de interesserte, så hadde dette fungert. Så her har du lagt på javascript unødvendig. Og så er det jo litt humoristisk, eller ikke så humoristisk for Chipotle. Han har gjort et matematisk tankeeksperiment, der han sier, sier at de har én million transaksjoner i uken.

Erling: Og den ene millionen er ikke noe han har dratt ut fra rompa, det kommer fra Chipotle sin egen …

Anders: Nei, det er ikke helt ut av det blå. Så sier han at de taper et halvt prosentpoeng, et tall de har tatt fra luften.

Erling: Vi kan diskutere det, men for å fullføre …

Anders: Det blir 5000 transaksjoner i uken. Så har han funnet snittverdien på en bestilling, som er 17 dollar. Så da har han funnet ut at det er 85 tusen dollar i uken. Og ganger du det med 52 igjen, så får 4,4 millioner dollar, som han mener at de kanskje burde kunne spart på å gjort HTML skikkelig. Og dette går jo ikke på det som vi har snakket om i dag, men det går mer på dette med god …

Erling: God skjemadesign.

Anders: Og semantisk kode.

Erling: Og ikke bruke avansert funksjonalitet når du har eksisterende funksjonalitet i HTML og så videre.

Anders: Så sier han jo «hei Chipotle, hvis dere synes at denne artikkelen her er verdt 4,4 millioner dollar, så tar jeg gledelig i mot litt penger fra dere Eller så kan firmaet mitt få lov å hjelpe dere bittelitt.»

Erling: Her har du et firma som har én million bestillinger i uken, da betyr disse små tingene veldig mye. Og her snakker vi om konverteringsoptimalisering. Men det som ikke blir nevnt, er hvor dumt det er for de som ikke klarer å bestille, det er jo snakk om å ekskludere folk. Du ekskluderer jo de som ikke klarer å fylle ut dette skjemaet.

Anders: Og du føler deg dum, og får dårlig selvbilde.

Erling: Vi kan dra den langt. Men 4,4 millioner dollar.

Anders: På et attributt.

Ris og ros

Erling: Så har vi dagens ris og ros. Bemanningsbransjen. Hvor skal vi begynne?

Anders: Vi begynner med litt ris til et selskap som Hytech. Eller jeg vet ikke om det uttales Hitech, for det skrives Hytech med y. De har en CV-løsning som heter proweb. Jeg vil si at dette er, nå har vi letet etter feil. Dette er ikke krise. Men de har …

Erling: Ikke på disse suksesskriteriene, men det er andre ting som vi ikke skal snakke om.

Anders: Det har vi gjort i tidligere episoder nå, vi har sklidd litt ut. Vi prøver å holde oss litt på sak. De spør etter adresse og de spør etter adresse 2.

Erling: Skal de ha adressen til hytten, eller?

Anders: Eller er det en ekstra linje hvis du ikke får plass i den første? Eller hvis du bor forskjellige plasser?

Erling: Er det sånn faktura- og leveringsadresse?

Anders: Er det som skiller det? Det tenkte jeg ikke på.

Erling: Det er ikke så lett å forstå hva denne adresse 2 er for noe.

Anders: De skulle hatt hjelpeinformasjon, eller enda bedre, beskrevet det. Hva det faktisk er.

Erling: I ledeteksten, i labelen.

Anders: Hvis det var leveringsadresse, noe jeg ikke tror det er i dette tilfellet.

Erling: Nei, vi dro det litt langt.

Anders: Vær litt tydeligere. Adresse 2 er ikke entydig.

Erling: Det kunne være at den første var adresselinje én, og den andre var adresselinje to. Eller at en hadde et flerlinjefelt. Textarea kunne ha løst dette.

Anders: Sannsynligheten for at de trenger dette feltet er nok liten. Løsningen er nok å kutte det.

Erling: Fjerne feltet i sin helhet. Det er ikke noe krise dette.

Anders: Og så har de et annet felt der de vil ha et bilde.

Erling: Da kan jeg laste opp bilde av bilen min?

Anders: Nå gjør du deg vrang. I en kontekst av å registrere en CV så forstår du at det ikke er bilen de vil ha.

Erling: Hvilket bilde vil de ha? Jeg skjønner jo at de vil ha bilde av deg. Men de kunne være mer spesifikk på. Det kunne være bilde av CV-en.

Anders: Det er jo personalia, jeg forstår at det er bilde av meg, men det de kunne gjort, er å fortelle hvordan de har tenkt å bruke dette bildet. Det er forskjell på om det er et bilde de skal bruke internt i sin interne database, eller om det er noe de skal presentere eksternt, som kommer ut på nettstedene.

Erling: Eller på adgangskortet.

Anders: Har du et greit mobilbilde for hånd, skal du laste opp det, eller skal du vente til du får et litt mer presentabelt bilde.

Erling: Skal du laste opp passbildet ditt eller bilde sammen med kompisene dine foran bilen din.

Anders: Der kunne de ha vært litt bedre. Og så har de en egen fane med et felt som heter fritekst. Der vil jeg si at det er bra, for du har sikker spørsmål eller kommentarer som du ønsker å stille i en slik situasjon. Men her ville jeg hatt mer kjøtt på beinet. Hva ønsker de, hva forventer de? Hvilken type informasjon skal du skrive her? Hva skal du ikke skrive i dette feltet?

Erling: Her står det fritekst. De kunne vært mer spesifikke. Kommentarer til din CV eller et eller annet.

Anders: Oi, nå ble det litt dunking og ulyder. Vi lukker døren.

Erling: Litt lekne hunder.

Anders: Så litt mer, hva forventer du her? Gi ut en hjelpende hånd.

Erling: Nettopp. Men vi må si at de fleste feltene her er ganske forståelige. Det er navn, fødselsnummer, adresse og så videre. Felt som ikke trenger hjelpetekst.

Anders: Så kan vi nevne poststed, du må skrive det inn.

Erling: Selv om du har postnummer.

Anders: Ikke krise, de fleste gjør det på denne måten. Litt rart for det er så unødvendig.

Erling: Ja, for har du postnummer så vet vi hva poststed er.

Anders: Postnummer er entydig, det kan du òg søke opp med et tilgjengelig API.

Erling: Hva med Manpower?

Anders: Der har jeg ikke kommet inn i selve kjernen.

Erling: For de krever at du lager ny bruker før du får sett skjemaet.

Anders: Og der har de et passordfelt som ikke forklares. De skriver bare passord.

Erling: Og gjenta passord. Men la oss ikke skli ut.

Anders: Det som er litt morsomt her er at de har mange regler for hva passordet skal være. De står ingen plass. Ikke i en spørsmålsboble. Så hvis jeg skriver først et passord som ikke innfrir til én regel, for eksempel lengde. Hvis jeg skriver passord 1 2 3, så får jeg opp en feilmelding om at passord må være åtte tegn. Hvis jeg da skriver passord 1 2 3 4 5 6 7 8, så får jeg opp flere regler, om at det må være en stor og en liten bokstav, og at det må være en kombinasjon. Så de har flere regler, men de velger å eksponere dem steg for steg, som jo kan være bevisst, som kan være bra, men der jeg tenker, hvis du har slike reglemer, vær nå tydelig på dem med én gang.

Erling: For det er veldig lett å feile, for brukeren å feile her. Det er ikke nok informasjon.

Anders: Da vet vi at jo flere steg du får feil i, jo større frustrasjon er det for de som i utgangspunktet har problemer med å fylle ut skjemaet.

Erling: Hvis det er strevsomt å fylle ut, å skrive inn, så er det dumt å måtte innom så mange steg.

Anders: Så kan vi si, selv om vi ikke er en sikkerhetspodkast, så er det en falsk trygghet å sette opp slike regler. Men den trenger vi ikke å ta nå.

Erling: Adecco da?

Anders: Da skal vi over til litt ros. De er de ledige stillingene til Adecco. Der har de et ganske godt autoforslag i søket sitt, som gjør at vi sparer mye tid, du kan se hva de har, hvis du skriver litt sakte, så får du opp muligheten til å velge ett av alternativene som dukker opp. Så er det litt rart å gi ros til dette, med det er sett i lys av Manpower. De har samme type regler. De har skrevet dem, men kanskje litt for detaljert. Det blir litt mye informasjon.

Erling: Det er en felle vi må være bevisst på i dette kriteriet. Vi kan bli for behjelpelige.

Anders: Her kunne de ha gjemt dem bak et spørsmålstegn.

Erling: Og de kunne òg ha skrevet dem på en enklere måte.

Anders: De har blant annet listet opp alle spesialtegn, skrevet med c, alle spesialtegn du kan bruke, utropstegn, dollar, stjerne, komma, bindestrek.

Erling: Det ser veldig rotete ut.

Anders: Kolon, slash.

Erling: Den morsomste er den på slutten.

Anders: De har et eksempel til oss. Et passord som innfrir reglene sine.

Erling: Igjen, dette er ikke en sikkerhetspodkast, men akkurat det der tror jeg er en veldig dårlig idé. Jeg lurer på hvor stor prosentandel av alle som har laget konto, som har det passordet.

Anders: Det hadde vært interessant å vite. Så hvis sikkerhetssjefen i Adecco hører på nå, så vil vi vite det, hvor mange bruker ki2009!vaa.

Avslutning

Erling: Så, det var dagens relativt korte episode. Vi pleier å si tre ting vi skal huske. I dag er det én. Hva er det?

Anders: Forklar utydelige felt, hvis du må ha utydelige felt eller utydelige ledetekster, men det beste er å unngå det.

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

Anders: Da skal vi snakke om korrekt HTML.

Erling: Men det snakket vi om 1.3.1?

Anders: Nå skal vi snakke om gramatikken, og vi har snakket om semantikken.

Erling: Nå snakker du avansert.

Anders: Vi skal snakke om syntaks.

Erling: Det kommer vi nærmere innpå i neste episode. Som vanlig, send oss kommentarer. Ris, ros, hva det måtte være til hei@universeltutformet.no. Det var det vi hadde i dag. Jeg er Erling fra Okse.

Anders: Jeg er Anders fra Webstep. Takk for at du hørte på!