HTML5, ARIA Vaidmenis ir Ekrano Skaitytuvus į Gali 2010

Išversta su http://accessibleculture.org/articles/2010/05/html5-aria/

Pastaba: Atnaujintos tyrimų ir rezultatų už Kovo 2011.

Yra gerų, naudingų pavyzdžių ir dirbti ten jau rodo, kaip kai kurie ekrano skaitytuvus, kovoti su įvairių HTML5 projektuoja ir ARIA vaidmenis. Aš žinau, specifikacija yra ne gatavų dar, ir pagalbinių technologijų pardavėjai visada su juo dirbti, bet aš norėjau pažaisti šiek tiek ir patvirtinti sau, kaip kai kurie iš pirmaujančių ekrano skaitytojų Windows, būtent JAWS 11, Window-Eyes 7.11, NVDA 2010.1, ir SAToGo 3.0.202, šiuo metu dirbti pagrindinį HTML5 sectioning elementų, taip pat ARIA orientyrą ir kitus vaidmenis. Buvo teigiama pasiūlė kad kol naršyklėmis ekrano skaitytojai, visiškai palaiko HTML5 elementų ir jų numanomas ARIA vaidmenis, mes turėtų būti aiškiai papildantis tam tikrus HTML5 elementus ir su jais susijusių ARIA vaidmenis.

Atnaujinti: Rezultatai VoiceOver į MacOS X Snow Leopard su Safari 4.0.3 pridėta. — Gali 07, 2010.

Bandymų Atvejus

Pirmasis išbandymas naudoja tik HTML5 elementų, visų pirma:

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

Antrojo bandymo atveju taip pat taikomas ir toliau ARIA vaidmenys:

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

Aš išbandyti su keturių ekrano skaitytuvus, naudojant Internet Explorer 8 ir Firefox 3.6.

Pastaba: Priklausomai nuo ekrano skaitytuvu ir naršyklės derinys jums naudoti, vidaus puslapio nuorodos bandymo atvejais, ypač tikslus, kurie yra paprasta pozicijose suidatributas, gali ar negali tinkamai nustatyti fokusavimą ir atnaujinti poziciją TAB tvarka. Tai yra problema, pakankamai gerai dokumentuota, ypač naršyklėmis ekrano skaitytojai, nesusiję naudoti HTML5 ir ARIA vaidmenis. Jis gali būti įvairiai sumažinti pridedant tabindex="-1"ir/arba naudojant faktinius a elementai įvairiais būdais vietoj, bet tai dėl skirtingų bandymų atvejus.

Rezultatai

Trumpai, NVDA nėra labai gerai su HTML5 ir HTML5 su ARIA vaidmenis bandymo atvejais, nesvarbu, ar ji yra IE8 arba FF3.6. Navigacija, skaito, bendrauja su HTML5 žymėjimo ir ARIA paminklų yra tiesiog paprastas. Tiek daug, kad ji nėra orderį, taip pat jį bandymų rezultatai: pakanka pasakyti, kad NVDA uolų.

JAWS veikia gerai, nors ir FF3.6 neatrodo kaip navelementas įdėtos per header. Dabar, bent, tai gali būti protinga išvengti lizdus nav elementai, headerelementai. Update (Rugpjūtis 27, 2010): Žiūrėti komentaras #3 Terrill Thompson žemiau. Deja, JAWS 11 Firefox 3.6 neleidžia elgtis gerai suheader elementas, bet įgyvendinimą.

SAToGo taip pat nėra gerai, ir dabar net leidžia navigacijos pagal ARIA žymus objektas, nors tai nėra automatiškai pranešti, tipą, orientyras, kaip jis ateina visoje. Ir aš galėtų gauti tik naršyti orientyrą viena kryptimi, IE8 o FF3.6, galėčiau vykti į abi next ir previous orientyrą paspausdami ir Shift ; atitinkamai. Atnaujinimas: Naujas rezultatai SAToGo versija 3.1.24, Gegužės 21, 2010.

Window-Eyes 7.11, kita vertus, ir tai yra vienas dalykas, mes jau žinojau, nepripažįsta ARIA vaidmenis, ne visi. Be to, Window-Eyes tik atrodo, kad balk IE8, kai jis ateina į HTML5 ir ARIA vaidmenis naudojama kartu: “Browse Mode” jis negali rasti jokių nuorodų per HTML5 sectioning elementas, kuris taip pat turi ARIA vaidmenį. Jei jūs savo ruožtu “Browse Mode” išjungta, ji rasti visas nuorodas, bet tai reiškia, jums reikės pastoviai kaitalioti “Browse Mode” nuo ir kad iš tikrųjų skaityti ir naudoti puslapį.

Kai kurie papildomi greitai bandymų aš parodė, kad IE8, Window-Eyes neturi problemų ieškant sąsajų su paprastadiv, kad taip pat han ARIA vaidmenį, arba per HTML5 sectioning elementas su no ARIA vaidmenį, tačiau sujungti du ir Window-Eyes IE8 tiesiog pasimes. Tai patvirtina, pavyzdžiui, Bruce Lawson interneto svetainę, kuri leidžia gerai išnaudoti HTML5 ir ARIA. Jei norite aplankyti Bruce svetainės Window-Eyes ir IE8, nė vienas iš šių nuorodų headerarba #sidebar navyra rasti, nes abu šie HTML5 elementų, taip pat turi ARIA vaidmenis įgyvendinti. Bet nėra problemų su nuorodomis pagrindinio turinio erdvę, net jeigu ji turirole="main", nes jis tiesiog naudoja reguliariaidiv. Jei jis naudojamassectionelementas, vietoj to, dauguma nuorodų puslapyje būtų tiesiog išnyksta Window-Eyes IE8.

O aš neturiu numerius, kad įrodytų, aš pav, kad dauguma Window-Eyes vartotojai paleisti Internet Explorer o ne Firefox, todėl tai gali būti priežastis, kad būtų išvengta naudojant HTML5 ir ARIA vaidmenis, kartu metu, priklausomai nuo to, kaip jūs manote apie maitinimo Window-Eyes vartotojai su IE8. Ji bus įdomu pamatyti, kaip ką pakeisti, kai IE9 ir Window-Eyes 8.

Išsamesni tyrimo rezultatai yra žemiau. Jei nenurodyta kitaip, ekrano skaitytuvą atliktas, nes vienas gali tikėtis ir tikėtis, naudingasis patirtis.

Atnaujinti #1 (Birželis 30, 2010): Atrodo, kad netroleelementą, kurio vaidmuo požymis per tėvų HTML5 sectioning elementas panašiai sukelia problemų Window-Eyes. Pavyzdžiui, saitai perulsurole="navigation"sudėlioti viduje tėvųnavelementas nebus rasta Window-Eyes.

Atnaujinti #2 (Liepos 5, 2010): Kita vertus, ir įdomu tai, lizdus yra HTML5 elementų vidujedivsu ARIA roleneatrodo, kad sukelti problemų Window-Eyes. Pavyzdžiui, nuorodos įnavelementas, kuris yra įdėtos perdivsurole="navigation"yra vis dar rasti Window-Eyes. Taigi, tai, dabar, tikriausiai, geriausias būdas naudoti HTML5 elementus ir ARIA orientyrą vaidmenis, kartu nedarant neigiamos įtakos Window-Eyes vartotojai.

Atnaujinti #3 (Liepos 7, 2010): Su naujausia update Window-Eyes 7.2, sąsajų su HTML5 elementų, kurie ARIA orientyrąroleyra dabar rasti ir naudoti. Deja, lizdus, bent jau kai semantinės HTML 4 elementų, kurių rolepožymis per tėvų HTML5 sectioning elementas vis dar sukelia problemų Window-Eyes 7.2. Tai yra, saitai perulsurole="navigation"sudėlioti viduje tėvųnavelementas, pavyzdžiui, vis dar nerastas ir baustinas naudojant šį naujausią versiją Window-Eyes.

Atnaujinti #4 (Liepos 21, 2010): Manau, kad pavyko padaryti tai, ko šiek tiek klaidina, šiuo metu, todėl prisiminkime: Internet Explorer 8, Window-Eyes versijos 7.2 ir žemiau, kai į įprastą Naršymo Režimą, turi tam tikrų problemų, ieškant ir naudojant nuorodas į turinį, kai ARIAroleyra naudojama kartu su HTML5 sectioning elementai tam tikrų priemonių. Naudojant nuorodas į HTML5 elementas su ARIArolepožymis yra problema su Window-Eyes 7.11 ir toliau. Tai ne problema Window-Eyes 7.2, bet su versija 7.2 ten jis išlieka problema su bent nenumeruotas ir užsisakyti sąrašus, ir galbūt kai kurių kitų elementų, taip pat, kad turi ARIAroletaikomos. Nei Window-Eyes 7.11, nei 7.2 gali naudoti nuorodas įulelementą, kuriorole="navigation", nesvarbu, ar ji yra, ar nėra įdėtos per gtv elementas. Tas pats pasakytina ir, pavyzdžiui, už nuorodas perolelementas surole="contentinfo". (Šį Window-Eyes klaidą pat pasireiškia tam tikra Firefox 3.6). Tačiau, lizdų su HTML5 elementų bendrajamedivsu ARIArole, arba atvirkščiai-guoliams div su ARIAroleper HTML5 elementas, neatrodo, kad sukelti problemų Window-Eyes. Taip, pavyzdžiui, vienas gali wrap savonavelementas su<div role="navigation">arba, alternatyviai, wrap vidaus turinys  nav į divsu ARIArole. Pavyzdžiai šių įvairių priemonių galima rasti šį specialių bandymų puslapyje Window-Eyes.

HTML5 Tik Bandymas Atveju

JAWS 11

IE8

  • jokių akivaizdžių problemų ar klausimų

FF3.6

  • nemėgstanavperheaderelementas: įkeliant puslapį, JAWS šokinėja kažkur žemiau antraštės ir pradeda skaityti, dažnai h1 arba “Pirmame Skyriuje” vidaus puslapio nuorodą; ir gtv nuorodos vidujeheadernėra rodomi JAWS ryšius sąrašą
  • gali spauskite klavišą TAB pasiekti kiekvieną nuorodą, bet, VirtualPC Žymeklį režimu,headerper antraštes, kai pasirinkta klaviatūra, registruoti ir veikia kaip kokia saito neheaderanksčiau buvo dėmesio (pvz., dažnai “Pirmąjį Skyrių” vidaus puslapio nuorodą per “pagrindinis” section)
  • su VirtualPC Žymeklį režimas išjungtas, headerantraštės dirbti gerai per klaviatūrą
  • nuorodosheader, atrodo, dirbti gerai, kai pasirinkti su pele, ar VirtualPC
  • Žymeklį režimas yra įjungtas ar išjungtas
    headerne antraštės yra visų pripažintas ir tinkamai veiktų

Window-Eyes 7.11

IE8 ir FF3.6

  • jokių akivaizdžių problemų ar klausimų

SAToGo 3.0.202

IE8 ir FF3.6

  • jokių akivaizdžių problemų ar klausimų

VoiceOver

Safari 4.0.3

  • jokių akivaizdžių problemų ar klausimų
HTML5 + ARIA Vaidmenis Bandymo Atveju

JAWS 11

IE8

  • pats kaip HTML5 Tik versija, išskyrus tuos atvejus,
  • visi ARIA orientyrai yra rasti ir laivybai
  • taip pat manorole="article"orientyrą

FF3.6

  • pačius klausimus, navgtvheaderkaip HTML5 Tik versija
  • visi ARIA orientyrai yra rasti ir laivybai, išskyrusnavigationARIA orientyrą įdėtos perheader
  • taip pat mano role="article"orientyrą

Window-Eyes 7.11

IE8

  • ne ARIA orientyrai rasti
  • nėra jokių ryšių rasti, nes puslapis trys pagrindinės dalys, naudoti HTML5 elementus, kartu su ARIA vaidmenys
  • antraštės, headerkuriųrole="banner",  sectionsu role="main", ir  footersurole="contentinfo"yra kiekvieno pripažintas kontrolę (pvz., jie gali būti pasiekiami paspaudus ) ir  TAB  užsakymo

FF3.6

  • ne ARIA orientyrai rasti
  • visos nuorodos yra nustatyta, kad, skirtingai nei IE8
  • header,  section, kuriame  role="main", ir  footerne pripažįstami, kaip kontroliuoja, kaip jie IE8

SAToGo 3.0.202

IE8

  • visi ARIA orientyrai yra rasti ir laivybai, bet tik viena kryptimi (paspaudus  ; kitas orientyras), ir tipo orientyrą vaidmuo nėra paskelbta

FF3.6

  • visi ARIA orientyrai yra rasti ir laivybai, į abi puses (paspaudus;ir Shift+;), bet tipo orientyrą vaidmuo nėra paskelbta

SAToGo 3.1.24 (Gegužės 21, 2010)

IE8

  • nors ši versija SAToGo dabar leidžia navigacijos pagal ARIA orientyrą, į abi puses IE8 (paspaudus ; ir Shift+;), tai nebėra manocomplementary orientyras vaidmenį
  • tipas orientyrą vaidmenį dar nepaskelbtus

FF3.6

  • SAToGo vis dar randa visus orientyrus, leidžia navigacijos abiem kryptimis, ir tipo orientyrą vaidmenį dar nepaskelbtus

VoiceOver

Safari 4.0.3

  • ne ARIA orientyrai rasti

Šios svetainės turinys yra licencijuotas pagal Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.

 

Grįžti į pagrindinį

Leave a Reply

Your email address will not be published. Required fields are marked *