WAI-ARIA-spesifikaatiota ylläpitää W3C:n Accessible Rich Internet Applications Working Group. Ensimmäisestä versiosta, ARIA 1.0:sta, tuli W3C-suositus vuonna 2014; ARIA 1.1 seurasi vuonna 2017, ja ARIA 1.2 saavutti suosituksen tilan vuonna 2023. Rooleja, tiloja ja ominaisuuksia lisättiin jokaisessa versiossa, ja jokainen on linkitetty luontikäytäntödokumenttiin, joka kuvaa näppäimistön odotettua toimintaa.

Aiheeseen liittyvä: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 horas.

Keskeinen ero erottaa roolit kahdesta muusta ARIA-luokasta. Roolit vastaavat: “Mikä tämä on?” Tilat ja ominaisuudet vastaavat: “Missä kunnossa se on?” ja “Mihin se liittyy?” role="checkbox" ilmoittaa widgetin tyypin; aria-checked="true" osoittaa sen nykyisen tilan. Näiden kahden sekoittaminen on yksi yleisimmistä rikkoutuneiden mukautettujen widgetien syistä.

Kuusi rooliluokkaa

ARIA-roolien ymmärtämiseksi on hyödyllistä tietää, että ARIA-spesifikaatio ryhmittelee roolit kuuteen perheeseen. Perheen ymmärtäminen antaa sinun ennustaa, mitä tiloja ja ominaisuuksia rooli tukee ja mitä näppäimistökuvioita sovelletaan.

Abstrakteja rooleja käytetään vain taksonomian järjestämiseen. Tekijät eivät saa koskaan kirjoittaa role="widget" tai role="input" merkintöihin; tämä johtaa määrittelemättömään toimintaan ja validointi epäonnistuu. Loput viisi luokkaa ovat niitä, joita todella haet.

Katsomisen arvoinen: AudioEye — Accesibilidad gestionada: automatización combinada con revisión humana.

Implisiittiset roolit ja ARIAn ensimmäinen sääntö

Jokaisella HTML-elementillä on implisiittinen ARIA-funktio (joka selittää, mitkä ovat aria-roolit), jotka on määritetty HTML Accessibility API Mapping (AAM) -määrityksen mukaan. <nav>-elementillä on implisiittinen role="navigation". <ul> sisältää implisiittisen role="list". Kohdissa "

" - "

" on “role=“heading"". on rooli “taulukko”.

Ensimmäinen W3C-sääntö ARIA:n käytöstä sanoo selvästi: Jos natiivi HTML-elementti tai -attribuutti välittää jo vaaditun semantiikan ja käyttäytymisen, käytä sitä sen sijaan, että käyttäisit elementtiä uudelleen ARIA:n kanssa. Role=“button”-tunnisteen lisääminen ""-kohtaan ei ole välttämätöntä. Vielä pahempaa on, että jos lisäät role="button"-tunnisteen <div>-kohtaan, saat ilmoituksen, mutta ei toimintaa: ei kohdistusta, ei näppäimistön aktivointia, ei lomakkeiden lähetystä.

Ver axe DevTools Pro

Redundanssi ei ole aina vaaratonta. Implisiittisen roolin ohittaminen voi menettää semantiikan, josta avustava tekniikka riippuu. role="presentation":n kirjoittaminen ` eliminoi täysin taulukon semantiikan, mikä on joskus tarkoituksellista asettelutaulukoiden kanssa, mutta tuhoisaa datataulukoiden kanssa.

Kuinka roolit ovat vuorovaikutuksessa valtioiden ja ominaisuuksien kanssa

Roolit toimivat kontteina tukemilleen tileille ja ominaisuuksille. Määritykset määrittelevät, mitkä attribuutit ovat kelvollisia millekin rooleille, ja selaimet paljastavat vain tuetut yhdistelmät esteettömyyspuussa.

Aariaroolien ymmärtäminen auttaa tietämään, että “role=“checkbox” tukee “aria-checked” -arvoa arvoilla “true”, “false” tai “mixed”. Role=“slider” tukee parametreja “aria-valuenow”, “aria-valuemin”, “aria-valuemax” ja valinnaisesti “aria-valuetext”. Role=“combobox” tukee muotoja “aria-expanded”, “aria-controls” ja “aria-activedescendant”. “Aria-checked”-tunnisteen käyttäminen “role=“button"" on merkityksetön, ja se jätetään huomiotta tai tuottaa hämmentäviä tuloksia joissakin näytönlukuohjelmissa.

Aiheeseen liittyvä: IAAP CPACC / WAS Certification — La Certificación profesional que acredita tu experiencia en accesibilidad.

Myös vaadittavat ominaisuudet ovat tärkeitä. Role=“checkbox” ilman “aria-checked” on virheellinen; valtio on pakollinen eikä valinnainen. Role=“slider” ilman “aria-valuenow”-merkkiä estää käyttäjää määrittämään nykyistä arvoa. ARIA-spesifikaatioissa ne merkitään “pakollisiksi tiloiksi ja ominaisuuksiksi”, ja vaatimustenmukaisuuden tarkistimet, kuten axe-core ja IBM Equal Access Accessibility Checker, osoittavat niiden puuttumisen.

Roolit, esteettömyyspuu ja selaimen tuki

Selaimet kääntävät ARIA-toiminnot alustan saavutettavuuden sovellusliittymiksi (UIA Windowsissa, AXAPI macOS:ssä, ATK/AT-SPI Linuxissa), ja näytönlukuohjelmat käyttävät näitä sovellusliittymiä. Rooli, jota mikään selain ei määritä oikein, on käytännössä näkymätön käyttäjille.

Tuki vaihtelee ominaisuuden ja selaimen mukaan. Ydintoimintoja, kuten “painike”, “linkki”, “otsikko”, “luettelo” ja “navigointi”, tuetaan yleisesti. Uudemmilla tai erikoistuneemmilla rooleilla (“syöte”, “matematiikka”, “doc-footnote” Digital Publishingin WAI-ARIA-moduulista) on hajanaisempi tuki. Rooli=“switch” on tuettu nykyaikaisissa selaimissa, mutta siitä ilmoitettiin epäjohdonmukaisesti vuosikymmen sitten.

Katsomisen arvoinen: UserWay — Widget de accesibilidad con plan gratuito para empezar hoy mismo.

Yleisön käyttämien todellisten yhdistelmien testaus on edelleen välttämätöntä. Widget, joka toimii NVDA:ssa Firefoxin kanssa, voi toimia eri tavalla VoiceOverissa ja Safarilla, koska nämä kaksi näytönlukuohjelmaa kuluttavat eri alustan sovellusliittymiä ja käyttävät eri heuristiikkaa.

Maamerkkiroolit ja sivun rakenne

Maamerkkiroolien avulla näytönlukijat voivat siirtyä suoraan sivun alueille. Kahdeksan maamerkkiroolia ovat “banneri”, “täydentävä”, “sisältötiedot”, “lomake”, “pää”, “navigointi”, “alue” ja “haku”. Nykyaikaisessa HTML:ssä on natiivivastineet useimmille: <header> muuttuu banneriksi, <footer>:sta contentinfo, <main> muuttuu pääksi, <nav> muuttuu navigaatioksi, <aside> muuttuu täydentäväksi, <lomakkeesta> tulee muotoinen nimi, jolla on käytettävissä oleva nimi alue`.

Natiivielementtien käyttö on suositeltavaa, koska ne toimivat, vaikka CSS tai JavaScript epäonnistuisi, ja koska ne vähentävät rooli- ja attribuuttiristiriitojen riskiä. “Haku”-maamerkillä ei ole alkuperäistä HTML-vastinetta, joten “role=“search”’ on edelleen oikea valinta hakualueelle.

Yleinen virhe on käyttää “role=“banner”-tunnistetta "

"-tunnisteeseen, joka on "

"- tai "

" sisällä. Maamerkkiroolit luovat maamerkkejä vain, jos ne eivät ole sisäkkäisiä tiettyjen muiden roolejen sisällä. Main-kohdan sisällä olevaa “banneria” ei näytetä maamerkkinä ollenkaan. Sijainti DOM:ssa on yhtä tärkeä kuin roolin arvo. Niille, jotka ihmettelevät, mitä aariarooleja ovat, nämä maamerkit ovat keskeinen osa eritelmää.

Live-alueen roolit

Kun pohditaan, mitkä ovat ariaroolit, elävät alueelliset roolit ilmoittavat sisällön muutoksista painopistettä muuttamatta. Neljä live-alueen toimintoa ovat “hälytys”, “tila”, “loki” ja “ajastin” sekä yleisempi “marquee”. Kummassakin on implisiittisesti “aria-live” -arvo: “alert” ja “log” käytännössä tarkoittavat “assertive” ja “kohteliasta”, kun taas “status” tarkoittaa “kohteliasta”.

Valinta “hälytys” ja “tila” välillä on suunnittelupäätös, jolla on todellisia seurauksia. “Hälytys” pysäyttää näytönlukijan lukeman sisällön, mikä sopii virheille ja kiireellisille ilmoituksille, mutta on haitallista, jos sitä käytetään liikaa. “Tila” odottaa taukoa, joka on sama kuin edistymisviestit ja vahvistustekstit.

Live-alueiden on oltava DOM:ssa, ennen kuin sisältö muuttuu. Role=“alert”-elementin ja sen tekstin lisääminen samanaikaisesti johtaa usein ilmoituksen puuttumiseen, koska aluetta ei ollut olemassa muutoksen aikaan. Luotettava malli on renderöidä tyhjä live-alue sivun latauksen yhteydessä ja päivittää sen tekstisisältö myöhemmin.

Milloin ARIA-rooleja EI saa käyttää

Toinen ARIA:n käytön sääntö on, että tekijöiden ei tule muuttaa alkuperäistä semantiikkaa, ellei heidän ole todella tarvetta. Viides sääntö sanoo, että jokaisen interaktiivisen elementin, riippumatta sen toiminnasta, on oltava saavutettavissa ja tarkennettavissa näppäimistön kautta.

Roolin lisääminen ei lisää käyttäytymistä. role="button" <div>:ssa aiheuttaa sen, että se ei tarkenna, ei vastaa syöttöön tai välilyöntiin eikä lähetä lomaketta. Sinun on lisättävä tabindex="0", näppäinpainalluksen käsittelijä syöttöä ja tilaa varten ja usein “rooliin sopiva” tilanhallinta. Tässä vaiheessa oikean "" käyttäminen vaatii vähemmän koodia ja vähemmän virheitä.

Jotkut roolit ovat aktiivisesti haitallisia, jos niitä käytetään väärin. role="presentation" ja role="none" poistavat semantiikan elementistä ja joissakin toteutuksissa sen vaadituista jälkeläisistä. Role=“application”:n käyttäminen siirtää näytönlukijat tilaan, jossa ne lopettavat näppäinpainallusten sieppaamisen, mikä voi loukuttaa käyttäjiä, jos mukautettu näppäimistön käsittely on epätäydellinen.

Päätöskehys roolien valinnassa

Lyhyen sarjan käsittely estää useimmat ARIA-roolivirheet. Jos haluat ymmärtää, mitä ARIA-roolit ovat ja miten niitä käytetään, toimi seuraavasti:

1. Tunnista widget tai alue. Nimeä, mikä elementti todella on selkeällä kielellä.
2. Tarkista natiivi HTML-vastine. Katso HTML-AAM-kartoitus. Jos <button>, <select>, <details> tai <dialog> sopii, käytä sitä.
3. Jos mikään natiivielementti ei sovi, valitse lähin ARIA-rooli. Varmista, että se on olemassa nykyisessä määrityksessä eikä se ole abstrakti.
4. Lisää vaaditut tilat ja ominaisuudet. Tarkista roolin määrittely pakollisten määritteiden varalta.
5. Ota käyttöön näppäimistön vuorovaikutuskuvio. Noudata widget-tyypin WAI-ARIA Authoring Practices Guide -ohjetta.
6. Testaa vähintään kahdella näytönluku- ja selainyhdistelmällä. Tarkista ilmoitukset, tilat ja näppäimistön toiminta.

Useimmat mukautetun widgetin virheet tapahtuvat vaiheissa 3–6. Näppäimistökuvion ohittaminen vaiheessa viisi luo widgetin, joka mainostaa oikein, mutta ei toimi, mikä on luultavasti pahempaa kuin ilman ARIAa ollenkaan.

Testaus- ja validointityökalut

Automaattiset työkalut havaitsevat rakenteelliset virheet: virheelliset rooliarvot, puuttuvat vaaditut ominaisuudet ja roolit, jotka on asetettu elementteihin, jotka eivät tue niitä. axe-core, monien selainlaajennusten takana oleva moottori, tarkistaa määritellyn ARIA-sääntöjen osajoukon. IBM Equal Access Accessibility Checker ja W3C:n oma Nu HTML Checker osoittavat myös roolien väärinkäyttöä.

Automaattiset työkalut eivät voi varmistaa, tuottaako rooli oikean ilmoituksen tai toimiiko näppäimistön vuorovaikutus. Manuaalinen testaus NVDA:lla ja Firefoxilla, JAWSilla ja Chromella tai VoiceOverilla ja Safarilla vaaditaan edelleen. Accessibility Insights for Web -laajennus yhdistää automaattiset tarkistukset ohjattuun manuaaliseen arviointiin, joka sisältää näppäimistön ja näytönlukijan vahvistuksen.

Itse ARIA-spesifikaatio, WAI-ARIA Authoring Practices Guide ja HTML-AAM-kartoitusdokumentti ovat arvovaltaisia ​​viitteitä ariarooleille. MDN Web Docs ARIA Reference on kätevä ja hyvin valittu toissijainen lähde, joka viittaa kunkin roolin spesifikaatioihin.

Keskeiset opit

• ARIA-roolit ilmoittavat, mikä elementti on; WAI-ARIA 1.2 määrittelee 87 roolia kuuteen kategoriaan, ja abstrakteja rooleja ei ehkä koskaan näy merkinnöissä.
• Natiivit HTML-elementit sisältävät implisiittisiä rooleja ja sisäänrakennettuja käyttäytymismalleja, joten ensimmäinen sääntö ARIAa käytettäessä on suosia niitä “div” plus “role” sijaan.
• Roolit vaativat niiden tuetut tilat ja ominaisuudet: “role=“checkbox"" ilman “aria-checked” on virheellinen eikä sitä voi käyttää.
• Roolin lisääminen ei koskaan lisää näppäimistön käyttäytymistä tai tarkennettavuutta; nämä on otettava käyttöön ja testattava erikseen.
• Maamerkki- ja Live Region -rooleilla on sijainti- ja ajoitussäännöt, jotka määrittävät, toimivatko ne vai eivät.
• Automaattiset tarkastajat havaitsevat vain rakenteelliset virheet; näytönlukuohjelmien testaus eri selainyhdistelmille on edelleen tarpeen.

Ymmärtääksesi, mitä ARIA-roolit ovat, muista, että ne määrittelevät aputekniikan elementin tarkoituksen.

Lähteet ja lisälukemista

• WAI-ARIA – Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) on World Wide Web Consortiumin (W3C) julkaisema tekninen eritelmä, joka…

Usein kysyttyjä kysymyksiä

Mitä ovat ARIA-roolit yksinkertaisesti sanottuna?

ARIA-roolit ovat tunnisteita, jotka liitetään HTML-elementteihin kertomaan aputeknologialle, mitä elementti edustaa. <div role="button"> ilmoitetaan painikkeena yleisen tekstin sijaan. Roolit tarjoavat, mikä tarkoittaa, että taustalla oleva tagi ei tarjoa, mutta ne eivät lisää käyttäytymistä, tarkennuksen käsittelyä tai näppäimistötukea yksinään.

Mitä eroa on ARIA-rooleilla ja ARIA-määritteillä?

Roolit kuvaavat elementin tyyppiä, kun taas attribuutit kuvaavat sen tilaa, arvoa tai suhteita. role="slider" tunnistaa liukusäätimen; aria-valuenow="50" ilmoittaa nykyisen sijaintinsa ja aria-labelledby osoittaa sen nimiöön. Rooleja ja attribuutteja käytetään yhdessä, ja jokainen rooli määrittelee, mitä attribuutteja se tukee.

Kuinka monta ARIA-roolia on?

WAI-ARIA 1.2 määrittelee 87 roolia, jotka on ryhmitelty kuuteen luokkaan: abstrakti, widget, asiakirjarakenne, maamerkki, elävä alue ja ikkuna. Abstraktit roolit, kuten widget ja input, ovat olemassa vain määrityksen sisäisessä taksonomiassa, eikä niitä koskaan tule kirjoittaa HTML-kielellä. Määrä kasvaa jokaisen spesifikaatiopäivityksen myötä.

Pitäisikö minun käyttää ARIA-rooleja semanttisen HTML:n sijaan?

Ei. ARIA-käytön ensimmäinen sääntö sanoo, että kannattaa suosia natiivia HTML-elementtiä aina, kun sellainen on olemassa vaaditulla semantiikkalla ja käyttäytymisellä. Käytä <button> <div role="button"> sijaan ja <nav> <div role="navigation"> sijaan. ARIA-roolit ovat varavaihtoehto tapauksiin, joissa ei ole sopivaa natiivia elementtiä.

Toimivatko ARIA-roolit kaikissa selaimissa ja näytönlukuohjelmissa?

Nykyaikaiset selaimet ja näytönlukuohjelmat tukevat luotettavasti ydinrooleja, kuten button, link, heading ja navigation. Uudemmat tai erikoistuneemmat roolit, mukaan lukien Digital Publishing -moduulin roolit, tarjoavat vaihtelevampaa tukea. Voit olla varma vain testaamalla yleisösi käyttämillä selaimen ja näytönlukuohjelman yhdistelmillä.

Voiko ARIA-roolin lisääminen heikentää saavutettavuutta?

Kyllä. Implisiittisen roolin ohittaminen voi menettää hyödyllisen semantiikan, esimerkiksi silloin, kun role="presentation" käytetään tietotaulukkoon. role="application":n käyttäminen voi estää käyttäjiä, jos mukautettu näppäimistön käsittely on epätäydellinen. Ylimääräiset roolit natiiveissa elementeissä aiheuttavat tarpeetonta melua ja johtavat toisinaan ristiriitaisiin ilmoituksiin.