Accesibilidad web: características clave comparadas

Webin saavutettavuus määritellään neljällä mitattavissa olevalla ominaisuudella – havaittava, toimiva, ymmärrettävä ja vankka – jotka on artikuloitu WCAG 2.2:n 13 A- ja AA-tason kriteerien mukaisesti, joita EN 301 549-standardi Euroopassa edellyttää. Nämä neljä ominaisuutta toimivat arviointikriteereinä: mikä tahansa widget, työkalu tai kehys arvioidaan sen perusteella, kuinka monta se täyttää ja millä lujuudella.

Keskeiset kohdat

• WCAG:n neljä ominaisuutta (havaittava, toimiva, ymmärrettävä, vankka) ovat arviointikehys, eivät iskulause: jokainen ryhmittelee todennettavat kriteerit dokumentoiduilla tekniikoilla.
• Taso AA on käytännön tavoite useimmissa projekteissa: se kattaa kontrastin, näppäimistön, lomakkeiden tunnisteet, rakenteen ja virheilmoitukset, ja se on kynnys, joka viittaa EU:n lainsäädäntöön.
• Mikään automaattinen työkalu ei havaitse enempää kuin murto-osan todellisista ongelmista; manuaalinen testaus näppäimistöllä ja näytönlukijalla on edelleen korvaamaton.
• “saavutettavan” widgetin tai kehyksen valitseminen edellyttää sen toiminnan tarkistamista näppäimistöllä, sen tarkennushallinnan ja ARIA-semantiikan avulla, ei vain sen markkinointia.
• Vaatimustenmukaisuus on jatkuva prosessi, joka liittyy tuotteen elinkaareen, ei kertaluonteinen tarkastus, joka arkistoidaan.

Mitä “verkkosaavutettavuuden ominaisuudet” todella tarkoittavat

Termiä “ominaisuudet” käytetään kahdella tavalla, jotka on syytä erottaa. Ensimmäinen on normatiivinen: WCAG järjestää onnistumiskriteerinsä neljään periaatteeseen tai ominaisuuteen – havaittava, toimiva, ymmärrettävä ja vankka – jotka tunnetaan englanninkielisistä alkukirjaimistaan nimellä POUR.

Toinen on käytännönläheinen: kun kehittäjä sanoo, että komponentilla on “hyvät saavutettavuusominaisuudet”, hän viittaa yleensä joukkoon konkreettisia käyttäytymismalleja (näppäimistönavigointi, oikeat ARIA-roolit, riittävä kontrasti, vaihtoehtoiset tekstit). Molempia tulkintoja tarvitaan: ensimmäinen antaa arviointikehyksen, jälkimmäinen toteutettavat yksityiskohdat.

W3C:n vuonna 2023 julkaisemat WCAG 2.2 säilyttävät neljä periaatetta ja lisäävät kriteereitä, kuten kohteen vähimmäiskoko (2.5.8) ja avun johdonmukaisuus (3.2.6). Taso A ryhmittelee vähimmäiskriteerit; AA lisää useimmille sivustoille olennaisimmat; AAA on tavoitteellinen ja harvoin kokonaisuudessaan vaadittu. XHTML/CSS-sivustolle, joka on suunnattu Espanjaan tai Latinalaiseen Amerikkaan, realistinen tavoite on AA, koska se on taso, johon eurooppalainen harmonisoitu standardi EN 301 549 ja sitä kautta direktiivi (EU) 2016/2102 julkisen sektorin verkkosivustojen saavutettavuudesta viittaavat.

Neljä WCAG-ominaisuutta yksitellen

Havaittava

Havaittavuus edellyttää, että tiedot esitetään tavalla, jota käyttäjä voi havaita aisteistaan riippumatta. Käytännössä tämä tarkoittaa tekstivaihtoehtoja ei-tekstuaaliselle sisällölle (1.1.1), tekstityksiä ja puheenvaihtoehtoja multimedialle (1.2.x), semanttista rakennetta, joka ei riipu vain sijainnista tai väristä (1.3.1), vähimmäiskontrastia 4,5:1 normaalille tekstille ja 3:1 suurelle tekstille (1.4.3) sekä sisältöä, joka pysyy luettavana 200 % suurennuksella ilman vaakasuuntaista vieritystä (1.4.10). Yleinen virhe vanhoilla XHTML-sivustoilla on asettelutaulukoiden tai tekstikuvien käyttö: molemmat heikentävät havaittavuutta, koska lukujärjestys ja skaalautuvuus katoavat.

Toimiva

La característica operable garantiza que todos los komponentes de la interfaz funcionen con teclado y con tecnologías de asistencia. Los criterios clave son accesibilidad completa por teclado (2.1.1), ausencia de trampas de foco (2.1.2), tiempo ajustable (2.2.1), mecanismos para pausar contenido en movimiento (2.2.2), navegación con enlaces de saltíivo script (2.4.1, 2.4.2), orden de foco lógico (2.4.3) y tamaño de objetivo suficiente (2.5.8). Aquí es donde fallan la mayoría de menús desplegables, modales y carruseles: capturan el foco y no lo devuelven, o dependen de eventos de ratón (“onmouseover”) sin ekvivalente de teclado.

Aiheeseen liittyvä: UserWay — Widget de accesibilidad con plan gratuito para empezar hoy mismo.

Ymmärrettävä

Ymmärrettävyys käsittelee sitä, että sisältö ja käyttöliittymän toiminta ovat ymmärrettäviä. Siihen kuuluu sivun kielen ilmoittaminen lang-attribuutilla (3.1.1), lomakkeiden tunnisteet ja ohjeet (3.3.2), virheiden tunnistaminen ja kuvaus (3.3.1, 3.3.3), johdonmukainen navigointi sivujen välillä (3.2.3) ja WCAG 2.2:ssa avun johdonmukaisuus (3.2.6). Lomake, joka merkitsee kentän punaiseksi mutta ei selitä, mikä meni vikaan, ei täytä tätä ominaisuutta, vaikka se olisi visuaalisesti selkeä henkilölle, jolla ei ole vammaisuutta.

Vankka

Vankkuus edellyttää, että sisältö toimii laajalla valikoimalla käyttäjäagentteja, mukaan lukien nykyiset ja tulevat. Keskeinen kriteeri on oikea syntaksianalyysi (4.1.1, vanhentunut WCAG 2.2:ssa mutta relevantti XHTML:ssä) sekä käyttöliittymäkomponenttien nimi, rooli ja arvo (4.1.2). Käytännössä tämä tarkoittaa validin HTML:n kirjoittamista, natiivielementtien käyttöä aina kun mahdollista ja ARIA:n käyttöä vain silloin, kun vaihtoehtoa ei ole, noudattaen ARIA:n ensimmäistä sääntöä: älä käytä ARIA:a, jos natiivi HTML-elementti hoitaa tehtävän.

Vertailutaulukko: työkalujen ja widgetien arviointi neljän ominaisuuden perusteella

Ominaisuus	Mitä tarkistaa työkalusta tai widgetistä	Hälytysmerkki
Havaittava	Luo tekstivaihtoehtoja, kunnioittaa kontrastia, ei riipu väristä	Validoi vain kuvat, jättää rakenteen ja kontrastin huomioimatta
Toimiva	Näppäimistönavigointi, fokuksen hallinta, ei loukkuja	Vaatii hiiren tai ei sulje Escape-näppäimellä
Ymmärrettävä	Tunnisteet, virheilmoitukset, ilmoitettu kieli	Merkitsee virheet ilman selitystekstiä
Vankka	Validi HTML, oikeat ARIA-roolit, toimii useissa selaimissa	Käyttää div-elementtiä onclick-tapahtumalla button-elementin sijaan

Tämä taulukko toimii kriteeristönä vaihtoehtojen välillä päättämiseen. Työkalu, joka kattaa vain “havaittava”-sarakkeen, on hyödyllinen ensimmäisenä suodattimena, mutta ei sertifiointina.

Katsomisen arvoinen: AudioEye — Accesibilidad gestionada: automatización combinada con revisión humana.

Herramientas y su relación con las características

Automaattiset arviointityökalut —kuten axe DevTools, WAVE tai Lighthouse— havaitsevat erityisesti havaittavuuden ja vankkuuden ongelmia: puuttuvat vaihtoehtoiset tekstit, riittämätön kontrasti, väärin muotoillut ARIA-attribuutit ja otsikkohierarkian puutteet. Niiden kattavuus on suunnitelman mukaisesti osittainen: ne eivät pysty arvioimaan, onko vaihtoehtoinen teksti kuvaava, onko fokuksen järjestys järkevä tai onko virheilmoitus ymmärrettävä. Dequen axe-dokumentaatio ja WebAIMin opas automaattisesta arvioinnista ovat yksimielisiä siitä, ettei mikään työkalu korvaa ihmisen tekemää tarkastusta.

Manuaalinen testaus kattaa sen, mitä työkalut eivät näe. Vähimmäistoimenpiteet sisältävät: navigoi koko sivulla vain sarkain- ja vaihto+sarkain-näppäimillä, tarkastetaan, että kohdistus on aina näkyvissä, testataan näytönlukijalla (NVDA tai VoiceOver), zoomataan 200 %:iin ja tarkistetaan, ettei mikään ole päällekkäisiä, sekä CSS:n poistaminen käytöstä varmistaaksesi, että sisällön järjestys on järkevä. Tämä viimeinen vaihe paljastaa ymmärrettävän ominaisuuden ongelmat, joita mikään työkalu ei osoita.

Valinta projektityypin mukaan

Espanjan julkishallinnon tai julkisen sektorin sivuston tulee tavoitella AA-tasoa ja dokumentoida vaatimustenmukaisuus, koska lainsäädäntö sitä edellyttää. Henkilökohtainen blogi voi priorisoida havaittavuutta ja toimivuutta, jotka poistavat suurimman osan todellisista esteistä.

Monimutkainen verkkosovellus, jossa on interaktiivisia komponentteja, vaatii panostuksia vankkuuteen ja toimivuuteen, koska mukautetut widgetit ovat yleisin virhelähde. Päätös ei ole “kuinka monta ominaisuutta täytän”, vaan “mitkä ominaisuudet ovat kriittisiä käyttäjilleni ja lakisääteisen velvoitteeni kannalta”.

Kehysten ja komponenttikirjastojen osalta käytännön arviointi sisältää komponentin testaamisen näppäimistöllä ennen sen käyttöönottoa. Mukautettu “valinta”, joka ei reagoi nuolille, modaali, joka ei kiinnitä tarkennusta oikein, tai työkaluvihje, joka näkyy vain hiiren osoittimen ollessa päällä, ovat merkkejä siitä, että kirjasto asettaa ulkonäön etusijalle toimivuuden sijaan. W3C ARIA Authoring Practices Guide -dokumentaatiossa kuvataan kunkin widgetin odotetut mallit ja annetaan vertailun lähtökohta.

Yleisimmät virheet ominaisuuksien tulkinnassa

Ensimmäinen virhe on kohdella neljää ominaisuutta binäärisenä tarkistuslistana. Vaatimustenmukaisuus on kumulatiivista ja kontekstuaalista: sivusto voi täyttää 40 kriteeriä ja epäonnistua yhdessä, joka estää käyttäjän pääsyn kokonaan.

Aiheeseen liittyvä: IAAP CPACC / WAS Certification — La Certificación profesional que acredita tu experiencia en accesibilidad.

Toinen virhe on luottaa “overlay”-ratkaisuihin tai saavutettavuuswidgetteihin, jotka lupaavat korjata sivuston skriptillä; nämä tuotteet eivät korjaa alla olevaa HTML-koodia, ja saavutettavuusyhteisö sekä vammaisjärjestöjen raportit ovat kritisoineet niitä. Kolmas virhe on auditoida vain kerran: sisältö muuttuu, komponentit päivittyvät ja vaatimustenmukaisuus heikkenee. Saavutettavuus on kehityssykliin integroitu prosessi, jossa testaus tapahtuu jokaisen julkaisun yhteydessä.

Usein kysyttyjä kysymyksiä

¿Cuáles son las cuatro características de la accesibilidad web según las WCAG?

WCAG jakaa kriteerinsä neljään periaatteeseen: havaittava, toimiva, ymmärrettävä ja vankka, tunnetaan nimellä POUR. Jokainen periaate ryhmittelee todennettavat onnistumiskriteerit tasoilla A, AA ja AAA. Tämä rakenne säilyy WCAG 2.2:ssa, ja se on perusta minkä tahansa paikan tai komponentin arvioinnille.

Minkä WCAG-vaatimustenmukaisuustason sivustoni tulisi täyttää?

Useimmille sivustoille AA-taso on käytännön tavoite ja se on taso, johon EU-lainsäädäntö viittaa EN 301 549 -standardin kautta. Taso A kattaa vähimmäisvaatimukset ja AAA on vaikea saavuttaa kokonaisuudessaan. Jos sivustosi kuuluu EU:n julkiseen sektoriin, AA-taso on vaatimus.

Jos olet ostoksilla: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 horas.

Riittävätkö automaattiset työkalut saavutettavuusominaisuuksien täyttämiseen?

Eivät. Automaattiset työkalut havaitsevat vain osan ongelmista, erityisesti kontrastia, vaihtoehtoisia tekstejä ja väärin muotoiltuja ARIA-attribuutteja, mutta ne eivät pysty arvioimaan, onko vaihtoehtoinen teksti sopiva tai onko fokuksen järjestys järkevä. Manuaalinen tarkistus näppäimistöllä ja näytönlukijalla on välttämätön todellisen vaatimustenmukaisuuden saavuttamiseksi.

¿Qué diferencia hay entre accesibilidad y usabilidad?

Esteettömyys varmistaa, että vammaiset voivat havaita, toimia, ymmärtää ja käyttää sisältöä; käytettävyys pyrkii varmistamaan, että käyttökokemus on tehokas ja jokaiselle käyttäjälle tyydyttävä. Ne menevät päällekkäin: esteetön sivusto on yleensä käyttökelpoisempi, mutta käyttökelpoinen sivusto ei välttämättä ole saavutettavissa.

Onko widgetit tai peittokuvat käytettävissä automaattisesti?

No corrigen el HTML subyacente ni los problems de estructura, foco o semántica. La comunidad de accesibilidad y diversos informes los han cuestonado porque pueden dar una falsa sensación de conformidad. La solución pasa por corregir el código y los komponentes, no por superponer un script.

Miten aloitan olemassa olevan XHTML/CSS-sivuston saavutettavuuden parantamisen?

Aloita vaikuttavimmista asioista: validi ja semanttinen HTML, kuvien vaihtoehtoiset tekstit, riittävä kontrasti, täysi näppäimistönavigointi ja lomakkeiden tunnisteet. Tee tämän jälkeen auditointi automaattisella työkalulla ja täydennä se manuaalisilla testeillä. Dokumentoi täytetyt kriteerit ja toista prosessi jokaisen merkittävän muutoksen yhteydessä.