ARIA Authoring Practices Guide (APG)

Hvad er ARIA APG, og hvem står bag

ARIA Authoring Practices Guide er en vejledning i, hvordan du bygger tilgængelighedssemantik ind i webmønstre og widgets. Guidens erklærede formål er at lære udviklere at bruge den tilgængelighedssemantik, som ARIA-specifikationen (Accessible Rich Internet Applications) definerer, til at skabe tilgængelige weboplevelser. Hvor ARIA-specifikationen selv er en teknisk normativ standard, der beskriver hvad de enkelte roller, tilstande og egenskaber betyder, er APG det praktiske lag ovenpå: den viser hvordan du sætter dem sammen til hele, brugbare komponenter.¹

Guiden er udgivet og vedligeholdt af W3C's Web Accessibility Initiative (WAI) gennem en dedikeret APG Task Force. Task force'en bygger udtrykkeligt på bred repræsentation og deltagelse fra fællesskabet for løbende at forbedre guidens anvendelighed og kvalitet. Det er værd at forstå denne forankring: W3C er den samme standardorganisation, der udgiver HTML, ARIA og WCAG, og APG er derfor ikke et privat blogprojekt eller en tilfældig samling kodeeksempler, men et officielt WAI-produkt, der lever tæt op ad selve specifikationerne.¹

Det er vigtigt at holde APG og WCAG adskilt i hovedet. WCAG (Web Content Accessibility Guidelines) er det normative regelsæt med succeskriterier, som lovgivning og indkøbskrav ofte henviser til; det er dét, du "overholder" eller ikke overholder. APG er derimod ikke et krav, du kan opfylde, men en vejledning i, hvordan du teknisk kommer i mål med ARIA på en måde, der understøtter tilgængelighed. Guiden linker da også direkte til den samlede WCAG 2-vejledning, netop fordi de to ressourcer supplerer hinanden frem for at overlappe. Du bruger WCAG til at vide, hvad der skal være opfyldt, og APG til at få konkrete mønstre for, hvordan en given widget kan implementeres tilgængeligt.¹

Endelig hænger APG uløseligt sammen med selve ARIA. Guiden forsøger ikke at erstatte ARIA-specifikationen, men at gøre den anvendelig. Hvor specifikationen definerer for eksempel rollen combobox og egenskaben aria-expanded formelt, viser APG dig, i hvilken rækkefølge og kombination de skal bruges for at bygge en kombinationsboks, der faktisk fungerer for en skærmlæserbruger. Man kan sige, at ARIA leverer ordforrådet, og APG leverer grammatikken og de færdige sætninger.¹

Hvad indeholder guiden

Kernen i APG er samlingen af designmønstre. På tidspunktet for denne artikel dokumenterer guiden omkring 29 mønstre for almindelige webwidgets og komponenter. Det spænder over interaktive widgets som accordion, alert, alert dialog, button, checkbox, combobox, modal dialog, disclosure, menu og menubar, menu button, radiogruppe, slider, spinbutton, switch, tabs og tooltip. Dertil kommer mønstre til datavisning som feed, grid, listbox, meter, table, tree view og treegrid, samt navigations- og layoutmønstre som breadcrumb, links, toolbar, window splitter og carousel.²

Hvert mønster er bygget op efter samme faste skabelon, hvilket gør guiden let at slå op i. Tag combobox-siden som eksempel: den er inddelt i sektionerne "About This Pattern", "Examples", "Keyboard Interaction" og "WAI-ARIA Roles, States, and Properties". Den samme struktur går igen på tværs af mønstrene, så når du først kender opbygningen af én side, kender du opbygningen af dem alle.³

Tastaturinteraktion fylder meget, fordi det er her de fleste custom-widgets fejler. For combobox beskriver guiden for eksempel præcist, hvordan piletaster navigerer i pop op-listen, hvordan Escape lukker den, hvordan skrivbare tegn indtastes i de redigerbare varianter, og hvordan Alt kombineret med piletaster valgfrit styrer visningen af pop op-vinduet. Et centralt fokusprincip beskrives også: for listbox-, grid- og tree-pop op-vinduer bevares DOM-fokus på selve komboboksen, mens hjælpeteknologiens fokus flyttes inde i pop op-vinduet ved hjælp af aria-activedescendant. Den slags detaljer er svære at gætte sig til, og det er netop derfor, guiden findes.³

Sektionen om roller, tilstande og egenskaber oversætter mønstret til konkret ARIA. For combobox betyder det blandt andet rollen combobox på inputelementet, aria-controls der peger på pop op-vinduet, aria-expanded der angiver om pop op-vinduet er synligt, aria-activedescendant når et element i pop op-vinduet har fokus, og aria-autocomplete der beskriver, hvilken form for autofuldførelse widgeten tilbyder. Hvert mønster har sin egen tilsvarende liste, så du kan se den fulde semantiske "opskrift" på ét sted.³

Ud over de rene widget-mønstre indeholder APG også bredere, grundlæggende emner. Guiden dækker landmark-regioner, hvor den forklarer, hvordan HTML-sektioneringselementer og ARIA-landmark-roller gør det let for brugere af hjælpeteknologi at forstå sidens overordnede layout og navigere mellem dens dele. Den behandler tilgængelige navne og beskrivelser, som guiden kalder et af de vigtigste ansvarsområder, en udvikler har, når der bygges tilgængelige weboplevelser: uden et korrekt tilgængeligt navn er selv en teknisk korrekt widget reelt ubrugelig for en skærmlæserbruger. Endelig samler en gruppe af øvrige grundlæggende praksisser råd om korrekt brug af tilgængelighedssemantik og udvikling af tastaturgrænseflader.¹

Til hvert mønster hører desuden en eller flere fungerende eksempelimplementeringer. For combobox alene linkes der til seks: select-only combobox, redigerbar combobox med både liste- og inline-autofuldførelse, redigerbar combobox med listeautofuldførelse, redigerbar combobox uden autofuldførelse, redigerbar combobox med grid-pop op og en date picker-combobox. Eksemplerne er levende demonstrationer, du kan prøve i browseren og inspicere kildekoden på, og de er guidens mest håndgribelige aktiv.³

Sådan bruger du APG i praksis

Den mest almindelige brug af APG er som opslagsværk. Du står med en konkret komponent, du skal bygge eller rette, for eksempel en fanebladsnavigation eller en modal dialog, og du vil vide, hvordan den gøres tilgængelig korrekt. Du finder det tilsvarende mønster i Patterns-oversigten, læser "About This Pattern" for at bekræfte, at det er den rigtige type widget, og går derefter direkte til de to sektioner, der som regel er mest værd: "Keyboard Interaction" og "WAI-ARIA Roles, States, and Properties". Tilsammen giver de dig en tjekliste over, hvilke taster der skal virke, og hvilke roller, tilstande og egenskaber der skal være på plads.³²

En vigtig disciplin er at kopiere mønstret, ikke koden. APG's eksempler er skrevet for at illustrere principperne så tydeligt som muligt, ikke for at være færdige komponenter, du kan klippe ind i din kodebase. Guiden er selv eksplicit på dette punkt: eksemplerne beskriver og implementerer bevidst ikke teknikker til at omgå de huller, der findes i browsernes og hjælpeteknologiernes understøttelse af ARIA 1.2. Det, du skal tage med dig, er interaktionsmodellen og semantikken; selve implementeringen skal tilpasses dit eget framework, dine egne komponenter og dine egne understøttelseskrav.⁴

Vær også opmærksom på konteksten for dit projekt. Guiden bemærker, at den endnu ikke oplyser, hvilke eksempler der understøtter mobil- og touch-grænseflader, og at nogle ARIA-funktioner slet ikke understøttes i nogen mobilbrowser. Hvis du bygger til touch, kan du derfor ikke antage, at et mønster fungerer, blot fordi det virker på desktop med tastatur og skærmlæser. Det er en konkret grund til altid at teste i de miljøer, dine brugere faktisk befinder sig i.⁴

En sund arbejdsgang er at bruge APG sammen med to andre ressourcer. Brug WCAG til at afklare, hvilke succeskriterier komponenten skal opfylde. Brug den native HTML-løsning, hvis den findes, før du overhovedet griber til ARIA, det er guidens egen forudsætning. Og brug så APG til at få den korrekte semantik og tastaturmodel, når du er nødt til at bygge en custom-widget, som HTML ikke tilbyder ud af boksen. På den måde bliver APG det tekniske bindeled mellem kravene i WCAG og den faktiske kode.¹⁴

Adgang, pris og vedligeholdelse

APG er gratis og offentligt tilgængelig. Hele guiden ligger frit på w3.org under WAI's sider, uden login, betalingsmur eller registrering. Alle mønstre, eksempler og praksisafsnit kan tilgås og bruges direkte, og eksempelkoden kan studeres og prøves i browseren. For et opslagsværk om tilgængelighed er det i sig selv passende: ressourcen er tilgængelig for alle, der har brug for den.¹

Guiden er et levende dokument, ikke en statisk udgivelse. Den vedligeholdes af APG Task Force under WAI, og task force'en bygger bevidst på bred deltagelse fra fællesskabet for løbende at forbedre guidens anvendelighed og kvalitet. I praksis betyder det, at mønstre, eksempler og anbefalinger opdateres over tid i takt med, at understøttelsen i browsere og hjælpeteknologier ændrer sig, og at nye mønstre kan komme til. Arbejdet foregår i åbenhed, og bidrag kan indsendes via det offentlige GitHub-repository, som task force'en arbejder ud fra.¹

For dig som bruger har den løbende vedligeholdelse to konsekvenser. På den positive side kan du regne med, at guiden afspejler en nogenlunde aktuel forståelse af, hvad der virker på tværs af hjælpeteknologier, snarere end en frossen anbefaling fra ét bestemt år. På den anden side betyder det, at du skal slå op i den aktuelle onlineversion og ikke stole på en gammel note eller et kodeeksempel, du gemte for et par år siden, for detaljerne kan have ændret sig.¹

Styrker og forbehold

APG's styrke er, at den samler noget, der ellers er spredt og svært at gætte sig til: den fulde tastatur- og semantikmodel for hver almindelig widget, ét sted, i en fast og genkendelig struktur, og med fungerende eksempler at holde sig op ad. For en udvikler eller designer, der skal bygge en tilgængelig komponent, sparer den timevis af research og reducerer risikoen for at overse en tilstand eller en tastehandling. Den er samtidig autoritativ, fordi den kommer fra samme organisation, der udgiver selve ARIA-specifikationen.¹³

Det vigtigste forbehold er, at APG ikke er en erstatning for test med rigtig hjælpeteknologi. Guiden siger det selv utvetydigt: "Testing assistive technology interoperability is essential before using code from this guide in production." Et mønster kan være korrekt efter guiden og alligevel opføre sig anderledes i en bestemt kombination af skærmlæser og browser, blandt andet på grund af de understøttelseshuller, guiden bevidst ikke prøver at omgå. Du skal derfor selv verificere i de faktiske miljøer, dine brugere anvender, og helst med rigtige brugere.⁴

Et andet forbehold er, at ARIA er et skarpt værktøj, der kan skære begge veje. Guidens egen ledesætning er "No ARIA is better than Bad ARIA", og den advarer om, at forkert ARIA misrepræsenterer den visuelle oplevelse med potentielt ødelæggende effekt på den tilsvarende ikke-visuelle oplevelse. Guiden minder også om, at en rolle er et løfte: sætter du role på et element, lover du samtidig, at du har leveret den JavaScript, der giver den forventede tastaturinteraktion. Med andre ord er det ikke nok at kopiere attributterne fra et mønster; du skal levere hele adfærden bag dem, ellers gør du fladen mindre tilgængelig, ikke mere.⁴

Endelig skal du huske APG's afgrænsning. Den fortæller dig, hvordan du bygger en given widget tilgængeligt, men ikke om du overhovedet burde bruge netop den widget, eller om den native HTML-løsning ville være bedre. Den erstatter heller ikke WCAG som kravgrundlag eller den bredere brugervenlighedsvurdering af, om designet giver mening for dine brugere. Brugt med de forbehold, som guiden selv fremhæver, er APG et af de stærkeste frie opslagsværk, der findes til tilgængelig frontend-udvikling.¹⁴

Ofte stillede spørgsmål

Kilder

1. ARIA Authoring Practices Guide (APG)W3C / Web Accessibility Initiative (WAI) · Guidens forside: formål, indhold, forhold til WCAG og ARIA samt vedligeholdelse via APG Task Force.
2. Patterns – ARIA Authoring Practices GuideW3C / Web Accessibility Initiative (WAI) · Oversigt over de dokumenterede designmønstre for widgets.
3. Combobox Pattern – ARIA Authoring Practices GuideW3C / Web Accessibility Initiative (WAI) · Eksempel på en mønsterside med sektionerne About, Examples, Keyboard Interaction og ARIA Roles, States, and Properties.
4. Read Me First – ARIA Authoring Practices GuideW3C / Web Accessibility Initiative (WAI) · Grundlæggende forbehold, herunder "No ARIA is better than Bad ARIA" og kravet om test med hjælpeteknologi før produktion.