UU-podcasten:Universelt utformet

Innledning

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: Hei Anders.

Anders: Hei Erling.

Erling: I dag skal vi snakke om WCAG 2.5, i episode 16. La oss begynne med det første, hva står 2 og hva står 5 for?

Anders: 2 står for mulig å bruke.

Erling: Operable.

Anders: 5 har vi oversatt til inputmetoder.

Erling: På engelsk er det input modalities.

Anders: Nei. Jo, det er det.

Erling: Nå trodde jeg at jeg sa feil her.

Anders: Nei.

Erling: Hvilke suksesskriterier har vi?

Anders: Først vil jeg si at dette er siste episode om prinsipp 2, og vi gjør oss ferdig med 5-en. 5-en er jo en retningslinje som er ganske ny. Kom i versjon 2.1. Vi avslutter, det blir en milepæl. Vi skal gå over til 3 i neste episode.

Erling: Nå er det bare 3 og 4 igjen etter denne episoden.

Anders: Vi er jo over halvveis i episoder, nå nærmer vi oss halvveis på prinsippnivå.

Erling: De tre suksesskriteriene vi skal snakke om i dag, hva handler de om?

Anders: De er helt adskilte.

Erling: De er ikke knyttet til hverandre?

Anders: Altså, de er inn under samme retningslinje, men de er ganske adskilte. Og den første 2.5.3 handler om ledetekst i navn, det er Difi sin oversettelse. Det betyr at du skal ha samme kodete og visuelle navn på komponenter. Menyer, lenker, knapper, skjemaelementer.

Erling: Hvorfor det?

Anders: Fordi hvis du skal henvise til noe du ser på skjermen, med for eksempel en inputmetode som kan være stemmestyring, så må det være samsvar, eller så vil det ikke fungere.

Erling: Nettopp.

Anders: Så skal vi snakke om 2.5.5, som handler om trykkflate. Der kommer navnet fra dagens episode som vi har kalt for pølsefingre, den sier veldig tydelig at du skal ha minimum 44 ganger 44 CSS-piksler på trykkbare ting. Og så har vi en 2.5.6, flere inputmetoder samtidig, eller vekslende. Den er ganske smal, så den skal vi ikke snakke så mye om.

Erling: Jeg har ikke slitt med å forstå hva den betyr, men jeg sliter med å forstå at noen kan bryte den.

Anders: Det finnes nok eksempler på det, men det skal vi komme tilbake til.

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

Anders: Hvordan skal du få uu på agendaen på arbeidsplassen eller i produktet ditt?

Erling: Det er et spennende emne. Og i ris og ros, hvem skal vi rise og rose.

Anders: Da skal vi se på drosjebilene.

Erling: Taxi.

Hvorfor?

Erling: Hvorfor har vi disse suksesskriteriene?

Anders: Nå er jo stemmestyring mer og mer populært.

Erling: Det blir mer og mer aktuelt. Det er òg en teknikk som tilgjengeligjør ting for flere.

Anders: Hovedgrunnen til at vi har 2.5.3 er at vi skal ha mulighet til å styre grensesnitt med stemmen. Her er det viktig at vi snakker om grensesnitt. En personlig assistent har jo ikke et grensesnitt. Visuelt grensesnitt. Det er ikke det vi snakker om her. Det er at du bruker tale som et alternativ til mus og tastatur.

Erling: At du ser en løsning på en nettside eller app, og du aktiverer en handling.

Anders: Men det er òg veldig nyttig for de som er seende og bruker skjermleser, for da vil det gi mer mening. Denne her treffer ikke de som ikke er seende, som bruker skjermleser, for de forholder seg ikke til det som skjer visuelt, så da kan det godt være et avvik.

Erling: Nå er jeg på litt tynn is, kan det ikke treffe dem dersom de snakker til en seende, over telefon, og referer til et element?

Anders: Jo, hvis de snakker med en seende. Da er det seende med i brukerreisen.

Erling: Nettopp. Og 2.5.5, som går på 44 ganger 44 piksler, hvorfor har vi den?

Anders: Den har vi fordi det skal være lett å treffe, vi skal ikke bomme. Hvis vi har nedsatt motorikk eller store fingre, eller om vi er i omgivelser som skjelver, som rister. Hvis du står på bussen eller trikken og det dunker litt.

Erling: Eller du springer og skal bytte sang. Hva det måtte være.

Anders: Det er noe som jeg regner med at alle har kjent litt på, at det er for små knapper til at en klarer å treffe dem på mobilen.

Erling: Dette er noe en har prekt i alle år. Som vi sa innledningsvis, dette er et nytt suksesskriterie i WCAG versjon 2.1, men dette er god praksis.

Anders: Og Apple og Google har hatt det i sine retningslinjer lenge. De har ikke nøyaktig 44 ganger 44, men det ligger rundt der.

Erling: Jeg sjekket, jeg lurer på om Apple har 44 ganger 44.

Anders: Er det Google som har 45 da?

Erling: Jeg vet ikke. Jeg vil gi et viktig perspektiv på dette, på trykkflater, som går litt på dette med fuck WCAG. 44 ganger 44 piksler er ikke en representasjon av hvor stort det faktisk bli på skjermen. Det er størrelsen på skjermen, altså trykkflaten på skjermen, som er viktig her, mer enn pikslene.

Anders: Men grunnen til at de har brukt piksler synes jeg er bra, for hvis de hadde skrevet det i en fysisk størrelse, i centimeter, så ville det vært umulig å implementere. Du kan ikke sikre at noe blir x antall centimeter på en skjerm, for du vet ikke hvilken oppløsning brukeren sitter på.

Erling: Jeg skjønner den, men relativt nylig var jeg med på et prosjekt hvor det var definert hvilken enhet de skal bruke, tegnet opp ting i henhold til WCAG selvfølgelig, og 44 ganger 44, men det var jo en Windows-tablet med 1920 ganger 1080, altså en hinsides høy oppløsngning. Så 44 piksler ble bittelite. Da måtte vi jo blåse det opp mye mer, for at det skal være stor nok trykkflate. En må være bevisst på det òg. Mobilprodusentene, Apple og gjengen, de har det som kalles faux resolution, altså da har du den faktiske oppløsningen på skjermen som er skyhøy, men så har de òg denne faux, som ivaretar disse 44 ganger 44 pikslene. På moderne mobiler går det fint, men for eksempel en Windows tablet så må en være ekstra påpasselig.

Anders: Men ja, det må være stort nok. Jeg er helt enig. En kan måle med et måleverktøy, men la oss teste det i tillegg.

Erling: 2.5.6 som går på inputmetoder, hvorfor har vi den.

Anders: Hvis du velger en inputmetode, så skal det ikke utelukke en annen. Så hvis noen kobler til et tastatur på en mobil, så skal ikke touchfunksjonaliteten på mobil forsvinne. Dette med å kombinere ulike inputmetoder har en gjort i lang tid.

Erling: Tastatur og mus er jo en kombinasjon.

Anders: Nå blir det enda mer aktuelt, nå som 2-i-1-PC-er kommer, nettbrett og bærbar PC.

Erling: Som dattera mi som har en Chromebook på skolen, hvor hun bytter på å trykke på skjermen, skrive med tastaturet og bruke touchpaden.

Anders: Det skal være mulig. Det har vi vel vært enige i at det er vanskelig å finne eksempler som bryter med dette. Det er vanskelig å bryte det. Det blir mer på veldig spesifikk applikasjoner hvor du krever en type input.

Erling: Det er en viktig suksesskriterie som vi bør være bevisst på. Jeg vil ikke prøve meg på eksempel engang.

Anders: Vi er ferdig med den, vi tar den ikke i ris og ros-spalten heller.

Hvem

Erling: Hvem må passe på disse suksesskriteriene?

Anders: Det er stort sett kodere i dag. Dette med trykkflate må designere tenke på, i den grad at det må være plass til en trykkflate. Det som er viktig her, er at det ikke er det visuelle som skal være 44 ganger 44 piksler. Du har lov å ha et lite ikon, så lenge trykkflaten, altså det interaktive området er stort nok..

Erling: Luften rundt kan brukes som en del av trykkflaten.

Anders: Ja! Det var godt sagt. Men hvis du designer masse små ikoner ved siden av hverandre, så ødelegger du for koderens mulighet til å utvide trykkflaten. Designeren har en rolle, men ikke en stor rolle, vil jeg påstå.

Erling: Jeg er litt uenlig.

Anders: Så gøy.

Erling: Litt for det du sier der, det må være nok luft rundt, en må være bevisst på det, en må sette fokus på det, for koderen. En typisk felle er at vi lager en meny på toppen hvor det i utgangspunktet kun er tekst på en linje bortover, hvor intensjonen til designeren, eller det ser ikke ut som om trykkflaten skal være større enn teksten i seg selv, men designeren intensjon har vært at hele høyden skal være trykkflaten. Da må designeren presisere dette ovenfor koderen.

Anders: God designdokumentasjon, eller?

Erling: Et bevisst forhold til det.

Hvordan

Erling: Hvordan kan vi være i henhold til disse suksesskriteriene?

Anders: Dette med ledetekst, visuell og kodet, at det er samsvar der, der er det jo bare å bruke samme ord eller begynne med samme ord.

Erling: Har du et eksempel?

Anders: Ja, hvis du har et søkefelt som det står søk visuelt og så har du en tilgjengelig tekst eller en ledetekst, for eksempel med aria-label som heter «Finn produkter», så er det ikke samsvar.

Erling: De bruker «Finn produkter» og placeholderen sier «Søk».

Anders: Så hvis du sier med stemmestyring, «Gå til feltet søk», så vil ikke datamaskinen kunne vite hvor det er, han finner ikke det.

Erling: De bruker et begrep som heter accessible name, kan du fortelle litt om det?

Anders: Det er det navnet som er i tilgjengelighetstreet. I tilgjengelighetstreet så har du forskjellige nivåer av informasjon som er oppfattbart av klienter eller UA-er.

Erling: User Agent, altså nettleseren eller mobilen.

Anders: Så hvis du bruker Chrome og Devtools, og inspiserer elementer, så har du til høyre en fane som heter accessiblity, og der får du se treet. De verdiene som står der, det er det vi kaller for accessible name. I sin enkleste form, når du bruker korrekt bruk av label på et skjemaelement, så er det verdien inne i label-taggen som er accessible name.

Erling: Og da trenger du ikke å gjøre noe ekstra her, da trenger du ikke å tenke på det.

Anders: Veldig ofte på skjemaelementer, så er det samsvar mellom det visuelle, altså det som står på labelen, og det kodete, altså accessible name. Det er lett å bli forvirret her, for dette har ikke noe med name-attributtet å gjøre.

Erling: Jeg var forvirret her.

Anders: For name-attributtet brukes ikke som accessible name.

Erling: Det er kun programmatisk vi bruker name og id og for og disse greiene her. Det har ikke noe med dette å gjøre.

Anders: Så ID-en til et komponent vises aldri i tilgjengelighetstreet. Nå kan folk bli forvirret, men ID-en til et felt vil ikke bli lest opp av en skjermleser, for å si det enkelt.

Erling: En måte å teste det på, for å finne ut om en type element er en del av accessibility-treet er å teste med en skjermleser og devtools i nettleseren.

Anders: Nå overforklarte vi det kanskje. Dette er logisk, dette er naturlig å gjøre.

Erling: Dette er ikke noe du feiler på hvis du ikke tenker på det. Men jeg måtte snu hodet mitt rundt det, så jeg tror det var greit at vi snakket gjennom det òg.

Anders: Et annet eksempel jeg kan ta, er dersom du har en knapp som er et bilde, og du har et annet begrep i alt-attributtet enn det bilde viser, så vil alt-teksten være accessible name.

Erling: Så hvis du har en knapp med et bilde det står søk, og alt-teksten er søk, så vil du være i henhold til denne suksesskriterien, men du vil bryte en haug med andre.

Anders: Tja, egentlig bare én tror jeg. Det var det. Vi skal så vidt komme innom denne på ris og ros, men som sagt er det lett å være i tråd med denne. Da hopper vi videre til den du kan mye om.

Erling: Én jeg har vært bevisst på veldig lenge, trykkflate og trykkflatestørrelse. Her er det jo verdt å presisere at har du en lenke som en del av en tekst, så treffer ikke denne suksesskriterien.

Anders: Så du må ikke ha 44 piksler i linjehøyde, det ville jo vært urimelig.

Erling: Det er vel derfor de har sagt det, det hadde vært urimelig. Det hadde vært greit å ha en større trykkflate, men de ser at det ikke er rimelig å be folk om å lage så høye linjer.

Anders: Et annet unntak her er jo, som jeg synes er rart, litt passivt unntak, det er hvis du har andre komponenter eller andre lenker til samme funksjon eller samme mål, som innfrir dette kravet, så er det greit. Det vil si at du kan kan ha en bitteliten logg inn-knapp i høyre hjørne, så kan du ha en stor logg inn-knapp i bunn, og ikke bryte kriteriet.

Erling: Det er et tilfelle hvor vi kan si fuck WCAG, for det bør du ikke gjøre.

Anders: Bruk sunn fornuft, det var å sette det på spissen.

Erling: Og så er det et tredje unntak. Det går på hvis du bruker standardelementer, hvis du ikke endrer på skjemaelementene eller knappene, så bryter du per definisjon ikke dette suksesskriteriet, men igjen, fuck WCAG, pass på at folk klarer å klikke på knappen eller elementet.

Anders: Hvis du setter inn et innskrivningsfelt og ikke har CSS og det blir mindre enn 44 piksler, så gjør du en dårlig designjobb, men du er i tråd med dette.

Erling: 2.5.6, hvilke teknikker?

Anders: Prøv å kombiner tastatur og … tastatur og mus fungerer som regel sammen.

Erling: Prøv å koble til tastatur til mobilen og se om du fortsatt kan trykke på skjermen.

Anders: Det vet vi er et ganske vanlig scenario, for blinde, som med hjelp av skjermleser lett kan navigere seg ved å trykke på skjerm, men å bruke et skjermtastatur er et mareritt, og da er det jo veldig viktig at løsningen fungerer med trykk på skjermen og mobiltastaturet.

Må du?

Anders: Må du følge dagens suksesskrierier, Erling?

Erling: Den ene. Skulle ønske det var flere. Den ene må du følge, det er 2.5.3 som går på ledetekster, eller accessible names, altså samme navn på de visuelle elementene og accessible name. Det er enkel A, den må du følge. Strengt tatt i versjon 2.1, WAD og alt det der …

Anders: Du har rett, det er ikke, når vi sitter her i slutten av august, så er det fortsatt ikke. Som Difi sier så ligger alt ann til at WAD blir en del av det norske regelverket. Følg den. Men den er ny.

Erling: 2.5.5 og 2.5.6, det som går på trykkflate og akseptere ulike inputmetoder, de er da overraskende nok, begge trippel A, det overrasket meg veldig. Spesielt den med trykkflater.

Anders: Jeg er enig.

Erling: Det har vært en tidlig retningslinje i mange år, og ting en har fulgt, fordi det gir mening, det er ikke så vanskelig å ikke følge det. Det kan være situasjoner der det er vanskelig. Nå er jeg ikke jeg noe ekspert på hvordan en skal vurdere graden, altså A-en i WCAG-systemet, men at den er en trippel A, det overrasker mer.

Anders: Jeg har en teori om hvorfor, den gjør det vanskeligere å bruke det, den gjør det ikke komplett umulig. Hvis du bommer, kan du fortsatt prøve én, to, ti ganger til og kanskje klare det. Mens de som er A, for eksempel med samme ord, hvis det ikke er samsvar mellom de begrepene, så klarer du ikke å bruke løsningen, du kommer deg ikke i mål.

Erling: Det er enklere å feile. Konsekvensene av å feile er større. Jeg kjøper den.

Anders: Hvis folk ignorerer den fordi den er trippel A, da har de ikke skjønt det.

Aside

Erling: Og i dagens aside. Da skal vi snakke om hvordan vi kan få universell utforming på agendaen. Nå høres det ut som om vi skal snakke om store ting, og det er litt stort. For det er jo viktig.

Anders: I det daglige så er det lett å gjerne nedprioritere og glemme.

Erling: Og hvis en ikke har det som en del av arbeidet sitt, så er det jo bare én ekstra ting som forsinker en allerede travel hverdag – må jeg gjøre uu òg? Så det er kanskje ikke så lett å få det på agendaen. Og når jeg sier agendaen, så er det jo å få organisasjonen til å si at uu er viktig. Men det viktigste er at de som sitter og utøver faget.

Anders: At det er en kultur for det.

Erling: At frontendere og designere og innholdsfolk og sånn, de tenker naturlig på uu. Og skjønner hvorfor det er viktig.

Anders: Hvordan får vi det på agendaen? Jeg regner med at de som hører på nå er litt interessert, og det er mange som sliter med det, at de føler seg litt alene i denne kampen.

Erling: Ja, det har jo både meg og deg kjent på. Og det viktigste rådet av de alle er jo å få folk til å høre på denne podkasten. Men snakk om det, ikke slutt å snakk om det. Ikke slutt å sette fokus. Fokuser gjerne på viktigheten og konsekvensen av å ikke ha fokus på det. Vær bevisst og kommunisere på hvor mange det rammer, at folk faktisk ikke kan bruke løsningen. Og hvis du snakker med folk som er veldig forretningsfokuserte, kan du si hvor mange penger en har tapt.

Anders: Det er ganske vanskelig å snakke om penger. Noen ting er ganske, kan jo bli dyre, som vi har snakket om, det er vanskelig å regne på det, hvor mye du får igjen, klart hvis en ser på det totale antall, andel av mennesker som har permanente, midlertidige eller situasjonsbetingede utfordringer, så går det ikke ann å ikke tenke på det.

Erling: Nei, og noen har prøvd å sette et tall på det. Vi snakker gjerne om 20 %. Én av fem. Og det er klart at det er ikke én av fem som treffer alle suksesskriteriene samtidig. Én ting er pengene, en kan argumentere for bøter, du får bot hvis du ikke følger dette, du bryter loven, osv. Det er et dårlig argument, for da fokuserer du ikke på det som er viktig her, det er jo brukerne, det er det samfunnsansvaret vi har, å gjøre ting tilgjengelig for alle. Den andre siden av det er jo at du ekskluderer folk, hvis du ikke fokuserer på det, så ekskluderer du en del av befolkningen. Du sier at de ikke er viktige, vi vil ikke at dere skal bruke de løsningene vi lager.

Anders: Vi må være inkluderende.

Erling: Inkluderende og pragmatiske. Altså, tenk løsning, ikke fokuser på alt som ikke fungerer når vi snakker om uu. Når du sier at den trykkflaten ikke er stor nok, hva om vi gjør slik? Hva om vi designer på denne måten? Vær pragmatisk, vær løsningsorientert. Ikke vær den som skaper trøbbel, da vil folk få avsmak fra uu. Så hadde du en god idé.

Anders: Ja, det har jo vært et generelt råd at du skal ha det med innledningsvis i prosjektene, du må ha det med i kravspekken, du må ha noen avsjekker underveis. Og det er viktig, å ha uu som en del av dokumentasjon eller kravspesifikasjonen til en løsning. Men hva med å ta det enda tidligere? Å enten ta det med i stillingsutlysninger.

Erling: Drive litt lobbyvirksomhet, for å få det med som en del av kompetansekravene når en ansetter designere og frontendutviklere spesielt.

Anders: Og jeg har tatt en sjekk på det tidligere, og det er få stillinger i dag som tar med dette som et krav, eller ønske. Ganske nylig så så jeg en stillingsannonse på en frontend-utvikler hos en lokal oppstartsbedrift her som heter Justify, og de tok med dette, de hadde en veldig fin stillingsannonse, og de tok med dette som et krav eller ønske, eller poeng.

Erling: Et lite perspektiv på det. Det kan jo være flere som leser det som tenker at de er dårlige på det, og tenker at de ikke kan søke på jobben. Det blir feil. Hvis de synes det er viktig, de trenger ikke å ha så stor kompetanse på det. Det er mer å være bevisst på det. Å annerkjenne at universell utforming er viktig, mer enn å kjenne til alle disse suksesskriteriene.

Anders: Enig, og du treffer aldri på alle punktene i en stillingsannonse.

Erling: En liten avsporing. En burde ikke treffe på alle punktene. Så gjerne åpne det opp litt, det hadde vært glimrende hvis du har kompetanse på universell utforming. Hvis ikke, ønsker vi at du skal få det hos oss.

Anders: Og du har ansvar for universell utforming i din del av leveransen, og så skal du støtte deg på resten av folket for å få det opp. Og så nevnte du jobbintervju, at HRHR bør …

Erling: Hvis en klarer å få det inn i stillingsannonsen, nå har ikke jeg så god kontroll på prosessen rundt stillingsutlysning, men ved å si at dette bør være en del av stillingsannonsen til HR, så skjønner de at det er en greie. Hvis de skjønner det, så tar de det med i andre jobbintervju. Hvis det blir satt fokus på det i jobbintervjuet, så smitter det kanskje ut i resten av organisasjonen. Fokus på uu på andre plasser enn design og frontent, så kan en få en helt annen forankring i organisasjonen.

Anders: Men nå Erling, nå har jeg fått med meg at Okse, ditt selskap, dere har ansatt folk i det siste. Har dette vært et tema? Har dere hatt det i stillingsannonsen? Har dere satt det som et kompetansekrav.

Erling: Nei. Det kunne vi absolutt ha gjort. Det er klart vi kunne gjort, men det er ikke like hensiktsmessig for oss, for mye av det vi gjør er ikke hands-on på UI og frontend. Men jeg er enig, jeg tar selvkritikk. Det burde vi gjøre.

Anders: Jeg visste ikke svare på det når jeg spurte deg.

Erling: Det er bra det. Ingen er perfekt. Selv ikke jeg.

Anders: Skomakerens barn.

Erling: Definitivt. Og dette er første gang, når vi snakket om det i dag, det er første gang jeg har hørt om ideen. Det er ikke at jeg aktivt har utelatt det. Men jeg likte det godt når du sa det. Det bør folk definitivt gjøre. Og et annet tips, hvis en jobber med persona, så kan et tips være å lage en persona som representerer universell utforming. Når jeg tenker persona hvordan de vil bruke en løsning. Hvis du har en persona som heter for eksempel Anders, han trenger ikke å ha alle verdens funksjonsnedsettelser for å kunne dekke det, men det er bare som et virkemiddel for å sette fokus. Så må vi huske universell utforming på dette.

Anders: Jeg synes persona er litt undervurdert verktøy. Jeg er glad i det, men det er så lite i bruk, i det minste i min hverdag.

Erling: Persona er som de fleste andre verktøy, det funker bra hvis en bruker det riktig. Det kan være et grep inn der. Som vi kan bruke for å sette fokus på universell utforming.

Anders: Håper vi har sådd noen frø om hvordan folk skal snakke varmt om dette.

Erling: Ikke slutt å snakk om universell utforming, selv om folk begynner å himle med øynene. Vær omgjengelig, vær pragmatisk, ikke vær han som går rundt å idealistisk preker WCAGs suksesskriterier opp og ned.

Anders: På rams. Fuck WCAG.

Ris og ros

Erling: Så til dagens ris og ros, Anders. Taxi. Drosje. Hvem er det vi har sett på i dag?

Anders: Vi har sett på, for å ikke være veldig lokale, vi har vært litt heldige. Stavanger og Oslo Taxi bruker samme løsning, så de har de samme feilene. I bestillingsskjemaet deres så er ledetekstene fra og til. Altså hvor skal du reise fra og hvor skal du reise til. De er ikke kodet opp mot inputfeltene. Dette er et brudd som får følgefeil her, så du klarer ikke å henvise til det med stemmestyring. Du kan ikke si «gå til fra-feltet», for fra er bare en tekst som ligger tilfeldigvis over det feltet. Så indirekte er det et brudd. På ledetekst-kriteriet. Det som er veldig gjennomgående. En gjennomgående feil på den 44 piksler-regelen. Det er rett og slett hovedmenyer, toppmenyer. Veldig vanlig at den består av kun tekst, og at den er for lav. Og det er selv om det er plass til større trykkflate. Det er viktig å nevne her, at for eksempel hovedmenyen til Stavanger … Faktisk så har Stavanger og Oslo forskjellig høyde på den hovedmenyen, henholdsvis 40 og 34 piksler høy.

Erling: Så noen har ment noe.

Anders: Ja, og det er litt rart når det ser ut til å være samme mal. Logg inn er kun 17 piksler høyt. Og her er det plass til mer. Det vil si at koderen kunne ha laget en padding uten at det hadde påvirket designet. Dette er ikke noe som ville ha endret utseende.

Erling: Det vil se helt likt ut.

Anders: Det vil kun bli bedre. Det har ingen negative konsekvenser, og det er ikke vanskeligere å gjøre det. Når en koder toppmenyer på den måten der, så vil jeg si at det er ren uvitenhet.

Erling: Ren uvitenhet.

AlexAnders: Blablabla.

Anders: Oisann, apropos stemmestyring.

Erling: Nå vet jeg ikke om dere hørte det, men Alexa var litt ivrig der.

Anders: Jeg har ikke sånn moderne smarthus hjemme jeg.

Erling: La oss gå videre på taxinæringen.

Anders: Men, for eksempel Stavanger, de har en mini innlogging, og så har de en stor innloggingsknapp på 200 ganger 50 piksler lengre nede. Så de slipper litt unna her, på grunn av det litt rare unntaket. Men så har jeg et annet eksempel, og det er språkvalget. Disse flaggene. Det er helt vanlig å bruke flagg. De er alt for små, altså 20 ganger 13 piksler. Men her kunne ikke koderen bare lagt på større trykkflate, for da hadde den overlappet. Så her måtte designeren ha, altså koderen kunne ha gjort det, men flyttet de lengre fra hverandre, men det er jo strengt tatt en designendring.

Erling: Han måtte ha endret på det visuelle for å få til dette.

Anders: Og så har vi en feil som er en slags gråsone. Og det er Taxi1. De har et søkefelt som ikke har label, som kun har placeholder.

Erling: Og det er et brudd i seg selv.

Anders: Ja, men ikke på dagens. Men det er klart brudd, at en placeholder kan ikke erstatte en label i uu-sammenheng. Men i denne sammenhengen kan det faktisk det, fordi placeholder er akseptert som det som vi kalte accessible name, du vil se placeholder i tilgjengelighetstreet.

Erling: Jeg er litt redd for at folk skal tro at siden vi sier at det er greit med tanke på dette suksesskriteriet, så er det greit å gjøre det, og det er det ikke. Nå snakker spesifikt i kontekst av dette suksesskriteriet.

Anders: Så i retrospekt, så kunne vi kanskje tatt denne sammen med den episoden der vi snakket om label og skjema. De har òg, som ikke treffer denne direkte, men de har òg en knapp som er en input submit som har ikon som et bakgrunnsbilde, og de har en value der som er rett og slett koden eller entiteten for hardt mellomrom, non breaking space, så det tilgjengelige navnet til den knappen er bare et space, så den vil du ikke klare å henvise til med stemme.

Erling: Da måtte jeg kanskje sagt «og n b s p semikolon.»

Anders: Jeg tror ikke det hadde gått. Veldig dårlig kodekvalitet på deres søkefelt. Så er vi på Bergen Taxi, de har gjort samme blemme som Oslo. Det vil si at skjemaelementene har ikke noe navn. Så hvis jeg sier «gå til feltet navn», så vil ikke datamaskinen forstå det, at det feltet heter navn.

Erling: Fordi det er ikke en del av tilgjengelighetstreet.

Anders: Vi tok med disse Lyft og Uber-tjenestene. De moderne. Vi har dem ikke i Stavanger enda.

Erling: Dessverre.

Anders: Og de kjører den klassiske feilen med for lav hovedmeny. Eller Lyft gjør det. Eller Uber og Lyft har bare 20 piksler i hovedmenyen. Lyft har placeholdertekst «enter mobile phone number» og name er «phone». Så det er ikke samsvar der. Phone brukes begge steder, men hvis du sier bare gå til phone, så vil ikke nødvendigvis det fungere.

Erling: Men hvis «enter mobile phone number» hadde begynt med phone, så hadde det vært i henhold.

Anders: Så du trenger ikke å ha 100 % samsvar, men du skal begynne med det. Ubers registreringsskjema, de bruker ikke label, kun placeholder.

Erling: Strengt tatt ikke et brudd på denne, men det er dårlig praksis. Og stygt.

Anders: Litt over til ros. Av alle de vi har snakket om nå, alle knapper er godkjente. Det vil si at de bruker button.

Erling: Er det òg godkjent på trykkflate?

Anders: Nei, nå er vi på ledetekst. Nå husker jeg ikke om jeg fant noen knapper med for liten trykkflate.

Erling: Men ledetekst.

Anders: Der er det vanskelig å feile, det er uvanlig å legge til ekstra tekst eller en annen tekst på den knapp, enn det du har i knappen.

Erling: Og det er ikke vanlig lengre å bruke bilde.

Anders: Så der er det generelt bra. Men på Uber har de en toppmeny og så har de en hovedmeny som er veldig fin. Der har de kombinert ikoner og tekst og der er trykkflaten veldig stor, 105 ganger 120. Der har de brukt en teknikk som er veldig fin, at all visuell tilgjengelig plass er klikkbar. All mulig luft er klikkbart. Litt slik nettavisene gjør, at hele boksen som omgir saken, tittelen, bilde og ingress, alt er klikkbart. Vi har Fitts lov som ikke direkte sier dette, men som er relatert til det, prøv å utnytt plassen.

Erling: Lite spørsmål, der er noen situasjoner hvor det kan irritere litt òg. For eksempel hvis du skal selecte deler av ingressen og lime ut, så klikker du på den.

Anders: Det kan løses, det må ikke bli slik.

Erling: Det går ann å hensyn ta den usecasen òg.

Anders: Men det er et godt prinsipp, spesielt på mobil. Men siste rosen går til Norgestaxi. Og jeg må si at av disse taxitjenestene, så må jeg si at Norgestaxi er flinkest på design. Der har de gjort akkurat det vi sa med høyde, selv om teksten ikke er så stor, så har de laget høy klikkflate. De har 49 piksler høyde i klikkflate. Bra, det er det vi vil ha. Så der har koderne til Norgestaxi gjort et solid håndverk.

Oppsummering

Erling: Det var dagens episode. Nå har vi noen ivrige hunder her. Vi må runde av. Neste episode, hva skal vi snakke om da?

Anders: Da beveger vi oss over til prinsipp 3. Vi skal snakke om språk. Om ulike språk, som norsk og engelsk, og vi skal òg snakke om godt språk, tydelig språk. Ikke stammespråk.

Erling: Det gleder jeg meg til, det blir bra.

Anders: Jeg òg, det blir en kjekk episode.

Erling: Som vanlig, det er så kjekt med kommentarer og innspill. Og ris og ros. Vi ønsker å bli bedre, så ris gjerne òg. Og måten du kan gjøre det på er å sende en e-post til hei@universeltutformet.no. Og så blir vi glad for stjerner i Itunes. Det var det vi hadde for i dag. Mitt navn er Erling fra Okse.

Anders: Mitt navn er Anders, jeg er fra Webstep. Ha det godt!