Webperf
Under våren fick Pajalabostäder en uppläxning av tillsynsmyndigheten DIGG när det gäller tillgänglighet. I juni var det dags för SL att hotas med böter på knappt en miljon kronor. DIGG håller nämligen koll på om DOS-lagen följs. Men hur brukar webbsidor funka för andra bolag som lyder under DOS-lagen? Det tar vi en titt på här!
Avsnitt:
- Sammanfattning av utvärderingen
- Vilka brister hittades
- Faktaruta
- Metod för utvärderingen
- Ladda ner resultatet från tillgänglighetstestet
Att 61% av kommunernas webbsidor har tillgänglighetsbrister konstaterades i april. Så Ockelbo kommun var inte ensamma, men först ut bland kommunerna att hotas med vite på grund av DOS-lagen. Sedan mitten av april fram till slutet av maj har Webperf utfört en motsvarande inventering på de bolag som ägs av offentlig sektor. Detta är ofta bolag som ägs helt eller delvis av kommuner eller regioner. För att erbjuda kollektivtrafik, bostäder, elnät, vatten-, avlopp- eller andra samhällstjänster. Fast under bolagsform. Ibland för att mer än en offentlig aktör ska kunna samarbeta över organisationsgränsen med andra.
Nyligen klubbades nya tillgänglighetsdirektivet i riksdagen, men det ska inte förväxlas med kraven på dessa företag. De företag som tas upp i den här utvärderingen lyder redan under DOS-lagen sedan i september 2019. De har haft 4 år på sig, ifall man inte räknar med diskrimineringslagstiftningen som fanns redan tidigare.
Att det här är verkliga krav blev tydligt under våren genom tillsynsmyndigheten Diggs hot om vite för Pajalabostäder.
Sammanfattning av utvärderingen - 86% har tillgänglighetsbrister
Endast 14% av utvärderade sidor hade inte en tillgänglighetsbrist och i genomsnitt hade de undersökta webbsidorna 2,5 fel på tillgängligheten per sida.
Om vi vänder på det lite; 48 procent av webbsidorna har en brist i kontrastförhållande mellan förgrund och bakgrund. Var sjunde sida har ett rent hantverksmässigt misstag med element med ett [tabindex]-värde som är större än 0. För att bara nämna två exempel av de 38 st olika sorters tillgänglighetsfel som upptäcktes på dessa webbplatser.
Benämningarna på tillgänglighetsbristerna är något yxiga och inte alls särskilt naturliga på svenska. Du som vill gräva i de svenska översättningarna och få benämningarna på andra språk kan kolla in Googles olika språkfiler och testdokumentation.
Varför jobba med tillgänglighet och inkluderande webbdesign?
Statistik säger inte så mycket om vad tillgänglighetsbristerna innebär för de som drabbas. För oss som bygger eller kravställer webbplatser är det nog inte möjligt att uppnå fullständig och bestående tillgänglighet. Och frågan är om det ens är ett vettigt mål.
En stor del inom inkluderande app- och webbdesign (som båda regleras av DOS-lagen) är att vara beredd att lägga tid på de svåra avvägningar som det innebär att komma fram till vilken lösning man väljer.
Vad är det som vägleder oss i denna strävan? Empati!
Utan ambitionen att läxa upp någon kan det vara värt att repetera vad empati kan handla om när man försöker tillämpa det vid webbutveckling.
Empati är en grundläggande faktor när det gäller att förstå och främja tillgänglighet, allas rätt att delta och egentligen mänskliga rättigheter. Det finns tre skäl att beakta:
- Förståelse för olikheter: Varje individ har unika behov, och dessa behov kan variera beroende på en mängd faktorer, inklusive fysisk och psykisk hälsa, och socioekonomisk bakgrund, med mera. Empati hjälper oss sätta oss i en annan persons ställe, vilket hjälper oss att bättre förstå deras unika behov och utmaningar.
- Främjande av jämlikhet: Mänskliga rättigheter handlar om jämlikhet och rättvisa. Empati hjälper oss att se att trots våra olikheter förtjänar alla människor samma grundläggande rättigheter och respekt. Genom empati kan vi se att en inskränkning i mänskliga rättigheter för en person faktiskt påverkar oss alla, som gemenskap.
- Drivkraft för att agera: Empati är inte bara att känna vad någon annan känner. Det är också en drivkraft för handling. När vi känner empati för andra, är vi mer benägna att vidta åtgärder för att hjälpa dem, vilket kan innebära att kämpa för att förbättra tillgänglighet och skydda de rättigheter vi alla har.
Vi har alla i våra professionella roller olika infallsvinklar på hur empati och inkludering blir relevant. Den kanske torraste infallsvinkeln är de av oss som jobbar med regelefterlevnad. Populärt kallat ”compliance”. Detta jobb kräver konstant interaktion med olika intressenter, och att ha förmågan att förstå och relatera till att intressenternas synpunkter kan vara avgörande för att effektivt uppfylla de lagar, krav och förväntningar som finns. Det blir lite av en sorts riskhantering. Som i frågan om man är beredd att betala viten på miljonbelopp för att man inte levde upp till lagkraven.
För de som jobbar ”mer anekdotiskt” med användarupplevelsen (UX) är empati något högst påtagligt i varje möte med de tilltänkta användarna. Man vill förstås inte göra dem besvikna.
De mer kluriga yrkesrollerna kan vara de personer och roller som är långt ifrån både användare och juridisk risk. En klassiker för att bygga empati hos dessa är att de får observera verkliga användare provköra det här de beställt, budgeterat eller haft ett finger med i skapandet.
Vilka brister hittades då?
Brister som har upptäckts redovisas i nedan tabell efter hur vanligt förekommande de är på webbplatser från företag som ägs helt eller delvis av offentlig sektor.
| Procent | Typ av fel |
|---|---|
| 48,2 | Kontrasten mellan bakgrundsfärg och förgrundsfärg är inte tillräckligt stor. |
| 39,3 | Vissa länkar har inte ett igenkännligt namn |
| 37,8 | Rubrikelementen har inte ordnats i följd i fallande ordning |
| 14,7 | Det finns element med ett [tabindex]-värde som är större än 0 |
| 13 | Alla bildelement har inte [alt]-attribut |
| 12,2 | Vissa knappar har inte namn som hjälpmedlen kan använda |
| 12 | Namnen för button-, link- och menuitem-elementen är inte igenkännliga. |
| 7,8 | `[user-scalable=" |
| 6,4 | Vissa <frame>- eller <iframe>-element saknar titel |
| 5,4 | Alla ARIA-id:n är inte unika |
| 5,2 | `[user-scalable=" |
| 4,6 | Alla attribut av typen [aria-*] stämmer inte med elementets roll |
| 4,5 | <html>-elementet har inget [lang]-attribut |
| 4,4 | Vissa formulärelement har inte etiketter |
| 4,2 | Listor innehåller inte enbart <li>-element och stödelement för skript (<script> och <template>). |
| 3,5 | Vissa listposter (<li>) saknar ett överordnat <ul>-, <ol>- eller <menu>-element. |
| 3,2 | Alla [id]-attribut för aktiva fokuserbara element är inte unika |
| 3,0 | Några eller alla obligatoriska underordnade element med [role] saknas för element med ARIA-rollen [role]. |
| 2,0 | Det finns element med [role]-attribut utan ett obligatoriskt överordnat element |
| 1,9 | Alla `[aria-hidden=" |
| 1,4 | `<meta http-equiv=" |
| 1,1 | Alla attribut av typen [aria-*] har inte ett giltigt värde |
| 1,1 | Namnen för inmatningsfälten för ARIA är inte tillgängliga |
| 1,1 | Vissa element med attributet [role] har inte alla obligatoriska attribut av typen [aria-*] |
| 0,8 | Alla `[aria-hidden="e |
| 0,6 | <html>-elementets [lang]-attribut har inte ett giltigt värde. |
| 0,6 | Vissa [role]-värden är inte giltiga |
| 0,5 | Vissa attribut av typen [aria-*] är ogiltiga eller felstavade |
| 0,3 | Vissa [lang]-attribut har inte ett giltigt värde |
| 0,3 | Det finns <dl>-element som inte enbart består av <dt>- och <dd>-grupper, <script>-, <template>- eller <div>-element. |
| 0,3 | Alla värden på [accesskey] är inte unika |
| 0,2 | `<meta http-equiv=" |
| 0,2 | Dokumentet har inget <title>-element |
| 0,1 | Namnen för progressbar-elementen för ARIA är inte igenkännliga. |
| 0,0 | <object> element saknar alt-text |
| 0,0 | Vissa poster i definitionslistor har inte bäddats in i <dl>-element |
| 0,0 | Det finns celler i ett <table>-element där attributet [headers] hänvisar till ett id-element som inte finns i samma tabell. |
| 0,0 | Vissa `<input type=" |
Faktaruta
- Drygt 26 000 stycken webbsidor testades. De hämtades från cirka 450 webbplatser. Mellan 1-80 sidor per webbplats har undersökts.
- Bara 3536 sidor av 26 167 saknade enligt testverktyget för tillgänglighet en enkelt funnen brist. Alltså en som ett simpelt tillägg för din webbläsare skulle kunna upptäcka på nolltid.
- Den genomsnittliga sidan på dessa webbplatser har 2,5 brister inom tillgänglighet.
- Testverktyget är Axe-Core. Samma som tillgänglighetstestet i Google Pagespeed Insights.
Metod för utvärderingen
Samtliga webbplatser ur kategorin Bolag ägda av offentlig sektor här på Webperf ingick i urvalet. För att gräva djupare än Webperfs vanliga jämförelser användes en annan metod än vid månadstesterna. Primärt användes crawling för att försöka hitta 70-80 stycken webbsidor på respektive webbplats. I många fall fanns denna mängd. Ibland kunde crawlern inte hitta fullt så många, men så länge den hittade något alls försökte den testa sidorna den hittade.
Ifall åtminstone en sida på webbplatsen lyckades testas bockades webbplatsen av som testad och avklarad.
Det betyder att det inte är exakt lika många sidor som testats per webbplats. Det är ok. Den här jämförelsen är mer ute efter att göra en storskalig undersökning om hur det kan se ut hos bolag som ägs av samhället. Av dig och mig. Kravställer, och skapar, de digitala medier så att de inte försätter många av oss i ett digitalt utanförskap? Det är frågan.
Cirka en sjundedel av webbplatserna lyckades inte alls crawlas. De har istället crawlats med Screaming Frog SEO Spider som verktyg. I de flesta fall gick det att komma över 50-60 adresser till webbsidor per webbplats på detta sätt. I vissa fall, när det var Single-Page Applications eller liknande, fanns bara en adress (eftersom de andra gömdes bakom en massa Javascript) och då testades bara en enda sida.
Verktyget som avgör om det finns tillgänglighetsbrister på en sida heter axe-core och utvecklas av Deque Systems. Axe är ett av de vanligaste verktygen idag för att automatiskt tillgänglighetstesta webbsidor och används i Googles testsvit Lighthouse, som vi använder här på Webperf, Googles snarlika öppna testtjänst Pagespeed Insights och Sitespeed.io för utvärdering av hur välbyggd en webbplats är utifrån krav på tillgänglighet.
Automatisk testning har sina brister
Automatiska testverktyg klarar inte av att hitta alla typer av brister. De är väldigt effektiva på så vis att de snabbt och effektivt kan skanna av massor med sidor på en webbplats. Men verktygen är olika bra på att hitta olika slags brister. Därför borde du kombinera flera olika när du testar av en enskild webbplats. Risken är att, om du bara siktar på att få godkänt i testverktygen, du kan få en falsk känsla av trygghet. Testverktyg ger dig inte en sanning. Gör manuella tester med automatiska verktyg, experttestare och ”vanligt folk”.
Just den här jämförelsen gör inte anspråk på annat än att se hur utbredd problematiken med ”enkelt funna brister” är. Då duger det att köra med ett enda verktyg. Men rimligen finns många fler tillgänglighetsbrister om man nu granskat med fler av Webperfs verktyg än just Axe-Core eller manuellt hade granskat alla dessa drygt fyrahundra webbplatserna enligt ett testprotokoll runt tillgänglighetstestning.
Vill du ladda ner hela tillgänglighetstestet?
Nedan är en CSV-fil du kan ladda hem med hela resultatet. Den är separerad med semikolon och kan importeras exempelvis i ett kalkylprogram om du vill jobba vidare med den.
På nedan länk kan du ladda ner datasetet bakom denna tillgänglighetstestning.
2023-offentliga-bolag-t12t.csv (CSV, 7Mb)
Men om du vill leka och lära runt data science så finns också följande Jupyter Notebook för dig att laborera med. Bara att klona ner från Github:
2023-t12t-offentliga-bolag.ipynb
Har du frågor eller behöver hjälp? Det brukar vi kunna bistå med som grupp på i vår Slack-grupp. Välkommen!
