Hurra for kvinner som koder!

I anledning kvinnedagen er det lansert en topp 50 liste over kvinner i teknologi. Det er få av disse jeg kjenner, så jeg kan ta feil i mine antakelser, men inntrykket mitt er at disse først og fremst jobber med ledelse og design. Hvis du gir noen to sekunder på å si hva de tror folk i teknologibransjen gjør, så tror jeg få svarer design og ledelse. 

Ikke at design og ledelse ikke er viktig, men hva hadde teknologibransjen vært uten de som faktisk sitter og koder? Jeg vil benytte dagen til å hylle de kvinner som har fullført sin IT-utdannelse uten å la seg friste inn i ledelse. Jeg kunne ha nevnt en haug fra min egen arbeidsplass, men fremhever heller noen som har gjort seg bemerket utenom min egen omgangskrets. 

Nicole Sullivan

Utviklet konseptet Object Oriented CSS (OOCSS), et rammeverk som blant annet har inspirert stilrammeverket til FINN.no. @stubbornella

Lea Verou

Vanligvis er jeg skeptisk til live-koding på konferanser, men det glemmer jeg når jeg ser denne greske dama demonstrere sine CSS-triks på scenen. @LeaVerou

Sara Soueidan

Det finnes knapt en front end konferanse hvor denne libanesiske dama ikke står på scenen. Har ikke sett henne selv ennå, men etter å ha fulgt henne på Twitter har jeg forstått at hun bidrar med langt mer enn ambisjonene om mangfold på konferansene. @SaraSoueidan

Leonie Watson

Startet som noe så sjelden som en blind webdesigner. Jobber nå for The Paciello Group og er blant fyrtårnene innen universell utforming, i tillegg til å være involvert i utarbeidelsen av web-standarder hos W3C. @LeonieWatson

Karianne Berg

Må jo ha en nordkvinne på listen også, og da vil jeg trekke frem dette fyrverkeriet av ei dame som er fast innslag på alle smidig-konferanser. @karianneberg

Listen er satt opp i full fart og røper nok også hvilken del av koden jeg selv jobber i. Bruk gjerne kommentarfeltet hvis du mener noen mangler i listen. 

Web analytics in service of accessibillity

Web analytics tools are not ment to tell us anything about users with disabilities

Web analytics is a well known tool for better user experience. If we couldn't see how our users use our site, we would be quite lost in knowing how it works.

For a long time I have been playing with the idea of filtering users who use assistive technology to see how their behavior is compared to those who don't. Are they using more time on each page? Do they have the same amount of page views? Maybe we even can detect barriers by doing this. But assistive technologies don't make this easy because they don't identify themselves to the server. I find it strange that web analytics tools can tell me see how big screens the users have or which versions of Windows they are running, but I can't know if they actually read or hear the content.

It's hard to believe that I am the first person to think about this, so I started googling web analytics and accessibility. What I found was a wall of scepticism about identifying people with disabilities. Many of the arguments are well-founded, but it seems like many people think they know the intentions without really listening. This article wraps it up quite well.

These are the arguments I find:

My disability is not your business

People don't want "dyslexia" written on their forehead. I can understand that. I don't want everyone to know every detail about me either. People also fear this information can be used for commercial purposes like advertising. I still see ads for cycling glasses everywhere after I bought a pair several months ago, so I get their point. People want to protect their privacy.

But to be honest, I don't care about you. Not when I analyse web traffic. I care about you as a group, not as individuals. I want to find out how a representative group of users who use screen readers or high contrast mode handle our pages. If I discover that their conversion rate is lower than average, maybe there is an accessibility barrier somewhere.

We are living in the age of Edward Snowden. Even if I swear that my intentions are pure, others may misuse the same information. But how new is this really? If you are blind, I suspect that Google's and Facebook's algorithms already have figured this out.

I don't want to be treated differently

Some web sites have separate "accessible pages" in addition to the fancy pages for "normal" people. Nobody wants to be sent here. They want to play on main pages with the cool kids.

I don't like to separate the users either. I don't want twice as many pages to maintain. I'm a fan of universal design. One web to rule them all!

The numbers will be wrong anyway

When assistive technologies don't identify themselves to the servers, it gets difficult to track them in web analytics. It is possible with some creativity, but it takes different measures for different tools and some will possibly not be logged. Besides, detecting a screen reader does not necessarily mean that there is a blind person on the client. I have tested plenty of sites with VoiceOver, but I'm definitely not blind. I have also seen my uncle holding a magnifier in front of the screen. How can we detect that? We will never get the numbers right.

But web analytics is not about exact numbers. It's about trends. We want to see if a change is for better or worse, how long the users stay on a page, how many pages they see per visit etc. And now I want to see if these data are different for users with disabilities. All I need is a representative group. It doesn't need to be complete, as long as the deviations in the data are noticeable. However, we need to keep in mind that we are logging specific events, not users with disabilities. We also need to treat the data as what they are.

I don't want to be counted

People are not always happy to be a part of some home made statistics of the users' abilities. When I advocate accessibility, I'm almost always asked how many blind users we have. I must admit that this was the first thing I was thinking when I got the idea of using web analytics for accessibility, but those numbers would not convince anyone anyway. As mentioned before: web analytics is not about counting, but analyzing users' behaviors.

I doubt many people find anything suspicious in my intentions. If they do, there is a bigger problem with web analytics in general. The challenge is that the same identification also can be used for other, more dubious purposes. It's hard to make people count if they don't want to be counted.

How do blind people use a camera?

When I did some research prior to a speach I was holding with a colleague at Mobile Era Conference, I came accross a cool film on Apple's accessibility page. It simply shows a blind man taking a picture of a family with an iPhone, and VoiceOver told him how many people there were in the picture.

This is not breaking new science. Most modern cameras have features that automaticly focuses on the faces. The new thing here is that someone got the brilliant idea of combining this with a screen reader.

I had to test this, and it worked great! Simply turn on VoiceOver on your iPhone when you use the camera.

How to make your colleagues think accessibility

This post was originally published on FINN.no's tech blog.

What to do when your colleagues don't make accessible products.

When developing a website which affects the life of almost every person in Norway, accessibility should be a main priority. Norwegians who are not able to use FINN.no are unable to find a home without assistance. Accessibility considerations are too often an afterthought, and this can have profound effects.

In the Spring of 2014, a small group of employees got together to find out how to make our colleagues care more about accessibility. After two years, the measures we think work best are workshops, user tests, and automatic validation.

Workshops

On a workshop we reveal accessibility issues and discuss how to solve them.

At our workshops we demonstrate how FINN.no works for people with disabilities before we let the team members test it the same way themselves. People find this a lot more inspiring than memorising WCAG 2.0 recommendations and running automatic validations locally.

How to test

Scaling Pages

The simplest thing to test for is page scalability, both for fonts and for the entire page. Most desktop browsers make it possible to scale both fonts and page no matter how poorly coded the pages are, but on mobile phones it’s still quite common to lock page size to screen size. It must be possible to pinch zoom every page on mobile phones.

The Straw Test

Another simple method is to pretend that you are looking at the page through a straw. This simulates how the page will appear for partially sighted people who either have a limited field of vision or need to magnify the page to read it. This reveals relevant elements spaced too far apart in a way that will make it difficult to navigate the page.

Keyboard Navigation

Most pages are designed and coded with mouse click and touch screens in mind, and we easily forget about people with broken arms, motor disabilities, or other reasons for not being able to use a mouse. By navigating the page with only a keyboard, we test that focus on links and buttons appears in a logical order.

High Contrast

Many partially sighted people are sensitive to bright light or struggle to see the contrasts on a page. They often invert the colors on the screen or switch to high contrast mode. Check that your pages are still readable in these modes. If you are using sprites or in other ways put relevant information in a background image, you may notice that this disappears on computers running Windows.

Screen Reader

Blind people depend on a screen reader to use a computer. Most cell phones have a screen reader built in by default. On Apple devices this is called VoiceOver and on Android it’s called TalkBack. You can turn this on in the accessibility settings. It takes some practice to use a screen reader, but when you handle it, you are likely to uncover a huge number of accessibility flaws.

Devopers actually think accessibility testing is fun (but you don't really have to use a straw).

User Tests

By testing our site during the workshops, we uncover the most obvious bugs. However, we cannot know how it actually feels for users with disabilities to use our site. That’s why we run user tests with blind and partially sighted users. We have people who run user tests at FINN, but because we don’t know what it’s like to be blind, we don’t always understand why they react as they do. Therefore, we need some external expertise to assist us. We are cooperating with Blindeforbundet (The National Association of Blind and Partially sighted, NABP) who run these tests for us.

Designers, developers, and product managers watch the tests, which are also videotaped for further analysis. After the tests, NABP hands over the videotapes with a commented report and recommended improvements.

Automatic Validation

Our next step is to include WCAG validation as a part of our automated tests. There are several tools offering this, including Pa11y and Tenon.io. We are likely to use Pa11y in our first effort, because it’s free.

Automatic validation gives an overview over detectable WCAG violations, and may work as a KPI for accessibility awareness or even break builds with new violations. If all developers and designers pay attention to this, we hopefully will stop deploying code with new WCAG violations.

Read more about Pa11y and Tenon.io.

Is It Working?

Accessibility used to be looked on as some kind of geeky pedantry for something that otherwise works fine. This attitude has changed over the past few years, and people take complaints about accessibility more seriously. In an internal speech I once mentioned that many of our pages weren’t scaleable on mobile. The next day, three teams had fixed that. A blind user complained that our iPhone app didn’t work with VoiceOver. This was fixed before the next release (several hours later). Another user complained that our banner ads caused epileptic seizure. This resulted in a huge debate on our forums, but sadly we still haven’t found a perfect way to use banners in a way that make both users and advertisers happy.

Whatever we do, the most effective way to get our accessibility flaws fixed is feedback from the users. We are not perfect yet, and we don’t always find accessible solutions that make everyone satisfied. Knowing that a user is unable to use FINN.no is far more convincing to our managers than being told that they have a WCAG violation. So please, if you have disabilities that make FINN.no hard to use, contact our service desk. It takes only one complaint to put your problem on our agenda.

Referat fra CSUN Conference

Inngangen til utstillingshallen.

I skrivende stund sitter jeg på flyet hjem fra San Diego, hvor jeg har deltatt på verdens største konferanse om teknologi for mennesker med nedsatt funksjonsevne, The International Conference for Technology and People with Disabilities, heretter kalt CSUN, som forvirrende nok er forkortelsen for universitetet som arrangerer konferansen, California State University Northridge. "Alle" de store var med og sponset konferansen, inkludert, men ikke utelukkende, Google, Adobe, Microsoft og Amazon.

En del av årsaken til jeg deltok var at jeg også holdt et foredrag på konferansen sammen med FINN-kollega Lotte Johansen, og en konsulent fra Vision2Access, Stein Erik Skotkjerra, som har assistert oss mye gjennom Blindeforbundets prosjekt Teknologi for alle. Tema for foredraget vårt var hvordan vi sammen har jobbet for å bygge en sterkere kultur for universell utforming i FINN. Mottakelsen av foredraget var veldig god, da det var mange som kjente seg igjen i situasjonen og var veldig interesserte i å prøve samme fremgangsmåte selv.

Fra utstillingshallen.

Dette var kun ett av nesten 500 foredrag i løpet av tre dager, så jeg har ikke først og fremst tenkt å skrive så mye om hva vi kom dit for å si, men heller hva vi lærte. Allerede på flyet fra London til San Diego kunne vi se at de var mange som var på vei til samme konferanse. Blinde mennesker med stokk er enkle å få øye på.

Ikke minst på Manchester Grand Hyatt Hotell, hvor konferansen holdes, kunne man føle seg omringet av blinde mennesker. Man må se hvor man går for å ikke snuble i stokkene deres. Kommer de fra flere kanter samtidig kan man fort føle seg omringet. Det er kanskje ikke pent å le av dette, men når Stein Erik, som selv er blind, med glimt i øyet kunne fortelle om at omvisningen for blinde på hotellet stadig måtte avbrytes av leteaksjoner etter folk som hadde kommet bort fra flokken og gått seg vil, så må vi kunne smile litt av dette vi også.

Konferansen ble gjennomført på en litt annen måte enn jeg er vant til. Foruten en egentlig ganske intetsigende Keynote kvelden før selve konferansen brøt løs, var det lite som ellers samlet alle deltakerne. Det var ingen felles lunsj under konferansen, og verst av alt, det var knapt kaffe å oppdrive uten å stå i lang kø i hotellets butikk eller løpe til nærmeste Starbucks. Dagene i forveien hadde det vært noen workshops for de som hadde betalt ekstra for å være med på dette, og dagen etter var det atter noen workshops som skulle løse noen spesifikke problemstillinger. Om kveldene ble det arrangert tweetup, accessible karaoke og andre nettverkingstiltak.

Ved hotellets lobby var det en stor utstillingshall hvor bransjen kunne presentere det nyeste av teknologiske hjelpemidler. Det sies at også Stevie Wonder tok turen innom denne messen for å shoppe. Selv fikk jeg med meg et elektrisk massasjeapparat som jeg håper jeg får til å virke like bra som jeg fikk den demonstrert.

Celebert besøk skaper begeistring

Men hovedingrediensen var de nesten 500 foredragene som det var 15 til 20 av hver time. Det var med andre ord litt av en jobb å finne ut hvilke foredrag man ville høre. Jeg skal ikke skrive om noen foredrag enkeltvis, men noen trender pekte seg ut. Mest interessant er det kanskje at det jobbes med en utvidelse av WCAG 2.0 med tanke på mobiltelefoner og andre trykkskjermer. Dette var også en del av budskapet til konferansens store rockestjerner: Karl Groves og Billy Gregory, populært kalt The Viking and The Lumberjack. Deres foredrag handlet egentlig om alt som er galt med WCAG, men at det ikke finnes noen bedre løsning heller. Noe av problemet var at det nye tillegget skal være valgfritt, ikke obligatorisk.

The Viking and The Lumberjack illustrerer hvor mye tekst det er i WCAG 2.0.

Vikingen Karl Groves lanserte også et nytt uttrykk: extreme accessibility. Dette låner prinsippene fra extreme programming, men med fokus på tilgjengelighet. Flere pratet om at de hadde laget universelt utformede mediaspillere, deriblant BBC. Andre hadde laget javascript eller add-ons som "reparer" sider som ikke er tilgjengelige. Atter andre hadde bygget WCAG validering inn i testrammeverket sitt, blant annet med Pa11y, som vi håper vi snart kommer i gang med også hos FINN. Og så var det noen foredrag som overlappet vårt eget, nemlig hvordan man kan bygge en kultur for tilgjengelighet innad i organisasjonen. Stein Erik hadde dessuten enda et et foredrag i tillegg til vårt, som handlet om at brukertester blir mer effektive hvis man passer på å inkludere testpersoner med nedsatt funksjonsevne.

Fornøyde etter et vellykket foredrag.

Foredragholderne er for det meste folk som oss, som jobber med utvikling eller har en dedikert rolle som accessibillity manager eller liknende. Det betyr at nivået på foredragsholderne varierer fra vårt nivå (kanskje enda lavere) til alfahanner som The Viking and The Lumberjack, som tilsynelatende holder foredrag like ofte som Bruce Spingsteen holder konserter.

Hvis dette alene ikke er nok til å friste deg til å delta på CSUN neste år, så kan det også nevnes at San Diego er en veldig fin by. Dette kan du lese om i reisebloggen min.

 

With a little pelp to my friends

På pelp.no kan du få tips om alt.

En gruppe med tidligere kolleger sluttet i FINN.no for å realisere de drømmer som ikke fikk oppfylt på gamlejobben. Resultatet ble pelp.no, hvor folk skal kunne spørre andre brukere om forbukertips eller dele sin visdom med andre. Jeg var en av de heldige inviterte som har fått leke meg her mens de har testet konseptet, men nå er produktet endelig sluppet fritt for alle.

Alle? La oss se på det. La oss se om pelp er universelt utformet. Jeg skal gjøre de samme testene på pelp.no som vi i uu-gruppa har fått de ulike teamene i finn.no til å gjøre på sine egne sider. Jeg skal teste om sidene er skalerbare, om det er enkelt å finne frem når sidene er forstørret, om det er mulig å finne frem med høykontrast-modus, om de kan navigeres med bare tastaturet, og om de funker med en skjermleser. Resultatet skal jeg publisere i all offentlighet til alle mine 86 månedlige brukere.

Denne testen er ingen skuddsikker garanti for at sidene oppfyller alle kravene i tilgjengelighetsloven. Det kan også hende at jeg henger meg opp i ting som ikke bryter med kravene. Men det er en nyttig test for å få en pekepinn på hvordan sidene oppleves for folk med ulike funksjonsnedsettelser.

Skalerbarhet

Den første testen avdekker den mest irriterende feilen, men den er kjapp å utføre og, hvis man full kontroll over eget rammeverk, enkel å fikse. Dette trenger man kun å teste på mobil fordi nettlesere på pc'er tvinger gjennom skalering av alle sider uansett. På mobiltelefoner derimot, er det mulig å låse sidens høyde og bredde til skjermen (noe som dessverre også er gjort på Bloggers mobilmaler, og dermed også denne bloggen). Dermed får man ingen hjelp hvis man synes teksten på siden er for liten.

Testen er såre enkel. Finn frem mobilen, gå inn på pelp.no og prøv å pinch-zoome siden for å gjøre den større. På pelp funker dette som en drøm. Bestått.

 

Sugerørstesten

Svaksynte mennesker må zoome mye for å kunne lese innholdet, og da må det også være mulig å finne frem med sterk zoom. Testen har fått navn etter det å se på sidene gjennom et sugerør, slik at man bare ser en liten del av siden av gangen. Det er flere måter å gjøre denne testen på. Man kan f.eks. lage et kikkehull gjennom knyttneven eller se gjennom et hull i et papirark. Det mest realistiske er å bruke operativsystemenes forstørringsverktøy, for det er det de svaksynte bruker. Selv foretrekker jeg å zoome maksimalt på mobilen.

Det er lov å jukse litt når man gjør denne testen, for det gjør de svaksynte også. Man kan zoome ut for å orientere seg om hvor elementene ligger, men så må man zoome inn igjen for å lese teksten. Denne testen er likevel en av de vanskeligste å tilfredsstille, særlig hvis man ønsker å opprettholde vennskapet med designeren.

Jeg synes Pelp kommer greit unna her også. Det er ikke til å unngå at man må zoome seg ut i blant for å orientere seg når man bruker skjermens fulle bredde, men de elementene som hører sammen er organisert vertikalt, slik at det er lett å gjøre det man skal selv om man kun ser en liten del av skjermen. De minimalistiske sidene viser deg ikke mer informasjon enn du trenger, og krever heller ikke mer informasjon enn de må ha. Da unngår de også å gjøre det vanskelig for seg selv når de skal lage et tilgjengelig design. Bestått.

 

Høykontrast

Bildebakgrunnen gjør det vanskelig å lese teksten, særlig med inverterte farger.

Svaksynte er ofte ømfintlige for lys, noe som gjør hvit bakgrunn slitsomt. For andre kan det rett og slett være enklere å se på siden med andre farger, f.eks. når man sitter med iPad'en ute i sola. Det er flere typer høykontrastfiltre man kan bruke på ulike operativsystemer. Det enkleste, synes jeg, er å invertere fargene.

Invertering av farger på pelp.no gir et par avsløringer. Det første som slår en er at det som normalt er lysegrå tekst på hvit bakgrunn plutselig blir veldig vanskelig å lese. Kontrasten ser ikke ut til å bli mindre med inverterte farger enn normale, men kontrasten er ikke veldig stor i utgangspunktet. Om kontrastene er i tråd med wcag-kravene har jeg ikke sjekket.

Deler av teksten blir vanskelig å lese med inverterte farger.

 

I store trekk er det fortsatt enkelt å finne frem. De har gjennomgående valgt mørk tekst på lys bakgrunn, og da unngår de å legge ut feller for seg selv. Unntaket er den siden hvor man velger kategorier. Her er kategoriene skrevet med hvit tekst over et bilde. Dette er alltid en risiko å ta, for da kan teksten fort bli vanskelig å lese. Jeg har ingen alvorlige problemer med å lese kategoriene med normale farger, men når jeg inverterer dem blir det vanskeligere.

Bakgrunnsbildene på temasiden fikk meg til å sjekke denne siden ekstra nøye. Når man bruker Internet Explorer i høykontrastmodus på en windows-pc blir nemlig alle bakgrunnsbilder fjernet, noe som kan skape problemer for mange sider. Men pelp slipper unna her også. Bildene er ikke implementert med background-taggen, men som vanlige bilder med tekst som er stylet til å plassere seg over bildet. Dermed vises fortsatt bildene, og fordi tekstbakgrunnen gjøres svart, blir den likevel enklere å lese enn uten høykontrastmodus.

Vanlig modus og høykontrast i Internet Explorer. Bildene i høykontrast blir kanskje ikke pene, men det er mulig å lese teksten.

 

Jeg gir pelp.no bestått også i høykontrast, men ville gjort en ny vurdering av den lysegrå teksten. Og med tekst over bildene på temasiden gjør de det litt vanskelig for seg selv. Jeg vil anbefale at de legger et halvtransperent lag mellom tekst og bilde for å unngå at teksten "blander seg" med bildet. Ved å gjøre teksten større og/eller fetere vil den også bli enklere å lese.

 

Tastenavigering

Når man skal lagre noe i Word eller et annet ikke web-basert program bruker man normalt ctrl+s når man først har lært seg kombinasjonen. Tilsvarende gjelder når man veksler mellom programmer, blar seg nedover dokumenter eller tilsvarende. Man lar musa ligge når man kan, så slipper man musearm i tillegg til at det går raskere. Pussig nok har man ikke de samme forventningene med websider, muligens fordi fordi for mange utviklere har klusset det til.

Her ser vi at snarveien til spørsmålene er i fokus, men fargen er ganske lik bakgrunnsfargene på deler av siden.

 

Når jeg begynner å navigere med tastaturet på forsiden til pelp.no begynner det bra. Logoen, som er det naturlige startpunktet på denne siden, markeres etter første trykk på tab. Men når jeg trykker for å komme til neste link forvinner markøren. Først 5 trykk senere dukker den opp igjen ved snarveien til spørsmålene. Det samme gjentar seg når jeg kommer til "Tema jeg følger". De har lagt en blå ramme rundt klikkbare elementer som er i fokus, men har ikke vært konsekvente i bruken. Markeringen burde også vært i en farge som ikke så lett går i ett med bakgrunnsfargene der hvor bakgrunnen er en annen enn hvit.

Også på temasiden får jeg problemer. På temaene med bildebakgrunn blir det veldig vanskelig å se markeringen, og selv om du aner hvilket tema markøren er på er det vanskelig å vite om du klikker på linken til temaet eller på følg-ikonet.

For å konkludere med det positive først: Tab-rekkefølgen på sidene er bra. De har ikke gjort noen grep for å kunne hoppe over headinger og komme raskere til innholdet, men på en såpass minimalistisk side savnes ikke dette. Det viktigste er at markøren hopper fra link til link i en forutsigbar rekkefølge, noe som også vitner om en ryddig markup bak siden. Men fargen på markøren bør de revurdere, samt sørge for at samtlige klikkbare elementer markeres.

 

Skjermleser

Svaksynte og blinde er helt avhengige av skjermlesere for å kunne lese en nettside. Her fant jeg frem telefon og headsett, og skrudde på VoiceOver.

Uffda, her snubler Pelp allerede på startstreken. Når jeg trykker på logoen sier damen i telefonen hva pelp.no er, men de har visst glemt å skrive navnet på tjenesten i alt-teksten sin.

Bortsett fra dette har jeg egentlig veldig lite problemer. Damen i telefonen leser opp den teksten som er relevant og unngår elementer som ikke er relevante, som f.eks. pilen ved siden av "Still spørsmål"-linken. Det største problemet er kanskje når knappen "Se alle" leses opp før overskriften "Nyeste spørsmål". Den motsatte rekkefølgen hadde vært mer naturlig. En annen ting de bør tenke over er når alt-teksten til bilder kan være blank, særlig på temasiden. Navnene på temaene leses opp veldig ofte når man skal velge et tema. Bestått likevel.

 

Konklusjon

Folk med nedsatt funksjonevne vil ha det mye enklere på pelp.no enn på de fleste andre sider. Om universell utforming er noe de har hatt spesielt fokus på vet jeg ikke, men jeg kjenner dem godt nok til å vite at de vet hva det er. Ved å lage sidene minimalistiske og kun fokusere på hva brukerne faktisk trenger har de gjort det enkelt for seg selv å lage en universelt utformet tjeneste. De har unngått feil som krever store, strukturelle endringer. De problemene jeg fant, som for det meste har å gjøre med fargevalg, bør det ikke ta mye tid å rette opp.

 

 

Det kunne vært vanskeligere

St. Olavs Hospital har klart å få en rullestolvennlig trapp til å se stilig ut. (Foto: Trond-Heggem, sakset fra doga.no)

Jeg var på en prisutdeling i går. Innovasjonsprisen for universell utforming. Vi hadde dristet oss til å melde på m.finn.no. Vi vant ikke, men fikk såkalt "hederlig omtale", hvilket i praksis vil bety andreplass i vår kategori.
Vinneren i kategorien informasjons- og interaksjonsdesign gikk til Skatteetaten. De hadde gjennomført et spennende prosjekt spesielt rettet mot folk med kognitive utfordringer, en målgruppe som har få WCAG 2.0 krav som taler deres sak, men som likevel kanskje er den største gruppen av dem alle. Det finnes mange synonymer for kognitivt utfordret, og få av dem bør komme på trykk, men det kan vel oppsummeres med folk som har konsentrasjons- og læringsvansker. Og det å gjøre skattereglene enkle å forstå for absolutt alle, er ingen liten utfordring. Vi kan finne oss i å bli slått av Skatteetaten. (men neste år...)

Hovedprisen gikk til St. Olavs Hospital. Etter beskrivelsen av prosjektet skulle man tro de hadde gjort halve Trondheim sentrum universelt utformet. Planleggingen hadde startet midt på nittitallet, og ombyggingen er nettopp ferdig. Fra starten av hadde universell utforming vært et overordnet krav fra oppdragsgiver og vært en rød tråd gjennom alle ledd av prosjektet.

La gå at det ikke er noen bombe at et sykehus bør være universelt utformet, men her har de tenkt på det i absolutt alle områder. De har til og med sørget for utsikt over Nidarosdomen og tilgang til Nidelva med rullestol.

Det er da det slår meg hvor enkelt det egentlig er å lage universelt utformede nettløsninger. Vi trenger ikke noen overordnede krav fra ledelsen eller lang tids planlegging for at en nettside skal kunne brukes av en skjermleser eller navigeres med tastaturet. Hvilken som helst utvikler kan gjøre den kodeendringen som trengs og få det ut på nettet samme dag.

Likevel er det så vanskelig. Hvorfor? Det er jo de stadige små kampene. Diskusjonen med sjefene for å få den ekstra tiden hvis det ikke lar seg fikse i en håndvending. Diskusjonen med designere for å gjøre den tilsynelatende overflødige OK-knappen synlig. Kampen med seg selv for å innse at jobben ikke ble gjort riktig første gang. Irritasjonen over at man heller ikke denne gangen klarte å tenke universell utforming allerede i starten av prosjektet.

Men vi trenger ihvertfall ikke å rive et sykehus og bygge det på nytt.