Uu-podcasten: Ulik

Introduksjon

Anders: Endelig i gang igjen! Ny podkastserie, Erling! Ulik.

Erling: Ulik, ja. Jeg skulle til å spørre hva den heter.

Anders: Ulik.

Erling: Vil du forklare det litt? Hvorfor Ulik?

Anders: Folk er ulike. Har ulike utfordringer. Vi skal snakke med ulike folk. Kun ulike folk, vi skal aldri snakke med de samme.

Erling: Og alle mennesker er jo ulike.

Anders: Ja, mangfold Erling. I dag har vi den store gleden av … Vi har tatt en litt pysete tilnærming. Vi har tatt en fyr vi kjenner. Vi starter litt mykt. Hvem er det, Erling?

Erling: Det er Frederick Rogers.

Anders: Frederick Michael Rogers.

Erling: Han har vel familie fra USA, men snakker kav stavangersk.

Anders: Alle ordene som er på engelsk, har han engelsk uttale på.

Erling: Korrekt, god uttale. Frederick, hva jobber han med?

Anders: Han er koder, utvikler i Altibox.

Erling: Mer spesifikt frontend-utvikler.

Anders: Vi inviterer ham jo fordi han har meninger om universell utforming.

Erling: Vi skal lære om hans arbeid, hans fokus, hans holdning til universell utforming.

Anders: Og hans ulike utfordringer.

Intervju

Samarbeid mellom designere og kodere

Anders: Én av de viktigste grunnene til at du ble invitert her … våre veier har krysset mange ganger, og en gang var etter at jeg hadde hatt et innslag eller noe om universell utforming, og så traff jeg deg noen dager etterpå, på gaten. Helt tilfeldig. Du kom bort til meg og var superengasjert, og så sier du «Vet du hva, Anders? Jeg har begynt å teste med en skjermleser, og vet du hva? De som bruker en skjermleser, de må ha det helt grusomt.» Og det er jo sant. Du viste en stor frustrasjon over at du hadde oppdaget at ikke alle bruker internett på samme måte.

Frederick: Det kommer jo litt i det som ligger i naturen av det å være utvikler. Det som interesserer meg er jo utfordringene. Det å løse et problem med et opphav i et behov, hvordan får vi det til? Og når jeg plutselig tenkte på skjermlesere, dette fikser jeg. Det er mye innhold å hente på nettsidene, dette kan vi jo bare presentere, det gir nok full mening. I den naive troen jeg hadde, fordi jeg ser og det jeg hører er veldig vanskelig å skille da jeg skrudde på skjermleseren og lukket øynene, da var alt bare kaos. Jeg kunne ikke gjøre de tilsynelatende enkle koblingene mellom lydene og det jeg så. Og da jeg prøvde å navigere rundt der, og hørte på responsen, så hadde jeg ikke snøring på hvor jeg var på denne nettsiden. Det er mange ord og setninger som kommer ut her, men de forteller meg nesten ingen ting.

Anders: Og jeg blir veldig glad over at du lukket øynene. For oss å teste en skjermleser med skjerm, og uten, er dag og natt. Nå er det faktisk en hurtighast på iPhone som skrur av skjermen når du sett igang skjermleseren. Det tar jeg meg selv i. 90 % av gangene jeg tester med skjermleser, og nå vi har testet i disse podkastene vi har hatt, Erling, så har vi alltid brukt med skjerm. Det blir ikke det samme. Du kan lene deg på det visuelle. Det er bedre enn ingenting, men det å lukke øynene … 

Frederick: Vi har jo snakket om dette tidligere, men én av tingene jeg ønsker i jobbsammenheng, er at hvis vi skal kjøre en skikkelig test, så må du finne noen som representerer målgruppen din, for å gi deg et realistisk perspektiv på det. For til og med når vi lukker øynene, så oppleverer du ikke nødvendigvis helt den samme frustrasjonen. For hvis alt går galt med skjermleseren, så kan jeg bare åpne øynene mine, så fikser jeg problemet. Hvis du ikke har den muligheten, så sitter du i en kjedelig situasjon der du er helt avhengig av denne skjermleseren og det arbeidet som har blitt gjort på denne nettsiden. Det er jo der litt av engasjementet mitt kommer, det er veldig frustrerende. Det er enkelt for meg, det er en situasjon som jeg mistenker er irriterende for noen. Jeg tenker at det må vi kunne løse. Her kommer min interesse. I jobbsammenheng prøver jeg å tenke så mye uu som mulig. Som vi kommer til å komme inn på, så er det litt utfordringer rundt dette.

Erling: Rundt hva da?

Frederick: Universal utforming på et teknisk nivå. En designer har veldig tydelige retningslinjer og måter å håndtere for eksempel farger på. Ikke at alt er så ekstremt tydelig, men jeg føler at kontrasten til utviklerne er større. Utviklerne må tenke i andre baner enn vi vanligvis gjør, vi tenker ofte veldig linært når vi lager eller strukturerer en nettside eller applikasjon, der du begynner på toppen og leser deg nedover. Vi gjør det jo med det visuelle som grunnlag. Vi plasser knapper og menyer rundt på denne siden, der vi forventer at det blir enkelt for de som bruker en mus, uten nødvendigvis å tenke på de som har utfordringer med bruken av enheter. De som ikke kan bruke mus, eller de som ikke kan bruke tastatur. Hvordan blir posisjoneringen eller koblingen mellom disse elementene, da bli mest mulig optimal?

Vi kan jo med tab-tasten på tastaturet, så kan du finne fokusområdene på nettsiden. Hvis du lager helt vanlig HTML uten å gjøre noe spesielt, så vil du jo tabbe i den rekkefølgen du har skrevet elementene. Så hvis du gjør ting skikkelig, så burde det være tilstrekkelig. Det er ikke alltid det. Det er alltid kompleksiteter. Du har en markedsføringsavdeling, du har forskjellige andre instanser som ønsker «ting», elementer rundt om på nettsiden som gjør at det å tabbe seg gjennom det, betyr at kanskje én person kanskje må trykke på den knappen 25 ganger før han kommer til den ene tingen han er ute etter. Han har vært på denne nettsiden, han er her tre ganger til dagen, han skal gjøre akkurat samme tingen og han vil komme til den knappen.

Det er her litt av jobben kommer inn, å finne ut hva de forskjellige trenger. Hva er de ute etter? Hva er behovene? Hva er bruksmønsteret her. Vi ser veldig mye på Hotjar og bruker sånne …

Anders: Kan du fortelle hva Hotjar er?

Frederick: Hotjar er et analyseverktøy som viser heatmaps. Et heatmap tar et gjennomsnitt av brukere og viser hvor brukerne har klikket. Det viser bruksmønsteret til gjennomsnittet av brukere. Du kan se hvilke knapper de trykker mest på, du kan se områder hvilke områder på siden som blir scrollet til mest. Det er jo nyttig, men det er jo tydelig for de som kan se nettsiden. Men hva med de som ikke kan se? Hvis du har hemninger med tanke på syn, så må du navigere basert på hva du hører. Hvor mange steg må du gjennom for å komme til der du er? Hva hvis det beste vi kan gjøre er å flytte noe fra én plass til en annen? Og du kan spare deg 20 klikk med tabknappen? Kanskje det er nok til å gjøre hverdagen til den personen så mye enklere? Og for oss koster det veldig lite, og for de kan det være veldig verdifullt. Det er den enkleste måten vi kan hjelpe.

Erling: Men du som utvikler, med litt bakgrunn som designer, langt tilbake, du hadde en interessant påstand her – jeg leste mellom linjene at det var mer komplisert for utviklere enn for designere å lage noe tilgjengelig.

Frederick: Med litt modifikasjoner. Jeg tror kanskje at dersom vi endrer fra designer til UX-er. En designer og en UX-er er jo litt annerledes. En UX-er har jo med utgangspunkt å gjøre ting så universelt utformet som mulig, lenge før du kommer til folk med diverse nedsettelser. De er allerede på det rette sporet, de trenger kun å gå litt dypere i det. Vi utviklere skriver kode sokm skal utføre en oppgave. Du trykker på en knapp, det skjer noe med den knappen, og så lenge det er gjort, da er vi fornøyde. Da har vi fullført oppgaven vår, det er ikke alltid at vi tenker på nødvendigvis hvordan denne boksen som dukker opp, ser ut. Det tar ikke vi så mye hensyn til. Det vi gjør er å tilrettelegge for at den dukker opp. Designeren skal kanskje utforme utseende på denne. Det vi ser mer og mer i sfæren frontend, så må vi som utviklere oftere adressere disse visuelle utformingene …

Erling: Du føler et ansvar blir lagt på dere?

Frederick: Ja.

Erling: Du beskrev det òg på en måte slik at det var linært. Du tar design av en side, og så implementerer du det slik det ser ut.

Frederick: Mer eller mindre.

Erling: Blir det feil fra et tilgjengelighetsståsted?

Frederick: Ikke nødvendigvis feil. Men jeg tror fort du hopper over viktige elementer der. Hvis du bare implementerer det du ser, så tenker du ikke nødvendigvis på alle aspektene med dette. Dette er et problem jeg opplever utenfor sfæren av universell utforming, generelt. Fordi det er typisk at du blir bedt om å lage en representasjon. Noen gir deg en tegning, så blir du bedt om å lage en kopi av tegningen, bare at vi legger til litt interaksjon. Det jeg ser at vi gjør nøyaktig det vi blir bedt om å gjøre, uten å tenke på de tingene som ikke nødvendigvis kommer tydelig frem i skissen, men samtidig må tas hensyn til. For min del så liker jeg godt å snakke med UX-erne før jeg begynner på dette, for å se om jeg har forstått intensjonen bak skissen. At jeg forstår hva formålet er, hvorfor ting har blitt gjort på denne måten.

Erling: Det du er inne på der, er semantisk HTML og tabrekkefølge og sånn.

Frederick: Stemmer. Nå har vi jo mye bedre verktøy enn det vi hadde da jeg først begynte. Da vi fikk en skisse så brydde vi oss ikke om det var en heading, om det var h1 eller h6. Hvilken type HTML var det? Vi bare lagte det vi. Det så fint ut på skjermen. Jeg er ferdig nå jeg.

Anders: Mange som gjør det fortsatt.

Erling: Verktøyene vi har nå til dags er så mye mer hjelpsomme. De forteller nøyaktig hva dette elementet er, denne visualiseringen, hvordan representerer vi den i form av HTML? Det hjelper enormt. Men det er ikke en 100 % fasit. Så vi må ha en god dialog med designer eller UX-er, eller de som produserte skissene for å være sikker på at du har en forståelse av intensjonen, er essensielt for at jeg skal kunne gjøre en god jobb.

Anders: Nå vet jeg at mange lyttere lurer på de verktøyene du nevnte. Hvilke verktøy bruker du? Det skal jeg komme tilbake til. Først har jeg to innspill til det du sa. Det første handler om at du måtte trykke 25 ganger for å komme ned til et element. Er det noe jeg har lært i løpet av de siste årene, når jeg har jobbet mye mer med uu enn jeg har gjort tidligere, så er det det effektive grensesnitt. Og det er et stjerneeksepel på at uu er bra for alle. Effektive grensesnitt er enormt viktig for de som sliter og bruker lang tid, og bruker hjelpemidler. Men det er òg navet i brukervennlighet. Noe som jeg har begynt å gjøre når jeg snakker med utviklere og designere, er å si at designere bør ta det mest kompliserte grensesnittet sitt, i løsningen de holder på med, å telle stoppene. Det finnes et tillegg til Figma, for de som bruker det. Det har jo blitt en bransjestandard, i følge UX i Norge. Eller hva heter den siste undersøkelsen din, Erling?

Erling: Design i Norge.

Anders: Der kom jo Figma veldig høyt ut, nå sist.

Erling: Stemmer det.

Anders: I Figma er det et utrolig kult tillegg, der du som designer definerer tabstoppene. Da får du nummerert dem med et lite ikon. Da blir det så visuelt tydelig hvor effektivt dette grensesnittet her er. Hvis du som utvikler får et design som du skal gjøre om til kode, og du ser at det ikke er effektivt, gå inn i en dialog – er det vits å ha fem ikoner for sosiale medier helt i toppen før hovedmenyen kommer? Det er fem trykk for en tastaturbruker. Det er fem intetsigende informasjonsbolker for en talebruker. Er dette et effektivt grensesnitt? Nei/ja. Kan vi effektivisere det? Det å oppfordre designere til å tenke gjennom dette, gjerne med et hjelpemiddel som du får i Figma. Jeg blir glad at du tar opp dette som et uu-tema, for dette er ikke normalt sett på som et viktig felt innen uu.

Vi har snakket om dette tidligere. Folk er veldig opptatt av å være i tråd med forskrifter, WCAG og alt det der. Du kan lage et utrolig ineffektivt grensesnitt og være i tråd med WCAG.

Frederick: Det er et veldig godt poeng. Jeg må ærlig innrømme at jeg ikke er så godt kjent med WCAG. Jeg tar utgangspunkt i de regelsettene som de har. Jeg tror WCAG har mer effekt på UX-ere og designere, fordi WCAG legger mye større vekt der enn det gjør for utviklerne. Samtidig er jeg helt enig med deg. Kanskje fordi jeg begynte karrieren min som designer, så har jeg litt større forståelse for hva som skjer når skissene skal bli utviklet. Jeg husker selv at jeg satt og designet i Photoshop, det var det vi gjorde back in the day. Før det var det Paintshop Pro. Da gikk fantasien av gårde, vi designet i alle retninger. Da jeg var superfornøyd, satt jeg meg ned og skulle implementere dette, da begynte hodepinen. Jeg hadde ikke tenkt i det hele tatt på hvordan dette skulle bli implementert. Flere ganger måtte jeg gå tilbake i skissene og justere skissene. Noe var helt umulig, eller så var det bare en forferdelig dårlig idé. Det er jo litt av det som er viktig, det er jo der dialogen mellom designere og utviklere må være god. De som lager skissene, det er jo ikke forventet at de skal ha en 100 % forståelse av implementeringsprosessen. Ikke alle kan være en ekspert på alt. Og det er ikke nødvendigvis det vi vil, heller. Når vi jobbe i teams, der vi har både utviklere og designere sammen på prosjekter, så tenker jeg at det enkleste må jo bare være å ha en dialog. Å kunne snakke sammen.

Erling: Og jeg liker godt det perspektivet du har der, både at designere og UX-ere tenker på hvordan opplevelsen er, hvordan det blir brukt. Mye blir «lost in translation» når det kommer til utviklerne.

Frederick: Ikke bare det. Når de allerede har begynt på det arbeidet, det smitter over på oss. I den dialogen, så spør jeg «hvorfor valgte du å gjøre det?» Så svarer de «ja, vi har sett via brukertester og basert på erfaring, så ser vi at å gjøre det på denne måten så vil kundene bli mer fornøyd.» Som utvikler tenker jeg da, «så flott, da vet jeg det». Det har blitt tatt hensyn til, da er det bare for meg å få dette til å fungere. Det gjør jobben min lettere, på mange måter. Det er en byrde som løftes av mine skuldre på mange måter. Da trenger ikke jeg nødvendigvis å gå gjennom den prosessen der. Da trenger ikke jeg å, nå har jeg glemt det norske ordet, å «second guess», jeg trenger ikke å betvile skissene, for da har UX-erne gjort det de skal. Jeg trenger bare å følge dette. Det gir en trygghet. Det er et samarbeid. Det er én av de kjekkeste tingene jeg gjør med jobben min, det er å samarbeide med UX-erne. Kanskje fordi jeg var tidligere designer og har en forståelse og forkjærlighet for prosessen.

Anders: Opplever du at andre ikke liker det?

Frederick: Jeg opplever av og til at det blir litt motstand. Av og til, under presentasjoner av skisser, der UX-er forklarer hvorfor noe er blitt gjort, så kan det av og til oppstå uenighet, der utvikler mener at det er unødvendig, kanskje. Det kan skyldes at et valg i skissene er veldig vanskelig å implementere. Da kan du få litt pushback. Det er ikke nødvendigvis helt feil det heller. Det må være en balanse. Vi som utviklere må være, på samme måte som UX-ere må være flinke til å fortelle oss hvordan og hvorfor vi bør bygge grensesnittet på denne måten, så må vi òg samtidig kunne fortelle designerene at her skaper vi en ekstrem byrde på teknologien. Hvis vi heller gjør det på denne måten, så blir det enten vanskelig for oss å vedlikeholde det, eller det kan være helt umulig å få det til. Nå skjer ikke det veldig ofte. Vi må ha den dialogen, rett og slett. Sammen finner vi ut hvordan vi får det til på best mulig måte. Det er et samarbeid, en synergi.

Verktøy

Anders: Skal vi gå til verktøy, som folk sitter og lurer på? Hva har du med deg i verktøykassen din?

Frederick: Jeg fant nettopp et fantastisk verktøy, som jeg på en eller annen måte har gått glipp av. Chrome har nå fått en accessibility tab i developer tools. Hvis du klikker på den, så kan jeg få opp antydede roller og alt mulig informasjon. Den er til fantastisk hjelp. Bare den siste uken her, så har den hjulpet meg.

Når det gjelder skjermlesere så har vi faktisk litt utfordringer rundt det. Fordi de fleste skjermlesere som vi prøver å teste med, støtter ikke norsk. De få som er på norsk må vi bruke på Windows-maskiner.

Erling: Du sitter på Linux?

Frederick: De fleste av oss sitter på Linux- eller Mac-maskiner.

Erling: Mac har jo veldig bra norsk skjermleser.

Frederick: Den har relativt god norsk. Den vi egentlig vil ha, nå husker jeg ikke navnet på den. Vi prøver å finne et standardverktøy som vi kan bruke. Vi burde ha satt oss inn i hvilke er mest populære. Nå vil jeg tro at iOS har et stort …

Erling: Dette kan du, Anders.

Anders: Dette kan jeg. iOS har desidert størst markedsandel på mobil. De knuser Android sin TalkBack. På desktop og bærbar så gikk NVDA forbi JAWS for første gang i historien. JAWS har vært den store skjermleseren. Den har gått nedover de siste årene. Nå er NVDA størst, og det er veldig fint, fordi den er gratis og har konkurrert mot store, tunge JAWS i lang tid. JAWS har vært litt utilgjengelig, blant annet fordi den koster mye penger.

Erling: Men NVDA, får du det til Linux?

Anders: Nei.

Erling: Bare Windows?

Anders: Ja.

Frederick: Det er fordi Linux har veldig snevert bruk utenfor bransjen. Det er et bransjeverktøy. Det er et fritidsverktøy, vil jeg si. Det overrasker meg ikke.

Anders: I podkasten Universelt Utformet så hadde vi en blind gjest, og han brukte Linux. Nå husker jeg ikke hvilken skjermleser han brukte.

Erling: Det husker ikke jeg heller.

Frederick: Det skal jeg finne ut.

Anders: Chrome har jo sin egen skjermleser som heter ChromeVox. (Dette er feil, den heter Screen Reader. ChromeVox er kun for Chrome OS. Den tipper jeg er tilgjengelig på Linux òg.

Frederick: Den gjør det. Sist vi prøvde den var det litt ymse støtte for norsk.

Anders: OK, det kjenner ikke jeg til.

Frederick: Nei, men vi holder på enda og utforsker. Det handler om å finne de rette verktøyene. Da du sa at NVDA og JAWS avviker fra hverandre, eller den ene overtar den andre, det bekymrer meg litt. Er det én ting vi vet om nettsider, hvertfall oss som har jobbet lenge nok i denne bransjen, når vi fikk flere nettlesere så ble livene våre vanskeligere. Alle nettlesere, mindre nå enn før, før så hadde de enormt avvik i hvordan de tolket koden vi som utviklere skrev, som …

Anders: Det var vel én nettleser som hadde stort avvik?

Erling: Størst hvertfall.

Frederick: Og den hadde størst markedsandel også.

Erling: På én måte var det ikke den som var avviket, det var de andre som var avvikene.

Anders: De som gjorde leksen sin, de avviket.

Frederick: Hvis du tenker på den gjennomsnittlige brukeren, så ville de vært enige med dere. Men vi som utviklere, vi som skrev koden, vi var veldig uenige. Vi mente at den nettleseren som avviket var feil på alle mulige måter.

Erling: Jeg mistenker at disse skjermleserene, fordi de er avhengige av den semantiske koden, så er avvikene mindre.

Frederick: Jeg vil tro det, ja.

Erling: Det er forskjeller der òg.

Frederick: De må tolke den samme semantikken som andre nettlesere, og det er absolutt rom for tolkning.

Anders: Det som jeg kan anbefale er å sjekke WebAIM sin skjermleserundersøkelse. De har gått grundig til verks.

Kognitive utfordringer

Anders: Jeg har ikke lyst at vi skal snakke så mye om skjermlesere, for det er så mye annet kjekt å snakke om. Noe av det jeg mener er at vi tre kan til en viss grad simulere det å være svaksynte eller blind. Det vi sier er at tester du på én blind, så tester du på én blind. Du har ikke testet på alle. Det å sørge for at ting fungerer i en skjemleser, det er forholdsvis enkelt. Det er gjennomførbart. Vi skjønner hva som skal til. Det som er mye vanskeligere å simulere, det du sa om effektive grensesnitt, og forstå hvor vanskelig det kan være å bruke noe dersom du har kognitive utfordringer. Vi kan ikke bestemme oss for å bli dyslektikere eller å få Asbergers, eller å få ADHD.

Frederick: Absolutt ikke.

Anders: Der tenker jeg at med gode rutiner, regler og prinsipper for enkle grensesnitt, for god brukervennlighet, for å følge konvensjoner, ikke å gå i kreative grøfter, er en viktig del av dette faget.

Frederick: Det er som du sier, det er litt utfordrende. Vi kan simulere det å være blind, vi kan lukke øynene og få et modicum av innsikt i hvordan den hverdagen er, men de andre kognitive utfordringene … Jeg kommer litt tilbake til dette med dialog. Du må ha en dialog med de brukerne. På samme måte som du har en dialog med, i mangel av et bedre uttrykk, «vanlige» brukerne. Hvilke utfordringer har de? Egentlig burde vi intervjue så mange forskjellige brukergrupper som mulig, og finne ut, hva er utfordringene? Hvis noen med ADHD sier at det hadde vært veldig flott hvis dere kunne flyttet det elementet eller den tekstblokken. De kan komme med et forslag, og så kan vi ta det til ettertanke og se om vi kan få til det, og se om det har en påvirkning. Og hvis det blir bedre, så er det bare å fortsette.

Samarbeid

Erling: Du sitter ikke alene og utvikler?

Frederick: Nei.

Erling: Hvordan er praten om universell utforming der?

Frederick: Hehe. Det er veldig morsomt. Jeg vil si at jeg trenger mer enn 100 % her. Det er 80 % engasjement, 60 % frustrasjon. Vi prøver. Vi engasjerer oss, og så blir vi fort uenige i hvordan vi skal løse noe. Etter en halvtime med diskusjon kommer vi frem til at vi ikke er de beste til å ta denne diskusjonen i det hele tatt.

Erling: Hva ender det opp med?

Frederick: Enten blir vi enige eller uenige. En typisk resultat er at noen sier at det ville vært bedre å gjort det på denne måten, og så må den personen som argumenterer komme med referanser. Eksempler. Større nettsider, hvordan løser de det? NRK for eksempel. Eller Språkrådet. Eller de statlige organene, som vi ofte bruker som eksempel. De prøver og de har ofte gode eksempler. Det som er det viktigste er å være åpen for å endre det senere. Du må prøve noe, så må du se hvordan det fungerer. Hvis det viser seg at det var feil, så prøver vi noe nytt. Gjør du det så vil du komme frem til det rette. Mye av dette er erfaringsbasert. Du har to veldig like utfordringer, og vi er fristet til å løse det på samme måte. Kanskje det ikke er best?

Teknisk om skjermlesere

Anders: Har du noen konkrete eksempler?

Frederick: aria-live er et spennende attributt for skjermlesere.

Erling: Hva gjør den?

Frederick: Mye av det vi gjør er å gjøre endringer på nettsiden som følge av interaksjoner.

Erling: Det skjer gjerne direkte på grunn av Javascript?

Frederick: Ja. Med bruk av Javascript kan vi trigge visuelle endringer på nettsiden. Du har et skjema der du skal fylle ut litt informasjon, så blir du plutselig presentert med et valg som utløser enda flere felt. Det er tydelig og synlig for de som ser det. Her har det dukket opp nye felt. Men hvis du er svaksynt er ikke det nødvendigvis like tydelig. Da kan en skjermleser være verktøyet som bistår deg med dette. En skjermleser tar i utgangspunkt i nettsiden som den er når den laster. Hvordan kan du da fortelle brukeren at det har skjedd noe? At det har oppstått en endring. Da bruker vi aria-live. Den gir oss mulighet til å overstyre skjermleseren til en viss grad. Indikere at her har det skjedd en endring. Du har tre valg mener jeg – polite og unpolite?

Anders: Assertive.

Frederick: Assertive var det ja. Og så har du en tredje der du skal ignorere det fullstendig. Når skal vi være polite og når skal vi være assertive? Den er ofte vanskelig å finne ut av. Når skal du gi et lite hint om en endring, og når skal du brøle og si ifra at har har det skjedd noe.

Anders: Det er veldig sjelden at du trenger assertive.

Frederick: Det er det vi har funnet ut, etter et par tester med skjermlesere. Ja, og det har mye å si hvor du plasserer dem òg. Midt i en gjennomgang av noe kan det hende at den bare stopper flatt. Og så har jeg opplevd at den ikke starter igjen. Dette må vi lære, og finne ut hva er den beste måten å gjøre ting på.

Tidsbruk

Erling: Hva tror du er hovedårsaken til at det ikke er bedre der ute, at det ikke er mer tilgjengelig?

Frederick: I alle jobbsammenhenger, uansett yrke, så skal du produsere. Ofte skal du produsere i et gitt tidsaspekt. Bedrifter som selger ting, vil jo helst at ting skjer i går. Siden uu, WCAG og disse nye standardene.

Anders: Nye?

Frederick: Nye og nye. Webben er treg. Vi adopterer ikke på strak fot, ikke nå lengre. Kanskje tidligere var vi mer villige ti å hive oss over alt som dukket opp. Nå er det en viss motstand. Spesielt der ting er tidskritiske. Da vil du alltid få spørsmålet hvorfor? Hvorfor skal vi gjøre dette hvis det medfører at jeg må bruke en uke ekstra på dette prosjektet? Hvorfor? Da må du forklare det.

Erling: Er det greit å forklare det?

Frederick: Ja, det er veldig greit å forklare.

Erling: Hvordan gjør du det?

Frederick: Jeg tar utgangpunkt i at de har en naiv tilnærming til dette, de har ikke tenkt gjennom det, de har ikke forstått utfordringen. Det er jo det. For de som ikke har disse utfordringene, eller nedsettelsene, så er det veldig lett å ikke tenke på det. Vi kan ikke klandre dem for det. Det er jo en utfordring i seg selv. Første skritt er å forklare hvorfor vi bør gjøre det på denne måten. Det gjør det lettere for den gruppen, eller den gruppen, eller den gruppen. Hvis de sier at den gruppen er så liten, det er bare 1 % eller 2 %. Da står du ovenfor statistikk. Da kan vi bruke argumentet som Anders ofte bruker – du må ikke tenke på individiuelle grupper, men heller tenke på dette i sin helhet. Det du gjør for den ene, vil sannsynligvis ha fordeler for den andre. Universell utforming handler først og fremst om å produktet bedre for alle. Der må vi begynne. Med én gang vi sier alle, så vil de endre seg. Da er det ikke 1 % lengre, da snakker vi om 100 %. Det er et tall som folk forstår og kan leve med. Det ser mye bedre ut i regnearket deres, sannsynligvis. Der begynner jeg.

Motstand

Erling: Møter du motstand når du setter fokus på det? Eller skjønner folk at det kan bety at ikke alle kan bruke det?

Frederick: Jeg skal være helt ærlig. Når vi først begynte med universell utforming i Altibox, så trodde jeg at vi skulle få mer motstand. Men det var relativt lite.

Erling: Var det noe?

Frederick: Det var noe, og jeg må innrømme at jeg var en del av den motstanden. Jeg tenkte «Hvorfor må jeg gjøre dette?» Det må ha et formål, og jeg må helst forstå det formålet. Takket være Anders, så er jeg veldig inneforstått med det nå.

Erling: Hva var det som fikk deg til å endre mening?

Frederick: Jeg må si at det som hjalp meg var de intervjuene du viste, du hadde noen videosnutter der du snakket med mennesker.

Erling: Med funksjonsnedsettelser?

Frederick: Med funksjonsnedsettelser. Da ble det plutselig ikke et abstrakt problem lengre. Da ble det et ansikt, et navn, representert, og det hadde stor påvirkning på meg. Da var det ikke snakk om statistikk lengre. Da var det snakk om et individ. Og det er bare én person. Hadde du hatt 10 personer, så hadde det sikkert hatt enda større påvirkning. Da forsvant min egen motstand.

Utdanning

Erling: Anders var jo inne der i fjor.

Anders: Ja.

Erling: Det var en fersk åpenbaring for deg?

Frederick: Det var ikke et ukjent område, men det var ikke et område jeg hadde brukt mye tid på.

Anders: Den engasjerte samtalen på fortauet var jo før jeg var inne og jobbet med teamet ditt?

Frederick: Det var kanskje det. Anders har jo mye ansvaret her. Samboeren min hadde òg en stor innflytelse. Hun jobber òg i bransjen. Hun har òg et stort engasjement. Hun sa at jeg måtte gjøre slik og slik, for da vil det fungere for de og de. Da tenkte jeg at jeg ikke gidder det.

Erling: Hvor hadde hun det fra?

Frederick: Hun studerer på Noroff. Så hun tar videreutdanning der, de har det som et fag på Noroff. Jeg kan ikke si nøyaktig hva de lærer, det har jeg ikke detaljer om. De har det som et fag, og det er jo et skritt i riktig retning. Nå vil det komme ut kull med juniorutviklere som allerede har forståelse for dette, der de ikke er avhengige av at miljøet på jobben står for denne kunnskapen. Det er enormt verdifullt.

Anders: Jeg har òg en kamerat som videreutdanner seg på Noroff. Han sendte over en oppgave som han jobbet med. Han ba meg gå gjennom for å se hva jeg syntes. Jeg var så imponert over oppgaven, oppgaveteksten og det de skulle løse. Fokus på uu, fokus på kvalitet og semantikk. De oppfordret til veldig godt håndverk. Oi, er det slik utdanningsinstitusjonene lærer folk? Dette må være unntaket, kjempebra. I etterkant har jeg hatt god dialog med Noroff. De lærer ikke folk å ta minste motstands vei når det gjelder kode og utvikling.

Frederick: Det er jo rett plass å begynne. Når jeg snakker med folk som vurderer å begynne i denne bransjen, sier jeg at de må ha en lidenskap for det. Det er ikke en slik jobb der du blir utlært på skolen og så begynner å jobbe – landskapet endrer seg hele tiden. Du må ta til deg ny kunnskap, du er ikke ferdig utdannet.

Retningslinjer fra 1999

Anders: Jeg vil bestride litt det du sier. Du har rett i at det er mye som har utviklet seg. Innenfor feltet uu, så har det egentlig gått ganske sent. De første retningslinjene kom i 1999, og der er mange punkter der som fortsatt er med oss. Første retningslinjen i 1999, første retningslinjen i WCAG er alternativ tekst på bilder. Det er jo én av de feilene som vi fortsatt neglisjerer, glemmer og snubler i. Senest i dag jobbet jeg med en seniorutvikler som har jobbet i 20 år. Så sier jeg «akkurat på det bildet her, så må vi ha tom alt-tekst». Han sier da «hvorfor»? Jeg orker ikke, bare gjør det.

Frederick: Dette deprimerer meg litt. I 22 år har dette vært et tema. For meg har det ikke vært på agendaen før de siste 5–10 årene.

Erling: Det var litt slik jeg tolket det du sa òg. Det er ikke nødvendigvis tilgjengelighetsprinsippene som har endret seg, men utviklere ser på dette som en ny ting. De må lære seg dette òg sammen med mye annet.

Frederick: Der vil du òg finne litt motstand. Det er de som tenker at de kan det de trenger, de trenger ikke å lære noe nytt. De er de vanskeligste å overbevise. De har en holdning der det ikke handler om å hjelpe folk, det handler om at de ikke vil lære noe nytt. De er et tapsprosjekt, der bruker jeg ikke energien min. Det er en oppoverbakke.

Fremtiden

Erling: Jeg leser litt optimisme mellom linjene. Du sier at de 5 siste årene, den siste tiden så har folk rundt deg blitt mer oppmerksomme. Hva tenker du om fremtiden?

Frederick: I fremtiden kommer dette til å være en naturlig del av jobben. Det kommer ikke til å være snakk om at du må gjøre dette på denne måten. Det kommer bare til å være den eneste måten du gjør ting på.

Erling: Så selv om du er flink til å male fanden på veggen, så er du en optimist?

Frederick: Absolutt. Det er utfordringene som er attraktive. Så når jeg negativ til noe, så beskriver jeg egentlig kun engasjementet mitt. Jo verre noe er, jo mer interessert er jeg.

Minoriteter og inkludering

Anders: Du nevnte at når du møter motstand, så blir det sagt at dette gjelder så få. Jeg leste nylig et motsvar til det, et perspektiv som jeg ikke har tenkt på. Dette gjelder så få. Hvor mange er det egentlig som bruker ditt og bruker datt? En bryterkontroll. «Åja, så du er ikke så opptatt av minoriteter? Hadde det vært greit å stengt noen ute basert på legning? Skal vi lage noe som ikke homofile kan bruke? Hadde det vært greit? Eller hadde det vært greit å lage noe som ikke svarte kan bruke? Hadde det vært innenfor?»

Erling: Et fint retorisk grep. Det er jo litt det vi preker. Å ikke bry seg om universell utforming handler om å ekskludere folk. Å ikke inkludere, da ekskluderer du?

Anders: Ja. Jeg så nylig et intervju med Tim Cook, et gammelt riktignok, der han ble spurt hvorfor Apple er så opptatt av dette. Apple er flinke. Og han sa, «Why shouldn't we? It is a basic human right». Det er slik det skal være. Det er slik vi skal behandle mennesker.

Frederick: Jeg tror dette er historisk i den forstand at, som en del av markedsføring liker de å lage demografier. I hvilken demografi kan vi tjene mest mulig penger? Da blir alt delt i prosenter. Så blir det satt et hardt skille på hvor mange prosenter du skal ha for at det er lønnsomt. Da tenker de at folk med funksjonsnedsettelser er for få, det er ikke nok av dem. Jeg synes det er interessant at de kan sette seg et kvartalsmål der de skal øke salget med 0,5 %. Da tenker jeg, vi har 2 eller 3 % brukere med en gitt hemning, hvis vi bare gjør det, det og det på nettsiden, så har du 3 %, ikke bare 0,5. Argumentet blir dumt. Det handler om å inkludere alle. Det handler om å bli bevisst på at ikke alle er inkludert til å begynne med. Som du sier med minoriteter, historisk sett så er dette en prosess som mennesker må gjennom. Plutselig blir vi bevisst på en gruppe, eller en minoritet som vi av en eller annen grunn ikke har tenkt på, eller enda verre unngått. Så tar vi det innover oss, så gjør vi det bedre. Så går vi til neste steg. Det handler om å bli bedre, være mer inkluderende. Det tenker jeg er måten vi må adressere universell utforming. Nå er det en utfordring. Om et par år er det standard.

Erling: På den noten, så tror jeg vil skal avslutte. Nå har vi holdt på i over én time. Veldig kjekt.

Anders: Jeg har lyst å snakke i timesvis med deg, Frederick. Jeg har så mange punkter på listen min som vi ikke har vært gjennom.

Erling: Det får bli en oppfølgingsepisode!

Anders: Helt avslutningsvis, har du noen tips til designere, utviklere, juniorer, seniorer?

Erling: Ikke bruk det første eksempelet du noengang finner. Alltid verifiser, sjekk alle mulige eksempler. Er du i tvil, ring Anders.

Erling: Hehehe.

Oppsummering

Erling: Det var spennende greier å høre på. Hva sitter du igjen med?

Anders: Uten å tenke meg om, så sitter jeg igjen med at Frederick og veldig mange andre, det er ikke for å henge ut ham, tenker at dette er noe nye greier, at fagområdet vårt er noe nytt. Det underbygger jo en holdning.

Erling: Men han var òg optimist, han mente at dette kom til å bli mer og mer den måten vi må gjøre ting på.

Anders: Hva sitter du igjen med?

Erling: Litt det samme. Det var kjekt. Selv om jeg snakker med utviklere jevnlig, så var det som om formatet vårt gjorde at jeg fikk et annet perspektiv på det når han snakket om å snakke med designere og den effekten det får. Han snakket spesielt om UX-designere, som er så opptatt av brukervennlighet og hvordan ting blir brukt. Ved å sette seg ned og snakke med dem, så vil det òg føre til bedre og mer tilgjengelige tjenester. De blir bedre implementert. De forstå behovet som designerene prøver å … innfri rett behov.

Anders: Jeg er veldig glad vi er i gang igjen, Erling. Dette har vært et savn. Nå har vi hatt en litt lang pause. Det trengte vi jo. Nå er jeg underernært på uu-preik.

Erling: Hvor lenge er det siden sist?

Anders: Det er nok fire måneder. Jeg vet ikke. Jeg er dårlig på tid. I neste episode skal vi treffe en fyr som vi ikke kjenner så godt. Det blir ikke like trygt.

Erling: For Frederick kjente vi jo ganske godt.

Anders: Ja, så vi startet mykt. Det blir ikke nødvendigvis hardt. Vi skal snakke om en rolle som Frederick snakket mye om – UX.

Erling: Hvem er det?

Anders: Pål Eirik Paulsen.

Erling: Hvem er han?

Anders: Han er vel UX-ansvarlig i en bedrift som heter Sopra Steria her i Stavanger. På én måte så samler vi da tre konkurrenter i samme rom. Liten by, lite miljø og alt det der.

Erling: Vi er jo fagfeller. Det er jo kjekt at vi samles på tvers av konkurrenter.

Anders: Da må vi finne ut av hva som fungerer for dem og ikke. Gleder meg veldig.

Erling: Hva gjør de for å redusere ulikheten?

Anders: Snakkes!