Tillgång till webben: egenskaper hos clave comparadas

Webbtillgänglighet definieras av fyra mätbara egenskaper – märkbar, funktionsduglig, begriplig och robust – artikulerade enligt de 13 nivå A- och AA-kriterierna i WCAG 2.2 som krävs av EN 301 549-standarden i Europa. Dessa fyra egenskaper fungerar som utvärderingskriterier: varje widget, verktyg eller ramverk bedöms utifrån hur många av dem det uppfyller och med vilken stabilitet.

Viktiga punkter

• De fyra WCAG-egenskaperna (märkbar, funktionsduglig, begriplig, robust) är bedömningsramen, inte en slogan: var och en grupperar verifierbara kriterier med dokumenterade tekniker.
• Nivå AA är det praktiska målet för de flesta projekt: den täcker kontrast, tangentbord, formuläretiketter, struktur och felmeddelanden, och det är tröskeln som hänvisar till europeisk lagstiftning.
• Inget automatiskt verktyg upptäcker mer än en bråkdel av de verkliga problemen; manuell testning med tangentbord och skärmläsare förblir oersättlig.
• Att välja en “tillgänglig” widget eller ett ramverk kräver att man kontrollerar dess beteende med tangentbordet, dess fokushantering och dess ARIA-semantik, inte bara dess marknadsföring.
• Efterlevnad är en pågående process kopplad till produktens livscykel, inte en engångsrevision som arkiveras.

Vad “egenskaper för webbtillgänglighet” egentligen betyder

Termen “egenskaper” används på två sätt som bör särskiljas. Det första är normativt: WCAG organiserar sina framgångskriterier i fyra principer eller egenskaper – märkbar, funktionsduglig, begriplig och robust – kända som POUR efter sina engelska initialer.

Det andra är praktiskt: när en utvecklare säger att en komponent “har goda tillgänglighetsegenskaper”, syftar hen vanligtvis på en uppsättning konkreta beteenden (tangentbordsnavigering, korrekta ARIA-roller, tillräcklig kontrast, alternativtext). Båda tolkningarna behövs: den första ger utvärderingsramen, den andra ger de implementerbara detaljerna.

WCAG 2.2, publicerade av W3C 2023, behåller de fyra principerna och lägger till kriterier som minsta målstorlek (2.5.8) och konsekvent hjälp (3.2.6). Nivå A grupperar minimikriterierna; AA lägger till de mest relevanta för de flesta webbplatser; AAA är ambitiöst och sällan fullt ut krävbart. För en XHTML/CSS-webbplats riktad mot Spanien eller Latinamerika är det realistiska målet AA, eftersom det är den nivå som refereras i den europeiska harmoniserade standarden EN 301 549 och, i förlängningen, direktiv (EU) 2016/2102 om tillgänglighet till webbplatser inom offentlig sektor.

De fyra WCAG-egenskaperna, en efter en

Märkbar

Egenskapen märkbar kräver att information presenteras på sätt som användaren kan uppfatta, oavsett sina sinnen. I praktiken innebär detta textalternativ för icke-textuellt innehåll (1.1.1), undertexter och transkriptioner för multimedia (1.2.x), semantisk struktur som inte bara beror på position eller färg (1.3.1), minsta kontrast på 4,5:1 för vanlig text och 3:1 för stor text (1.4.3), samt innehåll som förblir läsbart vid förstoring till 200 % utan horisontell scrollning (1.4.10). Ett vanligt fel på gamla XHTML-webbplatser är att använda layouttabeller eller textbilder: båda bryter mot märkbarheten eftersom läsordningen och skalbarheten går förlorad.

Funktionsduglig

Egenskapen funktionsduglig garanterar att alla gränssnittskomponenter fungerar med tangentbord och hjälpmedel. Nyckelkriterier är fullständig tangentbordstillgänglighet (2.1.1), frånvaro av fokusfällor (2.1.2), justerbar tid (2.2.1), mekanismer för att pausa rörligt innehåll (2.2.2), navigering med hopplänkar och beskrivande sidtitlar (2.4.1, 2.4.2), logisk fokusordning (2.4.3) och tillräcklig målstorlek (2.5.8). Det är här de flesta rullgardinsmenyer, modaler och karuseller brister: de fångar fokus och lämnar det inte, eller förlitar sig på mushändelser (onmouseover) utan tangentbordsekvivalent.

Relaterat: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 horas.

Begriplig

Egenskapen begriplig handlar om att innehållet och gränssnittets funktion ska vara förståeliga. Detta inkluderar sidans språk deklarerat med attributet lang (3.1.1), etiketter och hjälptexter vid inmatning i formulär (3.3.2), identifiering och beskrivning av fel (3.3.1, 3.3.3), konsekvent navigering mellan sidor (3.2.3) och, i WCAG 2.2, konsekvent hjälp (3.2.6). Ett formulär som markerar ett fält i rött men inte förklarar vad som blev fel bryter mot denna egenskap, även om det är visuellt tydligt för någon utan funktionsnedsättning.

Robust

Egenskapen robust kräver att innehållet fungerar med ett brett utbud av användaragenter, inklusive nuvarande och framtida. Det centrala kriteriet är korrekt syntaktisk analys (4.1.1, föråldrat i WCAG 2.2 men relevant i XHTML) samt namn, roll och värde för gränssnittskomponenter (4.1.2). I praktiken innebär det att skriva giltig HTML, använda nativa element så ofta som möjligt och ta till ARIA endast när det inte finns något alternativ, i enlighet med ARIA:s första regel: använd inte ARIA om ett nativt HTML-element redan gör jobbet.

Jämförelsetabell: hur man utvärderar verktyg och widgets mot de fyra egenskaperna

Egenskap	Vad man ska kontrollera i ett verktyg eller en widget	Varningssignal
Märkbar	Genererar textalternativ, respekterar kontrast, beror inte på färg	Validerar endast bilder, ignorerar struktur och kontrast
Funktionsduglig	Tangentbordsnavigering, fokushantering, inga fällor	Kräver mus eller stängs inte med Escape
Begriplig	Etiketter, felmeddelanden, deklarerat språk	Markerar fel utan förklarande text
Robust	Giltig HTML, korrekta ARIA-roller, fungerar i flera webbläsare	Använder div med onclick istället för button

Denna tabell fungerar som en lista med kriterier för att välja mellan alternativ. Ett verktyg som bara täcker kolumnen “märkbar” är användbart som ett första filter, men inte som en certifiering.

Värt att titta på: AudioEye — Accesibilidad gestionada: automatización combinada con revisión humana.

Verktyg och deras relation till egenskaperna

Automatiska utvärderingsverktyg — som axe DevTools, WAVE eller Lighthouse — upptäcker främst problem med egenskaperna märkbar och robust: saknad alternativtext, otillräcklig kontrast, felaktigt formaterade ARIA-attribut, rubrikhierarki. Deras täckning är partiell per design: de kan inte bedöma om en alternativtext är beskrivande, om fokusordningen är logisk eller om ett felmeddelande är begripligt. Deques dokumentation om axe och WebAIM:s guide om automatisk utvärdering är överens om att inget verktyg ersätter mänsklig granskning.

Manuell testning täcker det som verktygen inte ser. En minimal procedur inkluderar: att navigera på hela sidan endast med Tab och Shift+Tab, verifiera att fokus alltid är synligt, testa med en skärmläsare (NVDA eller VoiceOver), zooma till 200 % och verifiera att ingenting överlappar, samt inaktivera CSS för att bekräfta att innehållsordningen är logisk. Detta sista steg avslöjar problem med den begripliga egenskapen som inget verktyg påpekar.

Hur man väljer baserat på projekttyp

En institutionell webbplats eller en webbplats för offentlig sektor i Spanien bör sikta på AA och dokumentera efterlevnaden, eftersom regelverket kräver det. En personlig blogg kan prioritera märkbarhet och funktionsduglighet, vilket löser de flesta verkliga hinder.

En komplex webbapplikation med interaktiva komponenter behöver investera i robusthet och funktionsduglighet, eftersom anpassade widgets är den främsta källan till fel. Beslutet handlar inte om “hur många egenskaper jag uppfyller” utan om “vilka egenskaper som är kritiska för mina användare och min lagstadgade skyldighet”.

För ramverk och komponentbibliotek innebär praktisk utvärdering att man testar komponenten med ett tangentbord innan man antar den. En anpassad “select” som inte svarar på piltangenter, en modal som inte fångar fokus korrekt, eller ett verktygstips som bara visas vid hovring är signaler om att biblioteket prioriterar utseende framför funktionsduglighet. W3C:s ARIA Authoring Practices Guide beskriver de förväntade mönstren för varje widget och utgör baslinjen för jämförelse.

Vanliga fel vid tolkning av egenskaperna

Det första felet är att behandla de fyra egenskaperna som en binär checklista. Efterlevnad är kumulativ och kontextuell: en webbplats kan uppfylla 40 kriterier men misslyckas med ett som helt blockerar en användare.

Relaterat: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia and accesibilidad.

Det andra felet är att lita på ett “overlay” eller en tillgänglighetswidget som lovar att fixa webbplatsen med ett skript; dessa produkter korrigerar inte den underliggande HTML-koden och har kritiserats av communityn och i rapporter från funktionshindersorganisationer. Det tredje felet är att granska endast en gång: innehållet ändras, komponenterna uppdateras och efterlevnaden försämras. Tillgänglighet är en process integrerad i utvecklingscykeln, med tester vid varje leverans.

Vanliga frågor

Vilka är de fyra egenskaperna för webbtillgänglighet enligt WCAG?

WCAG organiserar sina kriterier i fyra principer: märkbar, funktionsduglig, begriplig och robust, kända som POUR. Varje princip grupperar verifierbara framgångskriterier med nivåerna A, AA och AAA. Denna struktur bibehålls i WCAG 2.2 och är grunden för att utvärdera vilken webbplats eller komponent som helst.

Vilken nivå av WCAG-efterlevnad bör min webbplats uppfylla?

För de flesta webbplatser är nivå AA det praktiska målet och den nivå som refereras i den europeiska lagstiftningen via standarden EN 301 549. Nivå A täcker det minimala och AAA är svårt att uppnå fullt ut. Om din webbplats tillhör offentlig sektor inom EU är AA ett krav.

Värt att titta på: UserWay — Widget för accessibilidad med plan gratis för empezar Hoy Mismo.

Räcker automatiska verktyg för att uppfylla tillgänglighetsegenskaperna?

Nej. Automatiska verktyg upptäcker en del av problemen, främst gällande kontrast, alternativtext och felaktig ARIA, men de kan inte utvärdera om en alternativtext är lämplig eller om fokusordningen är logisk. Manuell granskning med tangentbord och skärmläsare är nödvändig för verklig efterlevnad.

Vad är skillnaden mellan tillgänglighet och användbarhet?

Tillgänglighet säkerställer att personer med funktionsnedsättning kan uppfatta, använda, förstå och interagera med innehåll; användbarhet strävar efter att säkerställa att upplevelsen är effektiv och tillfredsställande för alla användare. De överlappar varandra: en tillgänglig webbplats är vanligtvis mer användbar, men en användbar webbplats är inte nödvändigtvis tillgänglig.

Fixar tillgänglighetswidgets eller overlays min webbplats automatiskt?

De korrigerar varken den underliggande HTML-koden eller problem med struktur, fokus eller semantik. Tillgänglighetscommunityn och olika rapporter har ifrågasatt dem eftersom de kan ge en falsk känsla av efterlevnad. Lösningen ligger i att korrigera koden och komponenterna, inte i att lägga på ett skript.

Hur börjar jag förbättra tillgängligheten på en befintlig XHTML/CSS-webbplats?

Börja med det som har störst inverkan: giltig och semantisk HTML, alternativtext på bilder, tillräcklig kontrast, fullständig tangentbordsnavigering och etiketter i formulär. Granska sedan med ett automatiskt verktyg och komplettera med manuella tester. Dokumentera de uppfyllda kriterierna och upprepa processen vid varje relevant ändring.