QualiBooth
Suomi

guides

Yleisiä saavutettavuusvirheitä, joita kannattaa välttää

Tutustu yleisimpiin verkon saavutettavuusvirheisiin, jotka estävät vammaisia käyttäjiä, ja opi korjaamaan ne ennen kuin niistä tulee vaatimustenmukaisuusriski.

10 min read QualiBooth
Tarkistuslista yleisistä verkon saavutettavuusongelmista, joita kannattaa välttää, mukaan lukien kontrasti, alt-teksti ja näppäimistönavigointi.

Miksi samat saavutettavuusongelmat toistuvat

Useimmat saavutettavuuden esteet eivät ole eksoottisia. Vuodesta toiseen automaattiset ja manuaaliset auditoinnit nostavat esiin saman lyhyen listan virheitä: puuttuva alt-teksti, heikko kontrasti, nimeämättömät lomakekentät, näppäimistöansat ja rikkinäinen rakenne. Ne toistuvat, koska ne syntyvät huomaamatta — kehittäjä julkaisee uuden komponentin, markkinoija lataa kuvan, suunnittelija valitsee brändivärin — eikä mikään normaalissa työnkulussa nosta ongelmaa esiin. Visuaalinen lopputulos näyttää hyvältä hiirtä ja terävää näköä käyttävälle, joten este pääsee tuotantoon.

Tämä luettelo käy läpi yleisimmät WCAG 2.2 -virheet, joita näemme todellisissa auditoinneissa. Jokaisen kohdalla löydät, miksi se on tärkeä, ketä se koskee, asiaankuuluvan onnistumiskriteerin sekä konkreettisen ennen/jälkeen-korjauksen. Yhdessä nämä ongelmat muodostavat suurimman osan esteistä, jotka estävät vammaisia käyttäjiä — ja suurimman osan oikeudellisista valituksista, jotka tehdään Euroopan esteettömyysdirektiivin, ADA:n ja Section 508:n nojalla.

Yksi asia on selvennettävä ennen listaa: automaattiset työkalut eivät löydä kaikkia näitä ongelmia. Riippumaton tutkimus osoittaa johdonmukaisesti, että jopa parhaat skannerit havaitsevat luotettavasti vain 30–40 % WCAG-ongelmista. Ne ovat erinomaisia havaitsemaan puuttuvat alt-attribuutit, ohjelmalliset kontrastivirheet ja puuttuvat lomakeselitteet, mutta ne eivät pysty arvioimaan, onko alt-teksti tarkka, onko kohdistusjärjestys looginen tai toimiiko mukautettu komponentti todella ruudunlukijan kanssa. Siksi jokainen uskottava ohjelma yhdistää skannauksen manuaaliseen tarkistukseen. Saavutettavuuden skannausohjelmistomme hoitaa automatisoitavan kerroksen; manuaaliset auditoinnit ja vammaisten henkilöiden tekemät auditoinnit kattavat loput.

Nopea tapa löytää oma lähtökohtasi ennen jatkamista: katso sivua kuvat poistettuna, lue jokainen sana yhtenä jäsentämättömänä kappaleena ja yritä suorittaa jokainen tehtävä pelkällä näppäimistöllä. Missä tahansa kokemus romahtaa, olet löytänyt esteen.

Havaittava: sisältö, jota ihmiset eivät voi nähdä tai lukea

Puuttuva tai virheellinen alt-teksti kuville

Ketä se koskee: sokeat tai heikkonäköiset henkilöt, jotka käyttävät ruudunlukijoita; kuka tahansa hitaalla yhteydellä, jossa kuvat eivät lataudu.

WCAG-kriteeri: 1.1.1 Ei-tekstuaalinen sisältö (taso A).

Kuvat ilman alt-attribuuttia ovat näkymättömiä aputeknologialle — käyttäjä ei välttämättä edes tiedä kuvan olemassaolosta. Puuttuvaa attribuuttia pahempi on virheellinen: tiedostonimet kuten IMG_4821.jpg, yleiset sanat kuten “kuva” tai avainsanoilla täytetyt merkkijonot harhauttavat kuuntelijaa aktiivisesti.

Sääntö on yksinkertainen mutta tilannekohtainen. Informatiiviset kuvat tarvitsevat tiiviin kuvauksen merkityksestään, ei ulkonäöstään. Koristekuvat, jotka eivät tuo mitään lisää, tulisi merkitä tyhjällä alt=""-arvolla, jotta ruudunlukijat ohittavat ne. Toiminnallisten kuvien — painikkeena toimivan kuvakkeen — on kuvattava toiminto, ei kuvaa. Monimutkaiset visuaalit kuten kaaviot tarvitsevat lyhyen alt-tekstin sekä pidemmän tekstivastineen lähelle.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

Automaattiset työkalut havaitsevat alt-tekstin puuttumisen välittömästi. Ne eivät voi kertoa, onko teksti oikein — siihen tarvitaan ihminen, joka lukee sivua kontekstissa.

Riittämätön värikontrasti

Ketä se koskee: heikkonäköiset, värisokeat tai ikääntymiseen liittyvästä näön heikkenemisestä kärsivät henkilöt; jokainen, joka käyttää näyttöä kirkkaassa auringonpaisteessa.

WCAG-kriteeri: 1.4.3 Kontrasti (minimi), taso AA; lisäksi 1.4.11 Ei-tekstuaalinen kontrasti käyttöliittymäkomponenteille.

WCAG 2.2 edellyttää vähintään 4.5:1 kontrastisuhdetta normaalille tekstille ja 3:1 suurelle tekstille (noin 18pt tai 14pt lihavoituna). Käyttöliittymäkomponenttien ja merkityksellisten grafiikoiden — syöttöreunusten, kohdistusindikaattoreiden, tilaa välittävien kuvakkeiden — on saavutettava 3:1 suhteessa ympäristöönsä. Kontrastivirheet ovat yleisimpiä ongelmia jokaisessa laajamittaisessa auditoinnissa, ja ne syntyvät lähes aina suunnitteluvaiheessa.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Testaa koko paletti, älä vain leipätekstiä: paikkamerkkiteksti, käytöstä poistetut tilat, jotka on silti luettava, virheilmoitukset ja valokuvien päälle aseteltu teksti ovat yleisiä rikkojia. Älä koskaan luota pelkkään väriin merkityksen välittämisessä (1.4.1) — virheellisen kentän punainen reunus on yhdistettävä tekstiin tai kuvakkeeseen.

Automaattisesti toistuva media ja liike

Ketä se koskee: henkilöt, joilla on vestibulaarisia häiriöitä, tarkkaavaisuus- tai kognitiivisia vammoja, ruudunlukijan käyttäjät, joiden ääniulostulo peittyy, ja kuka tahansa hiljaisessa jaetussa tilassa.

WCAG-kriteerit: 1.4.2 Äänen hallinta (taso A), 2.2.2 Tauota, pysäytä, piilota (taso A), 2.3.1 Kolme välähdystä (taso A) ja 2.3.3 Animaatio vuorovaikutuksista (taso AAA).

Ääni tai video, joka toistuu automaattisesti yli kolme sekuntia, on tarjottava ilmeinen tapa tauottaa tai mykistää se. Liikkuva, vilkkuva tai automaattisesti päivittyvä sisältö, joka kestää yli viisi sekuntia — karusellit, animoidut bannerit, juoksutekstit — tarvitsee saavutettavan taukopainikkeen. Sisältö, joka välähtää yli kolme kertaa sekunnissa, voi laukaista kohtauksia ja se on vältettävä kokonaan. Kunnioita käyttäjän prefers-reduced-motion-asetusta vähentääksesi ei-olennaista animaatiota.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Hallittava: asiat, joita ihmiset eivät voi käyttää

Näppäimistön saavuttamattomuus ja näppäimistöansat

Ketä se koskee: liikuntavammaiset henkilöt, jotka eivät voi käyttää hiirtä, ruudunlukijan käyttäjät (jotka navigoivat näppäimistöllä) ja kytkinlaitteita tai puheohjausta käyttävät henkilöt.

WCAG-kriteerit: 2.1.1 Näppäimistö (taso A) ja 2.1.2 Ei näppäimistöansaa (taso A).

Jokaisen vuorovaikutuksen — linkit, painikkeet, lomakekentät, valikot, modaalit, päivämäärävalitsimet, vedä ja pudota — on oltava täysin hallittavissa pelkällä näppäimistöllä. Vahingollisin muunnelma on näppäimistöansa: kohdistus siirtyy komponenttiin (usein modaaliin tai upotettuun komponenttiin) eikä pääse pois, jolloin käyttäjä jää jumiin sivulle. Mukautetut komponentit ovat yleensä syyllisiä, koska natiivielementit kuten <button> ja <a> ovat oletuksena näppäimistöllä hallittavissa, kun taas <div>-pohjaiset jäljitelmät eivät ole.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Käy tärkeimmät polut läpi käyttäen vain Tab-, Shift+Tab-, nuolinäppäimiä, Enter-, väli- ja Escape-näppäintä. Varmista, että kohdistus voi aina siirtyä eteenpäin ja takaisin ulos jokaisesta komponentista, että Escape sulkee peittokuvat ja ettei mikään vaadi osoitinta. Ruudunlukija-arviointipalvelumme testaa juuri näitä kulkuja siten kuin todelliset aputeknologian käyttäjät ne kokevat.

Puuttuvat tai näkymättömät kohdistusindikaattorit ja epälooginen kohdistusjärjestys

Ketä se koskee: näkevät näppäimistön käyttäjät, heikkonäköiset käyttäjät ja kuka tahansa, joka on menettänyt käsityksen siitä, missä on sivulla.

WCAG-kriteerit: 2.4.7 Kohdistus näkyvissä (taso A) ja 2.4.3 Kohdistusjärjestys (taso A); 2.4.11 Kohdistus ei peitossa (taso AA) WCAG 2.2:ssa.

Yleinen “siisti” virhe on selaimen oletuskohdistusrenkaan poistaminen outline: none -määrityksellä korvaamatta sitä koskaan. Näppäimistön käyttäjillä ei ole aavistustakaan, mikä elementti on aktiivinen. Yhtä haitallinen on kohdistusjärjestys, joka ei noudata visuaalista ja loogista lukujärjestystä — tyypillisesti positiivisten tabindex-arvojen tai renderöidystä asettelusta poikkeavan DOM-järjestyksen aiheuttama.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 lisää kriteerin 2.4.11: kun elementti saa kohdistuksen, se ei saa olla kokonaan piilossa kiinnitettyjen ylätunnisteiden, evästebannerien tai chat-komponenttien takana. Avaa modaali, selaa sitä sarkaimella ja varmista, ettei kohdistettu elementti koskaan jää piiloon.

Ei-kuvailevat linkit ja painikkeet

Ketä se koskee: ruudunlukijan käyttäjät, jotka avaavat listan kaikista linkeistä sivun selaamiseksi, ja kognitiivisesti vammaiset henkilöt.

WCAG-kriteerit: 2.4.4 Linkin tarkoitus (kontekstissa), taso A; 2.5.3 Selite nimessä, taso A.

Ruudunlukijan käyttäjät navigoivat usein hyppäämällä linkkien välillä ilman kontekstia. Sivu täynnä “klikkaa tästä”-, “lue lisää”- ja “lisätietoja”-linkkejä muuttuu merkityksettömäksi listana luettuna. Linkkitekstin tulee kuvata kohteensa itsenäisesti. Sama koskee pelkän kuvakkeen painikkeita, jotka tarvitsevat saavutettavan nimen.

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Ylikuormitettu navigointi ja ei tapaa ohittaa sitä

Ketä se koskee: ruudunlukijan käyttäjät, näppäimistön käyttäjät ja kognitiivisesti vammaiset henkilöt.

WCAG-kriteeri: 2.4.1 Lohkojen ohittaminen (taso A).

Megavalikko, jossa on kymmeniä linkkejä, pakottaa ruudunlukijan ja näppäimistön käyttäjät rämpimään läpi koko listan jokaisella sivulla ennen sisältöön pääsyä. “Siirry pääsisältöön” -linkki ensimmäisenä kohdistettavana elementtinä antaa heidän hypätä suoraan toistuvien lohkojen ohi. Ryhmittele toisiinsa liittyvät kohteet, pidä valikot kevyinä ja varmista, että ohituslinkki tulee näkyviin kohdistuksessa.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

Ymmärrettävä: sisältö, joka hämmentää

Nimeämättömät tai virheellisesti liitetyt lomakekentät

Ketä se koskee: ruudunlukijan käyttäjät, kognitiivisesti vammaiset henkilöt ja puheohjauksen käyttäjät, jotka viittaavat kenttiin nimellä.

WCAG-kriteerit: 1.3.1 Tieto ja suhteet, 3.3.2 Selitteet tai ohjeet ja 4.1.2 Nimi, rooli, arvo (kaikki taso A).

Syöttökentät ilman ohjelmallisesti liitettyä <label>-elementtiä ilmoitetaan muodossa “muokkaa tekstiä, tyhjä” — käyttäjällä ei ole aavistustakaan, mitä kirjoittaa. Paikkamerkkiteksti ei korvaa sitä: se katoaa syötettäessä ja yleensä epäonnistuu kontrastissa. Pakolliset kentät, muotoilusäännöt ja validointivirheet on myös välitettävä tekstinä, ei pelkällä värillä tai sijainnilla.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Sido virheilmoitukset kenttäänsä aria-describedby-attribuutilla, merkitse virheelliset kentät aria-invalid-attribuutilla ja varmista, että keskeneräisen lomakkeen lähettäminen siirtää kohdistuksen ensimmäiseen virheeseen.

Puuttuva sivun kieli

Ketä se koskee: ruudunlukijan käyttäjät — väärä kieli saa syntetisaattorin ääntämään kaiken väärin.

WCAG-kriteerit: 3.1.1 Sivun kieli (taso A) ja 3.1.2 Osien kieli (taso AA).

Yksi puuttuva attribuutti rikkoo ääntämisen koko sivulta. Ilmoita ensisijainen kieli juurielementissä ja merkitse toisella kielellä olevat sisäiset kappaleet omalla lang-määrityksellään.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Virheellinen otsikkohierarkia ja puuttuvat maamerkit

Ketä se koskee: ruudunlukijan käyttäjät, jotka navigoivat otsikoiden ja alueiden mukaan, ja kuka tahansa, joka luottaa dokumentin rakenteeseen.

WCAG-kriteeri: 1.3.1 Tieto ja suhteet (taso A).

Otsikot muodostavat sivun jäsennyksen. Ruudunlukijan käyttäjät hyppäävät otsikosta otsikkoon löytääkseen sisällön nopeasti; kun tasoja ohitetaan, käytetään pelkän fonttikoon vuoksi tai ne puuttuvat, tämä navigointi romahtaa. Jokaisella sivulla tulisi olla yksi <h1> ja looginen, katkeamaton sarja <h2>, <h3> ja niin edelleen. Yhtä tärkeitä ovat maamerkkialueet — <header>, <nav>, <main>, <footer> — joiden avulla käyttäjät voivat hypätä päätoiminta-alueiden välillä. Kokonaan <div>-elementeistä rakennettu sivu ei tarjoa tällaista karttaa.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Lujatekoinen: koodi, jota aputeknologia ei voi tulkita

Saavuttamattomat mukautetut komponentit ja ARIAn väärinkäyttö

Ketä se koskee: ennen kaikkea ruudunlukijan käyttäjät ja mikä tahansa aputeknologia, joka luottaa oikeaan saavutettavuuspuuhun.

WCAG-kriteeri: 4.1.2 Nimi, rooli, arvo (taso A).

Mukautetuilla pudotusvalikoilla, välilehdillä, haitareilla, yhdistelmäruuduilla, modaaleilla ja työkaluvihjeillä, jotka on rakennettu <div>- ja <span>-elementeistä, ei ole luontaista roolia, tilaa tai näppäimistökäyttäytymistä. Kehittäjät turvautuvat ARIAan tämän paikkaamiseen, mutta ARIA vain kuvaa — se ei lisää käyttäytymistä, ja virheellinen ARIA on pahempi kuin ei lainkaan ARIAa. ARIAn ensimmäinen sääntö on suosia natiivia HTML-elementtiä aina kun sellainen on olemassa. Kun sinun on rakennettava mukautettu komponentti, toteuta täydellinen näppäimistövuorovaikutus, jonka ARIA-laadintamallit määrittävät, ja pidä aria-expanded, aria-selected ja vastaavat tilat synkronoituina todellisuuden kanssa.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

Nämä ovat juuri niitä ongelmia, jotka automaattiset skannerit ohittavat useimmin. Skanneri näkee aria-expanded-attribuutin ja hyväksyy sen; vain ihminen (tai ruudunlukijaa käyttävä testaaja) voi vahvistaa, että arvo todella vaihtuu valikon avautuessa. Katso ruudunlukijatestauksen oppaastamme, miten varmistaa komponentin käyttäytyminen alusta loppuun.

Huomautus peittokomponenteista

On houkuttelevaa asentaa yhden rivin “saavutettavuuskomponentti” tai peittokuva, joka lupaa välittömän vaatimustenmukaisuuden. Nämä työkalut eivät korjaa yllä olevia ongelmia — alt-teksti puuttuu edelleen lähdekoodista, kontrasti epäonnistuu edelleen, mukautettu komponentti on edelleen rikki. Peittokuvat eivät voi korjata esteitä aiheuttavaa koodia, ne häiritsevät usein käyttäjien omaa aputeknologiaa, ja ne ovat olleet osallisina kasvavassa määrässä saavutettavuusoikeudenkäyntejä. Aito digitaalinen saavutettavuus syntyy taustalla olevan HTML:n, CSS:n ja käyttäytymisen korjaamisesta, ei sen peittämisestä.

Estä näiden ongelmien paluu

Bugilistan korjaaminen kerran on välttämätöntä mutta ei riittävää; samat ongelmat ilmaantuvat uudelleen seuraavan julkaisun myötä, ellet muuta sitä, miten asiat julkaistaan. Kestävä korjaus on rakentaa saavutettavuus työnkulkuun:

Vaiheittaista korjaustiekarttaa varten aloita oppaastamme siitä, miten tehdä verkkosivustostasi WCAG-vaatimustenmukainen.

Mistä aloittaa tänään

Kun maailmanlaajuisesti yli 1,3 miljardia ihmistä elää jonkinlaisen vamman kanssa, liiketoiminnallinen peruste saavutettavuudelle on selvä — ja kesäkuusta 2025 lähtien myös oikeudellinen peruste Euroopan esteettömyysdirektiivin nojalla on. Tämän luettelon ongelmat ovat ne, jotka tutkitaan ensimmäisinä missä tahansa valituksessa tai auditoinnissa.

Nopein tapa nähdä, missä mennään, on suorittaa ilmainen URL-skannaus — ei asennusta, ei velvoitteita. Kun olet valmis ylittämään sen, mihin automaatio yltää, pyydä esittely, niin näytämme, miten yhdistetty automaattinen-plus-manuaalinen ohjelma kuroo jäljellä olevan kuilun umpeen.

Löydä ongelmat, jotka automaattiset työkalut ohittavat

Keskustele asiantuntijan kanssa Ilmainen saavutettavuusskannaus