Standarder · WCAG 2.2
WCAG 2.2-succeskriterier
Alle 86 succeskriterier i WCAG 2.2 — 31 på niveau A, 24 på AA, 31 på AAA. 9 kom til i 2.2; 17 i 2.1; 60 føres videre fra 2.0. Hver post har et resumé i klart sprog, råd til at opfylde kriteriet og de fejl, vi oftest ser i gennemgange i produktion.
1. Opfattelig
Information og brugergrænsefladekomponenter skal præsenteres for brugerne på måder, de kan opfatte.
- 1.1.1 A
Ikke-tekstindhold
Alle billeder, ikoner, diagrammer, lydfiler og andre ikke-tekstkomponenter skal have et tekstalternativ, der tjener samme formål — så brugere af skærmlæser, punktskrift og kontakter får den samme information som seende brugere.
- 1.2.1 A
Kun lyd og kun video (forudindspillet)
Forudindspillet lyd skal have et teksttransskript. Forudindspillet lydløs video skal have enten en tekstbeskrivelse eller et lydspor, der formidler den samme information — så brugere, der ikke kan høre eller se, stadig får indholdet.
- 1.2.2 A
Undertekster (forudindspillet)
Alle forudindspillede videoer med lyd skal have synkroniserede undertekster, der dækker dialog, taler-identifikation og meningsbærende ikke-sproglige lyde — så døve og hørehæmmede brugere får den samme information fra lydsporet som alle andre.
- 1.2.3 A
Synstolkning eller mediealternativ (forudindspillet)
Forudindspillet video skal have enten et synstolkningsspor eller et fuldt tekstalternativ for visuel information, der ikke formidles af lydsporet — så blinde brugere får det samme indhold som seende.
- 1.2.4 AA
Undertekster (direkte)
Direkte lyd i synkroniserede medier — webinarer, livestreams, virtuelle arrangementer — skal have realtidsundertekster. Auto-undertekster kan kvalificere sig, hvis nøjagtigheden er høj nok, men professionel CART-undertekstning er den sikre løsning.
- 1.2.5 AA
Synstolkning (forudindspillet)
Forudindspillet video skal have et synstolkningsspor, der fortæller om vigtig visuel information i naturlige pauser i dialogen. På AA er et teksttransskript alene ikke længere tilstrækkeligt — beskrivelsen skal være i lydform.
- 1.2.6 AAA
Tegnsprog (forudindspillet)
Forudindspillet lyd i synkroniserede medier ledsages af en tegnsprogstolkning. Undertekster er ikke et substitut — mange døve brugere har tegnsprog som førstesprog og skriftsprog som andetsprog.
- 1.2.7 AAA
Udvidet synstolkning (forudindspillet)
Når pauser i dialogen ikke er lange nok til en standard synstolkning, skal videoen sættes på pause, så den udvidede beskrivelse kan afspilles — så blinde brugere får den fulde visuelle kontekst selv i tæt, hurtigtklippet indhold.
- 1.2.8 AAA
Mediealternativ (forudindspillet)
Forudindspillet synkroniseret medie — og forudindspillet video-only — skal have et komplet tekstalternativ, der formidler al samme information. Det går videre end undertekster og synstolkning: et fuldt selvstændigt dokument.
- 1.2.9 AAA
Kun lyd (direkte)
Direkte indhold med kun lyd — radiostreams, lydkonferencer, live-podcasts — skal have et realtidstekstalternativ som direkte undertekster, så døve og hørehæmmede brugere får indholdet i samme øjeblik det sker.
- 1.3.1 A
Information og relationer
Information og relationer, der formidles visuelt — overskrifter, lister, tabeller, formularetiketter, grupperinger — skal også udtrykkes i koden, så hjælpeteknologi kan gengive dem. Visuel formatering alene er ikke tilstrækkeligt.
- 1.3.2 A
Meningsfuld rækkefølge
Når læserækkefølgen af indhold er afgørende for forståelsen, skal DOM-rækkefølgen matche den visuelle rækkefølge. CSS-positionering og float, der forstyrrer sekvensen, ødelægger skærmlæsere og tastaturnavigation.
- 1.3.3 A
Sansemæssige egenskaber
Instrukser må ikke udelukkende basere sig på form, størrelse, placering, orientering, lyd eller farve. "Klik på den grønne knap til højre" udelukker brugere, der ikke kan se layoutet eller skelne farver.
- 1.3.4 AA
Orientering
Indhold må ikke låses til én enkelt orientering — stående eller liggende — medmindre den orientering er afgørende. Brugere, der sidder i kørestol eller holder telefonen i et fast greb, kan ikke rotere enheden.
- 1.3.5 AA
Identificer formålet med input
Formularfelter, der indsamler almindelige personoplysninger — navn, e-mail, telefon, adresse, kreditkort — skal programmatisk deklarere deres formål via HTML-attributten autocomplete. Dette giver browsere mulighed for autoudfyldning og hjælpeteknologi mulighed for at tilpasse brugergrænsefladen.
- 1.3.6 AAA
Identificer formål
Ud over formularfelter skal formålet med UI-komponenter, ikoner og regioner kunne identificeres programmatisk — så adaptive teknologier kan indsætte symboler, forenkle siden eller skjule ikke-essentielle dele.
- 1.4.1 A
Brug af farve
Farve må ikke være den eneste måde, information formidles på. Obligatoriske felter, fejltilstande, linkmarkeringer og diagramserier kræver alle et sekundært signal — tekst, ikon, understregning eller mønster — så farveblinde brugere får samme information.
- 1.4.2 A
Lydkontrol
Lyd, der afspilles automatisk i mere end tre sekunder, skal have en pause-, stop- eller lydstyrkeregulering uafhængig af systemlydstyrken — så den ikke overdøver skærmlæserens tale.
- 1.4.3 AA
Kontrast (minimum)
Brødtekst skal have et kontrastforhold på mindst 4,5:1 mod baggrunden. Stor tekst (18pt eller derover, eller 14pt fed) kræver 3:1. Logoer og dekorativ tekst er undtaget.
- 1.4.4 AA
Tilpasning af tekststørrelse
Tekst skal forblive læsbar og brugbar ved zoom op til 200% uden tab af indhold eller funktionalitet. Undertekster og tekstbilleder er undtaget.
- 1.4.5 AA
Tekst som billeder
Tekst bør implementeres som reel tekst og ikke som et rasterbillede — medmindre billedet er uundværligt (et logo, et skærmbillede af en brugergrænseflade der omtales) eller fuldt ud brugerdefinerbart.
- 1.4.6 AAA
Kontrast (forbedret)
AAA-niveau kontrast: 7:1 for brødtekst, 4,5:1 for stor tekst. Strengere end 1.4.3 og beregnet til brugere med betydelig synsnedsættelse, der har brug for højere kontrast for at læse komfortabelt.
- 1.4.7 AAA
Lav eller ingen baggrundsaudio
For forudindspillet lyd med tale som primært indhold skal baggrundslyde være mindst 20 dB lavere end forgrundstalens niveau — eller fraværende eller mulige at slå fra — så brugere med høretab kan følge dialogen.
- 1.4.8 AAA
Visuel præsentation
For blokke af tekst skal brugere kunne styre forgrunds-/baggrundsfarve, linjebredde (maks. 80 tegn), justering (ingen fuldlinjejustering), linjeafstand (1,5x) og afsnitsstørrelse (1,5x linjeafstand) — uden vandret rulning ved 200 % zoom.
- 1.4.9 AAA
Tekst som billeder (ingen undtagelse)
AAA-niveau: tekst som billeder er slet ikke tilladt undtagen logoer og uundværlige tilfælde (et skærmbillede der demonstrerer typografi). Undtagelsen for "brugerdefinerbar" tekst fra 1.4.5 er fjernet.
- 1.4.10 AA
Reflow
Indhold skal ombryde til en enkelt kolonne ved 320 CSS-pixel bredde (lodret scrollende indhold) eller 256 pixel højde (vandret scrollende indhold) uden tab af information eller funktionalitet. Ingen tovejsscrolling.
- 1.4.11 AA
Ikke-tekstlig kontrast
UI-komponenter (knapkanter, formularfeltomrids, fokusindikatorer, ikon-only-kontroller) og meningsfulde grafiske elementer (diagramserier, statusikonografier) skal have mindst 3:1 kontrast mod tilstødende farver.
- 1.4.12 AA
Tekstafstand
Når brugere tilsidesætter tekstafstand — linjehøjde 1,5x, afsnitafstand 2x skriftstørrelse, bogstavafstand 0,12 em, ordafstand 0,16 em — må siden ikke miste indhold eller funktionalitet.
- 1.4.13 AA
Indhold ved hover eller fokus
Tooltips, popovers og andet indhold, der vises ved hover eller fokus, skal kunne lukkes, være tilgængeligt med markøren (så brugere kan flytte markøren ind i det) og vedvarende — det forsvinder ikke, før brugeren lukker det, eller udløseren mister fokus.
2. Anvendelig
Brugergrænsefladekomponenter og navigation skal kunne betjenes af alle.
- 2.1.1 A
Tastatur
Alle funktioner på siden skal kunne betjenes fra et tastatur alene — ingen obligatoriske musebevægelser, træk-og-slip eller specifikke timinger. Skærmlæser-, switch- og stemmestyringbrugere er alle afhængige af dette grundlag.
- 2.1.2 A
Ingen tastaturblokering
Hvis tastaturfokus kan flyttes til en komponent, skal fokus også kunne flyttes væk fra den udelukkende med tastatur. Modalvinduer, indlejret indhold og brugerdefinerede widgets er de sædvanlige syndere.
- 2.1.3 AAA
Tastatur (ingen undtagelse)
Som 2.1.1 Tastatur, men uden undtagelsen for stiafhængigt input. Alle funktioner — herunder frihandstegning og underskriftsregistrering — skal have et tastaturbetjeneligt alternativ.
- 2.1.4 A
Tegntastatur-genveje
Enkeltkarakter-tastaturgenveje (et enkelt bogstav, tal eller symbol) skal kunne slås fra, tildeles en ny tast, eller kun være aktive, når den relevante komponent er i fokus. Beskytter brugere af stemmestyring og diktering mod utilsigtede aktiveringstastetryk.
- 2.2.1 A
Justerbar timing
Enhver tidsbegrænsning indholdet pålægger brugeren skal kunne slås fra, justeres til mindst ti gange standardværdien, eller forlænges med mindst 20 sekunders advarsel. Sessionstimeouts og quiztimere er de primære mål.
- 2.2.2 A
Pause, stop, skjul
Bevægende, blinkende, scrollende eller automatisk opdaterende indhold, der varer mere end fem sekunder, skal kunne sættes på pause, stoppes eller skjules af brugeren. Dækker karruseller, nyheds-tickers, animerede annoncer og automatisk opdaterende feeds.
- 2.2.3 AAA
Ingen timing
Tidsbegrænsninger indgår slet ikke i indholdet, undtagen ved ikke-interaktive realtidshændelser. Strengere end 2.2.1 — der er ingen fallback med advarsel og forlængelse.
- 2.2.4 AAA
Afbrydelser
Afbrydelser — pop-ups, notifikationer, advarsler, automatiske opdateringer — skal kunne udskydes eller undertrykkes af brugeren, undtagen dem der vedrører nødsituationer.
- 2.2.5 AAA
Genautentificering
Når en autentificeret session udløber, skal brugeren kunne fortsætte uden at miste data, vedkommende allerede har indtastet. Sessionen slutter, men arbejdet i gang gør ikke.
- 2.2.6 AAA
Timeouts
Brugere skal advares om enhver inaktivitetstimeout, der kan medføre datatab, medmindre data bevares i mere end 20 timers inaktivitet.
- 2.3.1 A
Tre blink eller under tærskelværdi
Intet på siden må blinke mere end tre gange per sekund, medmindre blinket er under definerede størrelses- og kontrasttærskelværdier. Designet til at forebygge lysfølsomme anfald.
- 2.3.2 AAA
Tre blink
Intet indhold på siden må blinke mere end tre gange i sekundet — uden undtagelse. Fjerner de størrelses- og tærskelundtagelser, som 2.3.1 tillader.
- 2.3.3 AAA
Animation fra interaktioner
Bevægelsesanimationer udløst af interaktion kan deaktiveres af brugeren, medmindre animationen er uundværlig. Respekter `prefers-reduced-motion`-medieforespørgslen.
- 2.4.1 A
Omgå blokke
Giv tastatur- og skærmlæserbrugere en måde at springe gentaget indhold over — typisk header, primær navigation og hjælpelinks — så de kan nå hovedindholdet uden at tabbe igennem snesevis af links.
- 2.4.2 A
Side med titel
Enhver side skal have en `<title>`, der beskriver dens emne eller formål. Titlen er det, skærmlæsere annoncerer ved sideindlæsning, og det brugere ser i faner, bogmærker, historik og søgeresultater.
- 2.4.3 A
Fokusrækkefølge
Når brugere trykker Tab igennem en side, skal fokusrækkefølgen bevare mening og operabilitet — typisk den visuelle læseorden. En rodet tabulatorrækkefølge er funktionelt ødelagt, selvom hvert enkelt element virker.
- 2.4.4 A
Linkets formål (i kontekst)
Formålet med hvert link skal fremgå af linkteksten eller af linkteksten kombineret med den omgivende kontekst — sætningen, listeelementet, tabelcellen eller afsnittet. Skærmlæserbrugere hører ofte links uden kontekst, fra en linkliste.
- 2.4.5 AA
Flere måder
Brugere skal have mere end én måde at finde en side inden for et sæt — typisk en kombination af navigationsmenu, søgning, sitemap, indholdsfortegnelse eller relaterede sider. Undtagelse er sider, der er trin i en proces (checkout, flertrinsformularer).
- 2.4.6 AA
Overskrifter og etiketter
Overskrifter og formularetiketter skal beskrive emnet eller formålet med det indhold, de introducerer. De behøver ikke være unikke, men de skal være informative — en overskrift der lyder 'Information' eller en etiket der lyder 'Felt' er ikke tilstrækkelig.
- 2.4.7 AA
Fokus synligt
Ethvert tastaturoperabelt interface skal have en synlig fokusindikator på det aktuelt fokuserede element. Kan en bruger ikke se, hvor tastaturets fokus er, kan de ikke bruge webstedet med tastatur. Et af de hyppigst citerede succeskriterier i audits.
- 2.4.8 AAA
Placering
Brugere skal kunne se, hvor de befinder sig inden for et sæt sider — typisk via brødkrummer, en aktuelt-side-indikator i navigationen eller et sitemap, der fremhæver den aktive sektion.
- 2.4.9 AAA
Linkets formål (kun link)
Den strengere AAA-version af 2.4.4: linkteksten alene — uden omgivende kontekst — skal identificere destinationen. 'Læs mere' fejler, selv hvis sætningen ovenfor forklarer det. Designet til skærmlæserbrugere, der navigerer via linklisten.
- 2.4.10 AAA
Sektionsoverskrifter
Brug overskrifter til at organisere indhold. Hvor en side har tydelige sektioner, skal hver sektion have et rigtigt overskriftselement (`<h1>`–`<h6>`) — ikke stylede afsnit, der blot ligner overskrifter.
- 2.4.11 AA Nyt 2.2
Fokus ikke skjult (minimum)
Når et element modtager tastaturfokus, må det ikke være fuldstændigt skjult bag andet UI-indhold — sticky headers, cookie-bannere, chatwidgets, sticky footers. Ny i WCAG 2.2 og ændrer, hvordan teams bygger sticky chrome.
- 2.4.12 AAA Nyt 2.2
Fokus ikke skjult (forbedret)
Strengere AAA-version af 2.4.11: når et element modtager fokus, må ingen del af det være skjult af andet indhold. Ny i WCAG 2.2.
- 2.4.13 AAA Nyt 2.2
Fokusudseende
Tastaturfokusindikatoren skal opfylde en målbar visuel standard: mindst 2 CSS-pixel tyk langs omkredsen, mindst 3:1 kontrast mod dens tidligere ikke-fokuserede tilstand og ikke skjult. Ny i WCAG 2.2; den mest konkrete fokusstylings-regel specifikationen nogensinde har udgivet.
- 2.5.1 A
Pegegester
Enhver funktion, der bruger en flerpunkts- eller stibaseret gestus — knib-zoom, to-fingers-rotation, stryg for at slette — skal også kunne betjenes med en enkeltpunktsaktivering, der ikke kræver en sti.
- 2.5.2 A
Annullering med pegeredskab
Funktioner udløst af et enkelt pegeredskab skal aktiveres ved op-hændelsen, ikke ned-hændelsen — så brugere kan trække fingeren væk for at afbryde. Afbryd, fortryd eller forudgående annullering skal være tilgængelig, medmindre øjeblikkelig aktivering er essentiel.
- 2.5.3 A
Etiket i navn
Når et element har synlig tekst, skal den præcise tekst optræde i starten af dets tilgængelige navn. Ellers kan stemmestyringsbrugere, der siger, hvad de ser, ikke aktivere elementet.
- 2.5.4 A
Bevægelsesaktivering
Funktioner udløst af enheds- eller kropsbevægelse — rystning, vipning, gestus foran kameraet — skal også kunne betjenes via normale UI-elementer, og det skal være muligt at deaktivere bevægelsestriggeren.
- 2.5.5 AAA
Målstørrelse (udvidet)
Interaktive mål bør være mindst 44×44 CSS-pixels. Dette er AAA-niveauets udvidede målstørrelseskrav; AA-niveauets 2.5.8 fastsætter et minimum på 24×24.
- 2.5.6 AAA
Samtidige inputmekanismer
Webindhold må ikke begrænse brugen af inputmodaliteter, der er tilgængelige på platformen — medmindre begrænsningen er essentiel, påkrævet for at sikre indhold eller nødvendig for at respektere brugerindstillinger.
- 2.5.7 AA Nyt 2.2
Trækbevægelser
Enhver funktion, der bruger en trækbevægelse, skal også kunne betjenes med en enkelt-pegeredskabshandling uden træk — normalt et tryk eller klik. Ny i WCAG 2.2.
- 2.5.8 AA Nyt 2.2
Målstørrelse (minimum)
Interaktive mål — knapper, links, formularfelter — skal være mindst 24×24 CSS-pixels, medmindre et tilsvarende mål på samme side er stort nok, eller målet er en del af en sætning. Ny i WCAG 2.2.
3. Forståelig
Information og betjeningen af brugergrænsefladen skal være forståelig.
- 3.1.1 A
Sidens sprog
Angiv standardsproget for hver side programmatisk — normalt med lang-attributten på html-elementet. Skærmlæsere, punktdisplays og oversættelsesværktøjer bruger dette til at vælge udtaleregeler, stemprofiler og tegntabeller.
- 3.1.2 AA
Sprog for dele
Når et afsnit eller en sætning på siden er på et andet sprog end sidens standard, skal det markeres med et lang-attribut på dets container — så skærmlæsere skifter stemme og udtale for det pågældende fragment.
- 3.1.3 AAA
Usædvanlige ord
Tilbyd en mekanisme til at identificere definitioner af ord, der bruges på en usædvanlig eller afgrænset måde — fagtermer, idiomer, tekniske begreber. En ordliste, inline-definitioner eller linkede definitioner opfylder alle dette AAA-kriterium.
- 3.1.4 AAA
Forkortelser
Tilbyd en mekanisme til at identificere den udvidede form eller betydning af forkortelser. Udskrivning ved første brug, et abbr-element med title eller en linket ordliste opfylder alle dette AAA-kriterium.
- 3.1.5 AAA
Læseniveau
Når indhold kræver læseevne ud over folkeskolens afgangsklasse, skal der tilbydes et enklere alternativ — en klartekstversion, et resumé eller supplerende materialer som illustrationer eller lyd.
- 3.1.6 AAA
Udtale
Når et ords betydning afhænger af dets udtale, og den korrekte udtale ikke er indlysende ud fra sammenhængen, skal der tilbydes en mekanisme, der afsløre udtalen — fonetisk stavning, lyd eller en linket guide.
- 3.2.1 A
Ved fokus
Når en brugergrænsefladkomponent modtager fokus, må det ikke udløse en kontekstændring — ingen automatisk sidenavigation, intet nyt vindue, ingen større indholdsomlægning. Fokus er til orientering, ikke til handling.
- 3.2.2 A
Ved input
Ændring af indstillingen på en brugergrænsefladkomponent må ikke automatisk forårsage en kontekstændring, medmindre brugeren er blevet advaret på forhånd. Valg af en værdi bør ikke stiltiende navigere, indsende eller omstrukturere siden.
- 3.2.3 AA
Konsistent navigation
Navigationsmekanismer, der gentages på tværs af sider — primær navigation, sidefod, brødkrummer, søgning — skal fremgå i samme relative rækkefølge på hver side, de optræder på. Brugere, der er afhængige af muskelhukommelse, bør ikke skulle genlære layoutet ved hvert besøg.
- 3.2.4 AA
Konsekvent identifikation
Komponenter med samme funktion på tværs af et website skal identificeres konsekvent — samme label, samme ikon, samme tilgængeligt navn. To knapper med samme funktion bør ikke hedde Søg på én side og Find på en anden.
- 3.2.5 AAA
Ændring efter anmodning
Kontekstændringer sker kun, når brugeren anmoder om det, eller brugeren kan slå den automatiske ændring fra. Ingen automatisk omdirigering, ingen uventet genindlæsning, ingen karrusel der skifter indhold under markøren.
- 3.2.6 A Nyt 2.2
Konsekvent hjælp
Hvis en side tilbyder hjælpemekanismer — kontaktoplysninger, et hjælpelink, en chatbot, en selvbetjeningsformular — skal de optræde i den samme relative rækkefølge på alle sider, hvor de er til stede. Ny i WCAG 2.2.
- 3.3.1 A
Fejlidentifikation
Når brugeren laver en formularfejl, der automatisk registreres, skal fejlen identificeres og beskrives for brugeren i tekst — ikke udelukkende ved farve, ikke udelukkende ved et ikon, ikke ved stilhed.
- 3.3.2 A
Labels eller instruktioner
Alle formularfelter, der kræver brugerinput, skal have et label eller en instruktion, der fortæller brugeren, hvad der skal indtastes. Felter med kun placeholder, ikon-only-input og tomme bokse er ikke tilstrækkeligt.
- 3.3.3 AA
Fejlforslag
Når en inputfejl registreres og en rettelse er kendt af systemet, skal systemet tilbyde brugeren et forslag — medmindre det ville kompromittere sikkerheden eller ugyldiggøre formålet med inputtet.
- 3.3.4 AA
Fejlforebyggelse (juridisk, finansielt, data)
Ved indsendelser med juridiske forpligtelser, finansielle transaktioner eller væsentlige ændringer af brugerdata skal brugeren enten kunne fortryde indsendelsen, få den kontrolleret for fejl med mulighed for korrektion, eller bekræfte den eksplicit inden den træder i kraft.
- 3.3.5 AAA
Hjælp
Kontekstfølsom hjælp er tilgængelig for formularer og brugerinput, der kræver det. Hjælp kan inkludere formateksempler, hints på siden, linked vejledning eller en kontaktmekanisme.
- 3.3.6 AAA
Fejlforebyggelse (alle)
Ved enhver brugerindsendelse — ikke kun juridiske, finansielle eller dataaendrende — skal brugeren kunne fortryde, kontrollere eller bekræfte, inden indsendelsen træder i kraft. AAA-generaliseringen af 3.3.4.
- 3.3.7 A Nyt 2.2
Redundant indtastning
Oplysninger, brugeren allerede har angivet i samme session, må ikke kræves igen — de skal auto-udfyldes eller vælges fra en liste, medmindre genindtastning er nødvendig (f.eks. bekræftelse af adgangskode). Ny i WCAG 2.2.
- 3.3.8 AA Nyt 2.2
Tilgængelig godkendelse (minimum)
Godkendelse må ikke kræve en kognitiv funktionstest — huske, transskribere, identificere objekter — medmindre et alternativ eller en hjælpemekanisme er tilgængelig. Adgangskoder, billed-CAPTCHA og kode-fra-e-mail-forløb er de hyppige fejl. Ny i WCAG 2.2.
- 3.3.9 AAA Nyt 2.2
Tilgængelig godkendelse (udvidet)
Godkendelse må ikke kræve nogen kognitiv funktionstest — heller ikke objektgenkendelse eller identifikation af personligt indhold. AAA-opgraderingen af 3.3.8 — passkeys, biometri og enhedsbundne legitimationer bliver de praktiske veje. Ny i WCAG 2.2.
4. Robust
Indholdet skal være robust nok til at kunne fortolkes pålideligt af en bred vifte af brugeragenter, herunder hjælpeteknologi.
- 4.1.2 A
Navn, rolle, værdi
Enhver UI-komponent skal programmatisk eksponere et navn, en rolle og — hvor relevant — en værdi og tilstand. Uden dette kan skærmlæsere, stemmestyring og kontaktkontrolenheder ikke identificere eller betjene kontrolelementet.
- 4.1.3 AA
Statusbeskeder
Statusbeskeder — bekræftelser, fejl, statusopdateringer, antal søgeresultater — skal annonceres til hjælpeteknologi uden at flytte fokus. Brug role=status, role=alert eller aria-live på en region, der allerede findes i DOM'en.
Ingen succeskriterier matcher dine filtre.