Text-to-speech vs. skærmlæsere

Dit indhold har en stemme

Text-to-speech-teknologi (TTS) omdanner skreven information til lyd. Det hjælper mennesker med blindhed, synshandicap, ordblindhed og ADHD med at indtage indhold på en måde, der fungerer for dem. TTS bruges også i vid udstrækning i skoler, af sprogstuderende og af fagfolk, der korrekturlæser med ørerne frem for med øjnene.

Fordi både TTS og skærmlæsere frembringer en syntetisk stemme, antager folk ofte, at de er det samme — eller at det at tilføje en “læs højt”-knap til et website gør det tilgængeligt for blinde brugere. Den antagelse er forkert, og at handle ud fra den kan efterlade dig med et site, der lyder tilgængeligt, men er umuligt for mange mennesker faktisk at bruge. Denne artikel forklarer, hvordan hver teknologi fungerer, hvem der er afhængig af den, hvor grænsen mellem dem reelt går, og hvad der skal til for at bygge ordentligt til skærmlæsere. Hvis du kun husker én ting, så lad det være denne: en læs højt-widget er en bekvemmelighedsfunktion, ikke en tilgængelighedsfunktion.

Hvordan fungerer TTS?

TTS behandler tekst i tre overordnede faser:

Tekstanalyse — bestemmelse af tone, grammatik og struktur, udfoldning af tal og symboler (“$5” bliver til “fem dollars”) og opdeling af sætninger.
Sproglig behandling — beregning af udtale, tryk og betoning, ofte ved hjælp af en udtaleordbog plus regler for ukendte ord.
Lydsyntese — generering af tale ud fra matematiske stemmemodeller, i stigende grad ved hjælp af neurale netværk, der lyder langt mere naturlige end ældre konkatenative motorer.

Moderne systemer tilbyder stemmetilpasning såsom hastighed, toneleje, stemmepersona og sprogvalg. Det afgørende punkt er, hvad TTS tager som input: en tekstblok, som nogen allerede har markeret, indsat eller peget den mod. TTS er grundlæggende en content-out-teknologi. Den læser det, den får. Den udforsker ikke en brugerflade, og den har intet begreb om knapper, formularfelter eller sidestruktur.

Hvad er begrænsningerne ved TTS-teknologi?

TTS er virkelig nyttig, men den er ikke perfekt, og dens begrænsninger betyder noget for den kommende sammenligning:

Udtalehuller — den kan udtale ualmindelige ord, egennavne, medicinske eller juridiske termer og forkortelser forkert.
Ujævn sprogunderstøttelse — mange værktøjer håndterer mainstream-sprog godt, men kæmper med mindre udbredte sprog og regionale dialekter.
Tone og nuance — TTS har svært ved sarkasme, humor og idiomatiske udtryk, så indhold kan blive formidlet med den forkerte tone.
Ingen interaktionsmodel — og det er den helt store: TTS læser; den lader dig ikke gøre noget. Du kan ikke udfylde en kassesideformular, lukke et modalvindue eller flytte mellem menupunkter med TTS alene.

Netop den sidste begrænsning er der, hvor forvekslingen med skærmlæsere begynder.

Hvad er forskellen mellem text-to-speech og skærmlæserteknologi?

Det er her, den udbredte misforståelse opstår. Text-to-speech læser tekst højt — det er dens primære funktion. En skærmlæser gør langt mere: den giver brugere mulighed for at navigere i og betjene en hel computer eller mobilenhed med ørerne og tastaturet (eller berøringsbevægelser).

Skærmlæsere annoncerer brugerfladens labels, formularfelter, knapper og links; de læser den alternative tekst på billeder, så brugere forstår visuelt indhold; og de eksponerer komponenters tilstand — om en afkrydsningsboks er markeret, en menu er udvidet, et faneblad er valgt, eller der er dukket en fejl op. De forvandler en visuel, musestyret brugerflade til en lineær, hørbar, betjenbar en.

En hurtig måde at mærke forskellen på: TTS besvarer spørgsmålet “Hvad står der i dette afsnit?” En skærmlæser besvarer “Hvor er jeg, hvad kan jeg gøre her, og hvad skete der lige?” Det første handler om at indtage indhold. Det andet handler om at styre software.

Hvordan en skærmlæserbruger faktisk bevæger sig gennem en side

Seende brugere skanner en side på få sekunder. En skærmlæserbruger opbygger en mental model sekventielt og er afhængig af struktur for at navigere effektivt. I praksis gør de følgende:

Springer mellem overskrifter for at forstå sidens disposition (derfor betyder et korrekt overskriftshierarki så meget).
Henter en liste over alle links eller alle formularfelter frem for at navigere efter landemærke i stedet for at læse fra top til bund.
Bruger landemærkeområder (banner, navigation, hovedindhold, sidefod) til at springe direkte til det indhold, de ønsker.
Bevæger sig gennem interaktive elementer med tabulatortasten og forventer, at fokus lander et synligt og logisk sted.
Lytter efter live-annonceringer, når noget ændrer sig uden en fuld genindlæsning af siden.

Intet af dette fungerer, medmindre den underliggende markup beskriver siden ærligt. En “læs højt”-funktion leverer ingen af disse navigationsmuligheder — den fortæller blot, hvilken tekst der er på skærmen, i visuel rækkefølge, uden mulighed for at betjene kontrolelementerne.

Hvem bruger hvad, og hvorfor det betyder noget

TTS bruges af et bredt publikum, ofte situationsbestemt: mennesker med ordblindhed, ADHD eller nedsat syn; multitaskere; sprogstuderende; og enhver, der simpelthen foretrækker at lytte. De fleste af disse brugere kan stadig se skærmen og bruge en mus.

Skærmlæserbrugere omfatter mennesker, der er blinde eller har svære synshandicap, samt nogle mennesker med kognitive eller motoriske handicap, som er afhængige af teknologien for overhovedet at kunne bruge en enhed. For dem er det ikke et præferencelag oven på en brugbar brugerflade — det er brugerfladen. De mest udbredte værktøjer er NVDA og JAWS på Windows, VoiceOver på Apple-enheder og TalkBack på Android. Hvert af dem fortolker den samme webside lidt forskelligt, hvilket er én af grundene til, at det betyder noget at teste på tværs af dem.

Hvorfor læs højt-widgets ikke er en erstatning for tilgængelighed

Et voksende antal websites bygger en “lyt til denne side”-knap eller en tredjeparts-widget på, der fremhæver og taler tekst. Disse værktøjer kan hjælpe nogle læsere, og der er intet galt i at tilbyde et som en bekvemmelighed. Problemet er at behandle det som en erstatning for ægte skærmlæserunderstøttelse. Det er det ikke, af flere konkrete grunde.

De læser kun; de betjener ikke. En læs højt-widget vil oplæse din pristabel, men den kan ikke lade en blind bruger vælge et abonnement, åbne kurven, indtaste betalingsoplysninger og gennemføre købet. Ægte opgaver kræver betjenbare kontrolelementer, ikke oplæsning.
De kan ikke eksponere tilstand eller roller. Om en knap er trykket ind, et felt er påkrævet, en sektion er foldet sammen, eller en fejlmeddelelse netop er dukket op — intet af det formidles ved at læse synlig tekst. Skærmlæsere er afhængige af roller, navne og tilstande i markuppen for at annoncere det.
Skærmlæserbrugere har allerede et værktøj. Blinde brugere medbringer deres egen skærmlæser, finjusteret til deres præferencer og muskelhukommelse. En widget på sideniveau konkurrerer med den, forstyrrer den nogle gange og gør intet for at rette den fejlbehæftede markup, som deres skærmlæser sætter i stå over.
De maskerer problemer i stedet for at rette dem. Hvis et formularfelt ikke har et label, springer widget’en det over, præcis som en skærmlæser ville — men nu er det manglende label skjult bag en funktion, der ser hjælpsom ud. Den underliggende defekt forbliver.

Den samme logik gælder, endnu stærkere, for såkaldte tilgængelighedsoverlays — scripts, der lover øjeblikkelig overholdelse ved at lægge automatiserede rettelser og en værktøjslinje oven på et eksisterende site. De reparerer ikke den underliggende kode, de konflikter ofte med brugernes egen hjælpeteknologi, og de kan ikke levere ægte overensstemmelse. Den pålidelige vej er at rette kilden. For en mere udførlig forklaring på, hvorfor overfladiske rettelser kommer til kort, se vores guide til ægte digital tilgængelighed.

Et konkret eksempel: kassesiden, der “taler”

Forestil dig en netbutik, der har tilføjet en læs højt-widget og er overbevist om, at sitet nu er tilgængeligt. En blind kunde ankommer med sin egen skærmlæser kørende. Produktbeskrivelsen læses fint — den del er bare tekst. Men “Læg i kurv”-kontrollen er en stylet div med en klik-handler i stedet for en rigtig knap, så skærmlæseren annoncerer den aldrig som en knap, og tastaturet kan ikke nå den. Antalsvælgeren opdaterer en total uden en live-region, så ændringen er tavs. Rabatkodefeltet har pladsholdertekst, men intet tilknyttet label, så det annonceres kun som “rediger tekst”. Forsendelsesformularen viser en rød fejl visuelt, men fejlen er ikke knyttet til feltet og annonceres slet ikke. Læs højt-widget’en oplæser muntert den synlige tekst og ændrer intet af dette. Kunden kan høre marketingteksten, men kan ikke gennemføre et køb. Den kløft — mellem at høre indhold og at betjene et produkt — er hele forskellen mellem en bekvemmelighedsfunktion og tilgængelighed.

Hvad det faktisk kræver at bygge til skærmlæsere

At understøtte skærmlæsere handler ikke om at tilføje en funktion — det handler om at konstruere dine sider sådan, at betydning, struktur og adfærd er tilgængelige for software, ikke kun for det menneskelige øje. Kerneingredienserne:

Semantisk, struktureret HTML

Brug rigtige overskrifter (h1–h6) i en logisk rækkefølge, native knapper og links til de rette formål, lister til lister og landemærkeelementer til sideområder. Semantisk HTML bærer tilgængelighedsinformation gratis; en mur af generiske containere bærer ingen.

Tekstalternativer til ikke-tekstuelt indhold

Ethvert meningsfuldt billede har brug for præcis alternativ tekst, og dekorative billeder bør markeres, så de springes over. Ikoner, der fungerer som knapper, har brug for tilgængelige navne. Diagrammer og infografikker har brug for et tekstuelt ækvivalent, der formidler den samme information.

Tilgængelige navne, roller og tilstande

Formularfelter har brug for programmatisk tilknyttede labels. Tilpassede komponenter — faneblade, harmonikaer, comboboxe, modalvinduer — har brug for de korrekte roller og tilstande, så skærmlæseren annoncerer, hvad de er, og hvordan de opfører sig. Hvor native HTML ikke er nok, udfylder ARIA hullet, men det skal bruges præcist; forkert ARIA er værre end ingen.

Tastaturbetjening og fokushåndtering

Alt, der virker med en mus, skal virke med et tastatur, fokusrækkefølgen skal være logisk, fokusindikatoren skal være synlig, og dynamiske ændringer (åbning af en dialog, afsløring af en fejl) skal flytte eller annoncere fokus på passende vis. Tastaturunderstøttelse og skærmlæserunderstøttelse er dybt sammenflettede.

Annoncering af dynamiske ændringer

Når indhold opdateres uden en genindlæsning af siden — en formularvalideringsmeddelelse, en kurvtæller, en indlæsningstilstand — så brug live-regioner, så skærmlæseren fortæller brugeren, at der skete noget. Tavse opdateringer er usynlige for mennesker, der ikke kan se skærmen.

Alle disse forventninger er kodificeret i WCAG 2.2-succeskriterierne, som udgør den tekniske rygrad i European Accessibility Act og ADA, som de anvendes på nettet. Hvis du vil have den praktiske detalje, gennemgår vores guide til skærmlæsertest trin for trin, hvordan du verificerer hver af disse adfærdsmønstre med rigtige værktøjer.

Hvorfor “det læses fint for mig” er vildledende

En seende udvikler kan slå en læs højt-funktion til, høre rene sætninger og konkludere, at siden er tilgængelig. Fælden er, at læs højt gengiver den synlige læserækkefølge og den synlige tekst, som begge allerede giver mening for en, der kigger på skærmen. Det fortæller intet om, hvorvidt en tilpasset dropdown annoncerer sine valgmuligheder, hvorvidt fokus er fanget inde i en åben dialog, hvorvidt en knap med kun et ikon har et navn, eller hvorvidt tabulatorrækkefølgen matcher det visuelle layout. Det er præcis de ting, der går i stykker for skærmlæserbrugere, og præcis de ting, som en læs højt-demo ikke kan afsløre. Den eneste måde at vide det på er at teste, som de faktiske brugere gør.

Hvordan du tester for begge — og hvorfor automatisering alene ikke er nok

Du kan ikke bekræfte, at en side fungerer for skærmlæserbrugere, ved at lytte til en læs højt-knap. Du bekræfter det ved at kontrollere struktur, navne, roller, tilstande, tastaturbetjening og den faktiske skærmlæseroplevelse på tværs af flere værktøjer og platforme.

En solid proces kombinerer tre lag:

Automatiseret skanning for at fange de mængdebaserede, maskinelt detekterbare problemer — manglende alt-tekst, tomme labels, brudte ARIA-referencer, kontrastfejl. Vores tilgængelighedsskanningssoftware og en gratis tilgængelighedsskanning er en hurtig måde at fastslå, hvor du står.
Manuel test af eksperter for at vurdere alt, hvad automatisering ikke kan bedømme: om et navn er meningsfuldt, om fokusrækkefølgen giver mening, om en tilpasset widget reelt er betjenbar. Ræsonnementet bag dette lag er dækket i vores guide til manuelle tilgængelighedsaudits.
Test med ægte hjælpeteknologi og ægte brugere. Intet erstatter at betjene siden med NVDA, JAWS, VoiceOver og TalkBack — og, ideelt set, at observere mennesker, der bruger disse værktøjer hver dag. Vores audits udført af mennesker med handicap bringer netop den levede ekspertise.

Automatiserede værktøjer detekterer typisk kun en del af WCAG 2.2-succeskriterierne; resten kræver menneskelig dømmekraft. At behandle en bestået automatiseret skanning som bevis på tilgængelighed er den samme kategori af fejl som at behandle en læs højt-widget som skærmlæserunderstøttelse.

Hvor QualiBooth passer ind

QualiBooth tester dit website mod både TTS- og skærmlæser-brugsscenarier, så dit indhold er tilgængeligt for brugere, der er afhængige af en af teknologierne — og så de mennesker, der er afhængige af en skærmlæser, ikke blot kan høre dit indhold, men faktisk kan betjene dit produkt. Vores tilgængelighedstoolkit og Agora-platformen kombinerer skanning med struktureret manuel gennemgang, og vores team for tilgængelighedsrådgivning hjælper dig med at udbedre det, testene afdækker, og bringe dig i overensstemmelse med kravene i WCAG 2.2, EAA og ADA.

Bundlinjen er enkel. At tilføje en stemme til dit indhold er et fint trick. At gøre dit indhold navigerbart, betjenbart og korrekt annonceret til en skærmlæser er tilgængelighed — og kun det ene af dem opfylder loven og de mennesker, den beskytter.