Motorn flaggar hellre än gissar: needs review
Needs review betyder att motorn hittade något den inte kunde avgöra på egen hand, och att den lämnar frågan till en människa. Den kallar det aldrig ett fel, och den räknar det aldrig in i någon siffra. I rapporten står det som "Behöver granskas", i klarspråksversionen som "Behöver en mänsklig kontroll".
Bakom funktionen ligger en enkel princip. Vår engine påstår aldrig att den hittat ett fel den inte kunnat verifiera. Den flaggar för mänsklig granskning i stället, och håller fyndet utanför alla siffror.
Problemet: automatik som låtsas vara säker
Ett automatiskt tillgänglighetsverktyg bygger på regler. Vissa saker kan en maskin avgöra med säkerhet, till exempel att en bild saknar alt-text. Andra saker kan den inte. Ett vanligt exempel är kontrast: om en text ligger ovanpå en bakgrund som delvis skyms av något annat, kan verktyget inte veta vilken färg som faktiskt möter ögat. Där behövs en människa som tittar.
Många verktyg löser det genom att tiga om osäkerheten, eller genom att kasta in den bland felen. Båda vägarna vilseleder. Tiger verktyget får du en rapport som ser renare ut än verkligheten. Buntar det ihop osäkerheten med felen får du en lista som ser värre ut än den är, och du lägger tid på att rätta något som kanske aldrig var trasigt.
Konsekvensen: du kan inte lita på nollan
axe-core, granskningsmotorn i botten, skiljer på två sorters fynd. Ett "violation" är ett fel som verktyget säkert kunnat konstatera. Ett "incomplete" är en kontroll det inte kunde avgöra. Räknas de två ihop blir varje siffra i rapporten otydlig. En nolla som egentligen döljer tjugo ogranskade kontroller är inte en ärlig nolla.
Vår motor läser axes incomplete-fynd och bär dem vidare som en egen kategori. En sida vars enda fynd är needs review påstår därför aldrig "0 hinder". Rapporten säger det verkliga skälet, aldrig en påhittad mätning.
Lösningen: en egen plats i varje format
Needs review har en egen plats oavsett hur du läser rapporten:
- I klarspråks- och CLI-rapporten ligger fynden i en egen sektion, utanför listan över fel.
- I JUnit-formatet blir de "skipped", aldrig "failure".
- I GitHub Actions kommer de som en notis, aldrig som ett fel eller en varning, och de kan därför aldrig fälla ett bygge.
- I molnsvaret ligger de i egna fält, skilda från felräkningen.
- I underlaget till ett tillgänglighetsutlåtande hålls de utanför listan över det som inte uppfyller kraven.
Texten du ser är rak. I klartext står ungefär att fyndet behöver granskas, att automatiken inte kunde avgöra det och att du behöver kontrollera det för hand, och att det inte räknas in i summorna ovan.
Vinsten: en rapport du kan lita på
När osäkerheten får en egen plats blir siffrorna sanna. En felsiffra betyder fel, inte fel plus sånt vi inte hann kolla. Du ser direkt vad som är bekräftat och vad som väntar på en mänsklig blick, och du kan planera därefter. En rapport ska säga precis vad vi vet, varken mer eller mindre.
För dig som lämnar in ett tillgänglighetsutlåtande betyder det något extra. Det du redovisar som en brist är en verklig brist, och en ogranskad kontroll hamnar inte där av misstag.
Funktionen finns i motorn från version 3.1.0 och framåt. Senaste publicerade versionen är 3.1.5.
Vill du se hur din webbplats står sig, både det bekräftade och det som behöver en mänsklig kontroll? Vår tillgänglighetsanalys bygger på samma motor och visar båda delarna. Boka en tid så tittar vi tillsammans.