Toolkit · For udviklere

Webtilgængelighed for udviklere — bygget til ingeniører, der hellere vil fikse rodårsagen end sende et overlay

Den ingeniørformede del af sitet. Semantiske HTML-mønstre, ARIA-roller der faktisk virker i produktion, testmiljøer med skærmlæserbevidsthed, CI-integrationsopskrifter og den framework-for-framework tilstand af tastaturhåndtering.

Kureret som udgangspunkt: mønstre, værktøjer, testmiljøer og framework-specifikke guides, som ingeniører faktisk har brug for for at levere tilgængelige funktioner uden overlay-teater. Krydslinket til den gratis WCAG 2.2-scanner til ad hoc-triage og overvågningskøbsguiden til løbende dækning.

De fire ingeniørpraksisser, der rykker nålen

Meningsfulde. Ikke udtømmende. Mønstrene der, når de følges, eliminerer de fleste tilgængelighedsregressioner inden code review.

Semantisk HTML først, ARIA anden

Når native HTML kan gøre jobbet, brug det. <button> har tastaturhåndtering, fokus, rolle og Enter/Space-aktivering indbygget; <label> binder et kontrolelement til dets beskrivelse; <dialog> leveres med fokusfangst- og inert-resten-af-siden-adfærd, som man ellers ville implementere manuelt; <details> er en disclosure-widget uden noget JavaScript overhovedet. ARIA er nødudgangen — nyttig når der ikke er noget native element til jobbet, skadelig når det drysses oven på et, der allerede virker. Reference: WCAG 2.2-succeskriterier og W3C ARIA Authoring Practices Guide.

Tastaturunderstøttelse er ikke et afkrydsningsfelt

Ethvert interaktivt element skal virke med tastaturet alene. Tab og Shift+Tab for at flytte; Enter eller Space for at aktivere; Esc for at lukke en midlertidig overflade (modal, popover, menu). Fokus skal være synligt — aldrig outline: none; uden et alternativ. Fokus skal bevæge sig fornuftigt — når en modal åbner, flyttes fokus ind i den; når modalen lukker, vender fokus tilbage til det element, der åbnede den. Test med tastaturet inden du tester med musen; musen skjuler fejl, som tastaturet afslører med det samme.

Tilgængelige navne + beskrivelser

Ikke aria-label-drys. Det tilgængelige navn kommer fra elementets tekstindhold som standard; aria-labelledby refererer til en anden nodes tekst; aria-label tilsidesætter alt med en hardkodet streng (og bør være din sidste udvej, fordi det omgår oversættelse og har tendens til at afvige fra den synlige etiket). Den tilgængelige beskrivelse er separat — aria-describedby refererer til hjælpetekst- eller fejlmeddelelses-noden. Verificer med DevTools-tilgængelighedstræet, hvad skærmlæseren faktisk modtager — antagelser og virkelighed er ofte uenige.

Test i din rigtige CI, ikke kun lokalt

Et lokalt axe-tjek er en fornuftstest. En grøn CI er en regressions-gate. Kabling eslint-plugin-jsx-a11y til hver PR; tilføj axe-core-påstande til unit- og e2e-tests; kør AT-driver-flows på repræsentative sider, så en rigtig skærmlæser vejer ind. Skærmlæsertestværktøjs-undersøgelsen dækker, hvad der er værd at automatisere, og hvad der stadig er et manuelt gennemløb.

Værktøjskæden — 13 kuraterede værktøjer og biblioteker

Hvert opslag mappes til en livscyklusfase — lint, unit-test, e2e, runtime, overvågning eller manuel gennemgang — så du kan koble det rigtige værktøj til den rigtige gate.

Framework-specifikke guides

Tilgængelighedsfaldgruberne der skifter form mellem økosystemer — og den dybere dækning af hver enkelt.

React

Nøgler på lister (fejlnøglede lister forvirrer skærmlæsere, når elementer omsorteres). Fokushåndtering ved ruteskift (uden det forbliver fokus på det link, der udløste navigationen, og den nye side er usynlig for hjælpeteknologibrugere). Portaler og fokusfangst — en modal renderet ind i document.body skal stadig holde fokus inde i sig selv. Hydreringsmismatch der ændrer DOM-struktur mellem SSR og klient kan stille bryde ARIA-relationer. Vores dybdegående artikel om aria-live-regioner i moderne frameworks dækker annonceringsmønsteret for live-regioner, som Reacts reconciliation har tendens til at bryde.

Vue / Svelte / Solid

Lignende mønstre; reaktive tilstandsændringer der ikke udløser live-regionsopdateringer som standard. Hvert frameworks reaktivitetsmodel har en anden definition af "DOM'en har ændret sig", og skærmlæsere ser den resulterende nodeopdatering — eller gør ikke — på subtilt forskellige måder. Vues v-if versus v-show, Sveltes reaktive erklæringer og Solids finmasket reaktivitet producerer alle forskellige tilgængeligheds-træ-opdateringer for tilsyneladende identisk kode.

Native mobil (iOS + Android)

En fuldstændig anden API-overflade. iOS eksponerer UIAccessibility (og SwiftUIs .accessibilityLabel() / .accessibilityHint()) til VoiceOver; Android eksponerer AccessibilityNodeInfo til TalkBack. Web-stil ARIA oversættes ikke. Artiklen om native mobile tilgængeligheds-API'er kortlægger webkoncepterne til deres native modparter, så web-trænede ingeniører kan stoppe med at gætte.

Komponentbiblioteker

Headless-biblioteker (Radix UI, Headless UI, React Aria) håndterer de svære dele — fokushåndtering, tastaturhåndtering, ARIA-kobling — og overlader det visuelle design helt til dig. Fuldt udstyrede biblioteker (Material UI, Chakra, Ant) leveres med meningsfulde visuals, men varierer bredt i tilgængelighedskvalitet, og "tilgængelig som standard" betyder sjældent "auditeret mod rigtige skærmlæsere". Vores undersøgelse af tilgængelige komponentbiblioteker bedømmer de største muligheder mod faktisk hjælpeteknologitest.

PR-gennemgangs-tjekliste for tilgængelighed

Udskriv, indsæt i din PR-skabelon, eller kobl til en bot. Minimummet enhver reviewer bør kigge på.

  • Interaktive elementer virker med tastatur alene (Tab + Enter + Space + Esc).
  • Fokusindikator synlig på hvert interaktivt element.
  • Formularinput har en tilknyttet <label>.
  • Fejlmeddelelser er knyttet til deres input (aria-describedby eller tilstødende tekst).
  • Dynamiske indholdsændringer annonceres via aria-live når relevant.
  • Modaldialogbokse fanger fokus og genopretter det til åbneren ved lukning.
  • Billeder har meningsfuld alternativ tekst; dekorative billeder bærer alt="".
  • Lister bruger <ul> / <ol> / <dl> — ikke <div>-salat.
  • Overskriftshierarki er fornuftigt (ingen hoppede niveauer).
  • Lint + axe-tests består i CI inden merge.

Almindelige ingeniørantimønstre

Mønstrene der passerer code review og så bryder i produktion. Fang dem tidligere.

  • "Overlay-widget" — tredjeparts-JavaScript der hævder at tilføje tilgængelighed til et eksisterende site. Det gør det ikke, det bryder ofte hjælpeteknologilaget, og det har genereret sin egen bølge af retssager. Baggrund: overlay-leverandører.
  • role="button" på en <div> — tilføjer rolleannonceringen uden tastaturadærden (Enter, Space) eller fokusdeltagelse. Brug <button>.
  • aria-hidden="true" på fokuserbare elementer — skaber en fokusfælde, hvor tastaturbrugere kan tabbe ind på et element, skærmlæseren er instrueret i at ignorere. Enten fjern elementet fra tab-rækkefølgen med tabindex="-1", eller fjern aria-hidden.
  • Brugerdefineret dropdown uden tastaturhåndtering — en <div>-baseret combobox, der åbner ved klik, men ignorerer piletaster, Home/End, type-ahead og Esc. Undersøgelsen af tilgængelige komponentbiblioteker dækker bibliotekerne, der får dette rigtigt ud af boksen.
  • Toast-notifikationer der ikke annoncerer — en midlertidig overflade renderet uden role="status" (polite) eller role="alert" (assertive). Seende brugere ser det; skærmlæserbrugere gør ikke.
  • Genereret DOM der bryder tilgængelighedstræet — tunge wrappers rundt om et input (en brugerdefineret select bygget af tolv indlejrede <div>'er) skjuler ofte det faktiske kontrolelement for hjælpeteknologi. Test, hvad hjælpeteknologien ser, ikke kun hvad brugeren ser.

Toolkit + overvågningspipeline

De fleste teams vil have tre ting i rækkefølge: en ad hoc-triagescanning når noget ser ødelagt ud, en ingeniørreferenceressource, når de vil forstå de underliggende mønstre, og et kontinuerligt overvågningslag, når tilgængelighed lander i produktions-roadmappen. Vores gratis WCAG 2.2-scanner dækker det første — indsæt en offentlig URL, få en axe-drevet rapport i en ny fane. Den ingeniørmæssige dækning på artiklernes redaktion dækker det andet — herunder tilgængeligheds-gæld-som-teknisk-gæld og tilgængeligheds-hændelser-SRE-postmortem-analyser for teams der administrerer tilgængelighed i stor skala.

For det kontinuerlige lag er overvågningskøbsguiden det mest meningsfulde stykke på sitet. Den bedømmer axe Monitor, Siteimprove, Level Access og Qualibooth — sidstnævnte integrerer overvågning med en manuel-audit-overdragelse, det manglende led i de fleste automatiserings-kun-stacks — mod dækningsbredde, falsk-positiv-rater og hvor rent data kobles ind i ingeniørarbejdsgange. Hele pointen med overvågning er at sikre, at de rettelser du leverer i dag, ikke regrederer næste sprint.

Hyppigt stillede ingeniørspørgsmål

Spørgsmålene der dukker op i hvert tilgængeligheds-kickoff. Afspejlet i FAQPage-strukturerede data.

Er aria-label bedre end synlige tekstetiketter?
Nej. Synlig tekst er næsten altid bedre — den gavner seende brugere, seende brugere med kognitive handicap, stemmekontroluserere (der siger, hvad de ser) og oversættelsesværktøj. Brug aria-label kun, når der ikke er synlig tekst at knytte til (ikon-kun-knapper), eller når den synlige tekst ikke er det tilgængelige navn, du ønsker.
Skal jeg bruge ARIA-roller til alt?
Nej. Den første regel om ARIA er "do not use ARIA". Native HTML-elementer leveres med den rigtige rolle, den rigtige tastaturadærd og den rigtige semantik i tilgængelighedstræet. Brug ARIA kun når (og kun når) der ikke er et native element, der passer — for eksempel en fane-liste, et træ eller en brugerdefineret dialog, hvor du ikke kan bruge <dialog>.
Hvordan tester jeg tilgængelighed i CI?
Tre lag, ordnet efter omkostninger. (1) Lint: eslint-plugin-jsx-a11y på hver PR. (2) Unit-tests: @testing-library/jest-dom plus jest-axe (eller @axe-core/react) på hvert komponent. (3) End-to-end: @axe-core/playwright på repræsentative brugerrejser. Tilføj en Pa11y- eller Lighthouse CI-gate på staging for at fange den drift, de lavere lag overser.
Er axe-core og Lighthouse det samme?
Lighthouse bruger axe-core under motorhjelmen til sin tilgængelighedsaudit, men kører et kureret undersæt af reglerne og præsenterer dem inden i en bredere performance-/SEO-/best-practices-rapport. axe-core er selve motoren — når du vil have hele regelsættet eller vil udvide det, bruger du axe-core direkte. For de fleste teams: brug Lighthouse til trendsporing, axe-core til den egentlige gate.
Hvad er minimumskonfigurationen for tilgængelighedstest i et React-projekt?
Tilføj eslint-plugin-jsx-a11y til den eksisterende ESLint-konfiguration (den følger med create-react-app og Next.js som standard). Tilføj @testing-library/jest-dom og jest-axe til dit unit-test-setup, og kald expect(await axe(container)).toHaveNoViolations() i mindst én test per komponent. Det er gulvet — det fanger ca. 40 % af reelle WCAG-problemer for et par timers opsætning.
Behøver jeg at teste med rigtige skærmlæsere?
Ja, for enhver produktfunktion, som en bruger af hjælpeteknologi faktisk vil bruge. Automatiserede værktøjer fanger de strukturelle fejl (manglende etiketter, kontrast, rollemismatch), men ikke de oplevelsesmæssige (fokus der hopper til sidefoden, live-regioner der ikke annoncerer, en "tilgængelig" modal der fanger fokus i det forkerte undertræ). Planlæg mindst ét manuelt gennemløb per større udgivelse med NVDA på Windows og VoiceOver på macOS / iOS.

Næste skridt

Kør et hurtigt tjek mod den gratis WCAG 2.2-scanner hvis du triagerer en specifik side. Læs undersøgelsen om skærmlæsertestværktøjer inden du kobler AT-driver ind i CI. Og hvis tilgængelighed er ved at gå fra "ad hoc-audit" til "løbende produktionsindsats", er overvågningskøbsguiden det mest konkrete stykke på sitet til at vælge en leverandør.