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.
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.
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.
Det ble nylig avholdt en intern tech dag for utviklerne i finn.no. Der holdt jeg en lyntale hvor jeg nevnte 5 tiltak som ble gjort på m.finn.no for å gjøre tjenesten mer universelt utformet. Dette er sånn cirka hva jeg sa:
Jeg hadde egentlig tenkt å prate om alt som er feil på finn, men etter at vi hadde Blindeforbundet på besøk i forrige uke, hvor en blind og en sterkt svaksynt demonstrerte hvordan de brukte finn og vi så at de stort sett klarte det de skulle gjøre, gikk det opp for meg at vi egentlig ikke er så aller verst. Tilbakemeldingen fra dem var at mye av det som gjenstår er å regne som pirk. Ikke dermed sagt at vi er i mål, men jeg synes vi for en gangs skyld kan være litt positive og se noen eksempler på problemer vi har tatt tak i, og hvordan de er løst.
Zoom
Denne metaggen nekter brukere på mobil å forstørre sidene, en slem ting å gjøre.
Den mest alvorlige feilen vi hadde på m.finn i våres var at det ikke var mulig å forstørre bildet. For svært mange blir teksten på en mobilskjerm for liten slik at det er greit å kunne zoome inn litt, i tillegg til at folk også kan studere bildene nærmere. Det ble fikset ganske enkelt ved å fjerne de to parametre det er satt en rød strek over på denne metatagen som nektet brukerne å zoome. Det er fortsatt noen sider på finn hvor man ikke kan forstørre sidene, så test deres egne sider med en gang og fjern disse parameterne. (Dagen etter at dette ble sagt hadde 3 nye markeder på finn blitt skalerbare)
Fotnote: Hvis du leser dette på mobil, så har du sikkert allerede avslørt at sidene på min blogg ikke lar seg forstørre. Akk, så ironisk. Årsaken til dette er at Blogger har nettopp disse forbannede parametrene i sine mobilmaler, og jeg har ikke funnet ut hvordan jeg fjerner. Så mitt tips til deg som ønsker en universelt utformet blogg er inntil videre: ikke velg Blogger!
Ikoner
Bildet til høyre er en annonse på finn.no i høykontrastmodus. Flere funksjoner blir borte fordi ikonene ligger som bakgrunnsbilder.
Ikoner er noe som har gjennomgått mye forandring gjennom årene. I gamle dager var et ikon en grafikkfil, og det var greit nok, bortsett fra at det ble mange requests mot serveren og dermed dårlig for ytelsen. Derfor gikk vi over til å bruke sprites, hvor flere ikoner ble trikset inn på samme bakgrunnsbilde. Det fikk fart på ytelsen, men vi brøt en grunnleggende lov med webdesign, nemlig at innhold ikke skal blandes med styling. Dermed fikk vi det vi ser på høyre side, som er en annonseside i høykontrastmodus, noe som er veldig nyttig for mange svaksynte. Den fjerner bakgrunnsbildene fordi den ikke anser det som vesentlig innhold. Der ser dere at logoen er borte. Ille nok, men kan noen fortelle meg hvordan man printer ut denne siden? Senere gikk vi over til å bruke font-ikoner, som f.eks. viser et hus når vi skriver utropstegn, men problemet er at skjermlesere fortsatt leser dette som utropstegn. Det har vi også klart å kode oss bort i fra, men enda bedre blir det når vi snart går over til å bruke svg til ikoner, dermed får vi både bedre ytelse, skalerbarhet og ikoner som ikke utgir seg for å være noe annet enn nettopp det.
Tastenavigering
I resultatlistene på m.finn.no markerer vi linkene i fokus med en rød kantlinje.
En annen ting er tastenavigering. Hvor mange er det som foretrekker å bruke tastekombinasjoner på desktop applikasjoner fremfor å bruke musa? Og hvor mange er det som gjør det samme på web? Hvorfor ikke? Vi har egentlig aldri vært spesielt dårlig på tastenavigasjon, men på m.finn har vi blitt gode, bla ved å tydelig markere hvilken link vi er på. Når vi navigerer er det mulig å hoppe over toppmenyen hvis man vil gå rett på sak, og på resultatsiden kan man også velge om man vil hoppe til filteret eller resultatet.
Tastevennlige filtre
Slidere eller tekstbokser for å begrense prisfilteret? Ja takk, begge deler!
I filtrene bruker vi slides når vi skal velge f.eks. en pris. Det er jo veldig kjapt å bruke på mobil og brett, men sitter man på en humpete buss kan det være vanskelig å treffe riktig beløp. Så nå har vi også gjort det mulig å taste inn beløpet hvis vi skulle ønske det. Dessuten, den slideren går ikke lavere enn en million, og for noen er det fortsatt veldig mye penger.
Skjermleservennlig informasjon
Ved å legge til attributtet "title=5 treff" klarer skjermleseren å lese mer meningsfylt informasjon for brukeren.
Når man gjør et søk med skjermleser på, følg med på hva den sier om hvor mange treff vi har. Hadde den bare sagt tallet, så hadde det vært vanskelig å putte det inn i kontekst. Men her sier den "5 treff". Dette er små ting vi kan gjøre som kan gjøre finn mye enklere å bruke.
Jeg sa innledningsvis at det som gjenstår av universell utforming på finn er å regne som pirk. Det betyr ikke at vi er i mål. Prøv å zoome skjermen til tredobbel størrelse i høykontrastmodus, eller naviger med tastene med skjermleseren på, så vil du fortsatt oppleve merkelige ting. Men hvis vi alle tenker på disse eksemplene når vi utvikler, vil vi fortsette å lage løsninger som er superbra - for alle!
I løpet av nokså mange år som framside-utvikler hos finn.no har jeg fått meg et rykte for å være den som maser mest om at tjenesten må være universelt utformet. I et forsøk på å gjøre meg fortjent til dette ryktet våger jeg meg på å starte en blogg om temaet. Jeg skal forsøke å skrive mest om ting som bør være interessant for alle som jobber med eller mener noe om det som finnes på web'en, men en del teknisk fagprat kan det nok også bli.
Hva er universell utforming?
Hvem hadde trodd at noe som skulle hjelpe blinde med å skrive ville utvikle seg til å bli dette?
Universell utforming, eller tilgjengelighet, som jeg synes er et bedre ord, handler om at alle skal ha mulighet til å gjøre de samme tingene, selv om fysikken kan gjøre det vanskeligere for noen. Det er derfor man må bygge dører som er brede nok til at en rullestol kan passere og at det finnes blindeskrift på tastene i minibanken. Like kjent er det kanskje ikke at det er mulig for blinde å surfe på nettet eller at det kan gjøres uten bruk av mus eller trykkskjerm. Vel, det er ikke på alle sider det er mulig heller, men det er fordi mulighetene ikke brukes, ikke fordi de ikke finnes.
Historien har vist oss at oppfinnelser som var ment som hjelpemidler for funksjonshemmede viste seg å være vel så nyttige for funksjonsfriske mennesker. Den vakreste historien er om den italienske oppfinneren Pellegrino Turri, som så sterkt ønsket at hans blinde elskerinne skulle kunne skrive brev til han at han i 1808 oppfant skrivemaskinen.
Jeg har også hørt påstander om at fjernkontrollen ble produsert med tanke på invalide krigsveteraner, men det har vist seg å være langt flere som har problemer med å bevege seg fra sofaen til TV'n.
Jeg tør til og med påstå at hjulet ble funnet opp av en person med dårlig rygg. ;-)
Tilgjengelig web
Da HTML ble utviklet for 25 år siden var universell utforming et av de grunnleggende prinsippene. Likevel er dette langt fra vanlig praksis på de sidene vi finner på nettet i dag. HTML er et glimrende format til det det var ment å gjøre, nemlig å publisere dokumenter på Internett som kan vises på alle slags dingser i alle størrelser, uansett om det er med skjerm, høyttalere eller papir.
Det eneste man ikke klarte å forutse var hvilken suksess dette skulle bli. Næringslivet oppdaget raskt hvor billig og effektivt www kunne brukes til å nå ut med sine tjenester, men det trauste utseendet på sidene var ikke bra for nok datidens (og nåtidens) markedsfolk og designere, som savnet de frie tøylene man har når man designer trykksaker. Grafikk ble derfor i stor grad brukt til å erstatte tekst og ellers pynte på sidene. Hittil hadde man bare sett nettsider på PC-skjermer, og nettleseren het vanligvis Netscape, så at HTML skulle vært et portabelt format ble fort glemt.
For å holde interessen varm lanserte Netscape sine egne tags som skulle gjøre sidene lekrere. Da Microsoft lanserte sin Internet Explorer kom de igjen med sine tags, og dermed var galskapen i gang. W3C kom løpende etter og forsøkte å tilpasse HTML-standarden, men de hadde mistet kontrollen over utviklingen.
Vanskelig å gjøre alle til lags
Med Internet Explorer ferdig installert på alle PCer vant Microsoft den første nettleserkrigen mot slutten av 90-tallet. Dermed glemte folk ikke bare at nettsider skulle fungere på ulike enheter, men også på ulike nettlesere. Det eneste som gjaldt nå var å få ting til å se bra ut i Internet Explorer.
Microsoft fikk igjen konkurranse da Opera, Firefox og Chrome kom på banen utover 2000-tallet. Disse nye nettleserne var mer trofaste mot W3C sine standarder, men utviklerne fikk sitt svare strev med å lage sider som så bra ut både på disse nye nettleserne og på den nå akterutseilte, men akk fortsatt så markedsterke Internet Explorer 6.
Endelig kom smarttelefonene på markedet, og verdien av å gjøre nettsidene lesbare andre steder enn på PCen ble tydelig. Men jeg er sikker på at man hadde begynt med mobilsurfing mye tidligere hvis grunnprinsippene for HTML og tilgjengelighet hadde blitt fulgt fra starten av.
Det neste store
Om mobilrevolusjonen har lært oss noe gjenstår å se. Ingen vet hva the next big thing blir, men vi kan være rimelig sikre på at innholdet også der vil være basert på HTML. Hvis man klarer å holde seg til universelt utformet HTML vil man trolig være tilgjengelig på den nye duppeditten fra dag en, i stedet for å lage enda en app eller spesialtilpasset side.
Fra 1.juli trer den nye tilgjengelighetsloven i kraft. En slik lov som krever at nettjenester skal være mulig å bruke også av folk med funksjonshemminger burde ikke være nødvendig, men kanskje er pålegg og bøter det eneste språket folk forstår. Håper at næringen i stedet for å skrike opp om overformynderi heller vil oppdage hvilke muligheter tilgjengelige nettsider vil åpne for.
