Lyhyt, kantaa ottava tarkistuslista saavutettaville verkkopainikkeille

Painikkeiden saavutettavuusohjeiden ongelma

Useimmat painikkeiden saavutettavuusohjeet jakautuvat kahteen leiriin: ne ovat joko 40-sivuisia WCAG-tulkintoja, joita kukaan ei lue, tai epämääräisiä kehotuksia "tehdä painikkeista saavutettavia" ilman toteuttamiskelpoisia vaiheita. Kumpikaan ei auta, kun ominaisuus pitäisi julkaista torstaina.

Tämä tarkistuslista kattaa viisi yleisintä painikkeiden saavutettavuuspuutetta, joita näemme tuotannossa. Se ei tee sinusta WCAG-asiantuntijaa, mutta se löytää ongelmat, jotka todella vaikuttavat käyttäjiin.

1. Käytä painikkeisiin button-elementtiä

Jos se toimii kuin painike, sen pitäisi olla <button>-elementti. Ei <div> ja onclick, ei <span> ja role="button", ei <a> ja href="#" sekä preventDefault.

<button>-elementti antaa näppäimistönavigoinnin, kohdistuksen hallinnan ja ruudunlukijoiden ilmoitukset valmiina. Kun käytät <div>-elementtiä, rakennat kaiken tämän alusta asti itse — ja teet sen väärin.

Ainoa poikkeus: jos toiminto vie uudelle sivulle tai muuttaa URL-osoitetta, käytä <a>-elementtiä. Linkit ja painikkeet ovat semanttisesti eri asioita. Ruudunlukijan käyttäjät navigoivat elementtityypin perusteella, ja he odottavat painikkeiden suorittavan toimintoja ja linkkien siirtävän paikasta toiseen.

2. Tee osuma-alueesta vähintään 44×44 pikseliä

WCAG 2.5.5 (Level AAA) edellyttää, että vuorovaikutteisilla elementeillä on vähintään 44×44 CSS-pikselin kohdekoko. Tässä ei ole kyse visuaalisesta koosta — vaan klikattavasta alueesta.

Sinulla voi olla visuaalisesti pieni painike, jossa on riittävä sisennys, tai voit laajentaa osuma-aluetta pseudo-elementillä. Olennaista on, ettei käyttäjän tarvitse tähdätä tarkasti.

Mobiilikäyttäjät, motorisista rajoitteista kärsivät ihmiset ja kaikki, jotka käyttävät laitetta liikkeessä, osuvat helposti ohi pienistä kohteista. 24×24 pikselin kuvakepainike voi näyttää siistiltä, mutta käytettävyyden kannalta se epäonnistuu.

3. Tarjoa näkyvät kohdistustilat, jotka eivät ole pelkkiä selaimen oletuksia

Selaimen oletuskohdistusrengas on parempi kuin ei mitään, mutta se vaihtelee selaimittain ja jää usein näkymättömäksi tiettyjä taustoja vasten. Tarvitset mukautetun kohdistustilan, joka toimii design systemissäsi.

Hyvällä kohdistuksen ilmaisimella on kolme ominaisuutta:

• Korkea kontrasti: vähintään 3:1 viereisiin väreihin nähden
• Näkyvä etäisyys: ei jää painikkeen oman reunan tai taustan peittämäksi
• Yhtenäinen muoto: käyttäjien pitäisi tunnistaa se kohdistuksen ilmaisimeksi koko käyttöliittymässäsi

Älä poista kohdistuskehystä outline: none -määrityksellä korvaamatta sitä paremmalla ratkaisulla. Älä myöskään tee kohdistustiloista niin hienovaraisia, että vain sinä näet ne täydellisissä valaistusolosuhteissa.

4. Kirjoita painikkeiden tekstit niin, että ne toimivat ilman kontekstia

Ruudunlukijan käyttäjät navigoivat usein hyppimällä painikkeiden välillä. Silloin he kuulevat listan painikkeiden tekstejä ilman ympäröivää kontekstia.

Painike, jonka teksti on "Lue lisää", on tällaisessa listassa hyödytön. Samoin "Klikkaa tästä" tai "Lähetä". Tekstin pitäisi kuvata toimintoa: "Lataa saavutettavuuden tarkistuslista", "Tilaa päivitykset", "Poista tämä kommentti".

Jos suunnittelusi edellyttää lyhyttä visuaalista tekstiä, käytä aria-label-attribuuttia kuvaavan vaihtoehdon tarjoamiseen. Parempi ratkaisu on kuitenkin kirjoittaa tekstit, jotka toimivat kaikille.

Pelkkää kuvaketta käyttävissä painikkeissa aria-label on pakollinen. Painike, jossa on vain suurennuslasikuvake, tarvitsee aria-label="Search"-attribuutin tai vastaavan tekstin. Kuvake ei ole ruudunlukijoille saavutettava.

5. Varmista riittävä värikontrasti

WCAG 2.1 edellyttää vähintään 4.5:1-kontrastisuhdetta normaalille tekstille ja 3:1-kontrastisuhdetta suurelle tekstille (18pt tai 14pt lihavoituna). Painikkeiden tekstit ovat yleensä normaalia tekstiä.

Vaaleanharmaa teksti valkoisessa painikkeessa ei täytä vaatimusta. Vaaleansininen teksti vaaleansinisellä taustalla ei täytä vaatimusta. Nämä yhdistelmät voivat näyttää hienostuneilta, mutta ne sulkevat ulkopuolelle käyttäjiä, joilla on heikko näkö, värisokeus tai näyttö kirkkaassa auringonvalossa.

Käytä kontrastintarkistinta suunnittelun aikana, älä vasta julkaisun jälkeen. Kontrastiongelmien korjaaminen tuotannossa on kallista, koska se vaatii usein muutoksia design systemiin.

Jos työskentelet kuvankäsittelytyökalujen kanssa, client-side processing voi auttaa säilyttämään yksityisyyden saavutettavia visuaalisia resursseja luotaessa — erityisesti väriyhdistelmien testaamisessa tai esikatselutilojen luomisessa.

Mitä tämä tarkistuslista ei kata

Tämä lista on tarkoituksella epätäydellinen. Se ei kata käytöstä poistettujen tilojen semantiikkaa, lataustiloja, virheenkäsittelyä tai monimutkaisia painikemalleja, kuten jaettuja painikkeita tai pudotusvalikkojen laukaisimia. Nämä mallit tarvitsevat omat ohjeensa.

Se ei myöskään kata laajempaa kysymystä siitä, milloin käyttää painiketta muiden vuorovaikutteisten elementtien sijaan. Sitä varten sinun täytyy ymmärtää semanttista HTML:ää ja accessibility tree -rakennetta — aiheita, jotka ansaitsevat omat artikkelinsa.

Se kattaa helpoimmat ja yleisimmät korjaukset: virheet, jotka näkyvät lähes jokaisessa koodikatselmoinnissa, vaikuttavat suurimpaan määrään käyttäjiä ja on helpointa korjata kehityksen aikana.

Miten integroit tämän työnkulkuusi

Saavutettavuuden tarkistuslistat toimivat vain, jos ne ovat osa kehitysprosessia eivätkä jälkikäteen päälle liimattuja. Näin saat sen tapahtumaan:

Suunnittelussa: lisää kohdistustilat ja osuma-alueiden merkinnät suunnittelutiedostoihisi. Älä jätä näitä kehittäjien arvattavaksi.

Koodikatselmoinnissa: tarkista <button>-elementit, kuvakepainikkeiden aria-label ja kohdistustilojen CSS. Nämä on nopea huomata.

Testauksessa: käy käyttöliittymä läpi sarkainnäppäimellä. Jos et pääse painikkeeseen tai et näe, missä kohdistus on, eivät käyttäjäsikään näe.

Dokumentaatiossa: sisällytä painikkeiden saavutettavuusvaatimukset komponenttikirjastoosi. Tee oikean asian tekemisestä helpompaa kuin väärän.

Jos selvität tuotanto-ongelmia, HTTP-otsakkeiden ja uudelleenohjausten tarkasteluun tarkoitetut työkalut voivat auttaa ymmärtämään, miten avustavat teknologiat tulkitsevat merkintääsi — erityisesti silloin, kun selvität kohdistuksen hallintaa navigoinnin jälkeen.

Tämän työn ohittamisen hinta

Saavuttamattomat painikkeet eivät vain riko WCAG-yhteensopivuutta — ne rikkovat työnkulkuja. Käyttäjä, joka ei voi klikata lähetyspainiketta, ei voi täyttää lomaketta loppuun. Käyttäjä, joka ei näe kohdistustiloja, ei voi navigoida näppäimistöllä. Käyttäjä, joka ei erota painikkeen tekstiä taustasta, ei voi lukea tunnistetta.

Nämä eivät ole reunatapauksia. Noin 15 prosentilla maailman väestöstä on jokin vamma tai toimintarajoite, ja tilapäiset haitat (rikkinäinen hiiri, kirkas auringonvalo, vauvan pitäminen sylissä) koskettavat lopulta kaikkia.

Hyvä uutinen on, että painikkeiden saavutettavuus koostuu enimmäkseen ratkaistuista ongelmista. Sinun ei tarvitse keksiä uusia malleja tai odottaa selaintukea. Sinun tarvitsee vain käyttää alustaa oikein ja testata työsi.

Keskeiset huomiot

• Käytä <button>-elementtejä painikkeisiin ja <a>-elementtejä navigointiin — semanttinen ero on tärkeä avustaville teknologioille
• Varmista, että osuma-alueet ovat vähintään 44×44 CSS-pikseliä, jotta ne tukevat motorisia rajoitteita ja mobiilikäyttäjiä
• Tarjoa näkyvät, korkean kontrastin kohdistustilat, jotka toimivat koko design systemissäsi
• Kirjoita painikkeiden tekstit niin, että ne ovat ymmärrettäviä erillään luettuina, ja käytä aria-label-attribuuttia pelkissä kuvakepainikkeissa
• Tarkista värikontrasti suunnittelun aikana, ei vasta julkaisun jälkeen, jotta vältät kalliit jälkikorjaukset

FAQ

Q: Voinko käyttää role="button"-attribuuttia <div>-elementissä, jos lisään näppäimistökäsittelijät?

A: Voit, mutta sinun ei pitäisi. Sinun täytyy käsitellä Enter, Space, kohdistuksen hallinta ja käytöstä poistetut tilat käsin — ja jätät väistämättä jotain huomaamatta. <button>-elementti tekee kaiken tämän oikein oletuksena. Käytä sitä.

Q: Entä painikkeet, jotka vaihtavat tilaa, kuten toista/tauko-painike?

A: Käytä aria-pressed="true" tai aria-pressed="false" nykyisen tilan ilmaisemiseen. Painikkeen tekstin pitäisi myös kuvata toimintoa, joka tapahtuu klikatessa ("Tauko", kun toisto on käynnissä, "Toista", kun se on tauolla), ei nykyistä tilaa. Ruudunlukijan käyttäjien täytyy tietää, mitä painike tekee, ei missä tilassa järjestelmä on.

Q: Täytyykö käytöstä poistettujen painikkeiden täyttää kontrastivaatimukset?

A: WCAG 2.1 vapauttaa käytöstä poistetut kontrollit kontrastivaatimuksista (1.4.3), mutta tämä on kiistanalaista. Heikon kontrastin käytöstä poistetut painikkeet ovat kaikille vaikeita havaita. Jos aiot näyttää käytöstä poistetun painikkeen, tee siitä luettava. Vielä parempi: piilota se tai selitä, miksi se on poistettu käytöstä.

Q: Miten testaan painikkeiden saavutettavuutta ilman ruudunlukijaa?

A: Käytä näppäimistöä. Selaa käyttöliittymä läpi sarkainnäppäimellä ja varmista, että pääset jokaiseen painikkeeseen, näet missä kohdistus on ja voit aktivoida painikkeet Enterillä tai Spacella. Tämä löytää useimmat ongelmat. Syvempää testausta varten käytä Chrome- tai Firefox DevTools -työkalujen accessibility inspectoria tarkistaaksesi lasketun roolin ja tunnisteen.

Q: Mitä eroa on aria-label- ja aria-labelledby-attribuuteilla?

A: aria-label tarjoaa tekstimerkkijonon suoraan. aria-labelledby viittaa toisen elementin ID:hen, jonka tekstisisällöstä tulee tunniste. Käytä aria-labelledby-attribuuttia, kun tunnisteteksti on jo olemassa muualla DOMissa. Käytä aria-label-attribuuttia, kun sinun täytyy tarjota tunniste, joka ei näy näytöllä.

Lähteet

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM