Bättre användarupplevelse med adaptiva verktyg

Verktygen för interaktion

För människor som är beroende av adaptiva webbverktyg för att navigera på internet är sättet innehållet byggs och presenteras på allt. Världens mest avancerade hjälpmedelsteknik kan inte läsa, tillkännage eller hantera innehåll som inte finns i en tillgänglig form. En knapp som egentligen är en formgiven <div>, en bild utan textalternativ eller en anpassad rullgardinsmeny utan tangentbordsstöd är helt enkelt osynlig — eller ännu värre, en återvändsgränd — för de människor som är beroende av dessa verktyg varje dag.

QualiBooth hjälper dig att förstå två saker samtidigt: hur en användares verktyg faktiskt tolkar ditt innehåll, och vilket innehåll eller vilken struktur som saknas, är trasig eller tvetydig. Den kombinationen är vad som skiljer en webbplats som tekniskt sett laddar från en som verkligen fungerar för alla.

Den här guiden går igenom de viktigaste kategorierna av hjälpmedels- och adaptiv teknik, hur var och en förväntar sig att en webbplats ska bete sig, och de praktiska steg du kan ta för att bygga med dessa verktyg snarare än mot dem. Den drar också en tydlig gräns mellan äkta hjälpmedelsteknik och tillgänglighetsoverlays — eftersom de två ofta förväxlas, och den förväxlingen får verkliga konsekvenser för verkliga användare.

Vad “adaptiva webbverktyg” faktiskt betyder

Adaptiva webbverktyg — oftare kallade hjälpmedelsteknik (AT) — är programvara och hårdvara som förändrar hur en person uppfattar eller hanterar ett digitalt gränssnitt. De är inte tillägg till din webbplats; de är användarens egen miljö, konfigurerad efter deras behov och ofta använd i timmar varje dag på tusentals webbplatser.

De största kategorierna inkluderar:

Skärmläsare som omvandlar innehåll på skärmen till syntetiserat tal eller uppdateringsbar punktskrift.
Skärmförstoring som förstorar och flödar om delar av eller hela skärmen.
Switch-åtkomst för personer som inte kan använda ett vanligt tangentbord eller en vanlig mus.
Röststyrning som styr gränssnittet helt med talade kommandon.
Inbyggda webbläsar- och operativsystemsfunktioner såsom högkontrastlägen, reducerad rörelse och läsverktyg.
Läs- och förståelsehjälpmedel som förenklar, läser upp eller omstrukturerar text.

Var och en av dessa bygger på samma grund: en välstrukturerad, semantisk sida som kan hanteras med tangentbord och följer etablerade standarder. När du bygger enligt WCAG 2.2 bygger du det kontrakt som vart och ett av dessa verktyg är beroende av.

Skärmläsare: struktur är gränssnittet

Skärmläsare är den mest välkända hjälpmedelstekniken och, för många team, den svåraste att designa för — just för att den visuella layout du ser berättar nästan ingenting om vad en skärmläsare tillkännager.

De mest använda skärmläsarna är NVDA och JAWS på Windows, VoiceOver på macOS och iOS, och TalkBack på Android. De “ser” inte din sida; de bygger en modell utifrån tillgänglighetsträdet, som härleds från din HTML-semantik och eventuell ARIA du lägger till ovanpå.

Vad skärmläsare behöver från dig

Äkta semantiska element. Använd <button>, <a>, <nav>, <main>, <h1>–<h6> och <table> till det de är. En rubrik måste vara en rubrik så att användare kan hoppa mellan avsnitt; en länk måste vara en länk så att den visas i länklistan.
Meningsfulla textalternativ. Varje informativ bild behöver ett alt-attribut som beskriver dess syfte. Dekorativa bilder bör ha ett tomt alt="" så att de hoppas över i stället för att tillkännages som brus.
Programmatiska etiketter för kontroller. Formulärfält behöver kopplade <label>-element; knappar med enbart ikon behöver ett tillgängligt namn via aria-label eller visuellt dold text.
En logisk rubrikhierarki. Rubriker är det primära sättet skärmläsaranvändare skummar en sida på. Att hoppa över nivåer eller använda rubriker enbart för visuell storlek bryter den navigeringen.
Korrekt ARIA — och endast vid behov. ARIA kan kommunicera tillstånd (expanderad, vald, inaktiverad) och roller för anpassade widgets, men dålig ARIA är värre än ingen. Den första regeln för ARIA är att använda inbyggd HTML i stället där det är möjligt.

En vanlig källa till förvirring är skillnaden mellan en skärmläsare och vanlig text-till-tal. Ett läsverktyg läser upp text; en skärmläsare exponerar och hanterar hela gränssnittet, inklusive kontroller, tillstånd och navigering. Vi går igenom denna distinktion på djupet i text-till-tal kontra skärmläsare.

Eftersom automatiserade verktyg bara kan fånga en bråkdel av skärmläsarproblemen är det enda tillförlitliga sättet att veta hur din webbplats låter att testa den på samma sätt som användarna gör. Vår guide för skärmläsartestning går igenom det praktiska arbetsflödet, och en dedikerad skärmläsarutvärdering tar dina viktigaste användarresor genom den processen med erfarna testare.

Skärmförstoring: designa för den inzoomade vyn

Personer med nedsatt syn förstorar ofta skärmen från 200 % till 800 % eller mer och ser bara en liten del av sidan åt gången. Vissa använder operativsystemets förstoringsverktyg; andra förlitar sig på webbläsarzoom eller specialiserad programvara.

Vid hög förstoring blir layoutbeslut du aldrig tänker på avgörande:

Omflöde. Innehåll måste flöda om till en enda kolumn vid 400 % zoom (WCAG 2.2 framgångskriterium 1.4.10) så att användare inte behöver scrolla i två riktningar för att läsa en mening.
Närhet mellan relaterade element. Om ett felmeddelande visas långt från det fält det beskriver kan en förstorande användare aldrig se dem i samma vyport. Håll etiketter, inmatningsfält och återkoppling samlade.
Synligt fokus. En tydlig fokusindikator med hög kontrast låter en förstorande användare hitta var de befinner sig efter att vyn hoppar.
Ingen förlust av innehåll eller funktion. Ingenting bör beskäras, överlappas eller göras obrukbart när text förstoras upp till 200 % (framgångskriterium 1.4.4).

Förstoring belönar rena, responsiva layouter och bestraffar designer med fasta pixlar och innehåll som är beroende av hovring.

Switch-åtkomst och tangentbordshantering

Switch-enheter låter människor hantera en dator med ett eller två enkla inmatningar — en knapp, en sug-blås-enhet eller en huvudrörelse — vanligtvis genom att skanna genom interaktiva element ett i taget. Switch-åtkomst bygger på tangentbordsstöd: om din webbplats fungerar fullt ut från tangentbordet fungerar den nästan säkert också med switchar.

Det gör fullständig tangentbordshantering till en av de saker med störst genomslag du kan få rätt:

Allt nåbart. Varje interaktivt element måste vara fokuserbart och hanterbart utan mus — länkar, knappar, formulärkontroller, menyer, modaler, karuseller och anpassade widgets allihop.
En synlig, logisk fokusordning. Fokus bör röra sig genom sidan i en ordning som matchar det visuella och läsflödet, och det fokuserade elementet måste alltid vara tydligt angivet.
Inga tangentbordsfällor. Användare måste kunna flytta fokus ut ur valfri komponent, inklusive inbäddade medier och dialoger.
Hopplänkar. En “hoppa till huvudinnehåll”-länk låter människor förbigå upprepad navigering i stället för att skanna genom den på varje sida.

Om en kund fyller i ett formulär, kan hen tabba genom varje fält, öppna en rullgardinsmeny, välja en produkt och skicka in — allt utan att röra en mus? Kommer webbläsarens autofyll att samarbeta med din markup? Det är de frågor som switch- och tangentbordsanvändare besvarar om din webbplats, oavsett om du frågar dem eller inte.

Röststyrning: namn och synliga etiketter spelar roll

Röststyrningsverktyg såsom Dragon, Voice Control och Voice Access låter användare säga kommandon som “klicka Skicka” eller “scrolla ner”. För att dessa kommandon ska fungera måste en kontrolls synliga etikett matcha dess tillgängliga namn. Detta är grunden för WCAG 2.2 framgångskriterium 2.5.3, Label in Name.

Praktisk vägledning:

Det tillgängliga namnet bör innehålla den synliga texten. Om det står “Skicka meddelande” på en knapp, ge den då inte ett aria-label med “Skicka formulär” — användaren som säger “klicka Skicka meddelande” kommer att ignoreras.
Undvik kontroller med enbart ikon utan text, eller ge dem ett tillgängligt namn som matchar ett troligt talat kommando.
Håll klickbara mål tillräckligt stora för att väljas tillförlitligt, vilket också uppfyller kriteriet för målstorlek i WCAG 2.2.

Tillgänglighetsfunktioner i webbläsare och operativsystem

Alla adaptiva verktyg är inte separata produkter. Moderna webbläsare och operativsystem levereras med kraftfulla inbyggda funktioner som användare aktiverar systemövergripande, och din webbplats bör respektera dem automatiskt:

Reducerad rörelse. Respektera mediafrågan prefers-reduced-motion för att inaktivera eller mildra animationer för användare som upplever illamående eller distraktion av rörelse.
Mörkt läge och hög kontrast. Stöd prefers-color-scheme och Windows High Contrast / Forced Colors så att ditt gränssnitt förblir läsbart utan att du motarbetar användarens inställningar.
Textförstoring och zoom. Använd relativa enheter så att webbläsarens textskalning fungerar, i stället för att låsa storlekar i pixlar.
Läslägen och läsverktyg. Webbläsarens läsvyer och verktyg som Immersive Reader skalar ner en sida till dess kärninnehåll — vilket fungerar mycket bättre när din HTML är semantisk och fri från oreda.

Dessa funktioner kostar inget extra för användaren och mycket lite för dig, men de förbättrar dramatiskt komforten för en bred publik, inklusive människor utan diagnostiserade funktionsnedsättningar.

Läs- och förståelseverktyg

Läsverktyg betjänar människor med dyslexi, ADHD, kognitiva funktionsnedsättningar eller begränsad läskunnighet i sidans språk. De inkluderar text-till-tal-uppläsare, läslinjaler, ordmarkering, sammanfattningsverktyg och översättningsverktyg.

För att fungera väl med dem:

Skriv på ett tydligt, välorganiserat språk med beskrivande rubriker och korta stycken.
Märk upp sidan så att huvudinnehållet är tydligt identifierbart och läsordningen är korrekt.
Undvik att förmedla mening enbart genom färg, layout eller bilder — erbjud en textmotsvarighet.
Se till att ditt språk är deklarerat (lang-attribut) så att uppläsning och översättning använder rätt uttal och regler.

God innehållsstruktur hjälper varje verktyg i den här artikeln på en gång, eftersom de alla hämtar från samma underliggande markup.

Äkta hjälpmedelsteknik kontra tillgänglighetsoverlays

Detta är den distinktion som betyder mest, och det är här många organisationer går fel.

Äkta hjälpmedelsteknik — skärmläsare, förstoringsverktyg, switch-åtkomst, röststyrning — körs på användarens enhet, under användarens kontroll, och hanterar din webbplats genom dess semantik och tangentbordsstöd. Användaren har ägnat år åt att konfigurera den. Din uppgift är helt enkelt att bygga en sida som dessa verktyg kan förstå.

Tillgänglighetsoverlays är tredjepartsskript du lägger till på din egen webbplats och som lovar att “göra den tillgänglig” automatiskt, vanligtvis via en flytande widget. De är inte en ersättning för hjälpmedelsteknik, och de är inte en lösning på en otillgänglig webbplats. Här är varför:

De kan inte reparera den underliggande koden. Overlays ligger ovanpå sidan; de kan inte tillförlitligt uppfinna saknad alt-text, reparera trasiga rubrikstrukturer eller få en <div> att bete sig som en riktig knapp i varje skärmläsare.
De krockar ofta med äkta AT. Många skärmläsaranvändare rapporterar att overlays stör de verktyg de redan förlitar sig på, vilket ibland gör webbplatser svårare att använda, inte enklare.
De skapar en falsk känsla av efterlevnad. Att installera en widget uppfyller inte WCAG 2.2, EAA eller ADA. Rättegångar har väckts mot webbplatser som använder overlays, just för att de underliggande hindren kvarstod.
De återspeglar inte den levda erfarenheten. Tillgänglighet bedöms i slutändan av de människor som använder AT varje dag — vilket är anledningen till att vi genomför granskningar av människor med funktionsnedsättning i stället för att förlita oss på ett skripts påståenden.

Den pålitliga vägen är att åtgärda tillgänglighet i koden och validera den med både automatiserad och mänsklig testning. Vi förklarar denna filosofi mer utförligt i vad äkta digital tillgänglighet betyder.

Ett praktiskt arbetsflöde för att bygga med adaptiva verktyg

Att bygga för hjälpmedelsteknik är inte ett engångsprojekt; det är en process som passar in i hur du redan levererar programvara. En hållbar metod kombinerar vanligtvis fyra saker:

Automatiserad skanning, tidigt och ofta. Verktyg som skanningsprogramvara för tillgänglighet fångar en stor mängd problem på kodnivå — saknade etiketter, kontrastfel, trasig ARIA — innan de når produktion. Automatiserade kontroller är snabba och repeterbara, men de täcker bara en del av bilden.
Manuell testning och testning med hjälpmedelsteknik. De problem som påverkar verkliga användare mest — förvirrande fokusordning, oklara tillkännagivanden, obrukbara anpassade widgets — kräver en människa. Vår guide för manuella tillgänglighetsgranskningar beskriver hur detta kompletterar automatisering.
Förankra tillgänglighet i ditt team. Att behandla tillgänglighet som en kontinuerlig disciplin, med stöd av förbättring av tillgänglighetsprocessen, förhindrar den långsamma regression som uppstår när åtgärder är engångsföreteelser.
Rätt verktyg för din stack. QualiBooth tillgänglighetsverktygslådan samlar skanning, övervakning och rapportering, medan Agora och vår community edition erbjuder ingångar för team i olika mognadsstadier.

Om du är ny inför terminologin i den här artikeln är tillgänglighetsordlistan en användbar följeslagare när du inför dessa metoder.

Var QualiBooth passar in

QualiBooth identifierar problem på din befintliga webbplats och kan också skanna sidor innan de publiceras, så att kunder som använder vilket adaptivt verktyg som helst får en sömlös upplevelse som ökar användbarheten och varumärkeslojaliteten. Vi kombinerar automatiserad upptäckt med utvärdering av erfarna testare och människor med funktionsnedsättning och hjälper sedan ditt team att omvandla resultat till hållbara åtgärder — aldrig en overlay som maskerar problemet.

Målet är okomplicerat: en webbplats som fungerar med de verktyg dina användare redan litar på, på deras villkor, varje gång de besöker.

Redo att se hur din webbplats presterar för äkta hjälpmedelsteknik? Kör en gratis tillgänglighetsskanning för att hitta snabba vinster, begär en demo för att se QualiBooth i praktiken, eller prata med vårt team om ett skräddarsytt tillgänglighetskonsult-uppdrag.