Kehittäjän opas ARIA-nimiin, joista on oikeasti apua
ARIA-nimet eivät ole maaginen saavutettavuuskerros. Oikein käytettyinä ne tekevät ohjaimista ymmärrettäviä. Huolimattomasti käytettyinä ne piilottavat hyödyllistä tekstiä ja luovat sekavia käyttöliittymiä.
Sisällysluettelo
- ARIA-nimet ovat nimiä varten, eivät anteeksipyyntöjä
- Saavutettava nimi selkokielellä
- Ensimmäinen sääntö: suosi natiivia HTML:ää ja näkyviä nimiöitä
- Milloin `aria-label` on oikea työkalu
- Milloin `aria-label` on väärä työkalu
- Käytä `aria-labelledby`-attribuuttia, kun näkyvä teksti on jo olemassa
- Käytä `aria-describedby`-attribuuttia ohjetekstiin, älä nimeen
- Toistuvat ohjaimet tarvitsevat yksilölliset nimet
- Älä nimeä kaikkea
- Tarkista laskettu nimi, älä vain koodia
- Käytännön tarkistuslista katselmointiin
- Hyvän ARIAn hiljainen kuri
ARIA-nimet ovat nimiä varten, eivät anteeksipyyntöjä
ARIA on hyödyllinen, mutta sitä käytetään usein paikkauksena epäselvälle HTML:lle. Siinä kohtaa tiimit joutuvat vaikeuksiin.
Yleisin esimerkki on aria-label. Se näyttää harmittomalta: lisätään merkkijono, tyydytetään linteri ja jatketaan eteenpäin. Saavutettava nimi ei kuitenkaan ole koriste. Se on nimi, jonka monet apuvälineteknologiat näyttävät käyttäjille, kun he liikkuvat painikkeiden, linkkien, lomakekenttien, otsikoiden, maamerkkien ja ohjainten välillä.
Jos nimi on epämääräinen, toistuva, vanhentunut tai poikkeaa näkyvästä nimestä, käyttöliittymästä tulee vaikeampi käyttää. Joskus vielä pahempaa: aria-label voi ohittaa paremman tekstin, joka oli jo valmiiksi DOMissa.
Tavoitteena ei ole lisätä enemmän ARIAa. Tavoitteena on tehdä kunkin käyttöliittymäelementin nimi, rooli, tila ja tarkoitus selväksi.
Saavutettava nimi selkokielellä
Useimmilla interaktiivisilla elementeillä on saavutettava nimi. Ruudunlukijat käyttävät tätä nimeä ilmoittaakseen, mikä elementti on.
Esimerkiksi:
<button>Save changes</button>
Ruudunlukija voi ilmoittaa jotakin tämän tapaista: “Save changes, button.” Rooli tulee natiivista button-elementistä. Nimi tulee sen sisällä olevasta tekstistä.
Tämä on ihannetapaus: näkyvä teksti ja saavutettava nimi vastaavat toisiaan.
ARIA-nimeämisattribuutit ovat hyödyllisiä silloin, kun näkyvä käyttöliittymä ei anna täydellistä nimeä tai kun nimen täytyy tulla toisesta elementistä. Tärkeimmät attribuutit ovat:
aria-label: antaa merkkijonon suoraan elementille.aria-labelledby: viittaa yhteen tai useampaan elementtiin, joiden tekstistä tulee nimi.aria-describedby: viittaa tukevaan kuvaustekstiin, ei pääasialliseen nimeen.
Nämä kolme liittyvät toisiinsa, mutta eivät ole keskenään vaihdettavia.
Ensimmäinen sääntö: suosi natiivia HTML:ää ja näkyviä nimiöitä
Jos voit laittaa ohjaimeen näkyvää tekstiä, tee se ensin.
Tämä on parempi:
<button>Delete invoice</button>
Kuin tämä:
<button aria-label="Delete invoice">
<svg aria-hidden="true" focusable="false">...</svg>
</button>
Toinen malli on kelvollinen kuvakepainikkeelle. Mutta jos ulkoasu sietää näkyvän tekstin, näkyvä teksti auttaa kaikkia: ruudunlukijan käyttäjiä, puheentunnistuksen käyttäjiä, kognitiivisen kuormituksen kanssa toimivia ihmisiä, nopeasti silmäileviä ihmisiä ja käännöstyökaluja käyttäviä ihmisiä.
Tämä on toistuva teema saavutettavuustyössä. Natiivi HTML ja näkyvät affordanssit ratkaisevat enemmän ongelmia kuin piilotettu metadata. Sama periaate pätee painikesemantiikkaan laajemminkin; jos tiiminne auditoi käyttöliittymäohjaimia, saavutettavien verkkopainikkeiden tarkistuslistamme on hyvä rinnakkaislukemisto tälle oppaalle.
Milloin aria-label on oikea työkalu
Käytä aria-label-attribuuttia silloin, kun elementti tarvitsee saavutettavan nimen eikä viitattavaksi ole sopivaa näkyvää tekstiä.
Klassinen tapaus on pelkkä kuvakepainike:
<button aria-label="Search">
<svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
<!-- icon -->
</svg>
</button>
Tämä on järkevää. Näkyvä kuvake viittaa hakuun, mutta SVG-polku itsessään ei anna luotettavaa nimeä. aria-label antaa sellaisen.
Muita hyviä tapauksia ovat:
- Sulkemispainike, jota edustaa vain “X”.
- Navigaatiomaamerkki, joka tarvitsee tarkemman nimen, kuten
aria-label="Product". - Toistuva ohjain, jossa näkyvä konteksti ei ole osa painikkeen tekstiä.
Esimerkiksi:
<nav aria-label="Primary">
...
</nav>
<nav aria-label="Footer">
...
</nav>
Molemmat ovat navigaatiomaamerkkejä, mutta niiden nimet auttavat käyttäjiä erottamaan ne toisistaan maamerkkien välillä liikuttaessa.
Milloin aria-label on väärä työkalu
Älä lisää aria-label-attribuuttia vain siksi, että testi sanoo elementin tarvitsevan nimen. Korjaa merkkaus ensin.
Huono:
<div role="button" tabindex="0" aria-label="Submit">Submit</div>
Parempi:
<button>Submit</button>
Ensimmäinen esimerkki luo tarpeetonta työtä. Nyt sinun täytyy luoda uudelleen näppäimistökäyttäytyminen, poistetut tilat, lomakekäyttäytyminen ja odotukset, jotka natiivit painikkeet tarjoavat jo valmiiksi.
Vältä myös aria-label-attribuutin käyttämistä näkyvän tekstin uudelleennimeämiseen tavalla, joka muuttaa merkitystä.
<button aria-label="Delete invoice">Remove</button>
Tämä näyttää pieneltä asialta, mutta se voi hämmentää käyttäjiä, jotka tukeutuvat puhesyötteeseen. Jos näkyvässä painikkeessa lukee “Remove”, mutta sen saavutettava nimi on “Delete invoice”, käyttäjä, joka yrittää sanoa “click Remove”, ei välttämättä saa odotettua tulosta. WCAG:n “label in name” -vaatimus on olemassa juuri tästä syystä: näkyvän tekstin pitäisi yleensä sisältyä saavutettavaan nimeen.
Parempi versio:
<button aria-label="Remove invoice">Remove</button>
Usein vielä parempi:
<button>Remove invoice</button>
Käytä aria-labelledby-attribuuttia, kun näkyvä teksti on jo olemassa
Jos nimiteksti on jo sivulla, aria-labelledby on yleensä parempi kuin aria-label.
Esimerkki:
<h2 id="billing-title">Billing address</h2>
<section aria-labelledby="billing-title">
...
</section>
Osion saavutettava nimi tulee nyt näkyvästä otsikosta. Vältät merkkijonojen monistamista, mikä vähentää käännösvirheitä ja vanhentuneita nimiä.
Tämä on erityisen hyödyllistä lomakeryhmille:
<fieldset aria-labelledby="shipping-speed-title">
<legend id="shipping-speed-title">Shipping speed</legend>
<label>
<input type="radio" name="shipping" value="standard">
Standard
</label>
<label>
<input type="radio" name="shipping" value="express">
Express
</label>
</fieldset>
Monissa tapauksissa natiivi legend riittää ilman ARIAa. Olennaista on, että näkyvien nimiöiden pitäisi johtaa. ARIAn pitäisi yhdistää olemassa oleva merkitys, ei luoda siitä toista yksityistä versiota.
Käytä aria-describedby-attribuuttia ohjetekstiin, älä nimeen
Kuvaus ei ole nimiö.
Tarkastellaan tätä kenttää:
<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>
Saavutettava nimi on “Password.” Kuvaus on “Use at least 12 characters.” Ruudunlukija voi ilmoittaa molemmat, mutta niillä on eri tarkoitukset.
Älä tee näin:
<input type="password" aria-label="Use at least 12 characters">
Tämä nimeää kentän ohjeen, ei käsitteen mukaan. Lomakkeessa liikkuva käyttäjä haluaa ensin tietää, mikä kenttä on, ja vasta sitten, mitä rajoituksia siihen liittyy.
Tällä erolla on merkitystä myös virhetiloissa:
<label for="email">Email</label>
<input
id="email"
type="email"
aria-invalid="true"
aria-describedby="email-error"
>
<p id="email-error">Enter an email address in the format [email protected].</p>
Nimiö pysyy vakaana. Virheilmoituksesta tulee tukevaa kontekstia.
Toistuvat ohjaimet tarvitsevat yksilölliset nimet
Listat ja kortit ovat paikkoja, joissa ARIA-nimet tulevat usein tarpeellisiksi.
Huono:
<button>Delete</button>
<button>Delete</button>
<button>Delete</button>
Painikkeiden välillä liikkuva ruudunlukijan käyttäjä voi kuulla “Delete, button” kolme kertaa ilman kontekstia.
Hyvä:
<button aria-label="Delete report: Q4 revenue">Delete</button>
<button aria-label="Delete report: Hiring plan">Delete</button>
<button aria-label="Delete report: Vendor list">Delete</button>
Tämä on perusteltu aria-label-attribuutin käyttötapaus: näkyvä teksti pysyy ytimekkäänä, kun taas saavutettava nimi sisältää kohteen.
Käytä tätä mallia kuitenkin harkiten. Jos kohteen nimi näkyy lähellä, aria-labelledby voi olla helpompi ylläpitää:
<article>
<h3 id="report-q4">Q4 revenue</h3>
<button aria-labelledby="delete-q4 report-q4" id="delete-q4">Delete</button>
</article>
Saavutettavaksi nimeksi tulee “Delete Q4 revenue.” Näin vältetään raportin otsikon monistaminen attribuuttiin.
Älä nimeä kaikkea
Kaikki elementit eivät tarvitse ARIA-nimeä.
Staattinen teksti ei yleensä tarvitse. Koristeelliset kuvakkeet eivät tarvitse. Säiliöt eivät tarvitse, ellei niillä ole merkityksellistä maamerkki- tai widget-roolia. Ylinimeäminen voi tehdä sivusta meluisan ja vaikeamman selata.
Käytä kuvissa kuvakohtaista mallia: merkitykselliset kuvat tarvitsevat hyödyllisen alt-tekstin; koristeelliset kuvat tarvitsevat tyhjän alt=""-tekstin. Älä käytä ARIA-nimiä hyvän kuvatekstin korvikkeena. Jos tiiminne sekoittaa näitä käsitteitä, palaa pragmaattiseen kuvien alt-tekstin oppaaseen ja erota kuvien vaihtoehtoiset tekstit ohjainten nimistä.
Yleinen virhe on antaa jokaiselle SVG:lle aria-label. Jos SVG on painikkeen sisällä ja painikkeella on jo nimi, kuvake pitäisi yleensä piilottaa apuvälineteknologioilta:
<button aria-label="Open menu">
<svg aria-hidden="true" focusable="false">...</svg>
</button>
Muuten käyttäjä voi kuulla päällekkäisiä tai outoja ilmoituksia selaimen ja apuvälineteknologian yhdistelmästä riippuen.
Tarkista laskettu nimi, älä vain koodia
Saavutettavuusvirheet selviävät usein koodikatselmoinnista, koska merkkaus näyttää uskottavalta.
Nykyaikaiset selainten kehittäjätyökalut voivat näyttää lasketun saavutettavuuspuun. Chrome-, Edge-, Firefox- ja Safari-selaimissa voit tarkastaa elementin ja etsiä saavutettavuustietoja, kuten roolia, nimeä ja kuvausta. Tarkistat kolme asiaa:
- Onko rooli se, mitä odotat?
- Onko saavutettava nimi selkeä ja täsmällinen?
- Onko kuvaus hyödyllinen korvaamatta nimeä?
Testaa sitten muutamia työnkulkuja oikealla ruudunlukijalla. Sinun ei tarvitse ryhtyä kokopäiväiseksi apuvälineteknologian asiantuntijaksi saadaksesi perusasiat kiinni. macOS:ssä VoiceOver on sisäänrakennettu. Windowsissa NVDA on laajasti käytetty ja ilmainen. Mobiilissa testaa tilanteen mukaan VoiceOverilla iOS:ssä ja TalkBackilla Androidissa.
Automaattiset työkalut ovat hyödyllisiä, mutta ne eivät voi luotettavasti kertoa, onko “Open,” “Read more,” tai “Delete” riittävän kontekstuaalinen. Kohtele automaatiota verkkona, älä tuomarina. Tämä muistuttaa suorituskyvyn auditointia: raportti voi osoittaa epäilyttäviä alueita, mutta vaikutus täytyy silti tulkita. Sama rauhallinen lähestymistapa, jota suosittelemme Lighthouse-raportin lukemiseen panikoimatta, pätee myös tässä.
Käytännön tarkistuslista katselmointiin
Ennen kuin julkaiset ARIA-nimiä, kysy:
- Voisiko tämä olla sen sijaan natiivia HTML:ää?
- Onko olemassa näkyvää tekstiä, jota pitäisi käyttää nimenä?
- Jos näkyvää tekstiä on, sisältyykö se saavutettavaan nimeen?
- Ovatko toistuvat ohjaimet yksilöllisiä, kun niissä liikutaan visuaalisen kontekstin ulkopuolella?
- Onko ohjeteksti yhdistetty
aria-describedby-attribuutilla eikä pakotettu nimeen? - Onko koristeelliset kuvakkeet piilotettu apuvälineteknologioilta?
- Onko joku tarkistanut lasketun saavutettavan nimen selaimen kehittäjätyökaluissa?
- Onko kriittinen työnkulku testattu vähintään kerran oikealla ruudunlukijalla?
Tämä tarkistuslista löytää useimmat nimeämisongelmat ennen kuin niistä tulee käyttäjien ongelmia.
Hyvän ARIAn hiljainen kuri
Hyvä ARIA-työ on harvoin dramaattista. Se on enimmäkseen pidättyvyyttä.
Käytä oikeita painikkeita. Käytä oikeita nimiöitä. Pidä näkyvät ja saavutettavat nimet linjassa. Lisää aria-label vain silloin, kun parempaa näkyvää lähdettä ei ole. Käytä aria-labelledby-attribuuttia, kun sivulla on jo oikea teksti. Käytä aria-describedby-attribuuttia tukeviin ohjeisiin ja virheisiin.
Verkkoalusta antaa kehittäjille paljon ilmaiseksi, kun käytämme sitä suoraan. ARIA on aukkoja varten. Taito on tietää, milloin aukko todella on.