HTML5, ARIA Roller og Skjermlesere i Mai 2010

On By admin

Original English version: http://accessibleculture.org/articles/2010/05/html5-aria/

Det er noen gode, nyttige eksempler og jobbe der ute allerede viser hvordan noen skjermlesere håndtere ulike HTML5 konstruksjoner og ARIA roller. Jeg vet specs er ikke ferdig ennå, og hjelpemidler teknologileverandører er alltid jobber med det, men jeg ønsket å spille litt rundt og bekrefte for meg selv hvordan noen av de ledende skjermlesere for Windows, nemlig JAWS 11, Windoweyes 7.11, NVDA 2010.1, og SAToGo 3.0.202, håndtak for tiden grunn HTML5 snitteelementer så vel som Aria av fjell og andre roller. Det har blitt foreslått at inntil nettlesere og skjermlesere full støtte HTML5 elementer og deres implisitte ARIA roller, bør vi være eksplisitt supplere visse HTML5 elementer med tilhørende ARIA roller.

Oppdater: Resultater for Voiceover i MacOS X Snow Leopard med Safari 4.0.3 lagt til. -Kan 07, 2010

Testtilfeller

Den første test anvender bare de HTML5 elementer, spesielt:

  • header
  • nav
  • section
  • article
  • aside
  • footer

Den andre testen tilfelle gjelder også de følgende Aria roller:

  • banner
  • navigation
  • main
  • article
  • complementary
  • contentinfo

Jeg testet med de fire skjermlesere bruker både Internet Explorer 8 og Firefox 3.6.

Merk:  Avhengig av skjermleser og nettleser kombinasjon du bruker, interne sider har lenker innenfor testtilfeller, særlig de med mål som er enkle overskrifter med enid attributt, kan eller ikke riktig satt fokus og oppdatere posisjonen i  TAB orden. Dette er et problem, godt nok dokumentert, med bestemte nettlesere og skjermlesere, og uten tilknytning til bruk av HTML5 og ARIA roller. Det kan være forskjellig reduseres ved å legge til  tabindex="-1" og/eller bruke faktiske  a elementer på forskjellige måter i stedet, men det er for et annet sett med testtilfeller.

Resultatene

Kort fortalt gjør NVDA godt med HTML5 og HTML5 med ARIA roller teste tilfeller, enten det er i IE8 eller FF3.6. Navigere, lesing, og i samspill med markup og ARIA landemerker HTML5 er bare grei. Så mye at den ikke garanterer inkludert den i testresultatene: Det er nok å si at NVDA bergarter.

JAWS gjør det bra, men i FF3.6 ser det ikke ut til å like et  nav element nestet i en header. For nå, minst, kan det være fornuftig å unngå hekke  nav elementer innen  header elementer. Update (27 august 2010): Se kommentar # 3 av Terrill Thompson nedenfor. Dessverre gjør JAWS 11 i Firefox 3.6 ikke håndtere godt med  header element i enhver implementering.

SAToGo gjør også greit, og nå enda gjør navigering av ARIA landemerke, selv om den ikke automatisk kunn type landemerke som den kommer over det. Og jeg kunne bare få det til å navigere etter landemerker i én retning i IE8, mens i FF3.6, kunne jeg gå til både den neste og forrige landemerke ved å trykke på  ; og  Shift+ ; hhv. Oppdatering: Nye resultater for SAToGo versjon 3.1.24, 21 mai 2010.

Windoweyes 7.11, på den annen side, og dette er en ting vi allerede visste, ikke gjenkjenner ARIA roller i det hele tatt. Videre synes Windoweyes bare for å vike i IE8 når det kommer til HTML5 og ARIA roller blir brukt sammen: i “Browse Mode” det kan ikke finne noen linker i en HTML5 seksjonering element som også har en ARIA rolle. Hvis du slår på “Browse Mode” av, gjør det finne alle linkene, men dette betyr at du må stadig skifte “Browse Mode” av og på å faktisk lese og bruke siden.

Noen ekstra rask testing jeg gjorde viste at i IE8, har ingen problemer med å finne linker i en enkel Windoweyes div som også Han en ARIA rolle, eller innenfor en HTML5 seksjonering element uten ARIA rolle, men kombinerer de to, og Windoweyes i IE8 nettopp blir tapt. Dette er bekreftet, for eksempel ved Bruce Lawson nettsted, noe som gjør god bruk av HTML5 og ARIA. Hvis du besøker Bruce nettsted med Window-Eyes og IE8, ingen av lenkene i header eller #sidebar  nav er funnet siden begge disse HTML5 elementer har også ARIA roller implementert. Men det er ingen problem med koblinger i hovedinnholdet området, selv om det har  role="main" siden den bare bruker en vanlig div. Hvis det brukes en sectionelement i stedet, de fleste av linkene på siden ville bare forsvinne for Windoweyes i IE8.

Selv om jeg ikke har tall som beviser det, jeg finne at et flertall av Windoweyes brukere kjører Internet Explorer i stedet for Firefox, så dette kan være en grunn til å unngå å bruke HTML5 og ARIA roller sammen for tiden, avhengig av hvor du føler om catering til Windoweyes brukere med IE8. Det vil være interessant å se hvordan ting endrer seg når IE9 og Windoweyes 8 er ute.

De mer detaljerte testresultater er nedenfor. Med mindre annet er angitt, utføres skjermleseren som man kunne håpe og forvente for en brukbar opplevelse.

Update # 1 (30 juni 2010):  Det synes at selv hekkende et element med et  role attributt i en overordnet HTML5 seksjonering element på samme måte skaper problemer for Windoweyes. For eksempel, koblinger i et  ul med  role="navigation" nestet inne i en overordnet  nav element ikke vil bli funnet ved vindus øyne.

Oppdater # 2 (05.07.2010):  På den annen side, og interessant, hekkende en HTML5 element inne i en  div med en ARIA  role ser ikke ut til å utløse problemet i Windoweyes. For eksempel, koblingene i et  nav element som er plassert inne i en  div med  role="navigation" fortsatt finnes ved vindus øyne. Så dette er, for nå, sannsynligvis den beste måten å bruke HTML5 elementer og ARIA landemerke roller sammen uten negativt påvirket Windoweyes brukere.

Update # 3 (7.7.2010):  Med den nyeste oppdateringen til Windoweyes 7.2, koblinger innenfor HTML5 elementer som har en arie landemerke  role er nå funnet og brukbare. Dessverre, nesting i det minste noen semantiske HTML-4-elementer med et  role attributt i en overordnet HTML5 seksjonerings element fremdeles skaper problemer for vindus øyne 7.2. Det vil si, koblinger innenfor et  ul med  role="navigation" nestet inne i en overordnet  nav element, for eksempel, er fortsatt ikke funnet og praktisk å bruke denne nyeste versjonen av Window-Eyes.

Update # 4 (21 juli 2010): Jeg tror jeg har klart å gjøre ting litt forvirrende på dette punktet, så la oss oppsummere: I Internet Explorer 8, Windoweyes versjoner 7.2 og under, når du er i normal Browse Mode, har noen problemer med å finne og ved hjelp av koblinger i innhold hvor Aria  roles brukes i forbindelse med HTML5 snitteelementer i visse arrangementer. Ved hjelp av koblinger i et HTML5 element med en arie  role attributtet er et problem med vindus-øyne 7.11 og nedenfor. Dette er ikke et problem med Windoweyes 7.2, men med versjon 7.2 er det ikke forbli et problem med minst uordnet og bestilte lister, og muligens noen andre elementer også, som har en ARIA  role brukt. Hverken Window-Øyne 7,11 nor 7,2 kan ved hjelp av koblingene i et  ul element med  role="navigation", hvorvidt eller ikke det er plassert inne i en nav element. Det samme gjelder for eksempel for koblinger innenfor et  ol element med  role="contentinfo". (Dette Windoweyes bug manifesterer også til en viss grad med Firefox 3.6). Men hekkende HTML5 element i en generisk  div med en ARIA  role, eller vice versa, hekkende en  div med ARIA  role innenfor en HTML5 element, synes ikke å forårsake et problem i Windoweyes. Så, for eksempel, kan man vikle sitt  navelement med  <div role="navigation"> eller, alternativt, vikle de interne innholdet av  nav i en  div med ARIA  role. Eksempler på disse forskjellige arrangementer kan bli funnet på denne spesielle testside for Windoweyes.

HTML5 Bare Test Case

JAWS 11

IE8
  • ingen åpenbare problemer eller problemer
FF3.6
  • liker ikke  nav innenfor  header element: På side belastning, hopper JAWS et sted under  header og begynner å lese, ofte  h1 eller “First Section” intern lenke; og  nav koblingene i den  header ikke dukker opp i JAWS’ linker liste
  • kan trykke på  TAB for å nå alle ledd, men i VirtualPC markørmodus, linkene innenfor  header, når valgt av tastatur, registrere og fungere som uansett adresse utenfor  headertidligere hadde fokus (f.eks, ofte “First Section” intern lenke innenfor  “main” section)
  • med VirtualPC markørmodus av, koblingene i  header fungerer fint via tastaturet
  • lenkene i header ser ut til å fungere fint når den er valgt med musen, enten VirtualPC markørmodus er på eller av
  • koblinger utenfor  header er alle anerkjent og fungere

Windoweyes 7.11

IE8 OG FF3.6
  • ingen åpenbare problemer eller problemer

SAToGo 3.0.202

IE8 OG FF3.6
  • ingen åpenbare problemer eller problemer

Voice

SAFARI 4.0.3
  • ingen åpenbare problemer eller problemer

HTML5 + ARIA Roller test

JAWS 11

IE8
  • samme som HTML5 eneste versjonen, bortsett fra at
  • alle landemerker ARIA er funnet og navigerbart
  • vurderer også  role="article" en fjell
FF3.6
  • samme problemene med  nav i  header som HTML5 Only versjon
  • alle landemerker ARIA er funnet og farbar, bortsett fra  navigation ARIA landemerke nestet innenfor header
  • vurderer også  role="article" en fjell

Windoweyes 7.11

IE8
  • ingen landemerker ARIA funnet
  • ingen linker funnet  fordi sidens tre hoveddeler bruke HTML5 elementer sammen med ARIA roller
  • den  header med role="banner"den  section med  role="main", og  footermed role="contentinfo" hver er anerkjent som kontroller (f.eks, de kan nås ved å trykke  C) og er i  TAB orden
FF3.6
  • ingen landemerker ARIA funnet
  • alle koblinger er funnet, i motsetning til i IE8
  • den  header, det  section med  role="main", og det  footer er ikke anerkjent som kontroller som de er i IE8

SAToGo 3.0.202

IE8
  • alle landemerker ARIA er funnet og farbar, men bare i én retning (ved å trykke  ; på neste landemerke), og den type landemerke rolle er ikke annonsert
FF3.6
  • alle landemerker ARIA er funnet og farbar i begge retninger (ved å trykke på  ; og  Shift+ ;), men den type landemerke rolle er ikke annonsert

SAToGo 3.1.24 (21 mai 2010)

IE8
  • mens denne versjonen av SAToGo nå tillater navigasjon ved Aria fjell i begge retninger i IE8 (ved å trykke  ; og  Shift+ ;), ikke lenger finner det i complementary fjell rolle
  • type landemerke rolle forblir uanmeldt
FF3.6
  • SAToGo finner fortsatt alle landemerker, gjør navigering i begge retninger, og den type landemerke rolle forblir uanmeldt

Voice

SAFARI 4.0.3
  • ingen landemerker ARIA funnet

 It is licenced under  Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License   http://creativecommons.org/licenses/by-nc-sa/3.0/.