WAI-ARIA ( Web Accessibility Initiative - Accessible Rich Internet Applications ) er et sett med dokumenter publisert av W3C ( World Wide Web Consortium ) som spesifiserer hvordan man kan øke tilgjengeligheten til dynamisk innhold og brukergrensesnittkomponenter utviklet med AJAX , HTML , JavaScript og andre relaterte teknologier.
HTML gir ikke muligheten til å lage dynamisk innhold eller avanserte brukergrensesnittkontroller, men det tillater inkludering av appleter ( Flash , Java ) og skripting på klientsiden (vanligvis JavaScript). Webutviklere bruker i økende grad klientsideskript for å lage brukergrensesnittkontroller som ikke kan opprettes med HTML alene. De bruker også skript på klientsiden for å oppdatere deler av en side uten å be om en ny fra webserveren . Slike teknikker på nettsteder kalles Rich Internet Applications . Disse kontrollene på brukersiden og dynamisk innholdsoppdatering er ofte ikke tilgjengelig for brukere med funksjonshemminger , spesielt de som bruker skjermlesere og brukere som ikke kan bruke musen eller andre pekeenheter.
WAI-ARIA beskriver hvordan du legger til semantikk eller andre metadata i HTML-innhold for å gjøre brukersidekontroller og dynamisk innhold mer tilgjengelig. For eksempel med WAI-ARIA er det mulig å identifisere en liste med lenker som en navigasjonsmeny ved å bestemme om den skal vises utvidet eller sammentrukket. Opprinnelig født for HTML, WAI-ARIA er ikke bare begrenset til dette: hovedsakelig kan den brukes i andre markup-språk som Scalable Vector Graphics (SVG). SVG 1.2 la til liten støtte for WAI-ARIA 15. september 2008 .
Tilgjengelige rike Internett-applikasjoner (WAI-ARIA) versjon 1.0 [1]
Dokument i hovedsak rettet mot utviklere av assisterende webteknologier og andre brukeragenter, utviklere av andre tekniske spesifikasjoner og utviklere av verktøy for evaluering av tilgjengelighet.
WAI-ARIA Primer [2]
Teknisk introduksjon til WAI-ARIA. Den beskriver problemene som WAI-ARIA adresserer, de grunnleggende konseptene, den tekniske tilnærmingen og de forretningsmessige årsakene til at WAI-ARIA bør tas i bruk.
WAI-ARIA De viktigste opplevelsene [3]
Beskriver beste fremgangsmåter for å spre rike internettapplikasjoner med WAI-ARIA: takler emner som de første trinnene for å bygge widgets , tastaturnavigasjon, relasjoner, skjemaegenskaper, støtte for kopiering og innliming , varsler og dialogbokser, gjenbrukbare komponentbiblioteker og testverktøy.
Før fremveksten av HTML5 semantiske tagger som <nav>, <aside>, <footer>, kunne ikke skjermlesere klart skille de ulike delene som nettsiden var sammensatt fra. Løsningen var i utgangspunktet å legge til en eller flere skjulte lenker øverst på siden. Disse koblingene ble omdirigert til de forskjellige delene av siden, for eksempel navigasjonslinjen [4] :
<a href = "#hidden" class = "hidden"> Gå til navigasjonslinjen < / a >HTML5 i tillegg til semantiske tagger oppdaterte også WAI ARIA-reglene [5] [6] [7] [8] :
Fyr | Oppgave | Eksempler |
---|---|---|
Roller | De definerer hva et element er og hva dets funksjon er | role="navigation"samsvarer med <nav> |
Eiendom | Gi elementene ekstra mening | aria-required="true"(obligatorisk inntastingsfelt) |
stater | De definerer de nåværende forholdene til elementene | aria-disabled="true"(inndatafelt deaktivert) |
Det er også fire kategorier av stater og eiendommer:
Egenskaper | Oppgave | Eksempler |
---|---|---|
Dra og slipp | Overfører informasjon til AT om dra-og-slipp-elementer,
inkludert drabare elementer og deres slippdestinasjoner. |
aria-dropeffect |
Live Region | Indikerer endringer i innholdet for en brukers AT, om en melding skal leses opp med innholdsstrømmen (dvs. aria-live=“polite”) eller i stedet stoppe innholdsstrømmen og leses høyt umiddelbart ( aria-live=“assertive”). Disse elementene trenger ikke være fokuserte og kan inneholde informasjon om hvordan brukeren kan gå frem. | aria-atomic |
Av forhold | De legger til forhold mellom elementer som ikke kan bestemmes på annen måte. | aria-describedby |
widget | Brukes for vanlige UI-elementer som mottar innspill fra brukere når de behandler disse handlingene og informasjonen. | aria-autocomplete |
Regel | Eksempler på bruk |
---|---|
Bruk alltid innebygd HTML | Feil:
<span role=“button” onClick=“submitForm();”>INVIA</span> Riktig: <button type=“submit” onClick=“submitForm();”>INVIA</button> |
Ikke endre den opprinnelige HTML-semantikken | |
Alle interaktive ARIA-kontroller må være tilgjengelige fra tastaturet. | <div tabindex=“0”>Ciao Mondo</div> |
For alle elementer som er fokuserbare, legg aldri til role=“presentation”eller aria-hidden=“true”. | Feil:
Search: <input type=“text” id=“search” /> Riktig: <input type=“text” id=“search” aria-label=“Search” /> |
Alle interaktive elementer må gis et tilgjengelig navn. |
Sak | Beskrivelse | Eksempler |
---|---|---|
Beskrivende etiketter | Når du trenger å legge til mer beskrivende etiketter til HTML-elementer som knapper eller lenker
(f.eks. Les mer, Lær mer osv.) |
<a aria-label=“Read More about how awesome Lullabot is” href=“/path/to/your/page”>Leggi di più</a> |
Varsler | For at hendelser skal kunngjøres til skjermlesere, må Live Region ARIA og advarselsmeldinger legges til disse elementene slik at de kan oppdages og leses høyt. | <div class=“alert-message” role=“alert”>
Hai completato con successo il modulo di contatto e riceverai presto un'email di conferma.</div> |
Relasjoner | For å skape en relasjon mellom elementer (foreldre/barn), må du legge til ARIA-attributter til hvert av elementene. | <nav id=“main-nav”> <button id=“menu-button-1” aria-haspopup=“true” aria-controls=“menu-list-1”>Menu 1</button> <ul id=“menu-list-1” role=“menu” aria-labelledby=“menu-button-1”> <li role=“none”><a role=“menuitem” href=“...”>Link 1</a></li> <li role=“none”><a role=“menuitem” href=“...”>Link 2</a></li> <li role=“none”><a role=“menuitem” href=“...”>Link 3</a></li> </ul> </nav> |
Former | Å gjøre skjemaer tilgjengelige for brukere av skjermlesere. | <label for=“first-name”>Primo nome</label><input type=“text” id=“first-name” aria-required=“true” aria-autocomplete=“on” /> |