Tillgänglighetsutvärdering via Webperf.se

Utvärdering av en webbplats tillgänglighet med hjälp av automatiska verktyg. En del av Webperf Premium.

Innehåll

Din rapport består av följande delar:

• Sammanfattning
• Metod
• Detaljer och fynd
• Appendix
  • Testprotokoll

Sammanfattning

En tillgänglighetsutvärdering är en process för att granska en webbplats eller webbapplikation för att avgöra hur väl den följer tillgänglighetsstandarder och riktlinjer. Dessa standarder och riktlinjer är utformade för att säkerställa att webbplatser och webbapplikationer kan användas av så många människor som möjligt, inklusive de med funktionsnedsättningar.

Under en tillgänglighetsutvärdering kommer en utvärderare vanligtvis att använda en kombination av manuell testning och automatiserade verktyg för att bedöma tillgängligheten för en webbplats. De kommer att leta efter problem som saknad eller otillräcklig alternativtext för bilder, dåligt utformade formulär och brist på tangentbordstillgänglighet.
Rapporten du nu läser täcker in den automatiska delen och kompletteras med fördel med jämna mellanrum av manuell testning. Tips kring manuell testning finns i slutet av rapporten.

Resultaten av en tillgänglighetsutvärdering kan användas för att identifiera områden på webbplatsen som behöver förbättras för att göra den mer tillgänglig. Detta kan inkludera uppdatering av koden eller designen på webbplatsen, samt tillhandahålla bättre handledning eller utbildning för innehållsskapare.

Sammantaget är en tillgänglighetsutvärdering en viktig del för att säkerställa att en webbplats är inkluderande och tillgänglig för alla användare.

Det övergripande resultatet av undersökningen av er webbplats kan sammanfattas i punktform:

• 293 st webbsidor hittades på ockelbo.se och har utvärderats
• På 8 av dessa sidor upptäcktes tillgänglighetsbrister.
• Frekvensen av sidor med brister är 2,7%
• Av sidorna med brister hittades i genomsnitt 1,8 st brister per sida.
• Det förekommer 5 st olika sorters fel på webbplatsen. Dessa är följande (som kan klistras in i redigerat skick i er tillgänglighetsredogörelse, om ni har en):
  1. Värden som tilldelats till `role=""` är inte giltiga ARIA-roller.
  2. Element med synliga textetiketter har inte matchande maskinläsbara etiketter.
  3. Vissa listposter (`<li>`) saknar ett överordnat `<ul>`-, `<ol>`- eller `<menu>`-element.
  4. `<td>`-element i en stor `<table>` saknar tabellrubriker.
  5. Rubrikelementen har inte ordnats i följd i fallande ordning

Metod

Metoden för denna tillgänglighetsutvärdering är av den automatiska sorten. Det är en god start för ditt tillgänglighetsarbete och en tillgänglighetsredogörelse. Men, både vi på Webperf och tillgänglighetsexperter rekommenderar att komplettera dessa automatiska tillgänglighetstester med manuell granskning. Samtidigt är det med tillgänglighetstester som med träning - det som blir gjort är bättre än att inte komma till skott.

Riktlinjen som undersöks är WCAG 2.1 (Web Content Accessibility Guidelines) på nivå AA, vilket motsvarar den europeiska standarden EN 301 549 som är basen för de som lyder under DOS-lagen (lagen om tillgänglighet till digital offentlig service). Dock rymmer EN 301 549 mer än WCAG 2.1, läs mer på Webbriktlinjer.se.

Du kan mycket väl behöva hjälp av en webbutvecklare för att tolka och nyansera det rapporten funnit och sammanställt. Testramverket som använts är Axe-core, från Deque, vilket är att betrakta som branschstandard. Det används i verktyg som Googles Lighthouse och Pagespeed Insights, Sitespeed.io och många fler.
En fördel med just Axe-testet framför exempelvis Pa11y är att Axe i mindre utsträckning falskeligen pekar ut felaktigheter.

Rent praktiskt har testet körts från en testserver ståendes i Sverige. För att samla in adresser att utvärdera används en crawler som börjat på startsidan av er webbplats och samlat på sig det antal länkar som är tänkta att testas. Ibland är det alla sidor på webbplatsen.
Ifall ni har tusentals sidor på webbplatsen samlas det in 10% extra för att kompensera för eventuella 404-sidor. Crawlern gör inte åtskillnad mellan adresser som upptäcks på http-protokollet även om ni oftast använder https. Det är också avsiktligen som det kan blandas ifall det är adresser med eller utan www.-prefixet. Crawlern plockar upp de adresserna den stöter på.

Frekventa frågeställningar om metoden:

1. Jag trodde det skulle vara fler sidor undersökta?
   Den förteckning över sidor som testats kan mycket väl innehålla färre sidor än det antal du förväntade dig. Det beror på att insamlingsmetoden inte på förhand känner till om en adress på din webbplats kommer svara, om den kan utvärderas, hänvisar testservern vidare till en annan webbsida, etc.
2. Det ser ut som att dubbletter testats?
   Om du upptäcker mer än en adress med samma adress är det troligen så att en av dem är med HTTP som prefix och en annan med HTTPS. Det beror på att din webbplats inte är konsekvent med hur den länkar till enbart resurser över HTTPS. Ifall du inte kan se skillnad för HTTP(S) så kolla hur konsekvent ett eventuellt www-prefix är i de adresser som hämtats in eller att avslutande snedstreck (/) inte är konsekvent.
3. Varför testas sidor som inte är avsedda för våra besökare?
   Ibland hittas länkar till inloggningsformulär till ens webbpubliceringssystem (CMS), eller andra webbsystem, och testas. Generellt är det viktigt att även inloggningsfunktioner är tillgängliga. För att utvärdera ert CMS:s tillgänglighet i relation till era webbredaktörer finns det en kompletterande riktlinje som heter ATAG (Authoring Tool Accessibility Guidelines) från W3C.
4. Utvärderas våra PDF-filers tillgänglighet?
   Nej. PDF-filer behöver testas med mer manuella metoder och är egentligen inte material som har på webben att göra då det är ett format för trycksaker och fixerad layout. Generellt sett är tillgänglighet och användbarhet med PDF:er ganska dålig, exempelvis för användare av små skärmar. Viktigt material som återfinns i PDF-filer bör publiceras i ett webbformat istället. Se Adobes tips om att skapa och verifiera PDF-filers tillgänglighet.
5. Tar rapporten upp precis alla potentiella tillgänglighetsbrister på min webbplats?
   Nej. De brister som tas med i denna rapport är de som av Axe-verktyget bedöms ha medel till stor påverkan på tillgängligheten. Det innebär att du får reda på om något är prioriterat att åtgärda snarare än en längre lista med saker som behöver expertkompetens för att beakta.

Detaljer och fynd

Nedan följer en förteckning över vad som hittats på er webbplats.

Du kan i samband med denna rapport också ha fått en CSV-fil med testresultatet. Den kan du importera till ett kalkylark då de under vissa omständigheter är enklare att jobba med eller söka i.

Gå direkt till en viss typ av brist som hittats:

• Värden som tilldelats till role="" är inte giltiga ARIA-roller.
• Element med synliga textetiketter har inte matchande maskinläsbara etiketter.
• Vissa listposter (<li>) saknar ett överordnat <ul>-, <ol>- eller <menu>-element.
• <td>-element i en stor <table> saknar tabellrubriker.
• Rubrikelementen har inte ordnats i följd i fallande ordning

Värden som tilldelats till role="" är inte giltiga ARIA-roller.

Bristen hittades på 3 st sidor. Sidor där detta fel upptäcktes:

• /aktuellt-i-ockelbo – Kolla med Lighthouse
• /evenemang – Kolla med Lighthouse
• /driftstorningar – Kolla med Lighthouse

Element med synliga textetiketter har inte matchande maskinläsbara etiketter.

Bristen hittades på 3 st sidor. Sidor där detta fel upptäcktes:

• /aktuellt-i-ockelbo – Kolla med Lighthouse
• /evenemang – Kolla med Lighthouse
• /driftstorningar – Kolla med Lighthouse

Vissa listposter (<li>) saknar ett överordnat <ul>-, <ol>- eller <menu>-element.

Bristen hittades på 3 st sidor. Sidor där detta fel upptäcktes:

• /aktuellt-i-ockelbo – Kolla med Lighthouse
• /evenemang – Kolla med Lighthouse
• /driftstorningar – Kolla med Lighthouse

<td>-element i en stor <table> saknar tabellrubriker.

Bristen hittades på 4 st sidor. Sidor där detta fel upptäcktes:

• /omsorg--stod/vara-aldre/taxekatalog – Kolla med Lighthouse
• /kommun--politik/beslut--handlingar/styrdokument-/reglementen-och-arvoden/arvodesreglemente-ockelbogardar – Kolla med Lighthouse
• /kommun--politik/beslut--handlingar/styrdokument-/taxor-och-avgifter/taxekatalog – Kolla med Lighthouse
• /kommun--politik/kommunfakta/ekonomi/taxor--avgifter – Kolla med Lighthouse

Rubrikelementen har inte ordnats i följd i fallande ordning

Bristen hittades på 1 st sidor. WCAG framgångskriterie 2.4.6, nivå AA.
Rubriknivåer används för att skapa en hierarki på en webbsida, där de högre nivåerna representerar viktigare innehåll. Det är viktigt att använda rubriknivåer på ett inkrementellt sätt eftersom det hjälper användare och sökmotorer att förstå sidans struktur och relationerna mellan olika delar av innehåll.

Om du till exempel har en rubrik högst upp på sidan som är markerad som en h1-rubrik, är det förmodligen den viktigaste rubriken på sidan. Efterföljande rubriker bör markeras med h2, h3, och så vidare, i fallande ordning efter betydelse. Detta skapar en hierarki av rubriker som gör att användare och sökmotorer snabbt kan förstå sidans struktur och navigera effektivt.
Ett verktyg du kan ha nytta av direkt i en Chromium-baserad webbläsare är HeadingsMap som synliggör rubrikstrukturen på en webbsida.
Dokumentation hos Deque University »

Sidor där detta fel upptäcktes:

• /kultur--fritid/bibliotek – Kolla med Lighthouse

Appendix

Om du är redo att ta nästa steg; att göra kvalitativa expertundersökningar, men inte vet hur du kan göra det själv. Då kan du kontakta någon som är specialist på området. Ett sätt att veta ifall en leverantör har tillgänglighetsexperter bland sina anställda är att kolla om de är certifierade inom tillgänglighet hos International Association of Accessibility Professionals (IAAP).

Några på den svenska marknaden att fundera på är:

• Axess Lab
• Begripsam
• ETU
• Funka Nu
• Nordic Accessibility Group - en grupp av aktörer som gått samman för att kunna svara på större upphandlingar
• UseIT
• WCAG Networks

Men många webbyråer har också individer som kan det här området tillräckligt väl för att göra experttester av en webbplats tillgänglighet. Så kolla först internt, sedan dina utvecklare eller byrå innan du börjar upphandla.

Verktyg för självdiagnostik

Testet i denna rapport är med verktyget Axe Core. Samma verktyg kan du köra själv på följande sätt för att veta exakt vad på en sida som behöver fixas:

• Google Pagespeed Insights visar bl.a. upp tillgänglighetsproblem.
• axe DevTools är ett plugin till webbläsare som gör att du kan köra Axe-testet direkt i din webbläsares utvecklarläge
• How To Do an Accessibility Review – en introduktion till hur du på egen hand gör en kvalitativ utvärdering av en webbplats tillgänglighet

Testprotokoll

Nedan tabell är testprotokollet för vilka sidor som testades, Lighthouse- och Webperf-betyg, och vilka eventuella fel som upptäcktes på den enskilda URL:en.

En rapport från Webperf.se