Sovelluskehittäjän saavutettavuusohjeet

Last modified by Emmi Sulander on 2024/04/30 11:17

Tämän ohjesivun tarkoituksena on tuoda esiin saavutettavuuden toimenpiteitä, tekniikoita ja työkaluja projektin/kehityksen eri vaiheissa saavutettavuuden ylläpitämisen tehostamiseksi. Saavutettavuuden sisällyttäminen jo määrittely- ja suunnitteluvaiheissa auttaa ehkäisemään korjaustoimenpiteiden määrää myöhemmissä vaiheissa, joka on aina työläämpää.

Sovelluskehityksen saavutettavuusaiheista löytyy hyviä resursseja, joihin tämä sivu ohjaa useassa kohdassa. Sivu toimii siis myös ulkoisten resurssien koostesivuna.

Saavutettavuuden arvioinnin ja ylläpidon pikaopas olemassaolevaan projektiin

Ohjesivu sisältää nämä aiheet tarkemmin, mutta tiivistetty versio tarvittavista toimenpiteistä:

  1. Digipalvelulain vaatimuksiin tutustuminen.
  2. Halutut ruudunlukijasovellukset, selainlaajennokset ja muut automaattiset tarkastuskeinot (CI/CD-testit, linterit).
  3. Saavutettavuusarviointi käyttäen yllämainittuja työkaluja, jonka tuotoksena tieto palvelun saavutettavuuden tilasta.
  4. Saavutettavuusselosteen laatiminen ja laittaminen palvelun sivuille.
  5. Puutteiden korjausten suunnittelu ja toteutus, selosteen päivittäminen.

Määrittely

Jo palvelun määrittelyvaiheessa on hyvä olla selvillä, kuuluuko palvelu digipalvelulain piiriin, jotta tiedetään, tuleeko digipalvelulain saavutettavuusvaatimusten täyttyä. Vaikka laki ei palvelua koskisi, on hyvä muistaa, että saavutettava sivu on yleensä myös käytettävyydeltään hyvä eli vaatimusten täyttäminen on aina hyvästä. Saavutettavuusvaatimukset on oltava osa muuta vaatimusmäärittelyä.

Digipalvelulain piiriin kuuluvien digitaalisten palveluiden tulee täyttää lain määrittelemät kolme vaatimusta:

  1. Palvelun tulee täyttää saavutettavuusvaatimukset eli tällä hetkellä WCAG 2.1 -ohjeistuksen 49 A- ja AA-tason kriteeriä.
  2. Palvelun ja sen sisältöjen saavutettavuus tulee arvioida ja saavutettavuuden tila ja sen mahdolliset puutteet esitellä saavutettavuusselosteessa.
  3. Palvelussa tulee ole palautekanava saavutettavuuspalautteen jättämistä varten. Yhteydenottoihin tulee vastata 14 päivässä.

Käyttäjätarpeet on myös hyvä selvittää jo määrittelyvaiheessa. Loppukäyttäjistä puhuttaessa on muistettava myös ns. erityisryhmät, kuten toimintarajoitteiset. Erityisesti erityisryhmien kohdalla osallistaminen on hyödyllistä, jos tällaiseen on mahdollisuus.

Verkkosisällön saavutettavuusohjeet, Web Content Accessibility Guidelines (WCAG) 2.1

  • Kokoelma saavutettavuusohjeita, joiden avulla voidaan saavuttaa digipalvelulain mukaiset tekniset saavutettavuusvaatimukset
  • Digipalvelulaki velvoittaa noudattamaan WCAG 2.1-ohjeistuksen 49:ää A ja AA-tason kriteeriä
  • Olennainen dokumentaatio:

Suunnittelu

Monia saavutettavuuspuutteita voidaan taklata jo suunnitteluvaiheessa, kun komponentit suunnitellaan alusta lähtien saavutettaviksi. Siksi käyttöliittymän ja käyttäjäkokemuksen suunnittelua tekevillä on hyvä olla riittävästi saavutettavuusosaamista. 

Design System helpottaa saavutettavuutta eniten, kun komponentit ovat jo valmiiksi saavutettavia. Vaihtoehtoisesti voidaan käyttää saavutettavaa komponenttikirjastoa (esim. MUI).

Jos on mahdollista saada saavutettavuusasiantuntijan arvio, siitä on hyötyä varsinkin seuraavissa asioissa:

  • väripaletti ja käyttöliittymäelementtien visuaalinen ilme 
  • käyttöliittymän layout, valikkorakenne, navigaatio ja informaatioarkkitehtuuri
  • kohdistimen askellusjärjestys, kun käyttötapana on näppäimistö tai muu vastaava

Rautalankamalleihin, sivupohjaluonnoksiin ja muihin vastaaviin dokumentteihin on hyvä laittaa saavutettavuusratkaisut näkyviin alusta lähtien.

Resursseja:

Toteutus

  • Kehitystiimillä tulee olla riittävästi saavutettavuusosaamista.
  • Ruudunlukijakäytön perusteet tulee hallita saavutettavuuden testaamiseksi.
  • Natiivit HTML-elementit ovat usein valmiiksi saavutettavia. Jos natiivi toteutus ei ole saavutettava, voidaan hyödyntää Accessible Rich Internet Applications (ARIA)-ratkaisuja.

ARIA:

  • Kokoelma rooleja ja attribuutteja, joiden avulla voidaan tehostaa erityisesti interaktiivisten toiminnallisuuksien semantiikkaa. 
  • Tarkoituksena harkita ARIA-ratkaisuja vain silloin, kun natiivi elementti ei ole saavutettava. Natiivi HTML5 on usein saavutettavaa.
  • Keskeinen dokumentaatio:

Testaus

Saavutettavuuden testaus koostuu automaattisesta ja manuaalisesta testauksesta.

Automaattisella testauksella voidaan testata tehokkaasti teknistä saavutettavuutta eri työkalujen avulla.

Manuaalisella testauksella testataan kaikki ne seikat, joita automaattinen testaus ei pysty testaamaan, kuten sisällön selkeys ja asiaankuuluvuus.

Automaattinen testaus

  • Sisältää esimerkiksi selainlaajennokset, linterit, CI/CD-putken testit.
  • Työkaluja kehityksen aikaiseen testaukseen esimerkiksi Axe Devtools ja eslint.
  • Automaattisen testauksen työkalut havaitsevat suuren osan teknisistä saavutettavuusongelmista.

Resursseja:

Manuaalinen testaus

  • Näppäimistökäyttö, ilman ruudunlukijaa ja hiirtä.

  • Näppäimistökäyttö ruudunlukijan kanssa.
  • Kaikki toiminnallisuus tulee olla saatavilla myös pelkällä näppäimistöllä.
  • Suosituimmat ruudunlukija- ja selainyhdistelmät alustan mukaan:

     

    Alusta

    Ruudunlukija

    Selain

    iOS

    VoiceOver

    Safari

    Android

    Talkback

    Chrome

    Windows

    JAWS

    Chrome

    Windows

    NVDA

    Chrome

    MacOS

    VoiceOver

    Safari

     

Resursseja:

Ylläpito

  • Saavutettavuustyö ei pääty digipalvelun julkaisuun. Mikäli palvelussa julkaistaan uutta sisältöä, sen tulee olla saavutettavaa.
  • Päivitysten myötä saavutettavuutta tulee ylläpitää.
  • Saavutettavuusselosteen päivittäminen.
  • Saavutettavuuspalautteeseen reagointi.

Saavutettavuusarviointi ja saavutettavuusseloste

Saavutettavuusarviointi

  • Saavutettavuusarvioinnissa tarkistetaan palvelun saavutettavuuden taso WCAG 2.1 A ja AA-tason kriteerejä vastaan.
  • Arvioinnin lopputuotoksena laaditaan saavutettavuusseloste, jossa listataan saavutettavuuden tila, puutteet, sekä palautekanava saavutettavuuspalautteen jättämistä varten.
  • Arviointiprosessi tiivistettynä:
  • Rajaa arvioitava verkkosisältö. Rajauksen tulisi olla mahdollisimman kattava otos sisällöstä. Arvioi esimerkiksi erilaisia alasivuja ja tyypillisiä käyttötilanteita ja -polkuja. Sivuston kaikkea sisältöä ei ole tarpeellista arvioida.
  • Arvioi sivun saavutettavuus automaattisten ja manuaalisten työkalujen ja keinojen kautta. Voit hyödyntää sivuston arvionnissa erilaisia valmiita tarkistuslistoja helpottamaan prosessia.

→ MagentaA11y:n testaustyökalu

  • Laadi saavutettavuusseloste, jossa on listattuna kaikki WCAG 2.1 A ja AA-tason sisältämät saavutettavuuspuutteet. Voit hyödyntää selosteen laatimisessa Aluehallintoviraston selostepohjaa.

→ Aluehallintoviraston selostetyökalu

  • Laita valmis seloste saataville sivustolle.

Saavutettavuusselosteen ylläpito

  • Saavutettavuusseloste on pidettävä ajantasalla. Korjausaikataulun ilmoittaminen ei ole pakollista, mutta ilmoitetussa aikataulussa on pysyttävä.
  • Selosteen päivitys mieluiten korjaustoimenpiteiden valmistuessa, mutta vähintään kerran vuodessa.
  • Mahdolliseen saavutettavuuteen liittyvään palautteeseen on reagoitava 14 vuorokauden sisällä myös loma-aikoina. Palautekanavan tulee siis olla sellainen, johon on pääsy mahdollisilla loma-ajan sijaisilla. Yleisesti palautteen käsittelyn prosessi on hyvä miettiä etukäteen.

Arvioinnin ja selosteen resursseja:

Resursseja koostettuna:

Työkalut 

Tarkastuslistat

Muut

Koulutukset

  • Kaksiosainen saavutettavuusperehdytys saatavilla Flammassa