Tilgjengelig web: karakteristiske clave comparadas

Netttilgjengelighet er definert av fire målbare egenskaper – oppfattelig, betjenbar, forståelig og robust – artikulert i henhold til de 13 nivå A- og AA-kriteriene i WCAG 2.2 som kreves av EN 301 549-standarden i Europa. Disse fire egenskapene fungerer som evalueringskriterier: enhver widget, verktøy eller rammeverk vurderes basert på hvor mange av disse den oppfyller og med hvilken soliditet.

Viktige takeaways

• De fire WCAG-egenskapene (oppfattelig, betjenbar, forståelig, robust) er vurderingsrammeverket, ikke et slagord: hver enkelt grupperer verifiserbare kriterier med dokumenterte teknikker.
• Nivå AA er det praktiske målet for de fleste prosjekter: det dekker kontrast, tastatur, skjemaetiketter, struktur og feilmeldinger, og det er terskelen som refereres til i europeisk lovgivning.
• Ingen automatiske verktøy oppdager mer enn en brøkdel av reelle problemer; manuell testing med tastatur og skjermleser forblir uerstattelig.
• Å velge en “tilgjengelig” widget eller rammeverk krever at man sjekker oppførselen med tastaturet, fokusstyringen og ARIA-semantikken, ikke bare markedsføringen.
• Samsvar (compliance) er en pågående prosess knyttet til produktets livssyklus, ikke en engangsrevisjon som arkiveres.

Hva betyr egentlig “egenskaper for netttilgjengelighet”

Begrepet “egenskaper” brukes på to måter som det er hensiktsmessig å skille mellom. Den første er normativ: WCAG organiserer sine suksesskriterier i fire prinsipper eller egenskaper – oppfattelig, betjenbar, forståelig og robust – kjent som POUR etter sine engelske initialer.

Den andre er praktisk: når en utvikler sier at en komponent “har gode tilgjengelighetsegenskaper”, refereres det vanligvis til et sett med konkrete oppførsler (tastaturnavigasjon, korrekte ARIA-roller, tilstrekkelig kontrast, alternativ tekst). Begge tolkningene er nødvendige: den første gir evalueringsrammeverket, den andre gir de implementerbare detaljene.

WCAG 2.2, publisert av W3C i 2023, opprettholder de fire prinsippene og legger til kriterier som minimumstørrelse på klikkflater (2.5.8) og konsistent hjelp (3.2.6). Nivå A grupperer minimumskriteriene; AA legger til de mest relevante for de fleste nettsteder; AAA er aspirasjonelt og sjelden påkrevd i sin helhet. For et XHTML/CSS-nettsted rettet mot Spania eller Latin-Amerika er det realistiske målet AA, fordi det er nivået som refereres til i den europeiske harmoniserte standarden EN 301 549 og, i forlengelsen, direktiv (EU) 2016/2102 om tilgjengelighet til nettsteder i offentlig sektor.

De fire WCAG-egenskapene, én etter én

Oppfattelig

Egenskapen oppfattelig krever at informasjon presenteres på måter som brukeren kan oppfatte, uavhengig av sansene. I praksis oversettes dette til tekstalternativer for ikke-tekstlig innhold (1.1.1), undertekster og transkripsjoner for multimedia (1.2.x), semantisk struktur som ikke bare avhenger av posisjon eller farge (1.3.1), minimumskontrast på 4,5:1 for normal tekst og 3:1 for stor tekst (1.4.3), og innhold som forblir lesbart ved forstørrelse til 200 % uten horisontal rulling (1.4.10). En vanlig feil på gamle XHTML-sider er bruk av tabeller for layout eller bilder av tekst: begge bryter med oppfatteligheten fordi leserekkefølge og skalerbarhet går tapt.

Betjenbar

Egenskapen betjenbar garanterer at alle komponentene i grensesnittet fungerer med tastatur og med hjelpemidler. Nøkkelkriteriene er full tastaturtilgjengelighet (2.1.1), fravær av fokusfeller (2.1.2), justerbar tid (2.2.1), mekanismer for å pause innhold i bevegelse (2.2.2), navigasjon med hopplenker og beskrivende sidetitler (2.4.1, 2.4.2), logisk fokusrekkefølge (2.4.3) og tilstrekkelig størrelse på klikkflater (2.5.8). Det er her de fleste rullegardinmenyer, modaler og karuseller feiler: de fanger fokuset uten å returnere det, eller de avhenger av musehendelser (onmouseover) uten tastaturekvivalent.

Relatert: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 timer.

Forståelig

Egenskapen forståelig handler om at innholdet og funksjonaliteten i grensesnittet skal være forståelig. Dette inkluderer sidens språk deklarert med lang-attributtet (3.1.1), etiketter og hjelpetekster i skjemaer (3.3.2), identifisering og beskrivelse av feil (3.3.1, 3.3.3), konsistent navigasjon mellom sider (3.2.3) og, i WCAG 2.2, konsistent hjelp (3.2.6). Et skjema som markerer et felt i rødt, men ikke forklarer hva som gikk galt, bryter med denne egenskapen, selv om det er visuelt tydelig for en person uten funksjonsnedsettelse.

Robust

Egenskapen robust krever at innholdet fungerer med et bredt utvalg av brukeragenter, inkludert nåværende og fremtidige. Det sentrale kriteriet er korrekt syntaksanalyse (4.1.1, foreldet i WCAG 2.2, men relevant for XHTML) og navn, rolle og verdi for grensesnittkomponenter (4.1.2). I praksis betyr dette å skrive gyldig HTML, bruke native elementer når de finnes, og kun ty til ARIA når det ikke finnes alternativer, i tråd med den første regelen for ARIA: ikke bruk ARIA hvis et native HTML-element allerede gjør jobben.

Sammenligningstabell: hvordan evaluere verktøy og widgets mot de fire egenskapene

Egenskap	Hva man bør sjekke i et verktøy eller en widget	Varselsignal
Oppfattelig	Genererer tekstalternativer, respekterer kontrast, er ikke avhengig av farge	Validerer kun bilder, ignorerer struktur og kontrast
Betjenbar	Tastaturnavigasjon, fokusstyring, ingen feller	Krever mus eller lukkes ikke med Escape
Forståelig	Etiketter, feilmeldinger, deklarert språk	Marker feil uten forklarende tekst
Robust	Gyldig HTML, korrekte ARIA-roller, fungerer i flere nettlesere	Bruker div med onclick i stedet for button

Denne tabellen fungerer som en sjekkliste for å velge mellom alternativer. Et verktøy som kun dekker kolonnen “oppfattelig” er nyttig som et første filter, men ikke som en sertifisering.

Verdt en titt: UserWay — Tilgjengelighetswidget med gratis plan for empezar Hoy Mismo.

Verktøy og deres forhold til egenskapene

Automatiske evalueringsverktøy – som axe DevTools, WAVE eller Lighthouse – oppdager primært problemer knyttet til egenskapene oppfattelig og robust: manglende alternativ tekst, utilstrekkelig kontrast, feilformede ARIA-attributter, overskriftshierarki. Deres dekning er delvis etter design: de kan ikke vurdere om en alternativ tekst er beskrivende, om fokusrekkefølgen gir mening, eller om en feilmelding er forståelig. Deque-dokumentasjonen om axe og WebAIM-guiden for automatisk evaluering er enige om at ingen verktøy erstatter menneskelig vurdering.

Manuell testing dekker det verktøyene ikke ser. En minimal prosedyre inkluderer: å navigere på hele siden kun med Tab og Shift+Tab, verifisere at fokuset alltid er synlig, teste med en skjermleser (NVDA eller VoiceOver), zoome til 200 % og verifisere at ingenting overlapper, og deaktivere CSS for å bekrefte at rekkefølgen på innholdet gir mening. Dette siste trinnet avslører problemer med den forståelige egenskapen som ingen verktøy påpeker.

Hvordan velge basert på prosjekttype

Et institusjonelt nettsted eller et nettsted for offentlig sektor i Spania bør sikte mot AA og dokumentere samsvar, fordi regelverket krever det. En personlig blogg kan prioritere oppfattelig og betjenbar, som løser de fleste reelle barrierer.

En kompleks webapplikasjon med interaktive komponenter må investere i robust og betjenbar, fordi tilpassede widgets er den primære kilden til feil. Beslutningen er ikke “hvor mange egenskaper oppfyller jeg”, men “hvilke egenskaper er kritiske for mine brukere og min juridiske forpliktelse”.

For rammeverk og komponentbiblioteker innebærer praktisk evaluering å teste komponenten med tastatur før den tas i bruk. En tilpasset “select” som ikke reagerer på piltaster, en modal som ikke fanger fokus korrekt, eller et verktøytips (tooltip) som kun vises ved hover, er signaler om at biblioteket prioriterer utseende over betjenbarhet. W3C ARIA Authoring Practices Guide-dokumentasjonen beskriver de forventede mønstrene for hver widget og gir grunnlaget for sammenligning.

Vanlige feil ved tolkning av egenskapene

Den første feilen er å behandle de fire egenskapene som en binær sjekkliste. Samsvar er kumulativt og kontekstuelt: et nettsted kan oppfylle 40 kriterier, men feile på ett som blokkerer en bruker fullstendig.

Relatert: IAAP CPACC / WAS Certification — Den profesjonelle sertifiseringen er godkjenning for å oppleve og få tilgang.

Den andre feilen er å stole på en “overlay” eller tilgjengelighets-widget som lover å fikse nettstedet med et skript; disse produktene korrigerer ikke den underliggende HTML-koden og har blitt kritisert av fagmiljøet og av rapporter fra organisasjoner for funksjonshemmede. Den tredje feilen er å revidere kun én gang: innholdet endres, komponentene oppdateres og samsvaret forringes. Tilgjengelighet er en prosess integrert i utviklingssyklusen, med tester ved hver leveranse.

Ofte stilte spørsmål

Hva er de fire egenskapene for netttilgjengelighet i henhold til WCAG?

WCAG organiserer sine kriterier i fire prinsipper: oppfattelig, betjenbar, forståelig og robust, kjent som POUR. Hvert prinsipp grupperer verifiserbare suksesskriterier med nivåene A, AA og AAA. Denne strukturen opprettholdes i WCAG 2.2 og er grunnlaget for evaluering av ethvert nettsted eller komponent.

Hvilket nivå av WCAG-samsvar bør mitt nettsted oppfylle?

For de fleste nettsteder er nivå AA det praktiske målet og det som refereres til i europeisk lovgivning gjennom standarden EN 301 549. Nivå A dekker det minimale, og AAA er vanskelig å oppnå i sin helhet. Hvis nettstedet ditt tilhører offentlig sektor i EU, er AA påkrevd.

Verdt en titt: AudioEye — Tilgjengelighet: automatisert kombinasjon med menneskelig revisjon.

Er automatiske verktøy tilstrekkelige for å oppfylle egenskapene for tilgjengelighet?

Nei. Automatiske verktøy oppdager en del av problemene, særlig knyttet til kontrast, alternativ tekst og feilformet ARIA, men de kan ikke vurdere om en alternativ tekst er hensiktsmessig eller om fokusrekkefølgen gir mening. Manuell gjennomgang med tastatur og skjermleser er uunnværlig for reelt samsvar.

Hva er forskjellen mellom tilgjengelighet og brukervennlighet?

Tilgjengelighet sikrer at personer med funksjonsnedsettelser kan oppfatte, betjene, forstå og bruke innhold; brukervennlighet søker å sikre at opplevelsen er effektiv og tilfredsstillende for enhver bruker. De overlapper: et tilgjengelig nettsted er vanligvis mer brukervennlig, men et brukervennlig nettsted er ikke nødvendigvis tilgjengelig.

Fikser tilgjengelighets-widgets eller overlays nettstedet mitt automatisk?

De korrigerer ikke den underliggende HTML-koden eller problemer med struktur, fokus eller semantikk. Tilgjengelighetsmiljøet og ulike rapporter har stilt spørsmål ved disse fordi de kan gi en falsk følelse av samsvar. Løsningen ligger i å korrigere koden og komponentene, ikke i å legge på et skript.

Hvordan begynner jeg å forbedre tilgjengeligheten på et eksisterende XHTML/CSS-nettsted?

Start med det som har størst innvirkning: gyldig og semantisk HTML, alternativ tekst på bilder, tilstrekkelig kontrast, full tastaturnavigasjon og etiketter i skjemaer. Gjennomfør deretter en revisjon med et automatisk verktøy og suppler med manuelle tester. Dokumenter kriteriene som er dekket, og gjenta prosessen ved hver relevante endring.