Globe Views
500 things that everyone should know ...
Home | About Us

Introduksjon til WAI ARIA

Denne artikkelen er for de som er nye til ARIA. Du trenger en forståelse av HTML og de potensielle problemer som personer med nedsatt funksjonsevne kan møte ved hjelp av Web. Det er nyttig å bli kjent med noen Rich Internet Applications fra en brukers perspektiv Etter å ha lest denne artikkelen, vil du forstå hva ARIA er for, hvordan integrere den inn i dine nettsteder, og hvordan du kan bruke den nå for å gjøre selv de enkleste av nettsteder mer tilgjengelige. Denne artikkelen er også tilgjengelig på: Vær oppmerksom på disse er oversettelser uavhengig av Opera.

Oppdater logg

Oppdatere den 8 oktober 2008: Liste over dokumenter landemerke roller oppdatert for å gjenspeile endring i spesifikasjonen. Update 1 april 2009: Seksjon for aria-kanal , og aria-live = "uhøflig" verdi fjernet for å reflektere endringer i spesifikasjonen. Begge har blitt fjernet fra spec.

Innledning

HyperText Markup Language (HTML) ble opprinnelig utviklet for å lage web-applikasjoner. HTML har et begrenset sett med grensesnitt kontroller, og er basert rundt en sekvensiell klient-server kommunikasjon modell. Web programutviklere har fått rundt disse begrensningene ved å opprette sine egne komponenter (widgets), ved hjelp av JavaScript for å legge oppførsel til widgets. Dessverre har de teknikker som brukes for å overvinne disse begrensningene ikke vært tilgjengelig. Selv tilpassede widgets kan se og oppføre seg som vanlige stasjonære søknad widgets, for eksempel en trevisning widget, rollen (hva widgeten gjør), state (dens unike konfigurasjon, for eksempel sjekket ), og andre viktige egenskaper er ikke tilgjengelig for hjelpemidler , som skjermlesere. Dette er det samme som styling ren tekst for å se ut som en overskrift, istedenfor å bruke en overskrift element - ren tekst ser ut som en overskrift, men er ikke avslørt som en overskrift for å hjelpemidler. Oppdateringer blir ofte oversett av folk som bruker hjelpemidler. Tillleggsprogram vanligvis forventer webinnhold til å endre svar på en navigere hendelse, for eksempel følge en kobling eller sende inn et skjema. Webprogrammer bruker teknikker, for eksempel AJAX , for å oppdatere innhold i bakgrunnen, som er noen ganger savnet av hjelpemidler. Selv om hjelpemidler er klar over oppdateringer, brukeren fremdeles ikke kan være oppmerksom på at innholdet er oppdatert, eller hvordan du finner oppdatert innhold. WAI - ARIA er en spesifikasjon som gir et middel for å beskrive roller, delstater og egenskaper for egendefinerte widgets slik at de er gjenkjennelige og brukes av hjelpefunksjoner brukere. WAI-ARIA gir også en mekanisme for å sikre at brukere av hjelpemidler teknologier er klar over oppdateringer i programmet.

A Brief History of HTML

HTML ble opprinnelig designet for å være et hypertekst system for å strukturere og dele koblede dokumenter. Tidlig HTML utkast definerte koder, for eksempel overskrifter, avsnitt, lister og ankere, for å legge struktur til tekstbaserte dokumenter. Den første forslag til en HTML-spesifikasjonen ved IETF også inkluderte img element for å tillate grafikk som skal vises inline. Den første formelle HTML-spesifikasjonen var 2 HTML , basert på de tidlige HTML utkast. Denne spesifikasjonen ble det innført former, og definert et lite sett med grensesnitt komponenter for å skape redigeringsbokser, knapper, avmerkingsbokser, alternativknapper og dropdown lister. Den lille sett av grensesnittkomponenter definert i HTML 2 har knapt endret sammenlignet med settet vi i dag bruker med HTML 4.01 . Kommunikasjonen modell for HTML er basert på klient-server modell. I klient-server modell, klienten sender forespørsler og kan motta svar, serveren lytter etter forespørsler, behandler forespørselen på serveren, og sender svar tilbake til klienten. Som HTML ikke har en atferd lag, ble kommunikasjon ment å være sekvensielle - klienten ber om en side fra serveren, serveren behandler forespørselen og sender en side til klienten.

Web Applications

Web-applikasjoner prøver å etterligne vanlige desktop-applikasjoner, bortsett webapplikasjoner kjører inni en annen vanlig desktop program - en nettleser. Det er også to grunnleggende forskjeller mellom HTML og sin kommunikasjon modell, og en vanlig desktop program:
  • Vanlige stasjonære applikasjoner har en atferd lag som ikke er avhengig av forespørsler til en server.
  • Regelmessige desktop-applikasjoner har en langt rikere sett av grensesnitt komponenter.

Simulere Regular Skrivebordsprogrammer

Bakgrunn Server Forespørsler

For å etterligne vanlige desktop-applikasjoner, web-applikasjoner bruker JavaScript til å legge atferd. For eksempel kan JavaScript brukes til å tillate et menyelement for å utvide og skjule når brukeren samhandler med det. Noen ganger kan data være nødvendig fra serveren. For eksempel kan programmet må hente poster fra en database på serveren for å oppdatere informasjonen på den aktuelle siden. Når programmet har til å samhandle med serveren, web-applikasjoner bruker teknikker som AJAX eller skjulte IFrame elementer å kommunisere med serveren i bakgrunnen.

Simulere Rich komponenter

Som HTML har svært få grensesnittkomponenter, web-applikasjoner og til trenger for å lage mer komplekse widgets, for eksempel en tri-state boksen eller en skyveknapp kontroll. Utseendet av disse widgets er vanligvis laget ved å tegne widgeten som grafikk, og legge skripting å gjøre dem oppføre seg som de innfødte komponent. Tre boksene, ukontrollert, sjekket, og delvis kontrollert Figur 1 - En dialogboks med en tri-state boksen. Skyvekontrollen med diskrete verdier for å indikere kvalitet Figur 2 - En glidebryter widget som kan brukes til å indikere kvaliteten til en tjeneste.

Tilgjengelighetsproblemer med Utseende og emulering

Visuelt etterligning rike komponenter og gjøre forespørsler i bakgrunnen skaper en rikere opplevelse for brukerne.Dessverre, dette resulterer i tilgjengelighetsproblemer som er spesielt ille for brukere av hjelpemidler, for eksempel skjermlesere brukere.
  • Widgets bygget på denne måten er sjelden tastaturet.
  • Rollen til widget, hva den gjør, er ikke tilgjengelig for hjelpemidler.
  • Stater og egenskaper widget er ikke tilgjengelig for hjelpemidler.
  • Oppdateringer, og oppdagelsen av oppdateringene er ikke rapportert til tekniske hjelpemidler.

WAI-ARIA til unnsetning

Heldigvis er alle problemene skissert ovenfor løses av Web Accessibility Initiative Accessible Rich Internet Applications (WAI-ARIA) spesifikasjon (forkortet til ARIA for resten av denne artikkelen). ARIA er en positiv, slik teknologi - i stedet for å fortelle utviklerne hva de ikke kan gjøre, gjør ARIA utviklere å lage rike webapplikasjoner.ARIA er også svært enkelt å implementere.

Tastaturnavigering

Sammen med å gi alternativ tekst for ikke-tekstobjekter, være i stand til å samhandle med grensesnittelementer ved hjelp av tastaturet alene er en av de mest grunnleggende tilgjengelighet bestemmelser. Utviklere som forstår tilgjengelighet kan bygge tilpassede widgets ved hjelp komponenter som får fokus, for eksempel innspill element med en typen attributt verdi av bildet ( <input type="image" ...> ). Dessverre er de fleste widgets ikke bygget med komponenter som er tastaturet, men i stedet bruke elementer som img element, eller kan bestå av sammensatte elementer som må være i en beholder element, for eksempel en div , som er ute av stand til å motta tastatur fokus. HTML 4 introduserte tabindex attributtet for et , område , knapp , inngang , objekt , velger , og textareaelementer. Den tabindex attributtet fra HTML 4 aksepterer en positiv verdi mellom 0 og 32767 . Navigasjon starter på elementene med lavest antall, og går til elementet med høyest nummer. Elementer med en verdi på 0 er besøkt i den rekkefølgen de vises i markeringen. Hvis markup har en logisk struktur, tabindex er attributtet ikke er nødvendig for grensesnittelementer som allerede er i tastaturet tabulatorrekkefølge. ARIA utvider tabindex attributtet slik at den kan brukes på alle synlige elementer. ARIA gir også en negativ verdi skal spesifiseres for elementer som ikke bør vises i tastaturet tabulatorrekkefølge, men kan programmatisk fokusert (gi fokus til et element med scripting). Som den faktiske verdien av negative tall er uviktig (elementet aldri får tastaturfokus), verdien -1 brukes vanligvis for elementer som ikke bør inkluderes i tabulatorrekkefølgen, men må kanskje være i stand til å motta programmatisk fokus. For eksempel kan du lage en meny widget der menyen selv er i tabulatorrekkefølgen og får fokus ved å tabbe til det, men menyelementer er ikke i tastaturet tabulatorrekkefølge. I stedet kan menyelementene programmeres slik at de kan navigeres ved hjelp av piltastene.Denne måten, trenger brukerne ikke trenger å fane gjennom alle elementene i menyen, og kan bedre navigere i dokumentet. Dette er sant for alle widgeter som har en serie av komponenter som trenger tastatur tilgang, for eksempel et tre.

Legge til Natural Tabulatorrekkefølge

Følgende eksempel bruker en tabindex attributtverdi av 0 for å sette en div element i kategorien rekkefølge slik at et tastatur bruker kan navigere til elementet.
< div  tabindex = "0" > ... </ div > 

Negativ tabindex

Følgende eksempel bruker en negativ tabindex attributtverdi, slik at elementet kan motta programmatisk fokus. <div id="progaccess" tabindex="-1"> ... </div> I dette eksempelet er div element ikke er plassert i kategorien for, men å ha en tabindex attributt verdi på -1 betyr at den kan motta programmatisk fokus. Følgende kodebit JavaScript velger element definert ovenfor, og bruker fokusmetode å plassere vekt på elementet. var objDiv = document.getElementById('progaccess'); // Focus on the element objDiv.focus(); Hva er jeg? ARIA introduserer rollen attributtet til å definere widgets, for eksempel en skyveknapp, og definere side struktur, slik som et navigasjonssystem delen. En av de store problemer med web-applikasjoner er at enhver elementet kan brukes til å gjøre en widget. HTML-elementer som allerede har forhåndsdefinerte roller. Rollen av et element er hva det gjør - det de gjør i strukturen. For eksempel er rollen som en overskrift godt forstått av hjelpemidler. Når widgets er bygget med eksisterende elementer, er rollen av elementet til det som avdekkes hjelpemidler, heller enn hva det visuelt representerer i widgeten. For eksempel, hvis tommelen for en skyveknapp kontroll er opprettet ved hjelp av en bildeelement med passende alternativ tekst, og deretter en skjermleser vil trolig kunngjøre kontroll som "Graphic, tommelen", i motsetning til noe mer meningsfylt, som "slider, verdi 16 prosent ". Slider&rsquo;s thumb Figur 3 - tommelen på en typisk skyvekontroll. Rollen gitt av den rollen attributt trumfer rolle de innfødte element. I følgende eksempel har en inngang element en rolle egenskap av glidebryteren (vi vil se på noen av de andre ARIA egenskapene senere i denne artikkelen) - rollen utsatt for hjelpemidler er skyveknapp, snarere enn input. <input type="image" src="thumb.gif" alt="Effectiveness" role="slider" aria-valuemin="0" aria-valuemax="100" aria-valuenow="42" aria-valuetext="42 percent" aria-labelledby="leffective"> Når dette elementet får fokus, forstår en skjermleser bruker rollen denne widgeten spiller. ARIA spesifikasjonen vedlikeholder en liste over roller. Document landemerke roller Samt roller å hjelpe definere widgeter, er rollene som kan bidra til å definere strukturen i dokumentet. Dokument landemerker er en undergruppe av vanlige roller som hjelper brukere med skjermleser forstå rollen som en del og hjelpe orientere seg i dokumentet. Page Structure Figur 4 - En typisk side med en overskrift, sidebar og hovedinnhold området. ARIA definerer følgende dokument landemerke roller. artikkelen Innhold som gir mening i seg selv, for eksempel en komplett blogginnlegg, en kommentar på en blogg, et innlegg i et forum, og så videre. banner Site-orientert innhold, for eksempel tittelen på siden og logoen. utfyllende Hjelpemiddel innhold for hovedinnholdet, men meningsfull i seg selv når adskilt fra hovedinnholdet. For eksempel, været notert på en portal. contentinfo Barn innhold, for eksempel fotnoter, opphavsrett, koblinger til personvernerklæringen, lenker til preferanser, og så videre. main Innhold som er direkte relatert til, eller utvides på den sentrale innholdet i dokumentet. navigasjon Innhold som inneholder koblingene for å navigere dette dokumentet og / eller relaterte dokumenter. søke Denne delen inneholder et søkeskjema for å søke i nettstedet. Følgende eksempel angir landemerke roller banner, navigasjon, og viktigste å opprette siden strukturen vist i Figur 4. <div role="banner"> ... </div> <div role="navigation"> ... </div> <div role="main"> ... </div> ARIA USA og Properties ARIA stater og egenskaper tillate ytterligere informasjon om widgeten for å bli gitt til tekniske hjelpemidler for å hjelpe brukeren å forstå hvordan de skal samhandle med widgeten. Staten identifiserer en unik konfigurering av informasjon for et objekt. For eksempel har arie-sjekket eiendommen tre statlige verdier, true, false, og blandet. I glidebryteren eksempelet ovenfor, har vi inkludert ulike arie-egenskaper, som vist nedenfor, som hjalp beskrive widgeten til tekniske hjelpemidler. aria-valuemin Lagrer den laveste verdien en rekke kan ha. aria-valuemax Lagrer den høyeste verdien en rekke kan ha. aria-valuenow Lagrer gjeldende verdi i et område. aria-valuetext Lagrer lesbar tekst for å hjelpe brukeren å forstå sammenhengen. For eksempel "30 dollar". aria-labelledby Lagrer id attributt av en tekst etikett med en passende ledetekst for denne widgeten. Noen egenskaper kan bli oppdatert ved hjelp av skript. For eksempel ville aria-valuenow og aria-valuetext egenskapene våre glidebryteren widget bli oppdatert når tommelen er flyttet. / / Sett Aria eiendomsverdiene når tommelen er / / Flyttet på skyveknappen objThumb.setAttribute ('aria-valuenow', iValue); objThumb.setAttribute ('aria-valuetext', iValue + '%'); Legge ARIA roller og attributter vil ikke bekrefte med HTML 4.01 eller XHTML 1.0, men det er helt greit, så ARIA er å legge viktig informasjon til spesifikasjonene som ble skrevet for lenge siden. Arbeid pågår definere en DTD som kan brukes med modulær XML, som XHTML 1.1. Det er en full liste over stater og egenskaper for å bidra til å definere tilgjengelige widgets i ARIA spesifikasjonen. Lever regioner Levende regioner tillater elementer i dokumentet vil bli annonsert om det er endringer, uten at brukeren mister fokus på deres nåværende aktivitet. Dette betyr at brukere kan bli informert om oppdateringer uten å miste sin plass i innholdet. For eksempel kan en chat program kunngjøre responsen fra personen brukeren prater med, uten å flytte fokus bort fra tekstfeltet for å legge en linje av chat. Aria-live Den gjenkjenning av oppdatert innhold er en av de største hindringene for brukere med skjermleser. ARIA gir en arie-live eiendom som har en verdi som indikerer detaljnivå for regionen. Følgende er de Ordmengde verdier som kan brukes sammen med aria-live eiendom. off Dette er standardverdien, og viser at regionen ikke er levende. <ul aria-live="off"> polite Dette er normal drift og forventet oppførsel for live regioner. En verdi på høflig indikerer at det ikke er nødvendig å svare før brukeren er ferdig med sin aktuelle aktivitet. <ul aria-live="polite"> assertive Denne verdien er høyere prioritet enn normalt, men ikke nødvendigvis avbryte brukeren umiddelbart. <ul aria-live="assertive"> Det er noen andre viktige egenskaper som kan brukes når du definerer levende regioner, oppsummert nedenfor. Arien-atomære Eiendom Han aria-atomic eiendom er en valgfri egenskap av levende regioner som kan ha verdiene sant eller usant (standard hvis denne egenskapen ikke er spesifisert). Når regionen er oppdatert, blir arien-atomære egenskap som brukes for å angi om hjelpemidler skal presentere hele eller deler av den endrede regionen til brukeren. Hvis denne egenskapen er satt til true, bør hjelpeteknologi presentere hele regionen som helhet, ellers kan den delen av regionen som endret bli annonsert på egen hånd. I følgende eksempel, vil alle elementer innen sorterte liste blir offentliggjort i sin helhet når regionen er talt, med mindre annet element lenger ned i kjeden overstyrer aria-atom eiendom. <ul aria-atomic="true" aria-live="polite"> Arien-opptatt Eiendom Arien-opptatt eiendom er en valgfri egenskap av levende regioner som kan ha verdiene sant eller usant (standard hvis denne egenskapen ikke er spesifisert). Hvis flere deler av en levende region må lastes før endringer blir annonsert til brukeren, kan aria-opptatt eiendom settes til true til den siste delen er lastet, og deretter satt til false når oppdateringene er fullført. Denne egenskapen hindrer tillleggsprogram annonserer endringer før oppdateringene er fullført. <ul aria-atomic="true" aria-busy="true" aria-live="polite"> Arien-relevant Eiendom Arien-relevant eiendommen er en valgfri egenskap av levende regioner som indikerer hvilke endringer anses relevant innenfor en region. Arien-relevant eiendommen aksepterer en plass separert liste av følgende eiendomsverdiene: additions Noder legges til DOM i regionen. removals Noder er fjernet fra DOM i regionen. tekst Tekst legges til eller fjernes fra DOM. all Alle de ovennevnte (tillegg, flytting, tekst) gjelder for denne regionen. I fravær av en eksplisitt arie-relevant eiendom, er standard å anta at det er tekst endringer og tilføyelser (aria-relevante = "tekst filer"). Følgende eksempel ville bare opplyse om endringer hvis noder legges til DOM i regionen. Hvis det er tekst endres, eller noder fjernes innen regionen, vil brukeren ikke bli varslet. <ul aria-relevant="additions" aria-atomic="true" aria-live="polite"> Når kan ARIA brukes? Det er ingen negative bivirkninger av å bruke ARIA, slik at du kan begynne å bruke den med en gang. Alle fire av de store nettleserne har implementert støtte for ARIA, eller har planer om å implementere støtte for ARIA. Opera 9.5 og Firefox 1.5 + allerede inkluderer støtte for ARIA. Internet Explorer 8 Beta har ARIA støtte, og WebKit, den open source program rammeverk bak Safari, har annonsert at de har begynt å legge til støtte for ARIA. ARIA blir også mye som støttes av hjelpemidler. JAWS 7.1 +, Window-Eyes 5.5 +, NVDA, ZoomText 9 +, og andre, har grunnleggende støtte for ARIA, og situasjonen er satt til å forbedre. Være tidlig ute Så det er ingen negative bivirkninger av å bruke ARIA, og støtte er allerede på plass, er det ingenting å tape ved å bli en tidlig adopter, men nok til å få. Selv om du har den enkleste av nettsteder, kan du inkludere dokument landemerke roller for å hjelpe brukerne bedre navigere, og orientere seg i innholdet. Bruk dokument landemerke roller På min personlige nettside, har jeg tatt dokument landemerke roller for main, navigasjon, søk, og sekundært. Vurdere følgende dokumentstruktur. <div id="ads"> ... </div> <div id="nav"> <form id="searchform" ...> ... </form> ... </div> <div id="content"> ... </div> Vi kunne skrive rollen attributt for våre dokument landemerker direkte inn markeringen. <div id="ads" role="banner"> ... </div> <div id="nav" role="navigation"> <form id="searchform" role="search" ...> ... </form> ... </div> <div id="content" role="main"> ... </div> Alternativt, som de fleste sidene er strukturert slik at de kan bli stylet med CSS, er det sannsynlig at siden vil bli strukturert med id attributter som kan sendes til en JavaScript-funksjon. Det følgende er et eksempel på en enkel JavaScript-funksjon som aksepterer id attributt av et element, og en rolle verdi, og setter rollen attributten på tilsvarende elementet. function addARIARole(strID, strRole) { // Find the element to add a role property to var objElement = document.getElementById(strID); if (objElement) { // Add the role property to the element objElement.setAttribute('role', strRole); } } Funksjonen kan da bli kalt med id av seksjonen, og dokumentet landemerke rolle i seksjonen. Så vurderer dokumentstrukturen ovenfor, kan vi bruke denne JavaScript-funksjonen for å sette rollen attributt, snarere enn å skrive det inn i markeringen. function setupARIA() { // Add ARIA roles to the document addARIARole('content', 'main'); addARIARole('nav', 'navigation'); addARIARole('searchform', 'search'); addARIARole('ads', 'banner'); } window.onload = setupARIA; Indikere nødvendige feltene Hvis du har skjemaer som inneholder nødvendige feltene, kan du benytte deg av aria-krevde eiendom. Aria-krevde eiendom indikerer at brukeren må angis på kontroll før skjemaet kan sendes inn. Følgende eksempel legger arien-krevde eiendom til en vanlig inngang element. <label for="contactname">Name</label> <input type="text" id="contactname" name="contactname" size="30" aria-required="true"> Wordpress har begynt å bruke arie-nødvendige attributtet for nødvendige feltene i kommentarfeltet for blogginnlegg. Legg til andre relevante egenskaper Det er mange ARIA egenskaper som kan brukes på de enkleste av nettsteder, for eksempel aria-labelledby og aria-describedby. Aria-labelledby eiendom til et eller flere elementer som anses etiketten for et element, og arie-describedby eiendom peker på en eller elementer som anses beskrivelsen for et element. <h2 id="limg">Paragliding</h2> <p id="dimg"> A long description of our paragliding trip ... </p> <div> <img src="takeoff.png" alt="Getting ready to take off" aria-labelledby="limg" aria-describedby="dimg"> </div> Forrang for markup ARIA markup forrang over hæren språk markup. Dette betyr at hvis aria-labelledby brukes sammen etikett for = "", vil aria-labelledby forrang. Etiketten elementet er fortsatt oppmuntret for eldre nettlesere som ikke forstår ARIA. En enkel teknikk for å unngå sammenstøt er å bruke aria-labelledby attributt å referere til en etikett - dette sikrer etiketten er tilgjengelig, uavhengig av ARIA støtte. <label id="lblef" for="effectiveness">Effectiveness</label> <input type="image" role="slider" id="effectiveness" aria-labelledby="lblef" ...> Ser gjennom hele listen over stater og egenskaper for å se hvordan ARIA kan hjelpe deg å sikre at innholdet er mer tilgjengelig.

Alle sammen nå

HTML ble opprinnelig laget for å lage web-applikasjoner, men utviklerne har skapt dem ved å tegne sine egne widgets, og legge atferd med JavaScript. Problemet er at rollen, stat og egenskaper widgets og oppdatert innhold på disse sidene ikke blir formidlet riktig å hjelpeteknologier. ARIA spesifikasjonen løser disse problemene ved å la utviklere å beskrive ting i detalj, definere dokumentstruktur, og definere områder av siden som vil forandre. Enten du utvikler fullverdig web-applikasjoner med komplekse widgets og live seksjoner, eller om du har den enkleste av nettsteder, kan du begynne å bruke ARIA nå til fordel brukere med nedsatt funksjonsevne.

Videre Reading

  Oversatt s http://dev.opera.com/articles/view/introduction-to-wai-aria/ Hjemmeside
Globe Views

Copyright™ 2014: «QRATOR Creative Technologies»