Gå direkt till sidans huvudinnehåll

Utvärdering av Siteimprove: ett verktyg för att testa WCAG och följa DOS-lagen

Utvärdering av Siteimprove: ett verktyg för att testa WCAG och följa DOS-lagen

Siteimprove är nog ett bekant namn för många som jobbar med webbkommunikation. Beroende på när du hörde talas om dem kan du tro allt från att de letar brutna länkar till att de har en bred produkt för både kvalitativ och kvantitativ analys av en webbplats.

Du som ofta hänger på Webperf men inte har erfarenhet av Siteimprove kanske undrar vad skillnaden kan vara? Har man ytlig kännedom om Siteimprove kan det verka som att båda verktygen gör samma sak. Så är det inte, vilket du kommer märka om du läser en bit in i denna artikel. Jag rekommenderar folk att kolla in Siteimprove även om jag skapat Webperf. Senast skrev jag till en beställare av webbutveckling på en av Sveriges myndigheter att (notera det jag formaterat med eftertryck):

”Webperf än så länge ganska tekniskt orienterad i sin approach och det gör det utmanande att ställa krav på sina utvecklare, samt att utvecklare inte alltid är bekväma med områden de inte är särskilt erfarna inom. Ett mer moget alternativ till Webperf är Siteimprove , men som förstås kostar en del pengar. Dock har de riktigt bra och pedagogiska vyer och de kollar förstås djupare än bara startsidan . Webperf kollar bara startsidor främst för att det är det minst dåliga alternativet för att kunna öppet jämföra webbplatser sinsemellan.”

– Webperfs grundare (Marcus) svarar om Webperf vs Siteimprove (augusti 2020)

När jag i augusti fick en redig genomgång av Siteimprove av deras egna säljstöd nämns det ett antal gånger att det absolut finns en uppsjö konkurrenter, men att fokuset för Siteimprove är att nå de utan särskilda förkunskaper. Det hela började för Siteimprove år 2003 med att i offentlig sektor i Danmark kontrollera döda länkar på webbplatser och på den vägen har de byggt vidare.

I augusti lades Webperf.se in i deras verktyg för att jag skulle kunna skriva denna artikel och kolla hur deras verktyg fungerar. Lagen om tillgänglighet till digital offentlig service (DOS-lagen) som från 23:e september gäller även äldre webbplatser kommer hösten 2020 ha en tonvikt på tillgänglighet på webben för många av oss. Därför har denna artikel ett särskilt fokus på hur Siteimprove kan bidra för att undersöka tillgänglighetsbrister som även maskiner kan hitta och hur det görs i större skala än de stickprov det blir om man ska göra det manuellt på en stor webbplats.

Instrumentpanel med ditt ”Digital Certainty Index”-betyg

Bild 1: En kontrollpanel/dashboard möter dig direkt efter inloggning. Webperf är 27 procentenheter bättre på tillgänglighet än den industri Siteimprove valt för jämförelse.

Det första som möter dig när du loggat in är den instrumentpanel som ger dig sammanfattande information om webbplatsen. De lägger betoningen på det de kallar DCI (Digital Certainty Index), vilket är ett sammanvävt betyg av de olika delarna som kontrolleras. Det är alltså ett samlingsbetyg av över hundra olika tester som utförs på en stor mängd sidor på webbplatsen.

Siteimprove har mer än utvärdering av tillgänglighet

Den här artikeln kommer fokusera på tillgänglighet (accessibility), uppföljande artiklar kommer ta upp Siteimproves övriga funktionalitet,

De andra områdena som Siteimprove har koll på är:

  • Kvalitetskontroll - kan handla om stavfel, texter som har för långa meningar eller är generellt svårlästa, trasiga länkar, dokument i märkliga format, etc.
  • SEO / sökmotoroptimering - saker som drar ner betyget är bland annat diverse omdirigeringar (vilka ska vara så få som möjligt), adresser med understreck, att strukturerade data saknas, hastighet, att metabeskrivningar är antingen för långa eller för korta.
  • Innehållsriktlinjer - klockrent för att hålla koll på att inte ord eller formuleringar man vill undvika finns på webbplatsen, förekomst av olämpliga förkortningar eller bevaka att inte fulkod från Microsoft Word råkar följa med när någon webbredaktör kopierar innehåll från ett Word-dokument.
  • Analytics - alltså mer klassisk kvantitativ webbanalys likt Google Analytics. Siteimproves analysfunktion svarar på frågor som när dina besökare är på webbplatsen, vilket innehåll de besöker, vilken typ av utrustning de använder, och mycket mer.
  • Webbprestanda - som kan berätta att bilder är för stora, teknikaliter som i vilken ordning du ska ladda filer, vad som borde gå att lägga i cacheminne, med mera.
  • Data privacy (hette tidigare GDPR) - listar bland annat sidor som mixar innehåll från både HTTPS och HTTP, cookies och några ytterligare verktyg.
  • Svarstid - hur snabbt svarar webbplatsen? Är den ens uppe? Inte helt olikt vad Pingdom började med en gång i tiden.

Många kvalitetstester påverkar mer än en kategori av betyg

Du märker redan i ovanstående korta lista att vissa tester rimligen återkommer i flera olika kategorier av tester. Det är egentligen inte så konstigt. Sökmotorer har precis som synskadade personer svårt att se och tolka en bild på webben. Om den bilden inte har en alternativtext kommer ingen av dem att veta vad den föreställer, vilket drabbar både på SEO och tillgängligheten.

Som du ser i bild 1 ligger Webperf rätt bra till jämfört med sin ”industri”, där Siteimprove valt IT, kommunikation, samhällsservice , vilket visas med den vita pricken i den gröna cirkeln. Att Webperf ligger så bra till gör det kanske mer utmanande att utvärdera verktyget. Webperf är inte tidigare testad enligt den måttstock Siteimprove använder, dock med alla de tester som Webperf själv använder. Trots dessa höga betyg finns det en ganska lång lista med saker som kan förbättras bland de 2500 st sidor som Siteimprove inspekterat.

Läsbarhetstest med LIX (Läsbarhetsindex)

Huruvida en texts läsbarhet ska inkluderas i arbetet med tillgänglighet eller inte går säkert att debattera. Siteimprove har dock placerat sin funktion för utvärdering av läsbarhet under rubriken “Quality assurance” istället för under den om tillgänglighet. En anledning till det kan vara att man vill skilja på de tillgänglighetsriktlinjer som man för närvarande klarar av att mäta automatiskt och det som faller utanför.

En rimlig nivå av läsbarhet finns med som ett framgångskriterie i WCAG, närmare bestämt 3.1.5 Reading Level , men läsbarhet är komplicerat utan manuella insatser och görs därför inte särskilt pricksäkert i massiv skala.

Siteimprove kan kolla hur texter fungerar ur ett läsbarhetsperspektiv. Om du kopplar det till tillgänglighet och DOS-lagen så tänker du säkert på kognitiv nedsättning, låg förmåga till läs- och skrivfärdighet, med mera. Det kan vara viktigare än man först inser och gälla fler än du tror.

Beroende på hur man mäter så har mellan var tjugonde till var tolfte person dyslexi. Det är drygt två elever per skolklass.

”I litteraturen anges olika siffror på hur vanligt förekommande dyslexi är i befolkningen. De flesta forskare anger 5 - 8% . I litteraturen nämns allt ifrån 2 - 4 % till ca 10%.”

Hur vanligt är läs- och skrivsvårigheter/dyslexi? (Dyslexiföreningen)

Så minst 200 000 och kanske så många som 1 000 000 svenskar har dyslexi. Då blir det förstås viktigt att texter är läsbara, begripliga och inte krångligare än nödvändigt. Ett mått på hur enkel en text är att läsa är LIX , men det finns flera. Vilken variant av läsbarhetstest som är optimalt beror på vilket språk det är på sidan du ska utvärdera. Olika språk behöver olika läsbarhetstest, exempelvis är Flesch–Kincaid Reading Ease populärt för engelska texter och är också det som används i Microsoft Word. Så med tanke på vår globaliserade värld och våra nationella minoritetsspråk räcker det inte riktigt med att nöja sig med LIX-testet på alla dina texter, eftersom du antagligen också har information på andra språk än just svenska eller andra besläktade västeuropeiska språk.

Siteimprove stödjer utöver LIX och Flesch–Kincaid ytterligare fem läsbarhetstest, nämligen:

  • Automated Readability Index (ARI)
  • Coleman Liau
  • Flesch Kincaid Grade level som till skillnad från det andra Flesch Kincaid-testet bedömer vilken utbildningsnivå läsaren behöver uppnått för att klara av texten.
  • Gunning Fog
  • SMOG

Dessa läsbarhetstest är anpassade främst för svenska, engelska och besläktade västeuropeiska språk. Därmed täcker de inte in andra vanligt förekommande språk som talas och skrivs i Sverige och för de med ett samhällsuppdrag behöver man förhålla sig till god praxis i fler språk.

Mer detaljer om läsbarhetstest finns på Siteimproves hjälpcenter .

Automatiska läsbarhetstest är rätt svårt

Bild 2: Det hade nog varit orimligt att förvänta sig att Siteimprove löst hela problemet med att identifiera det unika innehållet trots att det är väldigt begränsat på vissa webbsidor. Exempelvis denna.

”Begränsat innehåll hittades på sidan. Då en sida har lite innehåll kan det vara svårt att beräkna ett exakt läsbarhetsvärde. Begränsat innehåll kan leda till ett för högt värde.”

– Siteimproves läsbarhetstest, LIX

Det här med läsbarhet är ganska komplicerat. Jag har själv byggt funktioner, likt det Siteimprove har, till olika webbplatser för mina arbetsgivare och kunder. Det är inte lätt. Ifall den som skapat webbplatsen man ska testa kan ta gift på exakt hur strukturen ser ut på respektive webbplats så visst, då är det kanske någon annans problem med eventuell bristande precision ett test medför. Det man behöver veta är nämligen exakt var i koden som brödtexten är placerad. Så långt jag kommit i tanken med att analysera läsbarhet är att endast brödtexten är meningsfull och logisk att jämföra eller agera på.

Om man analyserar läsbarheten på all text på en webbsida kommer nämligen mängden av det för den enskilda webbsidan unika innehållet påverka betyget inom läsbarhet. Om en webbsida innehåller väldigt lite brödtext blir ett läsbarhetstest mer en recension av hur svårläst text i navigation och eventuell sidfot är. De består för det mesta av korta fraser eller meningar och ger då ett lättläst intryck jämfört med en webbsida som utöver navigation också har en massiv mängd brödtext.

Det är alltså svårt att helt automatiskt inte riskera att jämföra äpplen med päron när det gäller läsbarhet.

Man vill helst kunna välja att exkludera navigationen, sidfötter och annan för sidan icke-unik text från läsbarhetstestet. Här gör Siteimprove trots allt ett hyggligt jobb med tanke på förutsättningarna.

Läsbarhet på en djupare nivå

Bild 3: Siteimprove pekar ut en lång och komplicerad mening genom att rödmarkera den på sidan, så den är enkel att hitta.

Läsbarhetstestet LIX anger på en övergripande nivå hur läsbar en text är. Men vilka enskilda delar trampar över gränsen? Det svarar inte LIX på, men Siteimprove kan i sitt verktyg tydligt peka ut vilka meningar som gör läsbarheten svårare än nödvändigt. Detta erbjuder förstås också andra, bland annat Hemingway Editor , men de är ofta inte anpassade efter svenska språket.

Definiera regler som Siteimprove bevakar automatiskt

Låt säga att din organisation sätter en innehållsbudget i stil med hur webbanalys-boken exemplifierat det hela - med gränser för hur långa meningar ni tolererar? Om man utgår från brittiska Gov.uk så angav de att meningar skall vara under 65 tecken, inklusive mellanslag. Tyvärr verkar inte Siteimprove ha längd på mening som en särskild regel / policy att automatiskt bevaka, däremot finns färdiga regler för att bevaka läsbarheten på sidnivå, utöver mängder med andra färdiga regler som är enkelt att tillämpa.

Bild 4: Översikt för policyverktyget i Siteimprove.

Precis som verktyget i övrigt krävs det inte en massa förkunskaper eller mycket engagemang för att börja använda dessa regler. Samtidigt finns inget enkelt sätt att göra något avancerat. Det må vara hänt.

Praktiskt nog finns ett bibliotek med färdiga regler man kan välja att hämta och tillämpa på sin egen webbplats. Vissa kan låta lite redundanta, men vid närmare eftertanke beror nog många av dem på att det på väldigt stora webbplatser inte är möjligt att fixa alla fel. Eller kanske att man vill hålla örnkoll på startsidor eller de sidorna som är högt upp i strukturen, men kan vara lite mer förlåtande med annat material. Ett sådant exempel är att det finns en regel för att bevaka om sidor högt upp i strukturen har trasiga länkar, samt en annan regel som istället bevakar om nya sidor har trasiga länkar.

Dessa nyanseringar kommer säkert till nytta för de som är tvungna att prioritera sina insatser, eller kanske vill uppnå maximal skillnad tidigt med sina ansträngningar.

Färdiga regler kring tillgänglighet

Det finns färdiga tillgänglighetsregler, närmare bestämt tio stycken som är kategoriserade in i modulen för tillgänglighet. Dessa färdiga regler som finns just nu är:

  1. Startsidor som saknar alternativtext för bild.
  2. EUs tillgänglighetsdirektiv: Dokument publicerade på eller efter den 23e september 2018
  3. Icke-semantisk HTML-uppmärkning.
  4. Långa stycken.
  5. Word-dokument
  6. Excel-dokument
  7. PowerPoint-dokument
  8. Bilder som saknar ett alt-attribut
  9. Långa sidtitlar
  10. Ord med versaler

Till respektive färdig regel finns en hjälptext som ger mer bakgrund till vad regeln gör. Troligen kommer man väldigt långt bara med dessa i ett inledande skede när man utforskar Siteimprove som verktyg.

Du kan också definiera egna regler att bevaka. Som språkliga saker man vill undvika, exempelvis att inte använda vissa ord. Vi som jobbar med teknik har nyligen påmints om att gamla begrepp som “master” och “slave” inte är så bra ens i tekniska kretsar längre, vilket blev tydligt för många när Black Lives Matter gjorde ett återtåg sommaren 2020. Så här kan Siteimprove göra livet mindre ängsligt att någon råkar uttrycka sig klumpigt på ens officiella webbplats. Bravo!

Utvärdera tillgänglighet enligt WCAG 2.1 med Siteimprove

Innan förbättringsarbetet utifrån Sitemproves tillgänglighetstester gjordes hade Webperf.se 97,1 av 100 i betyg för tillgänglighet. Det är förstås väldigt högt, men där och då vid byggnationen av webbplatsen var måttstocken andra verktyg än just Siteimprove, närmare bestämt Axe och Pa11y som används här på Webperf självt. En brist med det arbetssättet är att det blir mer eller mindre omfattande stickprov då Webperf främst jämför startsidor, men visst, det finns ett hantverkskunnande vid utveckling av webbplatser som gör att Webperf håller en viss lägstanivå. Siteimproves genomsökning av Webperf.se handlar om 2500 st sidor på webbplatsen! Det är en bra bit över vad som är rimligt för stickprov även för oss som tror oss veta vad vi håller på med när det gäller tillgänglighet på webben.

Bild 5: Tillgänglighetsmodulen efter vissa justeringar av webbplatsen gjorts.

Så som Siteimproves säljpersonal beskriver det de skapat är att de byggt det mesta av testerna själva. De nämner att de varit med i ett projekt inom EU-programmet Horizon 2020 för att göra tillgänglighetsmodulen ännu bättre. Siteimprove deltog i WAI-tools hos webbstandardorganisationen W3C . W3C är de som skapat WCAG-riktlinjerna till att börja med.

Bild 6: Siteimprove är tydliga över vilka riktlinjer inom tillgänglighet på webben som man inte klarar av att mäta automatiskt (ännu). De är utgråade.

DOS-lagen för de inom offentlig sektor

Siteimprove har en tabell, se bild 6, över vad verktyget klarar av inom (den för vissa av oss lagstadgade nivån av) tillgänglighet och vad som behöver en mänsklig bedömning. Siteimprove hyr också ut personer som själva har funktionsnedsättningar och också kan Siteimprove.

Samtidigt vill Siteimprove inte bli jämförda med exempelvis Funka, som också gör tillgänglighetsanalyser. Och ja, det är väl logiskt. Siteimprove gör en automatiserad och kvantitativ kontroll, som de vid behov kompletterar med en kvalitativ metod, medan Funka fokuserar på det kvalitativa.

Siteimprove pekar på problemet, ger förslag och tipsar hur du läser på om respektive problem

Siteimprove klagar inte bara på vad som är fel utan ger förklaringar om varför det är ett problem. Det är bra för att inte skrämma slag på folk som är nya på området. För den som vill finns också länkar till officiell dokumentation från auktoriteten W3C som ändå är standardorganisationen bakom WCAG-riktlinjerna.

Bild 7: Siteimprove pekar tydligt ut var på webbsidan bristen finns. I detta fall att rubriknivåer inte respekterats.

Bild 8: Det hör till ovanligheterna att man hänvisas till ett ”fel” man inte lyckas bekräfta. Som här, där det anges att det finns en tom italics-tag, men den inte går att finna i webbsidans kod, samt att jag som enda utvecklare av webbsidan vet att jag inte ändrat någon kod nyligen som kan ha påverkat detta.

Med tanke på att Siteimprove är ett verktyg som tillämpar sina regler och tips på godtycklig webbplats är det kanske inte konstigt att det ibland inte är särskilt enkelt att veta vad problemet är. Se bild 8 ovan.

Något är tydligen skumt med sökfunktionen enligt Siteimprove. Men i ärlighetens namn har även Webperfs egna Pa11y-test reagerat på just sökrutan. Så visst kan det verka väldigt krävande att tro att Siteimprove löst svåra digitala problem på en generell nivå åt oss, när det kanske, egentligen, är ett orimligt komplext problem.

Ibland lite oklarheter från Siteimprove?

Bild 9: Till synes identiska budskap återkommer ibland i Siteimproves verktyg. Vad är skillnaden mellan dessa kategoriserade brister om inmatningsfält?

Jag har gått igenom alla varningar som Siteimprove ger kring tillgänglighet för Webperf och har bara hittat ett ynka fall där jag inte lyckades bekräfta felet de pekar på. Det är ändå långt över förväntan när det gäller ett automatiskt verktyg.

Bild 10: Notera flikarna nedtill, där “Redaktör” är vald. En praktisk uppdelning av de olika tillgänglighetsproblemen beroende på vilken roll man har för en webbplats.

Andra oklarheter som Siteimprove råkar lämna ifrån sig är de fall där de inte fullt ut lyckas klassificera om ett tillgänglighetsproblem är något redaktionellt, för en utvecklare eller en webmaster. Det är behjärtansvärt att ens försöka ge raka besked till webbredaktörerna, att de får en lista över vad de kan tänkas ansvara för. För det mesta fungerar det utmärkt. Och då har jag även i detalj kollat ett större konto på Siteimprove för en väldigt stor aktör i offentlig sektor (där jag råkar vara anställd).

Siteimprove som metod för att skapa en tillgänglighetsredogörelse

Bild 11: Lista med automatiskt funna tillgänglighetsbrister på Webperf.

Den som gör en tillgänglighetsredogörelse kan behöva komma ihåg att det är WCAG 2.1 på nivå AA som gäller. Risken är att man får med saker inom den strängare bedömningsnivån AAA i onödan. I Siteimprove kan du filtrera detta genom att välja “AA Nivå” i diverse listningar där du kan hitta “Överensstämmelsenivå”, exempelvis på bild 11 ovanför tabellen till höger. För en tillgänglighetsredogörelse är det nivå AA som förväntas. Men har man uppnått ett klanderfritt resultat på nivå AA är det absolut värt att kolla in vilka lågt hängande frukter som finns på nivå AAA.

Det har börjat dyka upp tillgänglighetsredogörelser bland de webbplatser som enligt DOS-lagen är tvungna att ha sådana senast 23:e september 2020. Vissa av dessa har angett Siteimprove som sin metod. Man kan förstås diskutera lämpligheten i att endast ha ett automatiserat verktyg för att hitta tillgänglighetsbrister, men det är i alla fall en smidig metod. Nackdelen är att man missar allt som inte kan upptäckas av en maskin.

För att få en grundläggande koll på tillgängligheten kan man gå in på Översikt Accessibility . Då kommer en lista ordnad efter hur många poäng webbplatsen (eller segmentet inom webbplatsen) går miste om på grund av tillgänglighetsbrister. Det kan man se som en sorterad lista med störst problem överst.

Bild 12: Siteimprove hittar förstås inte allt. Vissa saker kräver fortfarande manuella tilgänglighetstester.

Och för den som tänker göra det här med tillgänglighetsredogörelse ordentligt, det vill säga komplettera med kvalitativa stickprov och/eller hyra in expertis, så är det alltså de utgråade sakerna i bild 12 som dessa ska fokusera på.

Siteimprove för utvecklare och webmaster

Notera att jag som skriver denna artikel själv är utvecklare. Men som utvecklare behöver man ha förståelse för det redaktionella och hur man gör det lättare för de som har den rollen. Ett tänk vid användning av Siteimprove är att vi med utvecklarrollen initierar användandet, styr upp våra egna synder först innan redaktörer släpps in. Så de förmodat mindre tekniskt kunniga redaktörerna slipper onödiga grejer i sina listor som de kanske inte kan rå på, eller ens se utvecklarnas att-göra-grejer i gemensamma listor. Att det från min synvinkel riskerar att göra Siteimprove onödigt svårt (trots sin enkelhet), alltså att man ändå blandar helt olika roller, tillsammans med en oklarhet över ansvarsområdet “Webmaster” gör det knepigt.

Vad definierar en webmaster idag och vilka organisationer har ens en webmaster idag? Åtminstone för mig som utvecklare kändes alla identifierade brister under webmasterns ansvarsområde som något jag borde fixa. Det här kanske är logiskt för vissa av Siteimproves kunder, men åtminstone jag hänger inte med.

Bild 13: Siteimprove listar problem som hittats på praktiskt taget samtliga av de 2500 undersökta sidor.

Men för att återgå till Siteimprove för en webbutvecklare är det ju fantastiskt att få systematiska problem identifierade. Som webbutvecklare har man ju en unik insikt i hur små ändringar på en webbplats att göra storskalig nytta. Här blir Siteimprove ett smidigt verktyg i första skedet att identifiera bekymmer men också att efter förbättringar är genomförda (se bild 13 förbättringskolumn ute till höger) kunna validera genomslaget på ett kvantitativt sätt. För vad skulle vara alternativet? Manuella stickprov gör man ju hela tiden under utvecklandet, men för dagens webbutveckling vet man inte alltid på förhand hur olika komponenter kommer användas eller kombineras.

Och att bygga sitt eget verktyg för denna sorts kvalitetssäkring kanske är lockande, men förutom att verkligen vara att uppfinna ett eget underpresterande nytt hjul kan det faktiskt vara skönt att ha en utomstående tredjepart som Siteimprove att peka på.

Dessutom, med tanke på att Siteimprove inte tar betalt efter antalet webbplatser de undersöker, det är antalet kollade sidor som kostar, så finns det inget som hindrar dig från att låta Siteimprove hålla koll på en eller flera av de mer utvecklarnära webbplatserna. Någonstans i närheten av den senaste release kandidaten ni byggt. Den miljön där ni har några representativa undersidor, med exempelinnehåll och konfigurationer som liknar produktionsmiljön. Då slipper man fullt så ofta bli påkommen med att introducera nya onödiga brister och att behovsägaren måste vänta till nästa release för att få dem lagade.

Sammanfattningsvis

Siteimproves konkurrenter

Siteimprove har inte så många konkurrenter på helheten, om ens någon vad jag kunnat googla mig fram till . Det ryktas om monsido.com som en tänkbar framtida konkurrent, som består av avhoppare från Siteimprove, men de är idag inte i närheten av den bredd som Siteimprove har. Här kommer fler konkurrenter / alternativ till Siteimprove inom just tillgänglighet:

Det finns många som gör mindre delar riktigt bra, med mer eller mindre stor automatisering, och i olika stor skala. Siteimprove började inom offentlig sektor och är fortfarande otroligt stora i den sektorn. Siteimprove började med brutna länkar 2003, men har med SEO och webbanalys har de breddat sitt erbjudande. Och inte att förglömma att deras verktyg för tillgänglighetstestning blivit riktigt bra på senare tid.

Inom respektive område finns det förstås områdesexpertis att hyra in som konsulter för allt vad det kan innebära i form av branschstandarder, erfarenheter som hjälper till att prioritera arbetet och ett fokus på briljans. Varje område som Siteimprove täcker in har så klart också en uppsjö av verktyg. Lösningar som spänner ifrån gratisplugin till din webbläsare för att själv efter bästa förmåga göra stickprov, till produktifierade tekniklösningar. De alternativa verktygen är särskilt många inom SEO-området, av naturliga skäl då det är lättare att sätta ett ekonomiskt värde på en förbättring inom SEO.

Denna skrivelse har dock haft en tyngdpunkt inom tillgänglighetstestande och där verkar Siteimprove ha ett ordentligt försprång till andra automatiserade verktyg som kan göra detta i stor skala.

Läs mer: Länkar och övrigt

Exempel på tillgänglighetsredogörelser:

Verktyg:

Tack till korrekturläsarna av artikeln:

  • Johan Dahlqvist på Limepark
  • Martin Johnson
  • Mattias Blomkvist
Till toppen