Parempi käyttökokemus adaptiivisille verkkotyökaluille

Vuorovaikutuksen välineet

Ihmisille, jotka ovat riippuvaisia adaptiivisista verkkotyökaluista navigoidakseen internetissä, sisällön rakentamis- ja esitystapa on kaikki kaikessa. Maailman kehittyneinkään avustava teknologia ei voi lukea, ilmoittaa tai käyttää sisältöä, jota ei ole olemassa saavutettavassa muodossa. Painike, joka on todellisuudessa tyylitelty <div>, kuva ilman tekstivaihtoehtoa tai mukautettu pudotusvalikko ilman näppäimistötukea on yksinkertaisesti näkymätön — tai pahempaa, umpikuja — niille ihmisille, jotka ovat riippuvaisia näistä työkaluista joka päivä.

QualiBooth auttaa sinua ymmärtämään kaksi asiaa samanaikaisesti: miten käyttäjän työkalut todella tulkitsevat sisältöäsi ja mikä sisältö tai rakenne puuttuu, on rikki tai epäselvää. Juuri tämä yhdistelmä erottaa sivuston, joka teknisesti latautuu, sellaisesta, joka aidosti toimii kaikille.

Tämä opas käy läpi avustavan ja adaptiivisen teknologian pääkategoriat, miten kukin niistä odottaa verkkosivuston käyttäytyvän, ja käytännön askeleet, joilla voit rakentaa näiden työkalujen kanssa eikä niitä vastaan. Se vetää myös selkeän rajan aidon avustavan teknologian ja saavutettavuus-overlayden välille — koska nämä kaksi sekoitetaan usein toisiinsa, ja tällä sekaannuksella on todellisia seurauksia todellisille käyttäjille.

Mitä “adaptiiviset verkkotyökalut” oikeastaan tarkoittavat

Adaptiiviset verkkotyökalut — yleisemmin avustava teknologia (AT) — ovat ohjelmistoja ja laitteistoja, jotka muuttavat sitä, miten henkilö havaitsee tai käyttää digitaalista käyttöliittymää. Ne eivät ole lisäosia verkkosivustoosi; ne ovat käyttäjän oma ympäristö, joka on määritetty hänen tarpeisiinsa ja jota usein käytetään tuntikausia päivässä tuhansilla sivustoilla.

Pääkategorioita ovat:

Ruudunlukijat, jotka muuntavat näytöllä olevan sisällön syntetisoiduksi puheeksi tai päivittyväksi pistekirjoitukseksi.
Näytön suurennus, joka suurentaa ja uudelleenjärjestää osan näytöstä tai koko näytön.
Kytkinkäyttölaitteet ihmisille, jotka eivät voi käyttää tavallista näppäimistöä tai hiirtä.
Puheohjaus, joka ohjaa käyttöliittymää kokonaan puhutuilla komennoilla.
Selaimen ja käyttöjärjestelmän sisäänrakennetut ominaisuudet, kuten korkean kontrastin tilat, vähennetty liike ja lukutyökalut.
Luku- ja ymmärtämisapuvälineet, jotka yksinkertaistavat, lukevat ääneen tai uudelleenjäsentävät tekstiä.

Jokainen näistä nojaa samaan perustaan: hyvin jäsenneltyyn, semanttiseen, näppäimistöllä käytettävään sivuun, joka noudattaa vakiintuneita standardeja. Kun rakennat WCAG 2.2 -standardin mukaisesti, rakennat sen sopimuksen, josta jokainen näistä työkaluista on riippuvainen.

Ruudunlukijat: rakenne on käyttöliittymä

Ruudunlukijat ovat tunnetuin avustava teknologia ja monille tiimeille vaikein suunniteltava — juuri siksi, että näkemäsi visuaalinen asettelu kertoo sinulle lähes mitään siitä, mitä ruudunlukija ilmoittaa.

Käytetyimmät ruudunlukijat ovat NVDA ja JAWS Windowsissa, VoiceOver macOS:ssä ja iOS:ssä sekä TalkBack Androidissa. Ne eivät “näe” sivuasi; ne rakentavat mallin saavutettavuuspuusta, joka johdetaan HTML-semantiikastasi ja mahdollisesta ARIA:sta, jonka lisäät sen päälle.

Mitä ruudunlukijat tarvitsevat sinulta

Aitoja semanttisia elementtejä. Käytä <button>, <a>, <nav>, <main>, <h1>–<h6> ja <table> siihen, mitä ne ovat. Otsikon on oltava otsikko, jotta käyttäjät voivat hypätä osioiden välillä; linkin on oltava linkki, jotta se näkyy linkkilistassa.
Merkityksellisiä tekstivaihtoehtoja. Jokainen informatiivinen kuva tarvitsee alt-attribuutin, joka kuvaa sen tarkoituksen. Koristeellisilla kuvilla tulisi olla tyhjä alt="", jotta ne ohitetaan eikä niitä ilmoiteta meluna.
Ohjelmallisia tunnisteita ohjauselementeille. Lomakekentät tarvitsevat liitetyt <label>-elementit; pelkkiä kuvakkeita sisältävät painikkeet tarvitsevat saavutettavan nimen aria-label-attribuutin tai visuaalisesti piilotetun tekstin kautta.
Looginen otsikkohierarkia. Otsikot ovat ensisijainen tapa, jolla ruudunlukijan käyttäjät silmäilevät sivua. Tasojen ohittaminen tai otsikoiden käyttäminen pelkästään visuaaliseen kokoon rikkoo tämän navigoinnin.
Oikea ARIA — ja vain tarvittaessa. ARIA voi viestiä tiloja (laajennettu, valittu, poistettu käytöstä) ja rooleja mukautetuille widgeteille, mutta huono ARIA on huonompi kuin ei ARIA:a lainkaan. ARIA:n ensimmäinen sääntö on käyttää natiivia HTML:ää aina kun mahdollista.

Yleinen sekaannuksen aihe on ero ruudunlukijan ja tavallisen tekstistä puheeksi -toiminnon välillä. Lukutyökalu lukee tekstiä ääneen; ruudunlukija paljastaa ja käyttää koko käyttöliittymää, mukaan lukien ohjauselementit, tilat ja navigoinnin. Käsittelemme tätä eroa syvällisesti artikkelissa tekstistä puheeksi vastaan ruudunlukijat.

Koska automatisoidut työkalut voivat havaita vain murto-osan ruudunlukijaongelmista, ainoa luotettava tapa tietää, miltä sivustosi kuulostaa, on testata sitä niin kuin käyttäjät tekevät. Ruudunlukijan testausoppaamme käy läpi käytännön työnkulun, ja erillinen ruudunlukija-arviointi vie tärkeimmät käyttäjäpolkusi tämän prosessin läpi kokeneiden testaajien kanssa.

Näytön suurennus: suunnittele lähennettyä näkymää varten

Heikkonäköiset suurentavat näyttöä usein 200 %:sta 800 %:iin tai enemmän, katsoen vain pientä siivua sivusta kerrallaan. Jotkut käyttävät käyttöjärjestelmän suurenninta; toiset luottavat selaimen zoomiin tai erikoisohjelmistoihin.

Korkealla suurennuksella asetteluvalinnat, joita et koskaan ajattele, muuttuvat ratkaisevan tärkeiksi:

Uudelleenjärjestely (reflow). Sisällön on järjestyttävä uudelleen yhteen sarakkeeseen 400 %:n zoomilla (WCAG 2.2 -onnistumiskriteeri 1.4.10), jotta käyttäjien ei tarvitse vierittää kahteen suuntaan lukeakseen lauseen.
Toisiinsa liittyvien elementtien läheisyys. Jos virheilmoitus ilmestyy kauas kentästä, jota se kuvaa, suurentava käyttäjä ei välttämättä koskaan näe niitä samassa näkymässä. Pidä tunnisteet, syöttökentät ja palaute yhdessä.
Näkyvä kohdistus. Selkeä, korkean kontrastin kohdistusilmaisin antaa suurentavalle käyttäjälle mahdollisuuden löytää, missä hän on, kun näkymä hyppää.
Ei sisällön tai toiminnon menetystä. Mitään ei pitäisi leikata, peittää tai tehdä toimintakelvottomaksi, kun teksti suurennetaan jopa 200 %:iin (onnistumiskriteeri 1.4.4).

Suurennus palkitsee puhtaat, responsiiviset asettelut ja rankaisee kiinteäpikselisistä suunnitteluista ja sisällöstä, joka on riippuvainen hiiren osoituksesta (hover).

Kytkinkäyttö ja näppäimistökäytettävyys

Kytkinlaitteet antavat ihmisten käyttää tietokonetta yhdellä tai kahdella yksinkertaisella syötteellä — painikkeella, imu-puhalluslaitteella tai pään liikkeellä — yleensä skannaamalla interaktiivisia elementtejä yksi kerrallaan. Kytkinkäyttö rakentuu näppäimistötuen päälle: jos sivustosi toimii täysin näppäimistöltä, se toimii lähes varmasti myös kytkimillä.

Tämä tekee täydestä näppäimistökäytettävyydestä yhden vaikuttavimmista asioista, jotka voit saada oikein:

Kaikki saavutettavissa. Jokaisen interaktiivisen elementin on oltava kohdistettavissa ja käytettävissä ilman hiirtä — linkit, painikkeet, lomakeohjaimet, valikot, modaalit, karusellit ja mukautetut widgetit kaikki mukaan lukien.
Näkyvä, looginen kohdistusjärjestys. Kohdistuksen tulisi liikkua sivun läpi järjestyksessä, joka vastaa visuaalista ja lukuvirtaa, ja kohdistetun elementin on aina oltava selvästi osoitettu.
Ei näppäimistöansoja. Käyttäjien on voitava siirtää kohdistus ulos mistä tahansa komponentista, mukaan lukien upotettu media ja dialogit.
Ohituslinkit. “Siirry pääsisältöön” -linkki antaa ihmisille mahdollisuuden ohittaa toistuvan navigoinnin sen sijaan, että he silmäilisivät sen läpi jokaisella sivulla.

Jos asiakas täyttää lomaketta, voiko hän siirtyä sarkainnäppäimellä jokaisen kentän läpi, avata pudotusvalikon, valita tuotteen ja lähettää — kaikki ilman hiiren koskettamista? Toimiiko selaimen automaattinen täyttö merkintäsi kanssa? Nämä ovat kysymyksiä, joihin kytkin- ja näppäimistökäyttäjät vastaavat sivustostasi, kysyit niitä tai et.

Puheohjaus: nimet ja näkyvät tunnisteet ovat tärkeitä

Puheohjaustyökalut, kuten Dragon, Voice Control ja Voice Access, antavat käyttäjien sanoa komentoja kuten “klikkaa Lähetä” tai “vieritä alas”. Jotta nämä komennot toimisivat, ohjauselementin näkyvän tunnisteen on vastattava sen saavutettavaa nimeä. Tämä on WCAG 2.2 -onnistumiskriteerin 2.5.3, Label in Name, perusta.

Käytännön ohjeita:

Saavutettavan nimen tulisi sisältää näkyvä teksti. Jos painikkeessa lukee “Lähetä viesti”, älä anna sille aria-label-arvoa “Lähetä lomake” — käyttäjä, joka sanoo “klikkaa Lähetä viesti”, jätetään huomiotta.
Vältä pelkkiä kuvakkeita sisältäviä ohjaimia ilman tekstiä tai anna niille saavutettava nimi, joka vastaa todennäköistä puhuttua komentoa.
Pidä klikattavat kohteet riittävän suurina luotettavaa valintaa varten, mikä myös täyttää WCAG 2.2:n kohdekokokriteerin.

Selaimen ja käyttöjärjestelmän saavutettavuusominaisuudet

Kaikki adaptiiviset työkalut eivät ole erillisiä tuotteita. Modernit selaimet ja käyttöjärjestelmät toimitetaan tehokkailla sisäänrakennetuilla ominaisuuksilla, jotka käyttäjät ottavat käyttöön järjestelmänlaajuisesti, ja sivustosi tulisi kunnioittaa niitä automaattisesti:

Vähennetty liike. Kunnioita prefers-reduced-motion -mediakyselyä poistaaksesi käytöstä tai pehmentääksesi animaatioita käyttäjille, jotka kokevat pahoinvointia tai häiriötekijöitä liikkeestä.
Tumma tila ja korkea kontrasti. Tue prefers-color-scheme -ominaisuutta sekä Windowsin korkeaa kontrastia / Forced Colors -tilaa, jotta käyttöliittymäsi pysyy luettavana ilman, että taistelet käyttäjän asetuksia vastaan.
Tekstin koon muuttaminen ja zoomaus. Käytä suhteellisia yksiköitä, jotta selaimen tekstin skaalaus toimii, sen sijaan että lukitset koot pikseleihin.
Lukutilat ja lukutyökalut. Selaimen lukunäkymät ja työkalut kuten Immersive Reader riisuvat sivun sen ydinsisältöön — mikä toimii paljon paremmin, kun HTML:si on semanttista ja vapaata sotkusta.

Nämä ominaisuudet eivät maksa käyttäjälle mitään ylimääräistä ja sinulle hyvin vähän, mutta ne parantavat dramaattisesti mukavuutta laajalle yleisölle, mukaan lukien ihmiset ilman diagnosoituja vammoja.

Luku- ja ymmärtämistyökalut

Lukutyökalut palvelevat ihmisiä, joilla on lukihäiriö, ADHD, kognitiivisia vammoja tai rajallinen lukutaito sivun kielellä. Niihin kuuluvat tekstistä puheeksi -lukijat, lukuviivaimet, sanojen korostus, tiivistäjät ja käännöstyökalut.

Toimiaksesi hyvin niiden kanssa:

Kirjoita yksinkertaisella, hyvin järjestetyllä kielellä kuvailevilla otsikoilla ja lyhyillä kappaleilla.
Merkitse sivu siten, että pääsisältö on selvästi tunnistettavissa ja lukujärjestys on oikea.
Vältä merkityksen välittämistä pelkän värin, asettelun tai kuvien avulla — tarjoa tekstivastine.
Varmista, että kielesi on määritelty (lang-attribuutti), jotta ääneen lukeminen ja kääntäminen käyttävät oikeaa ääntämystä ja sääntöjä.

Hyvä sisältörakenne auttaa jokaista tämän artikkelin työkalua samanaikaisesti, koska ne kaikki ammentavat samasta taustalla olevasta merkinnästä.

Aito avustava teknologia vastaan saavutettavuus-overlayt

Tämä on tärkein ero, ja juuri tässä monet organisaatiot menevät pieleen.

Aito avustava teknologia — ruudunlukijat, suurentimet, kytkinkäyttö, puheohjaus — toimii käyttäjän laitteella, käyttäjän hallinnassa, ja käyttää sinun verkkosivustoasi sen semantiikan ja näppäimistötuen kautta. Käyttäjä on viettänyt vuosia sen määrittämiseen. Sinun tehtäväsi on yksinkertaisesti rakentaa sivu, jonka nämä työkalut voivat ymmärtää.

Saavutettavuus-overlayt ovat kolmannen osapuolen skriptejä, joita lisäät omaan sivustoosi ja jotka lupaavat tehdä siitä automaattisesti “saavutettavan”, yleensä kelluvan widgetin kautta. Ne eivät ole korvike avustavalle teknologialle, eivätkä ne korjaa saavuttamatonta sivustoa. Tässä syyt:

Ne eivät voi korjata taustalla olevaa koodia. Overlayt sijaitsevat sivun päällä; ne eivät voi luotettavasti keksiä puuttuvaa alt-tekstiä, korjata rikkinäisiä otsikkorakenteita tai saada <div>-elementtiä käyttäytymään kuin aito painike jokaisessa ruudunlukijassa.
Ne ovat usein ristiriidassa aidon AT:n kanssa. Monet ruudunlukijan käyttäjät raportoivat, että overlayt häiritsevät työkaluja, joihin he jo luottavat, tehden sivustoista joskus vaikeampia käyttää, ei helpompia.
Ne luovat väärän vaatimustenmukaisuuden tunteen. Widgetin asentaminen ei täytä WCAG 2.2, EAA tai ADA -vaatimuksia. Overlayt käyttäviä sivustoja vastaan on nostettu oikeusjuttuja juuri siksi, että taustalla olevat esteet säilyivät.
Ne eivät heijasta eletyä kokemusta. Saavutettavuuden arvioivat lopulta ne ihmiset, jotka käyttävät AT:tä joka päivä — siksi suoritamme vammaisten henkilöiden tekemiä auditointeja sen sijaan, että luottaisimme skriptin väitteisiin.

Luotettava polku on korjata saavutettavuus koodissa ja validoida se sekä automatisoidulla että ihmisen tekemällä testauksella. Selitämme tätä filosofiaa kattavammin artikkelissa mitä aito digitaalinen saavutettavuus tarkoittaa.

Käytännön työnkulku adaptiivisten työkalujen kanssa rakentamiseen

Avustavalle teknologialle rakentaminen ei ole kertaluonteinen projekti; se on prosessi, joka sopii siihen, miten jo toimitat ohjelmistoa. Kestävä lähestymistapa yhdistää yleensä neljä asiaa:

Automatisoitu skannaus, aikaisin ja usein. Työkalut kuten saavutettavuuden skannausohjelmisto havaitsevat suuren määrän koodi-tason ongelmia — puuttuvia tunnisteita, kontrastivirheitä, rikkinäistä ARIA:a — ennen kuin ne pääsevät tuotantoon. Automatisoidut tarkistukset ovat nopeita ja toistettavia, mutta ne kattavat vain osan kokonaiskuvasta.
Manuaalinen ja avustavan teknologian testaus. Ongelmat, jotka eniten vaikuttavat todellisiin käyttäjiin — sekava kohdistusjärjestys, epäselvät ilmoitukset, käyttökelvottomat mukautetut widgetit — vaativat ihmistä. Manuaalisten saavutettavuusauditointien oppaamme kuvaa, miten tämä täydentää automaatiota.
Saavutettavuuden juurruttaminen tiimiisi. Saavutettavuuden käsitteleminen jatkuvana kurinalaisuutena, jota tukee saavutettavuusprosessin parantaminen, estää hitaan taantumisen, joka tapahtuu, kun korjaukset ovat kertaluonteisia.
Oikea työkalusto pinollesi. QualiBoothin saavutettavuustyökalupakki tuo skannauksen, valvonnan ja raportoinnin yhteen, kun taas Agora ja community-versiomme tarjoavat aloituspisteitä eri kypsyysvaiheissa oleville tiimeille.

Jos tämän artikkelin termistö on sinulle uutta, saavutettavuussanasto on hyödyllinen kumppani, kun otat nämä käytännöt käyttöön.

Mihin QualiBooth sopii

QualiBooth tunnistaa ongelmat olemassa olevalla verkkosivustollasi ja voi myös skannata sivut ennen niiden julkaisua, jotta mitä tahansa adaptiivista työkalua käyttävät asiakkaat saavat saumattoman kokemuksen, joka lisää käytettävyyttä ja brändiuskollisuutta. Yhdistämme automatisoidun havaitsemisen kokeneiden testaajien ja vammaisten henkilöiden tekemään arviointiin ja autamme sitten tiimiäsi muuttamaan havainnot kestäviksi korjauksiksi — emme koskaan overlay-ratkaisuksi, joka peittää ongelman.

Tavoite on suoraviivainen: verkkosivusto, joka toimii yhdessä niiden työkalujen kanssa, joihin käyttäjäsi jo luottavat, heidän ehdoillaan, joka kerta kun he vierailevat.

Oletko valmis näkemään, miten sivustosi toimii aidon avustavan teknologian kanssa? Suorita ilmainen saavutettavuusskannaus löytääksesi nopeita voittoja, pyydä esittely nähdäksesi QualiBoothin toiminnassa tai keskustele tiimimme kanssa räätälöidystä saavutettavuuskonsultointi -toimeksiannosta.