POUR

POUR er den konceptuelle ramme, WCAG er bygget på. Hvert succeskriterium i WCAG 2.x knytter sig til præcis ét af de fire principper. At huske POUR er den korteste vej til at forstå, hvorfor en given regel eksisterer.

De fire principper

Perceivable (Opfattelig). Information og grænsefladekomponenter skal kunne præsenteres for brugere på måder, de kan opfatte. I praksis: tekstalternativer til ikke-tekstindhold (billeder, videoer), undertekster og transskriptioner til lyd, tilstrækkelig farvekontrast, indhold der tilpasser sig skærmlæsere og zoomede layouts. Hvis en seende bruger kan se noget, en blind bruger ikke kan, er der et opfattelighedsgab.

Operable (Betjenelig). Brugergrænsefladekomponenter og navigation skal kunne betjenes. De vigtigste regler under dette princip: fuld tastaturadgang (ingen musafhængige funktioner), nok tid til at læse og udføre opgaver, intet anfald-fremkaldende indhold (blink over 3 gange pr. sekund er den klare grænse), klar navigation og forudsigelig fokusrækkefølge. WCAG 2.2’s nye krav om fokussynlighed og alternativer til træk-og-slip er betjeningsregler.

Understandable (Forståelig). Information og betjening af grænsefladen skal være forståelig. Dette dækker forudsigelige navigationsmønstre, konsekvent mærkning på tværs af sider, klare instruktioner og hjælpsom fejlgendannelse. Arbejdsgruppens anbefalinger om kognitiv tilgængelighed falder under dette princip, selv når WCAG selv stopper kort for at gøre dem obligatoriske.

Robust (Robust). Indhold skal være robust nok til at kunne fortolkes pålideligt af en bred vifte af brugeragenter, herunder hjælpeteknologi. I praksis er dette det mindste princip med overvejende én regel — 4.1.2 Name, Role, Value — men den ene regel dækker en enorm overflade: den kræver, at hvert brugerdefineret UI-element afslører, hvad det er, hvad det gør, og hvilken tilstand det befinder sig i, på en måde, hjælpeteknologi kan læse. 4.1.2 er grunden til, at ARIA eksisterer.

Sådan bruger du POUR i praksis

Når du finder et tilgængelighedsproblem, spørg dig selv, hvilket princip det overtræder:

• En manglende alt-attribut er Perceivable.
• En tastatur-fælde er Operable.
• En forvirrende fejlmeddelelse er Understandable.
• En brugerdefineret dropdown, der ikke annoncerer sig selv som en combobox, er Robust.

Den kortlægning hjælper med prioritering: Perceivable- og Operable-fejl blokerer som regel brugere fuldstændigt; Understandable- og Robust-fejl forringer ofte oplevelsen uden at blokere den. De fleste teams fokuserer deres første revision på P og O af den grund.

POUR hjælper også med at identificere blinde vinkler. Et team, der obsessivt fikser Perceivable-problemer (alternativ tekst, kontrast), men ignorerer Operable-problemer (fokusrækkefølge, tastatur-fælder), har et genkendeligt og almindeligt fejlmønster. POUR gør den skævhed synlig.