Mistä nostetaan kanne: Käytännön opas 6 666 esteettömyysvalitusta taustalla olevista käyttöliittymämalleista

Otsikko on jokaisen sivun ensimmäinen vuorovaikutteinen alue, ja hampurilaispainike on usein ensimmäinen asia, johon näppäimistökäyttäjä pääsee käsiksi. Kun kyseinen painike näytetään <div> jos sivulla on CSS-taustakuva, sivulla ei ole esteetöntä nimeä tai jos valikko avautuu ja vie fokuksen tai ei ilmoita avoimen tai suljetun tilansa, koko sivusto muuttuu rakenteellisesti käyttökelvottomaksi näppäimistöllä jo ennen kuin käyttäjä on edes koskenut varsinaiseen sisältöön.

Ohituslinkki on toinen vika. Toimiva "Skip to main content" Linkki on viisirivinen korjaus, mutta se on myös tehokkain yksittäinen mittari sen selvittämiseen, onko esteettömyys ylipäätään kehitystiimin tarkistuslistalla. Valituksissa mainitaan usein molemmat samassa kappaleessa, sillä puuttuva tai toimimaton ohituslinkki toimii varoitusmerkkinä – jos tiimi ei ole lisännyt ohituslinkkiä, se ei ole lähes varmasti lisännyt myöskään aria-expanded-tiloja.

Muunna valikkokäynnistin todelliseksi <button> jossa on näkyvä tai vain näytönlukijalle tarkoitettu tekstimerkintä ja hallittu aria-expanded attribuutti. Määritä "Skip to main content" linkki, joka tulee näkyviin, kun hiiri viedään sen päälle, ja joka vie <main> maamerkki. Varmista, että kohdistus siirtyy valikkoon, kun se avautuu, palaa laukaisimeen, kun se sulkeutuu, ja että Esc sulkee valikon.

Hakutoiminto on useimmilla suurilla sivustoilla toteutettu mukautettuna komponenttina – viiveellä varustettuna tekstikenttänä, joka lähettää pyynnön jokaisen näppäinpainalluksen yhteydessä ja näyttää kelluvan ehdotuslistan absoluuttisesti sijoitetussa <div>. Itse tekstikenttä toimii yleensä hyvin. Ehdotuslista ei kuitenkaan toimi lähes koskaan. Se renderöidään tekstikentän DOM-kontekstin ulkopuolella, eikä sillä ole role="listbox", ei aria-activedescendant, eikä live-alueesta tule ilmoitusta tulosten ilmestyessä. Näytönlukijan käyttäjä kirjoittaa tekstiä, ei kuule mitään, painaa Enter-näppäintä ja saa tulossivun, jonka olemassaolosta hän ei ollut tietoinen.

Sama arkkitehtuurimalli toistuu faceted-search-suodatinpaneeleissa ja itse tulosluettelossa: elementit, joihin näppäimistön kohdistus voidaan siirtää ja jotka näkyvät ruudulla, mutta joita ei koskaan ilmoiteta ääneen. Hakutoimintoa koskevat valitukset eivät juurikaan koske hakukenttää, vaan kaikkea sitä, mikä tulee näkyviin sen jälkeen, kun käyttäjä on kirjoittanut hakusanan.

Käytä vakiintunutta WAI-ARIA-valintalista-mallia: role="combobox" syötteenä aria-expanded, aria-controlsja aria-activedescendant kytketty role="listbox" ehdotuksia. Lisää kohtelias reaaliaikainen alue, joka ilmoittaa tulosten lukumäärän. Varmista, että ehdotusluetteloon pääsee alas-nuolinäppäimellä, ei pelkästään hiirellä.

PLP-ruudukko kokoaa useita huonoja käytäntöjä yhdelle ruudulle. Jokainen ruutu on yleensä klikattava kortti, jossa on kolme tai neljä interaktiivista alielementtiä – kuvalinkki, otsikkolinkki, värinäytteet, pikalisäyspainike – ja joka on kääritty toiseen linkkiin tuotesivulle. Tuloksena on sisäkkäisiä interaktiivisia elementtejä (HTML-virhe), turhaa linkkitekstiä (neljä kertaa toistuva teksti ”Hero Dash Three Graphic Image Link”) sekä värinäytteitä, jotka on rakennettu <div> elementit, joilla on klikkauskäsittelijä mutta ei roolia eikä nimeä.

Suodattimen sivupalkki tuo mukanaan toisenlaisen virhetyypin. Suodatuskriteerit ovat yleensä valintaruutuluetteloita, mutta ne on rakennettu mukautetuista div- ja span-elementeistä, jotka on muotoiltu näyttämään valintaruuduilta, ja varsinaiset <input> piilotettu ruudun ulkopuolelle. Kun kyseinen piilotettu syöttökenttä menettää linkityksensä – joko CSS-säännön, välilyöntinäppäimen painallukset nielevän JavaScript-tapahtumankäsittelijän tai puuttuvan for näkyvän tekstikentän attribuutti — suodatinta voi käyttää vain hiirellä.

Käytä yhtä ankkuria kutakin tuotetta kohti ja liitä siihen kuvaava teksti, älä kolmea linkkiä tuotetta kohti. Esitä värimallit todellisuuden mukaisina <button> elementit sisällä role="radiogroup". Luo suodatussuodattimia todellisten <input type="checkbox"> elementit, joihin liittyy <label> tunnisteet; muokkaa syöttökenttien ulkoasua sen sijaan, että piilottaisit ne. Ilmoita suodattimen muutoksista kohteliaalla reaaliaikaisella alueella.

Tuotetietosivulla näytönlukijan käyttäjän on tehtävä useita tiettyjä valintoja oikeassa järjestyksessä: valittava väri, valittava koko, määritettävä määrä ja lisättävä tuote ostoskoriin. Jokainen näistä valinnoista on toteutettu nykyaikaisessa verkkokaupassa mukautettuna widgetinä – yleensä vaakasuuntaisena rivinä, jossa <button>-muotoinen <div>Koot, CSS-tyylillä muotoilluista div-elementeistä rakennetut värilaatat sekä kahdesta syöttökentän molemmin puolin sijaitsevasta kuvakepainikkeesta koostuva numeronvalitsin. Lisäys- ja vähennyspainikkeet toimitetaan yleensä ilman esteetöntä nimeä; valituksissa niitä kuvataan seuraavasti: julkaistu nimellä ”button, button” ilman mitään viitteitä siitä, mitä ne tekevät.

Kokotaulukot ja -ohjeet muodostavat oman ongelmakokonaisuutensa: ne löytyvät lähes aina ”Kokotaulukko”-linkin takaa, joka avaa ponnahdusikkunan, ja linkissä itsessään ei usein ole tekstiä, ponnahdusikkunalla ei usein ole näkyvää otsikkoa, eikä taulukossa ole usein rivien tai sarakkeiden otsikoita.

Käytä oikeita lomakekenttiä. Värinäytteet ja kokovalitsimet tulisi olla role="radiogroup" ... role="radio" painikkeet (tai näkymättömiksi muotoillut valintapainikkeet), joista jokaisella on esteetön nimi, kuten ”Koko: Keskikokoinen”. Määrän säätimessä tulisi olla nimikoitu numerokenttä sekä siihen liittyvät lisäys- ja vähennyspainikkeet, joiden esteettömissä nimissä mainitaan toiminto ja nykyinen määrä. Koko valintakokonaisuus tulisi sijoittaa fieldset-elementtiin, jossa on selite.

”Lisää ostoskoriin” on verkkokaupan ostopolun eniten testattu vaihe ja yksi niistä, jotka toimivat huonoimmin aputeknologian käyttäjille. Toimintamalli on yksinkertainen: kävijä painaa painiketta, pieni vahvistusilmoitus tai ostoskorin laatikko ilmestyy näkyviin kahdeksi tai kolmeksi sekunniksi, ja ostoskorikuvake päivittää otsikossa näkyvän kappalemäärän. Näkevät käyttäjät näkevät kaikki kolme signaalia. Näytönlukijan käyttäjät eivät yleensä näe yhtään. Ilmoitus näkyy live-alueen ulkopuolella, laatikko avautuu ilman fokuksen hallintaa ja ostoskorin sisältömäärän muutos toimitetaan tavallisena DOM-muutoksena, jota mikään näytönlukija ei ilmoita.

Tuloksena on painike, joka käyttäjän näkökulmasta ei tee mitään. Käyttäjä painaa sitä, ei kuule mitään, olettaa, että se ei toiminut, ja painaa sitä uudelleen. Joissakin valituksissa kerrotaan, että painiketta painettiin viisi tai kuusi kertaa, ennen kuin huomattiin, että ostoskoriin oli hiljaa kertynyt viisi tai kuusi tuotetta.

Kääri kärryn tilan alue aria-live="polite" ja päivitä sen teksti jokaisen onnistuneen lisäyksen yhteydessä. Jos suunnittelussa käytetään vahvistusvalikkoa, siirrä kohdistus valikkoon, kun se avautuu, ja palauta kohdistus alkuperäiseen painikkeeseen, kun valikko sulkeutuu. Päivitä ostoskorin kappalemäärän merkki näytönlukijalle tarkoitetulla ilmoituksella, kuten ”1 tuote lisätty. Ostoskorin yhteismäärä: 3 tuotetta.”

Pelkästään kuvakkeista koostuvat hallintalaitteet toimivat odotetulla tavalla: näkyvä sisältö on SVG-kuva tai kuvakefontin merkki, esteetön sisältö on tyhjä, ja näytönlukijan ääniilmoitus supistuu elementin rakenteelliseen rooliin ilman nimeä. Ostoskori-kuvake ilmoitetaan lopulta nimellä ”linkki” tai ”piilotettu”; puhekupla nimellä ”painike”; alatunnisteen sosiaalisen median kuvakkeiden rivi nimellä ”linkki, linkki, linkki, linkki, linkki”. Käyttäjällä ei ole mitään keinoa tietää, mitä kukin niistä tekee.

Ostoskori-ikonit epäonnistuvat muita ikoneita useammin rakenteellisesta syystä: monissa toteutuksissa ostoskorin sisältö näkyy ikonin esteettömässä nimessä (esim. ikoni näyttää SVG-tiedostossa numeron ”0”), ja näytönlukija lukee vain numeron. Valituksissa kerrotaan, että ostoskori-ikoni luetaan ääneen muodossa ”3, linkki” tai ”0, linkki” ilman mainintaa siitä, että ”3” viittaa ostoskorin sisältöön.

Jokaisella pelkästään kuvakkeesta koostuvalla ohjausobjektilla on oltava esteetön nimi. Lisää aria-label painikkeen päälle tai sijoita visuaalisesti piilotettu tekstikenttä sen sisään: "Shopping cart, 3 items". Vältä käyttämästä numerolukuja kuvakkeen esteettömässä nimessä ilman asiayhteyttä. Kun kyseessä ovat koristeelliset kuvakkeet, jotka sijaitsevat näkyvän tekstin vieressä, käytä aria-hidden="true" napsauta kuvaketta ja anna tekstin toimia nimikkeenä.

Kassasivu sisältää enemmän sääntöjen noudattamiseen liittyviä riskejä neliöpikseliä kohden kuin mikään muu verkkokaupan sivu, ja virheiden esiintyvyys on runsasta. Osoitevalikot on toteutettu mukautettuina <div> komponentit, jotka eivät reagoi välilyöntinäppäimeen. Pakollisten kenttien merkinnät näkyvät vain punaisena tähdellä, ilman aria-required eikä ohjelmointitason yhteyttä. Kentän alle punaisella tekstillä näkyvät rivin sisäiset virheilmoitukset, ilman aria-describedby kentän linkittäminen virheeseen ja live-alueen ilmoituksen puuttuminen, kun validointi epäonnistuu. Käyttäjä täyttää lomakkeen, painaa ”Jatka”-painiketta, ohjataan takaisin ilman selitystä eikä hänellä ole mitään keinoa tietää, mitkä kentät eivät täyttäneet vaatimuksia tai miksi.

Sama valitusten sisältö toistuu sadoissa tapauksissa: virheilmoitusta ei anneta, virheilmoitukset ovat epämääräisiä, laskutustietoja ei voi syöttää. Nämä eivät ole yksittäisiä virheitä. Ne ovat useimpien verkkokaupan kassakomponenttien oletusarvoista käyttäytymistä, kun niitä toimitetaan ilman nimenomaista esteettömyystyötä.

Käytä aitoa <label> syötteisiin liitetyt elementit for/id. Merkitse pakolliset kentät aria-required="true" ja ilmaise vaatimus näkyvällä tekstillä, ei pelkästään värillä. Jos validointi epäonnistuu, näytä virheilmoitus syöttökentän sisällä aria-describedby kohde, ilmoita virheellinen kenttä aria-invalid="true"ja siirrä näppäimistön kohdistus ensimmäiseen virheelliseen kenttään. Lisää lomakkeen yläosaan virheiden yhteenvetoalue, jossa on ankkurilinkit kuhunkin virheelliseen kenttään.

Maksulomake on poikkeuksellinen, koska se toimitetaan usein kolmannen osapuolen upotetun iframe-kehyksen kautta – esimerkiksi Stripe Elementsin, Braintree Hosted Fieldsin tai Adyenin drop-in-ratkaisun avulla. Iframe-kehyksen sisällä maksupalveluntarjoajan oma lomake on yleensä selkeästi merkitty. Mutta heti kun sivusto rakentaa oman korttitietojen syöttöalustansa tai käärii upotetut kentät mukautettuun asetteluun, joka korvaa merkinnät visuaalisilla paikkamerkkeillä, neljästä kentästä – numero, voimassaoloaika, CVV, postinumero – tulee näytönlukijalle rivi tyhjiä syöttökenttiä.

CVV-kenttä on se, joka on useimmin merkitty väärin, koska suunnittelijat korvaavat sen nimikkeen usein kysymysmerkkikuvakkeella, joka avaa työkaluvihjeen, jossa selitetään, mikä CVV on. Työkaluvihje ei ole kentän nimike; kentälle tarvitaan silti ohjelmointinimi. Jos sellaista ei ole, näytönlukija lukee koko maksukentän tekstin ”muokkaa, muokkaa, muokkaa, muokkaa” ja tapahtuma keskeytyy.

Jos käytät kolmannen osapuolen tarjoamaa kenttien integrointiratkaisua, noudata toimittajan esteettömyysohjeita – useimmat tarjoavat dokumentoidun tavan nimetä kentät iframe-kehyksen ulkopuolelta. Jos rakennat mukautettua korttitietojen syöttötoimintoa, jokaiselle syöttökentälle tarvitaan oikea <label> elementti, jossa on näkyvä tekstimerkintä, sekä autocomplete="cc-number" / cc-exp" / cc-csc" ominaisuudet, jotta salasananhallintaohjelmat ja aputeknologiat voivat tunnistaa kentät niiden käyttötarkoituksen perusteella.

Ostoskorisivulla toistuu tuotetietosivun määränvalitsimen toimintahäiriö, mutta tällä kertaa panokset ovat korkeammat: näytönlukijaa käyttävä asiakas, joka ei pysty käyttämään valitsinta, ei voi viedä tilausta loppuun. ”Poista”-painike on oma anti-mallinsa – se on yleensä pieni ×-kuvake kunkin rivin vieressä, usein ilman näkyvää tekstiä, ilman aria-label, eikä rivin poistamisesta tule mitään ilmoitusta. Käyttäjä painaa painiketta, jonka toivoo olevan poistopainike, rivi katoaa, mutta näytönlukija ei sano mitään. Ei ole mitään keinoa varmistaa, onko toiminto onnistunut.

Useissa valituksissa kuvataan samankaltaista toimintahäiriötä: ostoskorin kokonaissumma päivittyy reaaliaikaisesti, kun tuotemääriä muutetaan tai tuotteita poistetaan, mutta uusi summa näkyy tavallisena DOM-tekstinä reaaliaikaisen alueen ulkopuolella, joten käyttäjä ei tiedä, mitä häneltä veloitetaan.

Jokaisessa rivissä tulisi olla näkyvissä nimikoitu poistopainike (esim. "Remove Blue T-Shirt, size M, from cart"). Määrän säätimien tulisi ilmoittaa nykyinen arvonsa osana esteetöntä nimeä tai pariksi liitettyjen reaaliaikaisten alueiden päivitysten kautta. Ostoskorin välisumman tulisi sijaita aria-live="polite" alueella, joten muutokset ilmoitetaan. Vahvista poistot peruutusmahdollisuuden avulla.

Tämä on aineistossa suurin yksittäinen ryhmä, koska sen havaitseminen on edullisinta ja sen huomiotta jättäminen kalleinta. Näytönlukija käy läpi DOM-rakennetta ja törmää <input>ja lukee sen helppokäyttöisen nimen — jonka se laskee seuraavasta järjestyksestä: aria-labelledby, aria-label, siihen liittyvä <label for>, title attribuutti tai paikkamerkki. Jos kumpaakaan ei ole, näytönlukija lukee ääneen vain roolin: ”muokkauskenttä” tai ”muokkaus, tyhjä”. Tuo lause toistuu lähes sanasta sanaan sadoissa valitustapauksissa.

Syynä tähän yleiseen käytäntöön on rakenteellinen ongelma. Nykyaikaisissa suunnittelujärjestelmissä syöttökentän sisällä näkyvä paikkamerkki toimii usein näkyvän otsikon sijaisena, ja kehittäjät olettavat, että paikkamerkki hoitaa otsikoinnin. Näin ei kuitenkaan ole. Paikkamerkki katoaa, kun käyttäjä alkaa kirjoittaa, eikä se jätä jälkeensä ohjelmointitunnistetta, minkä vuoksi kenttä muuttuu käyttökelvottomaksi kaikille, jotka saapuvat siihen myöhemmin prosessin aikana tai palaavat sinne virheen jälkeen.

Jokaiselle interaktiiviselle ohjausobjektille annetaan näkyvä nimike, joka liitetään siihen ohjelmoimalla. <label for="email">Email</label><input id="email" type="email"> on vakiintunut käytäntö. Paikkamerkit ovat täydentäviä vihjeitä, eivät korvikkeita. Niissä ohjauselementeissä, joissa näkyvää tekstiä ei todellakaan haluta (hakukentät, kuvakepainikkeet), käytä aria-label kuvaustekstin kanssa — ei koskaan siten, että paikkamerkki toistuu.

Lause ”ei ilmoitettu tai siirretty fokukseen” esiintyy sanasta sanaan yli 400 valitusmerkinnässä ja on yksi koko aineiston toistuvimmista lauseista. Se kuvaa tiettyä toimintahäiriötä: sivulle avautuu modaalinen ikkuna tai valintaikkuna (usein automaattisesti – uutiskirjeen tilaus, ikärajatarkistus, sijainnin vahvistus), näkyvä sisältö muuttuu, mutta näytönlukijalle ei anneta merkkiä siitä, että jotain olisi muuttunut. Fokus pysyy taustalla olevalla sivulla. Käyttäjä jatkaa tabuloimista modaalin alla olleessa sisällössä täysin tietämättä, että esteenä oleva valintaikkuna on ilmestynyt.

Tämä on tyypillinen esimerkki modaalista, joka epäonnistuu kaikilla osa-alueilla yhtä aikaa: ei role="dialog", ei aria-modal="true", ohjelmoinnissa ei tapahdu painopisteen siirtymistä avoimeen tilaan, avoimessa tilassa ei esiinny painopisteen lukkiutumista, Esc-näppäimellä ei suljeta ikkunaa eikä otsikkoa ilmoiteta. Koska nämä ongelmat esiintyvät aina yhdessä, yksittäisen ongelman korjaaminen ei vaikuta tilanteen ratkaisuun.

Käytä vakiintunutta valintaikkunamallia (viitteenä WAI-ARIA Authoring Practices -määritys). Kun valintaikkuna avataan: siirrä kohdistus valintaikkunan ensimmäiseen kohdistettavaan elementtiin, aseta aria-modal="true" ja role="dialog", nimeä valintaikkuna aria-labelledby osoittamalla sen otsikkoa. Kun ikkuna on auki: pidä fokus valintaikkunassa. Kun ikkuna suljetaan: palauta fokus sen elementtiin, joka avasi ikkunan. Tunnista Esc-näppäin. Jos modaalinen ikkuna keskeyttää toiminnon (esim. sivun latautuessa käynnistyvän automaattisen toiston), tarjoa käyttäjälle yksi keino sulkea ikkuna pysyvästi.

Fokusindikaattorit poistetaan yleensä tarkoituksella: kehittäjä tai suunnittelija on pitänyt selaimen oletusmuotoilua visuaalisena häiriötekijänä ja kirjoittanut *:focus { outline: none; } yhtenäiseksi tyylitiedostoksi. Sivu näyttää nyt siistimmältä näkevälle hiiren käyttäjälle. Näkevälle näppäimistön käyttäjälle – mukaan lukien useimmat heikkonäköiset käyttäjät, liikuntarajoitteiset käyttäjät ja ilman hiirtä selaavat käyttäjät – sivu muuttuu käyttökelvottomaksi. Käyttäjä voi painaa Tab-näppäintä, mutta ei näe, missä kohtaa sivua hän on.

Tämä on yksi harvoista virhetilanteista, jotka ovat havaittavissa ilman aputeknologiaa. Laadunvarmistaja, joka selaa kotisivua kerran tab-näppäimellä ilman muita apuvälineitä, huomaa sen alle minuutissa. Se, että esteettömyystyöryhmät löytävät tämän virheen toistuvasti riitautetuilta sivustoilta, vaikka sisäisessä tarkastuksessa se on jäänyt huomaamatta, on yksi luotettavimmista merkkeistä aineistossa siitä, että sivusto ei läpäise näppäimistötestausta lainkaan.

Älä koskaan poista käytöstä kaikkia :focus reunaviivat ilman korvaavaa elementtiä. Luo näkyvä korostustyyli – yleensä 2–3 pikselin paksuinen reunaviiva, jolla on riittävä kontrasti sekä elementtiin että sen taustaan nähden – käyttämällä :focus-visible joten osoitin näkyy näppäimistönavigoinnissa, mutta ei hiiren napsautuksissa. Tarkista tämä jokaisesta interaktiivisesta komponentista, mukaan lukien mukautetut widgetit, korttien sisällä olevat linkit ja elementit, joissa on tabindex.

Logo on verkkosivuston eniten katsottu kuva ja yksi niistä, joissa esiintyy useimmin virheitä. Se sijaitsee yleensä linkissä, joka ohjaa takaisin kotisivulle, mutta kuva toimitetaan ilman alt, ei aria-label linkin kohdalla, eikä sen ympärillä ole tekstiä. Näytönlukija lukee ääneen vain ”linkki”, eikä siitä ole mitään tietoa, mihin se johtaa. Kerro tämä sivuston jokaisella sivulla.

Laajempi ryhmä – kuvat, joissa ei ole vaihtoehtoista tekstiä – kattaa bannerikuvat, tuotekuvat, pääkuvat, sosiaalisen median kuvakkeet sekä laajan valikoiman markkinointikuvia, joita tyypillisellä verkkokauppasivustolla käytetään. Tämän ryhmän valituksissa mainitaan usein tiettyjä kuvatiedostojen nimiä, mikä viittaa siihen, että kantajan asiantuntija on suorittanut automaattisen tarkistuksen, joka on listannut kaikki kuvat, joiden alt attribuutti puuttui tai oli tyhjä, vaikka sen olisi pitänyt olla kuvaava.

Logoissa tulisi olla vaihtoehtoinen teksti, jossa mainitaan yrityksen nimi ja, jos logo johtaa johonkin sivustoon, myös kohde — alt="Acme Co. — homepage". Koristekuviin määritetään tyhjä alt-attribuutti (alt=""), joka piilottaa ne tarkoituksella aputeknologialta. Selittävillä kuvilla on kuvaava vaihtoehtoinen teksti. Vältä vaihtoehtoisen tekstin automaattista luomista tiedostonimistä tai tekoälyn tuottamista kuvateksteistä ilman ihmisen tarkistusta; valitustiedoissa mainitaan toistuvasti tapauksia, joissa kuvanpäällystyökalut ovat kuvanneet yrityksen logon ”siniseksi ja keltaiseksi kyltiksi”.

Näytönlukijat tarjoavat ”linkkiluettelon” näkymän, jota kokeneet käyttäjät hyödyntävät ahkerasti sivun silmäilemiseen muutamassa sekunnissa. Tässä näkymässä näkyy vain linkin teksti, irrallaan sitä ympäröivästä kappaleesta. Sivu, jossa jokainen blogin esittelyteksti päättyy ”Lue lisää” näkyy kyseisessä näkymässä viidentoista samanlaisena merkintänä. Sivu, jolla on viisi tyhjää linkkiä — <a href="..."></a>, mikä on yleistä, kun kuvakkeet sijaitsevat linkkien kääreissä ilman tekstivaraa — tulostaa viisi tyhjää merkkiä.

Ratkaisu on yleisesti tiedossa ja ongelmakin on tunnettu, minkä vuoksi tämä ongelma toistuu jatkuvasti valituksissa — sen toistuminen viittaa kehitysprosessiin, jossa linkkitekstille ei ole käytössä automaattista linter-työkalua eikä manuaalista näytönlukijatarkistusta.

Jokaisella linkillä on oltava esteetön nimi, joka kuvaa sen kohdetta tai toimintoa. Korvaa yleisluontoiset ilmaisut kuvaavilla ilmaisuilla — ”Lue lisää” muuttuu ”Lue lisää kolmannen vuosineljänneksen tuloksesta”. Jos linkki sisältää vain kuvakkeen, lisää visuaalisesti piilotettu teksti tai aria-label. Suorita automaattinen tarkistus (axe, Lighthouse jne.) tyhjien <a> elementit CI:n aikana.

Videot nousevat esiin valituksissa kahdessa eri muodossa. Ensimmäinen on ilmeinen: markkinointivideo, tuotedemo tai selittävä video julkaistaan ilman tekstitystä, tekstikäsikirjoitusta tai minkäänlaista tekstivaihtoehtoa – jolloin kuuro tai huonokuuloinen kävijä ei pääse käsiksi sisältöön. Toinen on hienovaraisempi: sivun latautuessa automaattisesti toistuva hero-video, joka häiritsee näytönlukijan toimintaa ja rikkoo WCAG 2.2 AA -tason vaatimuksia tauko-/pysäytyspainikkeista (SC 2.2.2 Tauko, Pysäytys, Piilota liikkuvalle sisällölle ja SC 1.4.2 kaikelle äänelle).

Joissakin tämän aineiston valituksissa väitetään, että ”verkkosivuston videoiden tekstityksen puuttuminen rikkoo ADA-lakia”, ja tämä esitetään oikeudellisena johtopäätöksenä. Se, pitääkö tämä tulkinta paikkansa, riippuu lainkäyttöalueesta ja olosuhteista; vakaampaa on se, että nämä videot eivät täytä WCAG 2.2 AA -vaatimuksia, joita useimmat tuomioistuimet ja sovintoratkaisut pitävät toimivana vaatimustenmukaisuuden mittapuuna.

Tarjoa synkronoidut tekstitykset kaikille äänellä varustetuille, etukäteen tallennetuille videoille. Tarjoa myös tekstimuotoinen transkriptio; transkriptiot ovat hyödyllisiä käyttäjille, joiden laitteiden ääni on mykistetty, hitaiden verkkoyhteyksien ympäristöissä sekä sisällön indeksointia varten. Vältä automaattista toistoa; jos automaattinen toisto on välttämätöntä suunnittelullisista syistä, tarjoa tauko-/pysäytyspainike, joka on helposti käytettävissä näppäimistöllä. Pelkästään videosta koostuvassa sisällössä (ilman ääntä) tarjoa äänikuvaus tai tekstivaihtoehto.

Kirjautuminen on koko todennetun käyttökokemuksen portinvartija. Kun lomake ei toimi, kaikki sen takana olevat sivut muuttuvat saavuttamattomiksi, ja valituksissa tämä ketjureaktio nähdään usein yhtenä ainoana esteenä. Kuvio on sama lomakkeen merkintävirhe kuin E·01:ssä, usein yhdistettynä kolmeen erityiseen osavirheeseen: ”Näytä salasana” -kytkin, joka on toteutettu pelkästään kuvakkeena ilman nimeä ja tilanmuutoksen ilmoitusta, CAPTCHA, joka estää kokonaan näytönlukijan käytön, sekä rivivirheet (”virheelliset tunnistetiedot”), jotka näkyvät ruudulla mutta joita ei ilmoiteta.

”Muista minut” -valintaruutu on toinen toistuva pienvirhe: se näkyy muotoiltuna <div>, jossa todellinen <input> Kun valintaruutu on piilotettu näytön ulkopuolelle, sitä voi käyttää hiirellä, mutta ei näppäimistöllä tai näytönlukijalla. Käyttäjällä ei ole mahdollisuutta valita pysyvää istuntoa.

Käytä aitoa <input>, <label>ja <button> elementit. Tee salasanan näyttö-/piilotuspainikkeesta oikea painike, jolla on esteetön nimi ja joka päivittyy tilan mukaan ("Show password" / "Hide password") ja ilmoittaa muutoksesta aria-pressed. Tarjoa esteetön vaihtoehto kuvapohjaisille CAPTCHA-testeille (äänipohjainen CAPTCHA tai – mieluiten – korvaa CAPTCHA riskipohjaisella todennuksella tai hCaptchan esteettömillä versioilla).

Näytönlukijat esittävät sivun kolmella eri selaustavalla: otsikoiden, maamerkkien ja linkkien avulla. Sivu, joka toimitetaan ilman <h1>, ilman <main>, <nav>ja <footer> maamerkit, ja ilman lang="en" -attribuutti <html> -elementti on poistanut kaikki nämä kolme navigointitapaa kerralla. Käyttäjillä ei ole mahdollisuutta selata sivua, siirtyä suoraan sisältöön eikä näytönlukijalla ole keinoa ladata oikeaa ääntämisohjelmaa.

Kyseessä on poikkeuksellisen laaja-alainen vika: yhden ainoan puuttuvan viitepisteen vuoksi syntyy ketjureaktio, jossa valitukset kasaantuvat, sillä kaikki siitä riippuvat näytönlukijan navigointistrategiat pettävät. Tämän tyyppisissä valituksissa mainitaan yleensä neljä tai viisi konkreettista rakenteellista ongelmaa, jotka esitetään todisteena siitä, että sivustolla ei ole semanttista perustaa.

Jokaiselle sivulle annetaan yksi ja vain yksi <h1>, alaotsikoineen (<h2>, <h3>) järjestetään loogisesti. Kääri alueet HTML5-maamerkkielementteihin: <header>, <nav>, <main>, <aside>, <footer>. Aseta lang juurikansiossa <html> elementti. Tarkista oikeellisuus ääriviivatarkistimella tai suorita document.querySelectorAll('h1').length === 1 sovelluksen toimivuuden testinä jatkuvassa toiminnassa.

Suurin osa esteettömyyden laadunvarmistuksesta tehdään pöytäkoneiden selaimilla NVDA- tai JAWS-lukijaohjelmien avulla. Mobiililaitteiden aputeknologiat – iOS:n VoiceOver ja Androidin TalkBack – tuottavat saman DOM-rakenteen eri tavalla, ja niissä esiintyy usein erilaisia virheitä. Valituksissa käytetään toistuvasti lyhennettä ”mobile SRU” (mobiililaitteen näytönlukijan käyttäjä) viittaamaan mobiilinäkymälle ominaisiin virheisiin: hampurilaisvalikko, joka toimii NVDA:n kanssa työpöydällä mutta ei reagoi VoiceOverissa, Apple Pay -painike, joka on käytettävissä kannettavalla tietokoneella mutta ei sivun iPhone-versiossa, virheilmoitukset, jotka kuuluvat työpöydällä mutta eivät mobiililaitteella.

Aineiston perusteella näyttää siltä, että vastaajia, joiden tietokoneiden esteettömyys on muilta osin kunnossa, haastetaan edelleen oikeuteen mobiililaitteisiin liittyvissä kysymyksissä. Mobiililaitteiden esteettömyys on oma tarkastuskriteerinsä.

Testaa vähintään iOS-Safarissa VoiceOver-toiminnolla ja Android-Chromessa TalkBack-toiminnolla samat käyttövirrat, jotka kattavat työpöytäversiossa suoritettavan laadunvarmistuksen. Kiinnitä erityistä huomiota eleisiin perustuviin toimintoihin, laitteen omiin maksupainikkeisiin sekä lomakekenttien lukemiseen, kun niihin siirretään kohdistus. Jos sovelluksesta on olemassa oma versio, suorita sille sama tarkastus – valitukset koskevat usein sekä verkkosivustoa että sovellusta samassa tapauksessa.

Esteettömyys-overlay on tämän luettelon ainoa esimerkki, jossa ongelma ei ole lainkaan itse verkkosivustossa, vaan sen korjaamiseksi lisätyssä oletetussa korjauskerroksessa. Tähän luokkaan kuuluvat valitukset koskevat kahta erillistä haittaa. Ensinnäkin overlay-kerrokset eivät todellisuudessa poista taustalla olevia esteitä, joten käyttäjä kohtaa samat toimimattomat modaalit, väärin nimetyt lomakkeet ja ilmoittamattomat virheet riippumatta siitä, onko widget käytössä. Toinen haitta on terävämpi: overlay-kerrokset aiheuttavat toisinaan uusia virheitä lisäämällä virheellisiä nimikkeitä, soveltamalla ARIA-rooleja väärin tai häiritsemällä käyttäjän omaa aputeknologian kokoonpanoa.

Yksi huomionarvoinen seikka: vuosina 2024 ja 2025 tehdyissä valituksissa mainitaan yhä useammin overlay-ratkaisun toimittaja nimeltä. Kahdessa valituksen kohdassa mainitaan UserWay ja AccessiBe yksiselitteisesti, ja FTC:n viimeaikaiset toimet ovat luoneet selkeän riskin siitä, että overlay-ratkaisun lisääminen tulkitaan sinänsä todisteeksi siitä, ettei todellista korjaavaa työtä ole tehty – eikä puolustukseksi oikeudenkäyntiä vastaan.

Käsittele päällekkäisiä ratkaisuja pikaisena apukeinona, ei pysyvänä ratkaisuna. Jos tällainen ratkaisu on tällä hetkellä käytössä, laadi suunnitelma todellisille korjaustoimenpiteille, joissa puututaan ongelman taustalla olevaan koodiin sen sijaan, että peiteltäisiin se. Hyväksi todettu toimintamalli koostuu seuraavien tekijöiden yhdistelmästä: jatkuvaan integraatioon integroitu automaattinen skanneri, ihmisen suorittama tarkastus WCAG 2.2 AA -vaatimusten mukaisesti, manuaalinen testaus vähintään yhdellä näytönlukijalla ja pelkästään näppäimistöllä navigoimalla sekä jatkuva esteettömyyden laadunvarmistus suunnittelu- ja kehitysprosessissa.