WCAG 3.3.9: Tillgänglig autentisering (förbättrad)

Vad den här regeln innebär

WCAG 3.3.9 — Accessible Authentication (Enhanced) är AAA-nivåns motsvarighet till WCAG 3.3.8 (Accessible Authentication — Minimum, AA). Tillsammans utgör de ett par kriterier som introducerades i WCAG 2.2 och som är utformade för att säkerställa att processen att styrka sin identitet mot en webbplats eller applikation inte i sig blir ett tillgänglighetshinder.

På AAA-nivå skärper 3.3.9 kraven avsevärt. Kriteriet säger: Ett kognitivt funktionstest får inte krävas i något steg i en autentiseringsprocess om inte det steget tillhandahåller minst ett av följande: en alternativ autentiseringsmetod som inte bygger på ett kognitivt funktionstest; en mekanism finns tillgänglig för att hjälpa användaren att slutföra det kognitiva funktionstestet; eller det kognitiva funktionstestet består i att känna igen objekt. Avgörande är att AAA-kriteriet, till skillnad från AA-versionen (3.3.8), tar bort undantaget som tillät igenkänning av icke-objektinnehåll (såsom bilder av icke-objekt som en användare valt tidigare). På denna nivå är endast verklig objektigenkänning — att känna igen vanliga objekt från verkligheten, som bilder av en katt, en cykel eller ett hus — tillåten som kognitivt funktionstest, och endast om de andra villkoren inte är uppfyllda.

Ett kognitivt funktionstest definieras som varje uppgift som kräver att användaren minns, bearbetar eller transkriberar information. Detta inkluderar: att komma ihåg ett användarnamn eller lösenord, lösa ett matematiskt pussel, slutföra en CAPTCHA som kräver att man tyder förvrängd text, besvara en säkerhetsfråga om personlig historik (t.ex. "Vad hette ditt första husdjur?") eller transkribera en teckensekvens. Alla dessa är minnes- eller transkriptionsuppgifter som många användare inte kan utföra pålitligt.

Vad som räknas som godkänt: Ett autentiseringssteg uppfyller 3.3.9 om det inte kräver något kognitivt funktionstest, eller om det uppfyller ett av följande villkor: (1) en helt separat, icke-kognitiv autentiseringsväg erbjuds (t.ex. en magisk länk som skickas via e-post, WebAuthn/passkey, biometrisk inloggning); (2) en mekanism hjälper till att slutföra testet (t.ex. att webbläsarens lösenordshanterare inte blockeras, eller att kopiera-klistra in är tillåtet); eller (3) det enda kognitiva testet som förekommer är att känna igen ett vanligt objekt från verkligheten i en uppsättning bilder.

Vad som räknas som underkänt: Varje flöde som tvingar användaren — utan möjlighet att gå runt eller välja alternativ — att minnas ett lösenord utantill, transkribera en kod som inte kan klistras in, lösa en visuell eller ljudbaserad CAPTCHA utan alternativ, besvara kunskapsbaserade säkerhetsfrågor eller identifiera tidigare valda bilder av icke-objektinnehåll (t.ex. abstrakta former eller personliga foton) utan en alternativ autentiseringsväg.

Officiella undantag: Själva WCAG-specifikationen anger att igenkänning av objekt (fotografier av saker i verkligheten) är den enda bildigenkänningsuppgift som är tillåten på denna AAA-nivå. AA-kriteriet (3.3.8) tillät också igenkänning av "icke-objekt" i form av personligt valda bilder, men 3.3.9 tar bort det undantaget helt. Det finns inget undantag för "allmänt använda" autentiseringsmönster — om ett mönster kräver ett kognitivt test utan alternativ, underkänns det enligt 3.3.9.

Varför det är viktigt

Autentisering är ofta den första meningsfulla interaktionen en användare har med en digital tjänst. Om den interaktionen i sig är otillgänglig blir resten av webbplatsens tillgänglighet irrelevant — användaren kommer inte in över huvud taget. WCAG 3.3.9 adresserar detta hinder direkt, och dess påverkan sträcker sig över en bred grupp av personer med funktionsnedsättning.

Användare med kognitiva funktionsnedsättningar — inklusive personer med dyslexi, ADHD, traumatisk hjärnskada, demens eller inlärningssvårigheter — kan uppleva det som extremt svårt eller omöjligt att memorera komplexa lösenord, manuellt transkribera tidsbegränsade engångskoder eller tyda förvrängd CAPTCHA-text. Världshälsoorganisationen uppskattar att cirka 1 av 6 personer globalt upplever någon form av betydande funktionsnedsättning, och kognitiva funktionsnedsättningar utgör en av de största och mest underbetjänade kategorierna inom webbtillgänglighet.

Användare med motoriska funktionsnedsättningar — såsom personer med Parkinsons sjukdom, essentiell tremor, ryggmärgsskador eller tillstånd som kräver switch-styrning eller ögonstyrning — kan ha svårt att skriva lösenord eller transkribera koder tecken för tecken på ett korrekt sätt. Att blockera urklistring (en vanlig bedrägeriförebyggande åtgärd som är aktivt skadlig) innebär att dessa användare måste mata in varje tecken mödosamt via sitt hjälpmedel, vilket dramatiskt ökar felprocent och trötthet.

Användare som är blinda eller har nedsatt syn kan vara helt beroende av skärmläsare eller förstoringsverktyg. Visuella CAPTCHA:er är helt otillgängliga utan ett ljudalternativ, och även ljud-CAPTCHA:er är ökända för att vara svåra för användare med hörselnedsättning eller auditiva bearbetningssvårigheter. Bildbaserade utmaningar som "välj alla trafikljus" kan också vara problematiska när bildbeskrivningar saknas eller är missvisande.

Användare som är döva eller har nedsatt hörsel kan möta hinder i autentiseringsmetoder som enbart bygger på telefonsamtal för att leverera engångskoder, särskilt när dessa samtal är röstbaserade utan SMS-alternativ.

Ett konkret scenario från verkligheten: Föreställ dig en 72-årig användare med mild kognitiv svikt som försöker logga in på sin internetbank. Banken kräver ett användarnamn (som måste kommas ihåg, inte e-postadressen), ett komplext lösenord (urklistring är blockerad) och en CAPTCHA med förvrängd text. Användaren misslyckas med CAPTCHA:n två gånger, blir utelåst och måste ringa bankens kundtjänst — en process på 40 minuter. Om banken hade implementerat passkeys eller en magisk länk skulle den här användaren ha autentiserat på några sekunder. Detta scenario utspelar sig miljontals gånger dagligen på webben, och det är helt förebyggbart.

Utöver funktionsnedsättning gynnar tillgänglig autentisering alla användare. Lösenordshanterare, som används av hundratals miljoner människor, är beroende av möjligheten att klistra in inloggningsuppgifter. Att blockera klistra in, kräva manuell transkribering eller bädda in otillgängliga CAPTCHA:er frustrerar även vanliga användare. Det finns också säkerhetsargument: att tvinga fram komplex manuell lösenordsinmatning ökar sannolikheten för att användare väljer enklare, svagare lösenord eller återanvänder dem på flera webbplatser. Passkeys och magiska länkar, de rekommenderade alternativen, är både mer tillgängliga och säkrare än traditionella flöden med lösenord plus CAPTCHA.

Relaterade Axe-core-regler

WCAG 3.3.9 klassificeras som att den kräver endast manuell testning. Från och med axe-core 4.10 finns det ingen automatiserad regel som fullt ut utvärderar detta kriterium. För att förstå varför automatiserade verktyg inte kan upptäcka dessa överträdelser måste man förstå vad kriteriet faktiskt mäter.

• Manuell testning krävs — upptäckt av kognitiv funktion: Automatiska skannrar kan upptäcka förekomsten av vissa HTML-element (som ett <input type='password'> eller en iframe som bäddar in en tredjeparts CAPTCHA-widget), men de kan inte avgöra om ett komplett autentiserings-flöde kräver ett kognitivt funktionstest utan tillgängligt alternativ. Kriteriet handlar om hela användarresan över potentiellt flera steg och sidor, inte egenskaperna hos enskilda element. En skanner kan inte utvärdera om klistra in blockeras programmatiskt via JavaScript, om en tidsgräns på ett kodinmatningsfält är rimlig eller om en alternativ autentiseringsväg verkligen undviker kognitiva tester. Detta är beteende- och arkitekturfrågor som kräver att en mänsklig utvärderare går igenom den faktiska autentiseringsprocessen.
• Manuell testning krävs — verifiering av alternativ väg: Även om en skanner upptäcker en CAPTCHA-widget kan den inte verifiera om en tillgänglig alternativ autentiseringsmetod finns på samma sida eller i samma flöde. Den kan inte utvärdera om ett alternativ som "använd en passkey i stället" verkligen är likvärdigt eller om det är gömt på en sekundär inställningssida som i sig kräver att man klarar den otillgängliga CAPTCHA:n först. Att utvärdera likvärdigheten hos alternativa vägar kräver mänsklig bedömning av hur fullständiga och framträdande dessa alternativ är.
• Manuell testning krävs — beteende för urklistring: JavaScript som fångar upp paste-händelser och avbryter dem (event.preventDefault() i en paste-lyssnare) är osynligt för statisk HTML-analys. En skanner ser ett giltigt <input>-element; den kan inte veta att klistra in i det har inaktiverats. Endast manuell testning — att faktiskt försöka klistra in ett lösenord eller en kod — kan avslöja detta fel.
• Manuell testning krävs — kompatibilitet med hjälpmedel för autentiseringswidgets: Tredjeparts autentiserings-SDK:er (sociala inloggningsknappar, CAPTCHA-leverantörer, biometriska uppmaningar) kan renderas i iframes eller Shadow DOM som automatiska skannrar inte kan tränga igenom fullt ut. Manuell testning med skärmläsare som NVDA, JAWS och VoiceOver är avgörande för att bekräfta att alla interaktiva element i autentiseringsflödet är hanterbara och begripliga.

Hur man testar

1. Identifiera alla autentiseringsingångar: Innan du testar, kartlägg alla ställen i applikationen där en användare måste autentisera sig eller verifiera sin identitet. Detta inkluderar initial inloggning, skapande av konto, återställning av lösenord, tvåfaktorsautentiseringsuppmaningar, återautentisering vid sessionstimeout, betalningsbekräftelseskärmar och åldersverifieringsgrindar. Var och en av dessa flöden måste utvärderas separat.
2. Kör en automatiserad grundskanning: Använd axe DevTools (webbläsartillägg) eller Lighthouse i Chrome DevTools på varje autentiseringssida. Även om dessa verktyg inte direkt flaggar överträdelser av 3.3.9 kommer de att lyfta fram relaterade problem — saknade etiketter på formulärfält, otillgängligt iframe-innehåll, bristande fokus-hantering — som förstärker autentiseringshinder. Notera alla flaggade problem som kontext för den manuella utvärderingen. I axe DevTools, titta på fliken "Needs Review" för punkter som kräver manuell bedömning.
3. Granska efter kognitiva funktionstest: För varje autentiseringssteg, fråga: kräver detta steg att användaren (a) minns något, (b) transkriberar något eller (c) löser ett pussel? Om ja, verifiera att minst ett av följande finns och är lika framträdande: en icke-kognitiv alternativ väg; en mekanism (som tillåten urklistring eller ett fält som är kompatibelt med autofyll) som hjälper till att slutföra uppgiften; eller att den enda kognitiva uppgiften är att känna igen ett vanligt objekt från verkligheten.
4. Testa beteendet för urklistring: I varje lösenords- och kodinmatningsfält, kopiera en textsträng till urklippet och försök klistra in den med Ctrl+V (Windows/Linux) eller Cmd+V (macOS). Om klistra in blockeras är detta ett fel. Testa också om webbläsarens lösenordshanterare för autofyll undertrycks (kontrollera efter autocomplete='off' eller JavaScript som rensar autofyllvärden vid fokus).
5. Testa med NVDA + Firefox: Navigera genom hela autentiseringsflödet med enbart tangentbord och skärmläsaren NVDA. Verifiera att alla formulärfält annonseras med meningsfulla etiketter, att alla interaktiva kontroller (knappar, länkar, CAPTCHA-utmaningar) är nåbara och hanterbara, och att eventuella felmeddelanden är programmatiskt kopplade till relevant fält och annonseras omedelbart utan att ytterligare navigering krävs.
6. Testa med VoiceOver + Safari (macOS/iOS): Upprepa hela autentiseringsflödet. På iOS, verifiera också att biometrisk autentisering (Face ID / Touch ID) erbjuds som ett alternativ där inbyggd autentisering används, och att det webbaserade flödet är fullt hanterbart med Switch Control om biometrin inte är tillgänglig.
7. Testa med JAWS + Chrome: Upprepa flödet och var särskilt uppmärksam på hur tredjepartswidgets (OAuth social inloggning, CAPTCHA-iframes) annonseras. JAWS hanterar vissa ARIA-mönster annorlunda än NVDA; båda måste testas.
8. Utvärdera alternativa vägar för verklig likvärdighet: Om en alternativ autentiseringsmetod finns (t.ex. "Logga in med en magisk länk"), genomför hela flödet med enbart det alternativet. Bekräfta att det leder till samma autentiserade tillstånd utan att kräva något kognitivt test. Om den alternativa vägen i sig innehåller en CAPTCHA eller ett minnestest är den inte ett giltigt alternativ enligt 3.3.9.
9. Dokumentera fynd med bevis: För varje fel, fånga en skärminspelning eller en kommenterad skärmbild som visar exakt vilket steg som fallerar och varför. Denna dokumentation är avgörande för att kunna lämna över åtgärder till utvecklingsteam och för revisionsspår.

Hur man åtgärdar

CAPTCHA utan alternativ — Felaktigt

<!-- Fails 3.3.9: The only authentication path requires solving a visual CAPTCHA.
     No alternative is provided, and there is no object-recognition option. -->
<form method='post' action='/login'>
  <label for='username'>Username</label>
  <input type='text' id='username' name='username' autocomplete='username'>

  <label for='password'>Password</label>
  <input type='password' id='password' name='password' autocomplete='off'>

  <!-- Third-party CAPTCHA widget with no accessible alternative path -->
  <div class='g-recaptcha' data-sitekey='YOUR_SITE_KEY'></div>

  <button type='submit'>Log In</button>
</form>

CAPTCHA ersatt med passkey och magisk länk — Korrekt

<!-- Passes 3.3.9: CAPTCHA removed entirely. Primary path uses a passkey
     (WebAuthn — no cognitive test). A magic link fallback is offered
     for devices without passkey support. Password entry allows paste
     and browser autofill. -->
<form method='post' action='/login'>
  <label for='email'>Email address</label>
  <input type='email' id='email' name='email' autocomplete='email'>

  <!-- Passkey login: no password to remember, no CAPTCHA -->
  <button type='button' id='passkey-btn'>Sign in with Passkey</button>

  <!-- Password fallback: paste and autofill explicitly enabled -->
  <label for='password'>Password (optional)</label>
  <input type='password' id='password' name='password'
         autocomplete='current-password'>
  <!-- NOTE: Do NOT add autocomplete='off' or paste-blocking JS here -->

  <button type='submit'>Log In</button>
</form>

<!-- Non-cognitive alternative: magic link -->
<p><a href='/send-magic-link'>Send me a sign-in link instead</a></p>

<script>
  // WebAuthn passkey authentication — no cognitive function test
  document.getElementById('passkey-btn').addEventListener('click', async () => {
    const credential = await navigator.credentials.get({ publicKey: publicKeyOptions });
    // submit credential to server
  });
</script>

Urklistring blockeras i OTP-fält — Felaktigt

<!-- Fails 3.3.9: The one-time code field blocks paste via JavaScript,
     forcing users to manually transcribe a time-limited code.
     This is a transcription cognitive function test with no bypass. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='off'>

<script>
  document.getElementById('otp').addEventListener('paste', function(e) {
    e.preventDefault(); // Blocks paste — FAILS 3.3.9
  });
</script>

OTP-fält med tillåten urklistring och autocomplete-hint — Korrekt

<!-- Passes 3.3.9: Paste is allowed. The autocomplete='one-time-code' attribute
     enables browsers and password managers to automatically fill the OTP,
     eliminating the transcription requirement entirely. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='one-time-code'>

<!-- No paste-blocking JavaScript. autocomplete='one-time-code' allows
     the OS (iOS, Android, desktop browsers) to suggest the OTP
     automatically from SMS or authenticator apps. -->

Kunskapsbaserade säkerhetsfrågor — Felaktigt

<!-- Fails 3.3.9: Requiring answers to knowledge-based security questions
     is a memory-recall cognitive function test. No alternative is offered. -->
<form method='post' action='/verify-identity'>
  <p>To verify your identity, please answer your security question:</p>
  <label for='sq-answer'>What was the name of your childhood pet?</label>
  <input type='text' id='sq-answer' name='sq-answer' autocomplete='off'>
  <button type='submit'>Verify</button>
</form>

Identitetsverifiering med icke-kognitiva alternativ — Korrekt

<!-- Passes 3.3.9: Security questions replaced with email magic link
     and government ID upload options — neither requires memory recall.
     If security questions are retained for some users, a clearly labeled
     alternative path is provided upfront. -->
<form method='post' action='/verify-identity'>
  <p>We need to verify your identity. Choose one of the following methods:</p>

  <fieldset>
    <legend>Verification method</legend>

    <label>
      <input type='radio' name='verify-method' value='magic-link' checked>
      Send a verification link to my registered email
    </label>

    <label>
      <input type='radio' name='verify-method' value='id-upload'>
      Upload a photo of a government-issued ID
    </label>
  </fieldset>

  <button type='submit'>Continue</button>
</form>

Vanliga misstag

• Att lägga till autocomplete='off' i lösenordsfält för att förhindra webbläsarens autofyll. Detta inaktiverar den primära mekanismen som gör att användare kan slippa memorera lösenord och leder direkt till att 3.3.9 inte uppfylls. Ta bort autocomplete='off' och använd autocomplete='current-password' eller autocomplete='new-password' i stället.
• Att koppla en JavaScript-lyssnare för paste som anropar event.preventDefault() på autentiseringsfält, i tron att detta förbättrar säkerheten. I praktiken blockerar det lösenordshanterare och hjälpmedel och utgör ett transkriptionskrav enligt 3.3.9.
• Att betrakta ljud-CAPTCHA-alternativet som en tillräcklig kringgång för visuella CAPTCHA:er. Ljud-CAPTCHA:er utgör fortfarande ett kognitivt funktionstest (att transkribera förvrängda ljudtecken) och uppfyller inte 3.3.9. En verkligt icke-kognitiv alternativ väg krävs.
• Att erbjuda en passkey- eller social inloggningsmöjlighet men placera den bakom en CAPTCHA-utmaning först. Om användaren måste klara ett kognitivt test för att få tillgång till det tillgängliga alternativet är alternativet inte genuint likvärdigt och flödet uppfyller inte 3.3.9.
• Att använda sex separata enkelteckens-<input>-fält för OTP-inmatning (ett vanligt UI-mönster) utan stöd för att klistra in och fylla i över alla fält. Många implementationer klistrar bara in i det första fältet och kräver manuell tangenttryckning för de återstående fem, vilket är ett transkriptionshinder.
• Att förlita sig på "Kom ihåg mig" eller persistenta sessionscookies som den enda anpassningen för användare som inte kan autentisera sig upprepade gånger. Även om minskad autentiseringsfrekvens hjälper, löser det inte en otillgänglig autentiseringsprocess — användare måste fortfarande klara det kognitiva testet minst en gång, och sessioner löper ut eller rensas.
• Att implementera tidsbegränsade OTP-fält som rensas vid timeout utan varning, vilket tvingar användare att begära en ny kod och försöka transkribera igen. Detta förstärker den kognitiva belastningen för användare med långsam motorisk eller kognitiv bearbetningshastighet.
• Att använda bildbaserade CAPTCHA-utmaningar som kräver igenkänning av icke-objektinnehåll — såsom abstrakta mönster, färger eller sekvenser av personligt valda foton — och tro att detta uppfyller 3.3.9. AAA-kriteriet tillåter endast objektigenkänning (verkliga objekt som bilar, cyklar, trafikljus); igenkänning av icke-objektbilder är inte undantagen på denna nivå.
• Att blockera åtkomst till webbläsarens lösenordshanterare via autocomplete='new-password' på inloggningsfält (i stället för registreringsfält). Värdet new-password signalerar för webbläsare att detta är ett fält för att skapa ett nytt lösenord, vilket förhindrar autofyll av sparade inloggningsuppgifter vid inloggning.
• Att inte testa autentiseringsflöden med faktiska hjälpmedel och i stället enbart förlita sig på resultat från automatiska skanningar. Eftersom 3.3.9 endast kan testas manuellt kommer team som hoppar över manuell testning med skärmläsare och tangentbord systematiskt att missa fel i detta kriterium i varje releasecykel.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular No. 2025/10, publicerad i Official Gazette nr 32933 den 21 juni 2025, fastställer omfattande krav på webb- och mobiltillgänglighet för ett brett spektrum av offentliga och privata aktörer som är verksamma i Turkiet. Cirkuläret föreskriver efterlevnad av WCAG 2.2 och är därmed det första turkiska rättsliga instrumentet som uttryckligen hänvisar till version 2.2 av standarden.

De aktörer som omfattas av cirkuläret inkluderar: offentliga institutioner och myndigheter på alla förvaltningsnivåer; e-handelsplattformar och online-marknadsplatser; banker och finansiella institutioner; sjukhus och vårdgivare; teleoperatörer med 200,000 eller fler abonnenter; resebyråer; privata transportföretag; och privatskolor som auktoriserats av Ministry of National Education (MoNE). För dessa organisationer måste digitala tjänster — inklusive inloggningsportaler, patientportaler, bankgränssnitt, biljettsystem och elevinformationssystem — uppfylla de tillgänglighetskrav som definieras i cirkuläret.

WCAG 3.3.9, som ett AAA-kriterium, är inte en minsta rättslig skyldighet enligt cirkuläret. Den rättsligt föreskrivna basnivån motsvarar WCAG 2.2 nivå A- och AA-efterlevnad. Cirkulärets anda och räckvidd gör dock 3.3.9 mycket relevant i praktiken av flera skäl.

För det första är WCAG 3.3.8 (Accessible Authentication — Minimum) ett AA-krav och är därför rättsligt bindande för alla omfattade aktörer. Organisationer som arbetar för att uppfylla 3.3.8 kommer att upptäcka att vägen till efterlevnad av 3.3.9 ofta är ett litet steg ytterligare — främst att ta bort undantaget för bildigenkänning som 3.3.8 tillåter och säkerställa att alla kognitiva test har icke-kognitiva alternativ, inte bara hjälpande mekanismer.

För det andra, för aktörer som tillhandahåller tjänster till grupper med högre förekomst av kognitiva eller motoriska funktionsnedsättningar — särskilt sjukhus, offentliga vårdportaler och myndighetsportaler — innebär att uppnå AAA-efterlevnad för autentiseringskriterier ett meningsfullt åtagande för lika tillgång som ligger i linje med Turkiets bredare konstitutionella likhetsprinciper och landets åtaganden enligt FN:s konvention om rättigheter för personer med funktionsnedsättning (CRPD), som Turkiet har ratificerat.

För det tredje står turkiska banker och fintech-aktörer under särskild granskning när det gäller autentisering. Banking Regulation and Supervision Agency (BDDK) och Financial Crimes Investigation Board (MASAK) ställer starka krav på identitetsverifiering, och organisationer implementerar ofta komplexa, flerstegade autentiseringsflöden för att uppfylla dessa krav. Att implementera autentisering som uppfyller 3.3.9 — med passkeys, WebAuthn eller flöden med magiska länkar — är både mer tillgängligt och ligger i linje med moderna bästa praxis för säker autentisering som stöds av internationella finansiella tillsynsmyndigheter, vilket gör det till ett designmål som tjänar efterlevnad på flera fronter samtidigt.

Organisationer som vill särskilja sin tillgänglighetsprofil, förbereda sig för potentiell framtida skärpning av regleringen eller betjäna användare på tillgängliga och inkluderande sätt uppmuntras starkt att behandla WCAG 3.3.9 som en designstandard, inte bara en valfri förbättring. Att implementera fullt ut icke-kognitiva autentiseringsvägar är alltmer genomförbart med moderna webbläsar-API:er (WebAuthn/passkeys) och autentiserings-SDK:er, vilket gör kostnaden för efterlevnad lägre än någonsin samtidigt som nyttan — att eliminera ett av de mest betydelsefulla tillgänglighetshindren i en digital produkt — är betydande.