Saavutettava käyttöliittymä (UI)

WCAG 2.1

WCAGAvautuu uuteen välilehteen on joukko WAI:n luomia suosituksia. WAIAvautuu uuteen välilehteen on W3C:n aloite. W3CAvautuu uuteen välilehteen on organisaatio, jolla ei ole täytäntöönpanovaltaa.

Kuten EU:n lainsäädännön osiossaAvautuu uuteen välilehteen mainitsimme, EU-direktiivi 2016/2102 ja sen liitteenä olevat asiakirjat ovat kuitenkin mahdollistaneet WCAG 2.1 -tason AA noudattamisen vähimmäisstandardina kaikkialla EU:ssa.

Ulkoiset lähteet:

• WCAG 2.1Avautuu uuteen välilehteen W3C-verkkosivuilla
• What's New in WCAG 2.1Avautuu uuteen välilehteen W3C-verkkosivuilla

WCAG rakenne

WCAG 2.1 sisältää monta ohjaustasoa:

1. Toimintaperiaatteet: käyttöliittymät ja sisällöt on oltava havaittavissa, käyttökelpoisia, ymmärrettäviä ja kestäviä. Voit muistaa nämä neljä periaatetta käyttämällä POUR-lyhennettä, joka muodostuu englanninkielisistä sanoista 'perceivable', 'operable', 'understandable' ja 'robust'.
2. Ohjeet: jokaisella periaatteella on joukko suuntaviivoja tai ohjeita, jotka ovat laajoja tavoitteita. Kaiken kaikkiaan näitä ohjeita on 13.
3. Onnistumiskriteerit: jokaisella ohjeella taas on joukko testattavissa olevia onnistumiskriteerejä, joista jokainen liittyy yhteen seuraavista kolmesta tasosta: A, AA, ja AAA (pienimmästä korkeimpaan). Jotta digitaalinen palvelu täyttää tason AA, sen on täytettävä kaikki A- ja AA-kriteerit. Onnistumiskriteerejä on yhteensä 78.
4. Riittävä ja konsultatiivinen tekniikka: Jokaisella ohjeella ja onnistumiskriteerillä on siihen liittyvä luettelo ehdotetuista tekniikoista, joita voidaan käyttää täyttämään se joko minimitasolla (riittävät tekniikat) tai optimaalisesti (konsultatiiviset tekniikat). Luettelo ei ole tyhjentävä; tämä tarkoittaa, että on hyväksyttävää käyttää muita tekniikoita, kunhan ne täyttävät kyseisen ohjeen tai kriteerin. Lisäksi samassa asiakirjassa on luettelo yleisimmistä virheistä, jotka rikkovat tiettyjä ohjeita tai perusteita ja joita on vältettävä.

Ulkoiset lähteet:

• WCAG 2 Layers of GuidanceAvautuu uuteen välilehteen W3C-verkkosivuilla
• Techniques for WCAG 2.1Avautuu uuteen välilehteen W3C-verkkosivuilla

WCAG periaatteet

WCAG 2.1:n mukaan käyttöliittymät ja sisällöt on oltava:

• Havaittavia: käyttäjien on kyettävä havaitsemaan käyttöliittymä ja sisältö yhdellä tai useammalla aistilla. Käytännössä tämä tarkoittaa sitä, että verkkosisällön on oltava havaittavissa useilla aisteilla, jotta se sopii eri käyttäjille.
• Käyttökelpoisia: käyttäjien on kyettävä käyttämään käyttöliittymää ja olla vuorovaikutuksessa sen kanssa. Käytännössä tämä tarkoittaa, että verkkopalveluiden käyttöliittymien on oltava käyttökelpoisia monin tavoin, mukaan lukien avustavien tekniikoiden kanssa.
• Ymmärrettäviä: käyttäjien on kyettävä ymmärtämään verkkopalvelun sisältöä ja kuinka käyttöliittymää käytetään. Käytännössä tämä tarkoittaa, että verkkosisällön ja rajapintojen on oltava ymmärrettäviä käyttäjille, joilla on erityyppisiä kognitiivisia ja älyllisiä rajoitteita.
• Kestäviä: Verkopalvelun käyttöliittymä ja sisältö pitää pystyä tulkitsemaan luotettavasti eri tekniikoiden avulla. Käytännössä tämä tarkoittaa, että käyttöliittymän ja sisällön on oltava saavutettava nykyisille käyttäjille ja apuvälineille ja myös tulevaisuudessa sitä mukaa kun käyttäjät ja teknologiat kehittyvät.

Sanoista "hover", eli osoittimen vieminen elementin päälle ja "focus" eli kohdistaminen keskustellaan laajasti WCAG:ssa, ja ne ovatkin merkittäviä saavutettavuuden kannalta.

Vuorovaikutteisia verkkoelementtejä on monia: linkit, painikkeet, syöttökentät jne. Vuorovaikutuksessa voi olla minkä tahansa näiden elementtien kanssa seuraavasti:

• Osoittimen vieminen elementin päälle (hover): viemällä osoittimen elementin päälle, elementti aktivoituu hiiren painalluksesta tai jollakin muulla teknologialla, jota voi käyttää hiiren sijaan, kuten katseen- ja liikkeenseuranta.
• Kohdentaminen: kohdennettua elementtiä voi aktivoida joko näppäimistöllä tai muulla teknologialla, jota käytetään näppäimistön sijaan, kuten erilaiset ohjaimet.
  • Näppäimistöllä tai vastaavalla laitteella voit käyttää Tab-painiketta, kunnes pääset kyseiseen elementtiin. "Tabbaus" voi tarkoittaa yksinkertaisesti Tab-näppäimen painamista tai monimutkaisemman näppäinyhdistelmän painamista selaimesta ja asetuksista riippuen.
  • Jotkut ruudunlukijat siirtävät tarkennuksen tarkennettavaan elementtiin, kun ne lukevat sen. Tarkennus pysyy sitten kyseisessä elementissä, kunnes lukija kohtaa toisen tarkennettavan elementin.
  • Useimmissa selaimissa painikkeen aktivoinnin jälkeen se pysyy tarkennettuna.
• Aktivointi: elementti on aktiivinen kun se on, no, aktiivinen.
  • Hiirellä tai hiirenkaltaisella työkalulla voit klikata elementtiä kun viet osoittimen elementin päälle.
  • Näppäimistöllä tai näppäimistön kaltaisella työkalulla:
    • Linkit: voit painaa Enter-näppäintä kun elementti on kohdennettuna.
    • Painikkeet, alasvetovalikko ja monet syöttökentät: voit painaa Välilyönti-näppäintä kun elementti on kohdennettuna.

Osoittamisen, kohdistuksen ja aktiivisten tilojen suunnittelu ja kehittäminen

Osoittamisen tyylit (hover-tyylit) auttavat meitä ymmärtämään, että voimme olla vuorovaikutuksessa elementin kanssa. Tämä on erityisen hyödyllistä ihmisille, joilla on oppimisvaikeuksia, kognitiivisia vammoja ​​ja rajoitettuja tietokoneen lukutaitoja.

Tarkennustyylit ovat niin tärkeitä näppäimistöjä ja näppäimistöön verrattavia laitteita, että kaikkien selainten on tarjottava oletusarvoiset tarkennustyylit. Tavanomaisesti käytetään outline CSS-ominaisuutta koska se ei vaikuta asetteluun tai liikkuta lähellä olevia elementtejä. Valitettavasti emme voi luottaa pelkästään oletustyyleihin seuraavista syistä:

• Jotkut selaimen oletusasetukset eivät yksinkertaisesti ole riittävän havaittavia.
• Suurin osa selaimen oletusasetuksista on suunniteltu erottumaan vaaleista taustoista, eikä niitä pysty havaitsemaan tarpeeksi hyvin tummassa taustassa.

Tässä on joitain vinkkejä lisätarkennustyylien toteuttamiseen:

• Varmista, että suunnittelet tarkennustyylejä, jotka ovat riittävän havaittavia, etenkin ihmisille, joilla on näkörajoitteita. Kun käyttäjä käy verkkopalvelua Tab-painikkeella läpi, hän ei voi ennustaa, missä seuraava tarkennettava kohde on. Tästä syystä tarkennustyyli on kiinnitettävä heidän huomionsa.
• Älä muokkaa oletustarkennustyylejä: älä käytä outline: none saadaksesi ne häviämään, äläkä käytä outline ominaisuutta lisäkohdistuksen korostamiseen tai muuhun. Moni ihminen, joka luottaa näkyvään tarkennukseen navigoidessaan sivustolla, on omat mieltymyksensä ja käyttävät outline ominaisuutta ylikirjoittamaan selaimen oletustyylejä. Jos myös sinä käytät outline ominaisuutta, saatat sekoittaa käyttäjän valintoja tai valinta voi johtaa tahattomiin tuloksiin.
• Jos sinä tai asiakas ette pidä selaimen oletusarvoisesta tyylien ulkoasusta, voit käyttää :focus-visible  polyfill. Se perustuu uuteen CSS-pseudoluokkaan, joka voidaan lisätä seuraavaan CSS-versioon täydentämään osoitusta, kohdistusta ja aktiivisia pseudoluokkia. Kun käytät :focus-visible, selain näyttää tarkennustyyliä vain, jos se toteaa, että sellaista tarvitaan (esimerkiksi jos käyttäjä navigoi näppäimistön avulla).

Aktiiviset tyylit auttavat käyttäjiä ymmärtämään, että he pystyivät aktivoimaan elementin onnistuneesti. Koska aktivointiaika on yleensä melko lyhyt (hiiren napsautuksen tai näppäimen painalluksen ajan), näiden tyylien tulisi olla havaittavissa, mutta huomaamattomia.

Tutustu myös:

• StatesAvautuu uuteen välilehteen, Material Design
• Avoid Default Browser Focus StylesAvautuu uuteen välilehteen, Adrian Roselli (2017)
• Stop Messing with the Browser's Default Focus outlineAvautuu uuteen välilehteen, TJ VanToll (2013)
• Polyfill for :focus-visibleAvautuu uuteen välilehteen GitHubissa
• :focus-visible and backwards compatibilityAvautuu uuteen välilehteen, Patrick H. Lauke (2018)

Kuvasisältö voi olla valokuvia, kuvituksia, piirroksia, kuvakkeita, kaavioita, jne. Kuvasisällöllä voi olla jompikumpi seuraavasta kahdesta roolista:

• Informatiivinen: kun se välittää tietoa, ja sitä tietoa ei anneta ympäröivässä tekstissä.
• Kuvitus: kun se ei välitä tietoa; tai jos se välittää tietoa niin sama tieto löytyy jo ympäröivässä tekstissä.

Informatiivisella kuvasisällöllä on oltava sopiva tekstivastine, jonka ruudunlukijat voivat sitten ilmoittaa. Tekstivastineet voidaan tarjota monin tavoin:

• Käyttäen alt attribuuttia (elementeille, joilla on sille tuki, eli <img>, <area>, ja <input type="image"> elementit).
  Käyttäen ARIA-pohjaiset lähestymistavat, lähinnä aria-label ja aria-labelledby.
• Käyttäen visuaalisesti piilotettua tekstiä.

Yleisiä vinkkejä

• Sinun ei tarvitse käyttää sanoja "kuva" tai "tämä kuvastaa". Ruudunlukija ilmoittaa jo, että kyseessä on <img>-elementti.
• Älä kuvaile vain kuvan sisältöä kirjaimellisesti tai yleisesti, vaan pyri mahdollisimman yksityiskohtaiseen kuvaukseen.
• Kysy itseltäsi: mitä tietoa haluan välittää tällä kuvalla?
• Kuvittele, että vieressäsi istuu sokea ihminen. Miten kerrot hänelle kuvan välittämän tiedon?

Esimerkki: Rio 2016 paralympialaisten pyörätuolitenniksen voittajaa koskevan artikkelin yhteydessä ei kannata kirjoittaa tekstivastineeksi "nainen pyörätuolissa". Sen sijaan teksti "hollantilainen pelaaja Jiske Griffioen juhlii voitettuaan kultamitalin naisten yksinpelissä vuoden 2016 kesäparalympiakisoissa Rio de Janeirossa, Brasiliassa", kertoo huomattavasti tarkemmin kuvan sisällön tekstimuodossa.

Tekstivastineet riippuvat asiayhteydestä

Otetaan esimerkkinä Wunder-logo, joka löytyy <img>-elementtinä:

• Jos se on osa ruudukkoa, jossa näytetään kaikkien projektia tukeneiden yritysten logoja, sinun tulisi käyttää alt="Wunder"ja samalla tavalla myös muut yritykset ja niiden logot. Silloin ruudunlukija tulee ja lukee: "Tukijat: Wunder, Elisa, Google ...".
• Jos haluat kertoa, että kyseessä on logo, käytä alt="Wunder logo".
• Jos haluat kertoa miltä logo näyttää (esim. suunnittelukeskustelussa), kirjoita esim. näin: alt="The Wunder logo: tyylikäs ja eloisa violetti porkkana, jolla on kolme päällekkäistä lehteä. Yleisilmeeltään pyöreähkö muoto muistuttaa juurikasta tai retiisiä".

Otetaan toinen esimerkki. Joskus käytämme korttilinkkejä, jotka sisältävät <img>-elementin ja otsikon. Kun napsautamme linkkiä, siirrymme toiselle sivulle, jolla on sama kuva.

• Kortissa kuva on kuvituskuva. Tässä tapauksessa meidän tulisi käyttää tyhjää tekstivastinetta (alt=""), jotta ruudunlukijat eivät lukisi kuvaa tässä kohtaa.
• Artikkelisivulla kuva voi olla informatiivinen tai kuvituskuva. Vinkki: jos käytät jonkinlaista ostettua arkistokuvaa, se on todennäköisesti kuvituskuva.

Arkkitehtien, sisällönsuunnittelijoiden, sisällöntuottajien ja kehittäjien on erittäin suositeltavaa tehdä yhteistyötä varmistaakseen hyvät ja yhdenmukaiset tekstivastinekäytännnöt.

Kieliversiot, ruudunlukijat ja tekstivastineet 

Monikieliset tilanteet johtavat valitettavasti virheelliseen kielikäyttäytymiseen kaikissa testaamissamme ruudunlukija-, käyttöjärjestelmä- ja selainyhdistelmissä, jopa silloin, kun sivun tai sivun osan kieli on asetettu oikein. Esimerkki monikielisestä tilanteesta on, kun ruudunlukijan käyttöliittymä on suomeksi ja verkkosisältö on englanniksi; tässä yhteydessä ruudunlukija saattaa lukea englanninkielisen tekstin suomenkielisellä äänellä (tai ”aksentilla”).

Yksi yleisimmistä virheistä on, että HTML-määritteenä annettu tekstisisältö (esimerkiksi alttai aria-label:inmukaan toimitetut tekstivastineet) ilmoitetaan usein väärällä äänellä. Vaikka emme voi tehdä mitään <img>- tai muille elementeille, joissa vaaditaan alt-atribuuttia, voimme kuitenkin vaikuttaa muihin elementteihin:

• Voimme tarjota tekstivastineen käyttämällä ARIA-pohjaisia ​​lähestymistapoja. Tätä on helpompi toteuttaa ja ylläpitää, mutta se luetaan usein väärällä äänellä (yli 50% ajasta Xurxen testeissä).
• Vaihtoehtoisesti voimme tarjota tekstivastineen visuaalisesti piilotettuna tekstinä, joka on sijoitettu kyseisen elementin sisään. Tätä on vähän vaikeampi toteuttaa, mutta se luetaan yleensä oikealla äänellä (melkein 100% tapauksista Xurxen teisteissä).

Tutustu myös:

• Decorative ImagesAvautuu uuteen välilehteen, W3C:n tarjoamat verkko-ohjaustunnit
• Alternative TextAvautuu uuteen välilehteen, WebAIM
• Screen Reader Multilanguage ExperimentAvautuu uuteen välilehteen, Wunderin oma saavutettavuusasiantuntija Xurxe Toivo García (2020)
• Accessible Labelling Multilanguage ExperimentAvautuu uuteen välilehteen, Wunderin oma saavutettavuusasiantuntija Xurxe Toivo García (2020)

Mikä se on?

HTML-elementit voi jakaa kahteen kategoriaan:

• Ei-semanttinen: nämä elementit eivät määrittele mitään niiden sisällöstä, ja niitä käytetään vain ryhmittelemään muita elementtejä tai erottamaan tietyt elementit toisistaan. Tärkeimmät esimerkit ovat <div> ja <span>.
• Semanttinen: nämä elementit välittävät tietoa niiden sisällöstä. Jotkut ovat yhtä vanhoja kuin HTML itse (esimerkiksi kappaleiden <p> -elementti ja linkkien <a> -elementti). Jokainen HTML-versio on lisännyt uusia semanttisia elementtejä: erityisesti HTML5 on tuonut monia semanttisia elementtejä, jotka ovat välttämättömiä saavutettavuuden parantamiseksi (kuten<nav>navigointielementeille ja<time> ajalle ja päivämäärille).

Kuinka ja miksi niitä käytetään?

On tärkeää käyttää semanttisia elementtejä oikein, jotta ruudunlukijat ja muut avustavat tekniikat ymmärtäisivät niiden merkityksen ja välittäisivät sen tiedon käyttäjälle.

Esimerkiksi:

• Jos käytät (oikein) <h2>-elementtejä esimerkiksi hedelmiä ja vihanneksia käsittelevien osioiden alussa, ruudunlukija voi ilmoittaa niistä nimellä "Otsikkotaso 2, hedelmät" ja myöhemmin "Otsikkotaso 2, vihannekset". Lisäksi useimmat ruudunlukijat sallivat käyttäjän selata otsikoittain, jotta he voivat ymmärtää sivun rakenteen tai siirtyä eteenpäin kiinnostaviin osioihin.
• Jos käytät<p>-elementtejä näihin otsikoihin (mikä olisi väärin) ja lisäät sitten CSS-muotoilun saadaksesi ne näyttämään isommilta ja lihavimmilta, käyttäjät jotka eivät näe miltä teksti näyttää, eivät tiedä että ne palvelevat erityistä tarkoitusta. Lisäksi käyttäjät eivät voi selata sivua otsikoittain.

Tiettyjen merkitysten lisäksi, interaktiivisissa semanttisissa elementeissä on myös sisäänrakennettuja toiminnallisuuksia, jotka ovat erittäin tärkeitä saavutettavuuden kannalta.

Otetaan esimerkkinä painike. Sinun tulisi käyttää HTML <button>-elementtiä. Voisit käyttää teknisesti eri elementtiä, kuten<div>, ja sitten tyylitellä se CSS:llä. Jotta se käyttäytyisi kuten todellinen painike, sinun pitäisi kuitenkin tehdä vielä seuraavaa:

• Lisää painikkeelle ARIA-rooli role="button", jotta ruudunlukijat voivat kertoa, että kyseessä on painike.
• Tee siitä kohdistettava tabindex="0", jotta se olisi saavutettava myös näppäimistöllä tai näppäimistön kaltaisella laitteella.
• Lisää keyup tapahtuman käsittely ainakin välilyöntinäppäimelle, jotta painiketta voisi aktivoida näppäimistöllä tai näppäimistön kaltaisella laitteella.
• Lisää click tapahtuman käsittely, jotta painiketta voisi aktivoida hiirellä tai hiiren kaltaisella laitteella.

Kaikki tämä vain saman toiminnallisuuden saavuttamiseksi, jonka saat "avaimet käteen"-periaatteella kun käytät <button>-elementtiä. Eli, miksi tehdä asioista vaikeampia kuin mitä niiden täytyy olla?

Tutustu myös:

• HTML: A good basis for accessibilityAvautuu uuteen välilehteen, MDN-verkkotiedosto
• HTML5 AccessibilityAvautuu uuteen välilehteen, Steve Faulkner
• Semantic Structure: Regions, Headings, and ListsAvautuu uuteen välilehteen, WebAIM-verkkosivulla
• Semantics to Screen ReadersAvautuu uuteen välilehteen, Melanie Richards (2019)

Mikä se on?

ARIAAvautuu uuteen välilehteen on WAIAvautuu uuteen välilehteen:n luoma tekninen eritelmä, ja WAI on W3CAvautuu uuteen välilehteen:n aloite. ARIA 1.2 on nykyinen versio.

Rich web-sovellukset (aiemmin tunnettu nimellä "rich Internet applications") ovat verkkosivustoja, joilla on monimutkaisia ​​ominaisuuksia, jotka aiemmin olivat mahdollisia vain työpöytäsovelluksissa. ARIA on suunniteltu täydentämään HTML:ää tarjoamalla lisäominaisuuksia, jotka helpottavat ja parantavat Rich Web -sovellusten saavutettavuutta.

Monet tekniikat, joita voidaan käyttää WCAG:n onnistumiskriteerien täyttämiseen, perustuvat ARIA:an. Sinun on kuitenkin käytettävä ARIA:a vastuullisesti, koska sen väärinkäyttö on vahingollisempaa vammaisille kuin sen käyttämättä jättäminen.

Muista aina: ARIA:n käyttämättä jättäminen on parempi asia kuin huonon ARIA:n käyttäminen.

ARIA-määritteitä, joita voidaan lisätä HTML-koodiin, on kolmen tyyppisiä:

• Roolit määrittelevät komponentin tarkoituksen käyttöliittymässä.
• Ominaisuudet määrittelevät komponentin ominaisuuksia.
• Tila määrittelee komponentin nykyisen tilan.

Jatka lukemista saadaksesi lisätietoja näistä!

ARIA roolit

ARIA-roolit välittävät komponentin tarkoituksen käyttöliittymässä; esim. role="radiogroup" määrittää joukon radiopainikkeita.

Rooleja on yhteensä 82, jaettuna kuuteen kategoriaan:

1. Abstraktit roolit: älä huoli näistä liikaa, et koskaan käytä niitä suoraan. Ne ovat olemassa käsitteellisenä perustana muille rooleille.
2. Maamerkkiroolit: nämä rajaavat sivun tärkeimmät alueet, jotka ovat navigointikohteita. Näitä ovat päänavigaatio, hakukentät, alatunnisteet jne.
3. Tiedostorakenteen roolit: nämä kertovat meille sivun erityyppisestä sisällöstä ja siitä, kuinka ne on järjestetty. Näitä ovat otsikot, taulukot, kuvat, artikkelit jne.
4. Vimpain-roolit: nämä ovat interaktiivisia elementtejä, joita käyttäjä voi jollain tavalla hallita. Näitä ovat painikkeet, vierityspalkit, välilehdet jne.
5. Live-alueen roolit: nämä ovat sivun osia, jotka muuttavat sisältöä, kun painopiste on muualla. Ne voivat muuttua vastauksena käyttäjän suorittamiin toimiin tai johonkin ulkoiseen tapahtumaan. Näitä ovat esim. hälytykset ja ajastimet.
6. Ikkunaroolit: nämä ovat ikkunoita selaimessa tai sovelluksessa. Näitä ovat esim.  valintaikkunat ja hälytysikkunat. 

ARIA ominaisuudet ja tilat

ARIA ominaisuuksia on 27 kappaletta, jotka määrittelevät komponentin ominaisuuksia. Esimerkiksi aria-required="true" voi kertoa, että kohteen valinta radioryhmästä vaaditaan ennen lomakkeen lähettämistä.

ARIA tiloja on 9 kappaletta, jotka määrittelevät komponentin nykyistä tilaa. Esimerkiksi aria-checked="true" voi kertoa, että jokin tietty radiopainike on valittuna.

Kaikilla ARIA ominaisuuksilla ja tiloilla on etuliite aria-* ja niihin voidaan yhteisesti viitata "ria-* -attribuutteina".

Jotkut aria-* attribuutit ovat globaaleja; niitä voidaan soveltaa elementteihin, joissa on mikä tahansa ARIA-rooli, tai elementteihin, joissa ei ole ARIA-roolia. Näitä ovat yleisesti käytetty aria-hidden (joka piilottaa elementin avustavilta teknologioilta) ja aria-label (joka tarjoaa elementille saavutettavan etiketin).

Muita aria-* attribuutteja voidaan vain soveltaa elementteihin, joilla on tietyt ARIA-roolit. Esimerkiksi aria-checked voidaan käyttää esim. rrole="radio":n kanssa mutta ei role="navigation":n kanssa

ARIA ja semanttinen HTML

Kuten keskustelimme semanttisessa HTML-sivullamme, useimmilla HTML-elementeillä on tietty natiivi semantiikka, joista monet vastaavat ARIA-attribuutteja (roolit, ominaisuudet ja tilat).

Kun käytät HTML-semanttisia elementtejä, älä koskaan lisää ARIA-attribuutteja, jotka jo sisältyvät elementtiin. Esimerkiksi:

• <button> -elementillä on jo selkeä role="button".
• Valittu radiopainike, jossa checked HTML-attribuutilla on jo selkeä aria-checked="true".

Lisäksi älä koskaan lisää ARIA-attribuutteja, jotka ovat ristiriidassa kyseisen elementin alkuperäisen semantiikan kanssa. Esimerkiksi:

• <button> -elementillä ei voi olla roolia ole="heading"; painike on jotain, jonka aktivoit toiminnon suorittamiseksi, ei jotain, joka antaa sinulle tietoja sivun rakenteesta.
• Radiopainikkeella ei voi olla aria-checked="mixed"; radiopainikkeilla voi ainoastaan olla arvot true ja false. Valintaruudut puolestaan ​​tukevat kolmatta, mixed -tilaa.

Käytä aina semanttisia elementtejä, jos mahdollista, monesta syystä: 

• Alkuperäisellä semantiikalla on parempi tuki, etenkin kun kyse on kansainvälistymisestä. Esimerkiksi, jos käytät ruudunlukijaaAvautuu uuteen välilehteen suomeksi, <nav>-elementti ilmoitetaan yleensä oikein nimellä "navigointi" (suomenkielinen sana, aksentti), mutta <div role="navigation"> ilmoitetaan usein väärin "navigation" (englanninkielinen sana, suomenkielinen aksentti).
• Interaktiivisissa elementeissä on sisäänrakennettu toiminnallisuus, jonka selain on toteuttanut. Esimerkiksi <button> -elementti toimii sekä hiiren (tai hiiren kaltaisella laitteella) että näppäimistön (tai näppäimistön kaltaisella laitteella) kanssa. Lisäämällä role="button" ei automaattisesti tee sitä käyttäytymään kuin todellinen painike.

Joten käytä ARIA:a vastuullisesti. Ja on hyvä muistaa: ARIA:n käyttämättä jättäminen on parempi asia kuin huonon ARIA:n käyttäminen. 

ARIA maamerkit

ARIA-maamerkkiroolit vastaavat sivun alueita, joita pidetään navigoinnin kannalta merkittävinä. Niitä on kahdeksan:

• Banner (enintään yksi per sivu): sisältää enimmäkseen yleistä tietoa sivustosta, ei niinkään yhden yksittäisen sivun tietoa.
• Navigation (ei rajoituksia): sisältää enimmäkseen linkkejä sivulla tai sivustolla liikkumiseen.
• Main (enintään yksi per sivu): sisältää sivuston pääsisällön.
• Complementary (ei rajoituksia): sisältää tietoja, jotka täydentävät pääaluetta, mutta joita voidaan silti pitää erillisenä kokonaisuutena.
• Content info (enintään yksi per sivu): sisältää tietoa sivustosta tai sivusta.
• Form (ei rajoituksia): sisältää yhden tai useamman lomakkeen muodostavan elementin (mutta ei hakulomaketta).
• Search (ei rajoituksia): sisältää yhden tai useamman elementin, joka toimii hakuna.
• Region (ei rajoituksia): sisältöosioille, jotka ovat riittävän suuria ja tärkeitä, jotta niitä voidaan pitää tärkeänä maamerkkinä, mutta jotka eivät sovellu mihinkään muuhun maamerkkirooliin.

Tietyillä HTML5:ään sisällytetyillä elementeillä on nämä ARIA-roolit osana implisiittistä semantiikkaansa. Esimerkiksi <main> HTML-elementissä on implisiittinen role="main", eikä meidän pitäisi lisätä sitä nimenomaisesti koodiin. Tässä ovat niiden keskinäiset suhteet:

• <header>: implisiittinen banner rooli.
• <nav>: implisiittinen navigation rooli.
• <main>: implisiittinen main rooli.
• <aside>: implisiittinen complementary rooli.
• <footer>: implisiittinen contentinfo rooli.
• <form>: implisiittinen form rooli.
• Mikään HTML-elementti ei sisällä implisiittistä search-roolia. Useimmissa tapauksissa käytämme lomake-elementtiä ja annamme sille nimenomaisen role="search"-roolin.
• <section>: implisiittinen region rooli.

Kaikki sivun sisällöt tulisi sijaita ARIA-maamerkien sisällä: Joillakin apuvälineillä (kuten ruudunlukijoilla) on pikavalinnat tiettyihin maamerkkeihin tai nykyisen maamerkin alkuun tai loppuun siirtymiseen. Sisällöt, jotka eivät sijaitse maamerkkien sisällä, voivat jäädä näiltä käyttäjiltä huomaamatta.

Jotkut maamerkit ovat vain ylimmän tason maamerkkejä: <header>, <main>, <aside> ja <footer>eivät voi olla muiden maamerkkialueiden sisällä. Muille sallitaan sisäkkäin upottamisen tarvittaessa, mutta sitä ei vaadita. Esimerkiksi <nav> -elementti voi olla ylimmällä tasolla tai olla toisen maamerkin (kuten <header>) sisällä.

Vain joitain maamerkkejä voi esiintyä sivulla useita kertoja (katso aikaisempi luettelo): jos samantyyppisiä maamerkkejä on useita, ne on erotettava käyttämällä aria-label tai aria-labelledby. Sinulla voi olla esimerkiksi ensisijainen navigaatiopalkki (joka on aria-label="primary") sivun yläosassa ja toissijainen navigaatioelementti (joka on aria-label="secondary") alatunnisteen sisällä.

Tutustu myös:

Yleinen ARIA:

• ARIA 1.2Avautuu uuteen välilehteen, W3C-verkkopalvelussa
• ARIAAvautuu uuteen välilehteen, MDN verkkotiedosto
• Latest ARIA Authoring Practices GuideAvautuu uuteen välilehteen, W3C-verkkopalvelussa
• "No ARIA is better than bad ARIA"Avautuu uuteen välilehteen, ARIA Authoring Practices 1.1

ARIA attribuutit:

• Categorization of rolesAvautuu uuteen välilehteen ARIA 1.2
• Supported states and propertiesAvautuu uuteen välilehteen ARIA 1.2
• Landmark RolesAvautuu uuteen välilehteen ARIA 1.2

ARIA ja HTML:

• ARIA in HTMLAvautuu uuteen välilehteen W3C-verkkopalvelussa
• Document conformance requirements for use of ARIA attributes in HTMLAvautuu uuteen välilehteen, W3C-verkkopalvelussa
• Allowed ARIA roles, states and propertiesAvautuu uuteen välilehteen, W3C-verkkopalvelussa
• ARIA Landmarks ExampleAvautuu uuteen välilehteen, W3C-verkkopalvelussa
• Semantic Structure: Regions, Headings, and ListsAvautuu uuteen välilehteen, WebAIM (2020)
• Accessible LandmarksAvautuu uuteen välilehteen, Scott O'Hara (2018)

Jos olet kiinnostunut saavutettavuuden kehittämisestä kustannustehokkaasti, suosittelemme sinulle tallennetta webinaarista, jonka järjestimme yhdessä saavutettavuuteen erikoistuneen yrityksen, Annanpuran kanssa. Webinaarissa käymme lävitse kesästä 2025 eteenpäin voimassa olevat saavutettavuusvaatimukset, kerromme sivustojen saavutettavuusauditeista sekä annamme vinkit kognitiivisen saavutettavuuden kehittämiseen kustannustehokkaasti. Tilaamalla tallennelinkin saat myös presentaatiomateriaalit, joissa mukana pitkä lista hyödyllisiä linkkejä sekä ilmaisia saavutettavuteen liittyviä työkaluja.

Tilaa tallenne ja presentaatiomateriaalit täältä