Saavutettavat käyttöliittymän komponentit Webissä

Päästäkseen käyttöliittymäkomponenttien on toimittava useiden laitteiden välillä, joiden näytön koko ja näyttö on erilainen. Lisäksi komponenttien tulisi olla käytettävissä laajimmalle käyttäjäryhmälle, vammaiset mukaan lukien.

Suunniteltaessa esteettömyyttä on huomioitava neljä vammaisuuden avainaluetta: visio, kuulo, liikkuvuus ja kognitio.

Visuaaliset kysymykset voivat vaihdella kyvyttömyydestä erottaa värit tai olla visiomatta ollenkaan.

  • Varmista, että kontrastisuhteen vähimmäisraja saavutetaan tekstisisällössä.
  • Vältä tietojen välittämistä pelkästään väreillä ja varmista, että kaiken tekstin kokoa voidaan muuttaa.
  • Varmista, että kaikkia käyttöliittymän komponentteja voidaan käyttää avustavien tekniikoiden kanssa, kuten näytönlukija, suurennuslasi ja pistekirjoitusnäyttö. Tämä edellyttää sen varmistamista, että käyttöliittymäkomponentit on merkitty siten, että esteettömyysliittymät voivat ohjelmallisesti määrittää minkä tahansa elementin roolin, tilan, arvon ja otsikon.

Kuulovaikeudet tarkoittavat, että käyttäjällä voi olla ongelmia kuulla sivulta lähetettyä ääntä.

  • Tee sisällöstä ymmärrettävää käyttämällä tekstivaihtoehtoja kaikelle sisällölle, joka ei ole tiukasti tekstiä.
  • Varmista, että testaat, että käyttöliittymäkomponentit ovat edelleen toiminnassa ilman ääntä.

Liikkuvuusongelmiin voi kuulua kyvyttömyys käyttää hiirtä, näppäimistöä tai kosketusnäyttöä.

  • Tee käyttöliittymäkomponenttien sisältö toiminnallisesti saatavissa näppäimistöltä kaikille toimille, joihin muuten käytettäisiin hiirtä.
  • Varmista, että käyttöliittymän komponentit on merkitty oikein avustekniikoihin; nämä käyttäjät voivat käyttää tekniikoita, kuten ääniohjausohjelmistoja ja fyysisiä kytkimen ohjaimia, joilla on taipumus käyttää samoja sovellusliittymiä kuin muilla avustekniikoilla, kuten näytönlukijalla.

Kognitiiviset ongelmat tarkoittavat, että käyttäjä voi tarvita aputekniikoita auttamaan heitä tekstin lukemisessa, joten on tärkeää varmistaa, että tekstivaihtoehdot ovat olemassa.

  • Vältä toistuvaa tai vilkkuvaa visuaalista esitystä, koska tämä voi aiheuttaa joillekin käyttäjille ongelmia.
  • Vältä vuorovaikutusta, joka perustuu ajoitukseen.

Tämä voi tuntua monelta pohjalta, mutta käymme läpi prosessin, jolla arvioidaan ja sitten parannetaan käyttöliittymäkomponentin käytettävyyttä.

Onko käyttöliittymäkomponentti käytettävissä?

Yhteenveto (tl; dr)

Kun tarkastelet pääsyhakemustasi, kysy itseltäsi:

  • Voitko käyttää käyttöliittymäkomponenttia vain näppäimistön kanssa? Pystyykö se keskittymään ja välttämään keskittymisloukkuja? Voiko se vastata asianmukaisiin näppäimistötapahtumiin?
  • Voitko käyttää käyttöliittymäsi komponenttia näytönlukijan kanssa? Oletko antanut tekstivaihtoehtoja visuaalisesti esitetyille tiedoille? Oletko lisännyt semanttista tietoa ARIA: n avulla?
  • Voiko käyttöliittymäkomponentti toimia ilman ääntä? Sammuta kaiuttimet ja käy läpi käyttölaukut.
  • Voiko se toimia ilman väriä? Varmista, että käyttöliittymän komponenttia voi käyttää joku, joka ei näe värejä. Hyödyllinen työkalu värisokeuden simulointiin on SEE-niminen Chrome-laajennus (kokeile kaikkia neljää saatavana olevaa värisokeuden simulointimuotoa). Saatat olla kiinnostunut myös Daltonize-laajennuksesta, joka on samoin hyödyllinen.
  • Voiko käyttöliittymäkomponentti toimia korkean kontrastin tilassa käytössä? Kaikki nykyaikaiset käyttöjärjestelmät tukevat korkea kontrastitilaa. High Contrast on saatavana oleva Chrome-laajennus, josta voi olla apua tässä.

Alkuperäisillä säätimillä (kuten ja ) on sisäänrakennettu pääsy selaimeen. Ne ovat tarkennettavissa sarkainnäppäimellä, reagoivat näppäimistötapahtumiin (kuten Enter, välilyönti ja nuolinäppäimet), ja niillä on semanttiset roolit, tilat ja ominaisuudet, joita esteettömyysvälineet käyttävät. Oletusmuodon tulee myös täyttää saavutettavuusvaatimukset, jotka on lueteltu yllä.

Mukautetuissa käyttöliittymäkomponenteissa (lukuun ottamatta komponentteja, jotka laajentavat alkuperäisiä elementtejä, kuten ), ei ole sisäänrakennettuja toimintoja, mukaan lukien esteettömyys, joten sinun on toimitettava tämä. Hyvä paikka aloittaa saavutettavuuden saavuttamisessa on vertailla komponenttejasi vastaavaan natiiviin elementtiin (tai useiden natiivien elementtien yhdistelmään sen mukaan, kuinka monimutkainen komponentti on).

Seuraava on luettelo kysymyksistä, joita voit kysyä itseltäsi yrittäessäsi tehdä käyttöliittymäkomponenteista helpompaa käytettävyyttä.

Voidaanko käyttöliittymäsi komponenttia käyttää pelkästään näppäimistön kanssa?

Ihannetapauksessa varmista, että käyttöliittymäkomponentin kaikki toiminnot voidaan saavuttaa näppäimistöllä. Mieti UX-suunnittelusi aikana, kuinka käyttäisit elementtiä vain näppäimistön kanssa, ja selvitä johdonmukainen näppäimistötoimintojen joukko.

Ensinnäkin, varmista, että sinulla on järkevä tarkennuskohde jokaiselle komponentille. Esimerkiksi monimutkainen komponentti, kuten valikko, voi olla yksi tarkennuskohde sivulla, mutta sen tulisi sitten hallita tarkennusta itsessään, jotta aktiivinen valikkokohta keskittyy aina.

Tarkennuksen hallinta monimutkaisessa elementissä

Tabindexin käyttö

Tabindex-määritteen avulla elementit / käyttöliittymäkomponentit voidaan keskittää näppäimistön avulla. Vain näppäimistön ja avustavan tekniikan käyttäjien on pystyttävä keskittymään näppäimistöön elementteihin ollakseen vuorovaikutuksessa heidän kanssaan. Alkuperäiset vuorovaikutteiset elementit ovat epäsuorasti tarkennettavissa, joten he eivät tarvitse tabindex-määritteitä, ellemme halua muuttaa heidän sijaintia välilehtijärjestyksessä.

Tabindex-arvoja on kolme tyyppiä:

  • tabindex = ”0” on yleisin ja sijoittaa elementin “luonnollisen” välilehden järjestykseen (DOM-järjestyksen määrittelemä).
  • Jos tabindex-arvo on suurempi kuin 0, asetetaan elementti manuaaliseen välilehtijärjestykseen - kaikki sivun elementit, joilla on positiivinen tabindex-arvo, käyvät numerojärjestyksessä ennen elementtejä luonnollisessa välilehden järjestyksessä.
  • Tabindex-arvo, joka on -1, saa elementin ohjelmoidusti tarkennettavaksi, mutta ei välilehtijärjestyksessä.

Mukautettujen käyttöliittymäkomponenttien tapauksessa käytä aina tabindex-arvoja 0 tai -1, koska et voi määrittää tietyn sivun elementtien järjestystä etukäteen - ja vaikka tekisimmekin, ne saattavat muuttua. Tabindex-arvo -1 on erityisen hyödyllinen keskittymisen hallitsemiseksi monimutkaisissa komponenteissa, kuten yllä on kuvattu.

Varmista myös, että tarkennus on aina näkyvissä joko sallimalla tarkennuksen oletussoittoääni tai soveltamalla havaittavissa olevaa tarkennustyyliä. Muista olla notkauttamatta näppäimistön käyttäjää - tarkennus pitäisi voida siirtää pois elementistä käyttämällä vain näppäimistöä.

Saatat olla kiinnostunut myös MDN: n kattamista kiertävistä välilehdistä tai aria-aktiivisista johtavista lähestymistavoista.

Automaattitarkennuksen käyttäminen

HTML-automaattitarkennusattribuutti antaa tekijälle määrittää, että tietyn elementin tulisi keskittyä automaattisesti sivun lataamisen yhteydessä. Sitä tuetaan jo kaikissa verkkomuodon ohjaimissa, mukaan lukien . Jos haluat tarkentaa elementtejä omiin mukautettuihin käyttöliittymäkomponenteihisi, soita focus () -menetelmälle, jota tuetaan kaikissa kohdistettavissa olevissa HTML-elementeissä (esim. Document.getElementById ('myButton'. Focus. ()).

Näppäimistövuorovaikutuksen lisääminen

Kun käyttöliittymäkomponentti on tarkennettavissa, yritä tarjota hyvä näppäimistövuorovaikutustiedosto, kun komponentti on tarkennettu, käsittelemällä asianmukaisia ​​näppäimistötapahtumia - anna käyttäjän esimerkiksi käyttää nuolinäppäimiä valikkovaihtoehtojen valitsemiseen ja välilyöntiä tai syöttää aktivoidaksesi painikkeita. ARIA-suunnittelumalliopas tarjoaa tässä joitain ohjeita.

Varmista lopuksi, että pikanäppäimet ovat löydettävissä. Esimerkiksi yleinen käytäntö on, että pikanäppäimillä (näytöllä oleva teksti) ilmoitetaan käyttäjälle, että oikotiet on olemassa. Esimerkiksi ”Paina? pikanäppäimille ”. Vaihtoehtoisesti vihjettä tällaiseen työkaluvihjeeseen voidaan käyttää ilmoittamaan käyttäjälle olemassa olevasta pikakuvakkeesta.

Keskittymisen hallinnan merkitystä ei voida aliarvioida. Yksi esimerkki on navigointilaatikko. Jos lisäät käyttöliittymäkomponentin sivulle, sinun on kohdistettava kohdistus sivun sisäiseen elementtiin, muuten käyttäjien on ehkä joutettava välilehti läpi koko sivun päästäkseen sinne. Tämä voi olla turhauttavaa, joten muista testata kaikkien sivusi näppäimistön avulla navigoitavien komponenttien keskittyminen.

Voitko käyttää käyttöliittymäsi komponenttia näytönlukijan kanssa?

Noin 1–2% käyttäjistä käyttää näytönlukijaa. Tämän artikkelin lopussa luetellaan joitain näytönlukijoita, joita voidaan käyttää vapaasti: kokeile käyttää komponenttia vähintään yhden näistä näytönlukijoista kanssa. Voitko määrittää kaikki tärkeät tiedot ja olla vuorovaikutuksessa komponentin kanssa pelkällä näytönlukijalla ja näppäimistöllä?

Seuraavien kysymysten pitäisi auttaa sinua käsittelemään näytönlukijan saavutettavuutta:

Onko kaikilla komponenteilla ja kuvilla merkityksellisiä tekstivaihtoehtoja?

Aina, kun interaktiivisen komponentin nimestä tai tarkoituksesta välitetään tietoja visuaalisesti, on tarjottava käytettävä tekstivaihtoehto.

Esimerkiksi, jos UI-komponentti näyttää vain kuvakkeen, kuten ..

Asetukset-valikkokuvake

osoittaakseen, että se on asetusvalikko, se tarvitsee käytettävän tekstivaihtoehdon, kuten ”asetukset”, joka välittää samat tiedot. Kontekstista riippuen, tämä voi käyttää alt-attribuuttia, aria-label-attribuuttia, aria-labelledby -attribuuttia tai tavallista tekstiä Shadow DOM -sovelluksessa. Löydät yleisiä teknisiä vinkkejä WebAIM-pikaoppaasta.

Kaikkien kuvan näyttävien käyttöliittymäkomponenttien tulisi tarjota mekanismi vaihtoehtoisen tekstin tarjoamiseksi kyseiselle kuvalle, vastaavasti alt-määritteelle.

Antavatko komponentit semanttista tietoa?

Avustekniikka välittää semanttista tietoa, joka muuten ilmaistaan ​​näkökykyisille käyttäjille visuaalisten ohjeiden, kuten muotoilun, kohdistintyylin tai sijainnin, kautta. Alkuperäisillä elementeillä on semanttinen semanttinen informaatio, mutta räätälöityjen komponenttien lisäämiseksi tietoihin on käytettävä ARIA: ta.

Peukalosääntönä, että kaikilla komponenteilla, jotka kuuntelevat hiiren napsautusta tai hiiritapahtumaa, ei tulisi olla vain jonkinlainen näppäimistötapahtuman kuuntelija, vaan myös ARIA-rooli ja mahdollisesti ARIA-tilat ja määritteet.

Esimerkiksi mukautettu UI-komponentti voi ottaa ARIA-liukusäätimen roolin, jolla on joitain liittyviä ARIA-ominaisuuksia: aria-valuenow, aria-valuemin ja aria-valuemax. Sitomalla nämä ominaisuudet mukautetun komponentin asiaankuuluviin ominaisuuksiin, voit antaa aputekniikan käyttäjille olla vuorovaikutuksessa elementin kanssa ja muuttaa sen arvoa, ja jopa aiheuttaa elementin visuaalisen esityksen muutoksen vastaavasti.

Alueen liukusäätimen komponentti
 

Voivatko käyttäjät ymmärtää kaiken luottamatta väriin?

Väriä ei tule käyttää ainoana keinona tiedon välittämiseen, kuten tilan ilmoittamiseen, vastauksen pyytämiseen tai visuaalisen mukautetun komponentin erottamiseen. Esimerkiksi, jos olet luonut -komponentin, joka käyttää väriä erottamaan raskas, kohtalainen ja kevyt liikenne, tulisi tarjota myös vaihtoehtoinen tapa erottaa liikennetiedot: yksi ratkaisu voi olla siirtää hiiren elementin päälle tietojen näyttämiseksi työkaluvihjeessä.

Onko tekstin / kuvien ja taustan välillä riittävästi kontrastia?

Kaikkien komponentteissasi näytettävien tekstisisällön tulee täyttää vähimmäisvaste (AA). Harkitse korkeakontrastisen teeman tarjoamista, joka täyttää ylemmän (AAA) palkin, ja varmista myös, että käyttäjäagenttityylitaulukoita voidaan käyttää, jos käyttäjät vaativat äärimmäistä kontrastia tai erilaisia ​​värejä. Voit käyttää tätä värikontrastitarkistusta apuna suunnittelussa.

Onko komponenttien liikkuva tai vilkkuva sisältö pysäytettävissä ja turvallinen?

Sisältö, joka liikkuu, vierittää tai vilkkuu yli viiden sekunnin ajan, pitäisi voida keskeyttää, pysäyttää tai piilottaa. Yritä yleensä vilkkua enintään kolme kertaa sekunnissa.

Helppokäyttöisyys

Saatavana on useita työkaluja, jotka voivat auttaa visuaalisten komponenttien käytettävyyden virheenkorjauksessa. Nämä sisältävät:

  • ax - automatisoitu käytettävyystestaus valitsemasi kehyksen tai selaimen kanssa
  • Chromen majakan saavutettavuustarkastukset tarjoavat hyödyllisiä oivalluksia esteettömyysongelmien löytämiseksi.
Alkuperäisen saavutettavuuden tarkastus DevToolsissa
  • Tenon.io - hyödyllinen yleisten saavutettavuusongelmien testaamiseen. Tenonilla on vahva integraatiotuki rakennustyökaluissa, selaimissa (laajennusten kautta) ja jopa tekstieditorissa.
  • Voit tutkia tapaa, jolla avustekniikat näkevät verkkosisällön, käyttämällä Accessibility Inspector (Mac) tai Windows Automation API Testing Tools ja AccProbe (Windows) -sovelluksia. Lisäksi voit nähdä Chromen luoman täydellisen esteettömyyspuun siirtymällä kohtaan chrome: // saavutettavuus.
  • Paras tapa testata näytönlukijatukea Macilla on VoiceOver-apuohjelman käyttö. Voit käyttää ⌘F5 aktivoidaksesi / poistaaksesi käytöstä, Ctrl + Optio ← → liikkuaksesi sivulla ja Ctrl + Vaihto + Optio + ↑ ↓ siirtääksesi puuta ylös / alas. Tarkempia ohjeita on täydellisessä luettelossa VoiceOver-komennoista ja luettelossa VoiceOver-Web-komennoista.
  • tota11y on hyödyllinen visualisoija Khan Akatemian rakentamiin avustekniikkakysymyksiin. Se on skripti, joka lisää painikkeen asiakirjaan, joka laukaisee useita laajennuksia huomautusten tekemiseen, kuten riittämätön kontrastisuhde ja muut a11y rikkomukset
  • ally.js (kirjoittanut Rodney Rehm) on kirjasto, joka yrittää yksinkertaistaa muutamien esteettömyysominaisuuksien lisäämistä sovellukseesi. Se auttaa kysymään DOM: sta kaikkia fokusoitavia tai tabboitavia elementtejä, ansaitsee keskittyä tiettyihin DOM-alapuihin, auttaa määrittämään, kuinka tarkennus on muuttunut ja miten se tulee useiden muiden auttajien kanssa.
  • Windows, NVDA on ilmainen, avoimen lähdekoodin näytönlukija, joka on täysin varustelluissa ja kasvattaa nopeasti suosiotaan. Huomaa kuitenkin, että sillä on huomattavasti jyrkempi oppimiskäyrä näkeville käyttäjille kuin VoiceOver.
  • ChromeLens auttaa kehittämään näkövammaisia. Sillä on myös suuri tuki näppäimistön navigointipolkujen visualisoinnille http://chromelens.xyz/
ChromeLens DevTools -laajennus, jolla on useita vaihtoehtoja sokeuden eri muotojen jäljittelemiseksi, välilehtien jäljitys ja esteettömyystarkastus.
  • ChromeVox on näytönlukija, joka on saatavana Chromen laajennuksena ja sisäänrakennettu ChromeOS-laitteisiin.

Huomaa: Suuret kiitokset Alice Boxhallille ja Rob Dodsonille avusta artikkelissa.

PS: Jos olet kiinnostunut oppimaan lisää, voit oppia esteettömyyden perusteista tästä ilmaisesta Udacity-kurssista https://bit.ly/web-a11y