Tillgänglighet ≠ Overlay: när ett overlay stör skärmläsaren
Skärmläsare presenterar information som ett gränssnitt exponerar programmatiskt genom tal eller punktskrift. Användare lär sig kommandon, ställer in preferenser och utvecklar strategier för rubriker, länkar, regioner, formulär och kontroller. W3C räknar skärmläsare som hjälpmedel för webbanvändning. Utgångspunkten bör därför vara en korrekt byggd webbplats, inte att sidan försöker ersätta användarens teknik.
Skärmläsaren är redan användarens hjälpmedel
Skärmläsare presenterar information som ett gränssnitt exponerar programmatiskt genom tal eller punktskrift. Användare lär sig kommandon, ställer in preferenser och utvecklar strategier för rubriker, länkar, regioner, formulär och kontroller. W3C räknar skärmläsare som hjälpmedel för webbanvändning. Utgångspunkten bör därför vara en korrekt byggd webbplats, inte att sidan försöker ersätta användarens teknik.
Vad en skärmläsare faktiskt behöver från en webbplats
Interoperabilitet beror på koden: semantisk HTML, riktiga rubriker, identifierbara länkar och knappar, etiketter kopplade till fält, korrekta tillgängliga namn, roller, tillstånd och värden samt konsekvent fokusordning. W3C beskriver hur skärmläsare kan använda rubrikstrukturen för navigering och hur standardkontroller i HTML stödjer hjälpmedel. Om denna grund brister ligger problemet i webbplatsens implementation.
Vad som förändras när ett overlay läggs till
Vissa overlays lägger in JavaScript från tredje part som analyserar sidan och försöker reparera problem i gränssnittet. Hjälpmedlet kan då få en modifierad version av gränssnittet. Overlay Fact Sheet varnar för att sådana reparationer kan göra sidan långsammare eller orsaka oväntade förändringar för hjälpmedelsanvändare. Det betyder inte att varje overlay alltid orsakar samma fel, men ytterligare en variabel införs mellan webbplats och skärmläsare.
Fokus, tangentbord och struktur: små förändringar kan bli stora hinder
För den som navigerar utan syn avgör fokus var personen befinner sig och vilket element som ska användas. Oväntade fokusförflyttningar, avlyssnade tangenter eller ändrad semantik kan skapa stor desorientering. Detsamma gäller konstgjorda rubriker, opålitliga namn eller tillstånd som inte meddelas korrekt. Overlay Fact Sheet samlar erfarenheter där skärmläsaranvändare beskriver fokushopp och svårare navigering.
En knapp för ”skärmläsarprofil” ställer fel fråga
Frågan bör inte vara om användaren aktiverat en särskild profil, utan om webbplatsen fungerar med den vanliga hjälpmedelstekniken från början. W3C påpekar att människor använder olika inställningar och verktyg utifrån behov och preferenser. Att behöva hitta en widget, öppna den och välja ett extra läge lägger till steg utan att garantera att de ursprungliga hindren åtgärdas.
Alla skärmläsaranvändare navigerar inte på samma sätt
NVDA, JAWS, VoiceOver, TalkBack och andra lösningar har olika kommandon och lägen. Användare ställer dessutom in röst, hastighet, skiljetecken, punktskrift och navigering individuellt. Det är riskabelt att utforma en universell ”skärmläsarupplevelse”. Robust tillgänglighet exponerar standardiserad och förutsägbar information.
Korrekt semantik låter användaren bestämma hur navigeringen ska ske
En bra rubrik är inte bara stor text. Ett fält blir inte tillgängligt bara för att ett ord visas visuellt i närheten. Med lämplig HTML och vid behov korrekt ARIA kan skärmläsaren förmedla strukturen och användaren navigera med sina egna kommandon. W3C rekommenderar inbyggda element när det är möjligt och ARIA för att förmedla roller, tillstånd och egenskaper.
Att testa med skärmläsare är inte bara att kontrollera att sidan talar
Att höra text bevisar inte att sidan går att använda. Hela uppgifter behöver testas: nå huvudinnehållet, förstå hierarkin, använda menyer och formulär, identifiera fel, hantera dialoger och dynamiska komponenter och återfå orienteringen efter interaktion. Tangentbordstestning och tester med vana användare är också viktiga.
Vad ett företag bör göra i stället för att förlita sig på ett lager
Identifiera först de verkliga hindren och åtgärda dem sedan i komponenten, mallen, temat eller applikationen som skapar dem. Använd semantisk HTML, tillgängliga mönster, korrekt fokushantering och tester med representativa kombinationer av webbläsare och hjälpmedel. Automatisering kan hitta vissa problem men ersätter inte funktionella och mänskliga tester.
Tillgänglighet ≠ Overlay
Leverans 06 fokuserar på en enkel idé: skärmläsaren tillhör användaren, inte webbplatsen. Webbplatsen ska erbjuda ett stabilt och förutsägbart gränssnitt som tekniken kan samverka med. Om ett lager ändrar struktur, fokus eller semantik kan ett känt hinder bli ett annat som är svårare att diagnostisera. Den hållbara lösningen är fortfarande att rätta vid källan och testa med verkliga hjälpmedel.
Officiella och tekniska källor
W3C Web Accessibility Initiative (WAI)
Tools and Techniques — How People with Disabilities Use the Web
Page Structure Tutorial
WAI-ARIA Overview
Overlay Fact Sheet
Overlay Fact Sheet — assistive technology experiences and limitations
Entrega 06 — Overlays y lectores de pantalla.