Aikaisemmin julkaistussa Wunder-artikkelissa olemme puhuneet siitä, että saavutettavuus on yksi perusoikeuksista. Nykytekniikka lisää ihmisten potentiaalia ja mahdollistaa asioita uudella tavalla. Maailmanlaajuisesti jopa miljardilla ihmisellä on jonkinasteinen rajoite. Huolehtimalla digitaalisen verkkopalvelusi saavutettavuudesta varmistat, että palvelusi ovat saatavilla myös tälle huomattavalle ryhmälle ihmisiä.
Saavutettavuus ja avustavat teknologiat voivat helposti aluksi vaikuttaa vieraalle ja vähän vaikealle kokonaisuudelle. Mistä pitäisi aloittaa? Saavutettavuuden eri ulottuvuudet ja niiden testaamiseen liittyvät prosessit saattavat aluksi tuntua lähes ylitsepääsemättömän monimutkaiselta kokonaisuudelta. Tämän artikkelin luettuasi sinulla on hyvät perustiedot aiheesta ja tiedät miten edetä.
Erityisen haastavalta saattaa tuntua kansainvälinen saavutettavuuden kriteeristö, WCAG 2.1. Ja mikä on WCAG 2.1? Se on lyhenne sanoista Web Content Accessibility Guidelines (Web-sisällön saavutettavuusohjeistus).
WCAG on kokoelma ohjesääntöjä, joilla voidaan arvioida onko jokin sivusto saavutettava vai ei. WCAG:tä käytetään myös arvioimaan lainmukainen saavutettavuuden taso. Uusi Euroopan Unionin saavutettavuuslainsäädäntö on jo osittain astunut voimaan ja nojaa laajalti WCAG:n ohjesääntöihin. Voidaankin sanoa, että kyseisen lain webiä koskeva osuus on kompakti versio WCAG 2.1:stä.
WCAG 2.1 itsessään on kaikkea muuta kuin kompakti: se on yli 80 ohjesääntöä koostuen useista suosituksista. Lopputulos on satoja sivuja pitkä. Huomattavasti helpompi ja tehokkaampi tapa perehtyä aiheeseen on neljän perusperiaatteen kautta, joita kutsutaan POUR:iksi.
POUR
POUR voisi viitata ranskan kieleen ja siihen, että on jotakin varten, mutta kyseessä on englanninkielisistä termeistä koostuva lyhenne. Kirjaimet tulevat sanoista:
- Perceivable (havaittava)
- Operable (hallittava)
- Understandable (ymmärrettävä)
- Robust (lujatekoinen)
Jotta sivusto olisi aidosti saavutettava näiden neljän periaatteen tulee toteutua. Käyttöliittymän tulee olla havaittava, hallittava, ymmärrettävä ja lujatekoinen, riippumatta siitä onko käyttäjällä jotain fyysisiä tai kognitiivisia rajoitteita.
1. Perceivable = havaittava
Yleisesti havaittavuus ajatellaan kykynä nähdä jotain. Kyse on kuitenkin laajemmasta kokonaisuudesta tapoja saada tietoa; ihminen voi havaita kokonaisuuksia myös mm. kuulon tai tuntoaistin perusteella.
Toki, suurin osa meistä havaitsee web-sisältöä nimenomaan näköaistiin perustuen. Katsomme näyttöä, luemme siitä tekstiä, näemme siinä värejä, tunnistamme siinä tuttuja muotoja ja mielemme rakentaa kaikesta tästä kokonaisuuksia.
Visuaalisessa muotoilussa parannetaan käytettävyyttä hyödyntäntämällä vastaanottajalle entuudestaan tuttuja elementtejä, kuten muotoja ja värejä.
Visuaaliseen vastaanottokykyyn vaikuttavia tekijöitä on lukuisia ja nämä seikat on huomioitava suunnittelussa. Punavihersokeus on yleistä: tästä syystä jonkin asian viestiminen pelkällä värillä on epävarmaa. Yksi yleisimmistä virheistä on esimerkiksi nettikaupoissa käytetty tapa viestiä tilasta, kuten tuotteen saatavuudesta värein; kertomalla siitä vihreä/punainen -väriyhdistelmällä. Punavihersokealle käyttäjälle tämä ei kerro mitään.
Iän myötä myös näkökyky heikkenee kaikilla. Tästä syystä tekstin tulisi olla järkevän kokoista jo lähtökohtaisesti ja sivuston rakenteen tulisi responsiivisuutta hyödyntämällä tukea käyttäjän mahdollisuutta valita suurempi fonttikoko. Myös tekstin ja taustan välinen kontrastiero vaikuttaa luettavuuteen; mitä isompi kontrasti, sitä parempi luettavuus.
Lopun viimein sisällön tulisi olla saavutettava jopa heille, jotka eivät näe lainkaan. Onneksi HTML, huolellisesti laadittuna, sisältää runsaasti näkemäämme enemmän tietoa, jota voidaan esittää useammalla esitystavalla. Otsikointi, eli heading, ei tarkoita vain suurikokoista tekstiä. Otsikointi luo piilevän hierarkisen rakenteen sisällölle ja tämä helpottaa navigointia sivulla ruudunlukuohjelmaa käytettäessä. Kuvista löytyy tekstivastineet, listojen kohtien kokonaismäärä sekä järjestys on tiedossa ja sivurakenteen tärkeimmillä alueilla on piilonimet. Taulukot (tables) rakentuvat otsakkeista, sarakkeista ja riveistä, mikä mahdollistaa niiden tehokkaan tarkastelun eri apuvälineillä. Tyypillinen HTML-sivu sisältää paljon enemmän tietoa kuin mitä voimme nähdä.
HTML:n ja tekstisisällön hienous on juuri siinä, että niitä voidaan esittää niin monella tavalla. Avustavat teknologiat mahdollistavat sivustojen sisällön havaitsemisen monella eri aistilla.
Yksi tärkeä ja saavutettavuuden symboliksi muodostunut avustava teknologia on ruudunlukuohjelma. Se ymmärtää HTML:ää ja lukee sitä ääneen ihmiselle ymmärrettävällä tavalla. Tämä mahdollistaa sisällön ymmärtämisen ja rakenteen hahmottamisen pelkästään ääneen perustuen.
Entä jos henkilö ei näe eikä kuule? Ruudunlukuohjelmat voivat kääntää sisällöt erilliselle laitteelle pistekirjoitukseksi ja näin sisältöön pääsee kirjaimellisesti käsiksi.
Sisältö voi olla myös ääntä. Äänipohjaiselle informaatiolle tulee olla vaihtoehtoinen esitystapa. Tekstitykset ja auditiivisen sisällön kuvaaminen tekstillä ovat yleisimpiä tapoja tehdä äänisisällöstä saavutettavaa. Monille tuttu esimerkki on nettisarjoissa valittava tekstitys, jossa dialogin lisäksi tekstimuodossa kuvaillaan juonen kannalta tärkeitä ääniä (hälytysajoneuvon sireeni, kova pamaus, taustamusiikin luonne jne.)
Digiluiska helpottaa kaikkien surffausta
Samalla tavalla kuin lastenvaunujen tai rullatuolin kanssa liikkuvalle luiskat ja rampit mahdollistavat pääsyn rakennuksiin, saavutettavat verkkopalvelut mahdollistavat pääsyn tiedon luokse ja asioinnin erilaisille käyttäjille. Havaittava sivusto ei ole vain siltä osin saavutettava vaan tarjoaa ikään kuin samalla digitaalisia luiskoja. Ne lisäävät helppokäyttöisyyttä ja näin ollen palvelevat kaikkia käyttäjiä.
Esimerkkejä digiluiskoista:
- Riittävä kontrasti; tarve korostuu kaikilla käyttäjillä, kun sisältöjä käytetään matkapuhelimella kirkkaassa auringonpaisteessa
- Tekstitys; näin videosisällöt toimivat myös ilman ääntä tai meluisassa ympäristössä
- Ruudunlukijaohjelmaa käyttäviä suuresti auttava artikkeleiden korrekti rakenne mahdollistaa sisällön lukemisen myös selaimen erityisellä lukutilalla. Artikkelin voi myös tallentaa luettavaksi myöhemmin erilliseen pilvipalveluun. Tämä on mahdollista vain, kun sivuston rakenteen HTML on laadittu huolellisesti.
- Asetus tekstin fonttikoon muuttamiseen voi auttaa, kun et löydä lukulaseja tai esität pientä sisältöä näyttöä ryhmälle.
- Tumma tila (dark mode) ei häikäise valoherkkyydestä kärsiviä, vähentää taustavalon aiheuttamaa häiriötä hämärässä tilassa, eikä rasita silmiä samalla tavalla kuin vaalea tausta mustalla tekstillä.
Havaittavuuden huomioiminen ja sen lisääminen ei ainoastaan mahdollista käyttöä useammalle, vaan hyödyttää kaikkia käyttäjiä. Ihan mukava sivuvaikutus!
2. Operable = hallittava
Verkkopalvelun havaittavuus on ensimmäinen askel, mutta miten käy, kun sivustolla pitäisi pystyä navigoimaan? Valtaosa käyttää sivustoja näppäimistön ja hiiren tai kosketusnäytön avulla. Hiiri on pitkään ollut, ja on edelleen, yksi käytetyimmistä tavoista käyttää verkkosisältöä. Kosketusnäytöt ovat toki suurilta osin korvanneet hiiren, mutta lähtökohtaisesti osoitamme yhä tiettyä kohtaa näytöllä, oli se sitten koskettamalla, hiiren, pallohiiren tai kosketuslevyn välityksellä.
Tämä ei kuitenkaan ole ainoa tapa käyttää laitteita. Osalla meistä voi olla alentunut motorinen kyvykkyys. Yhden tai molempien käsien käyttäminen voi olla väliaikaisesti tai pysyvästi mahdotonta. Näin ollen näppäimistön ja hiiren yhdistelmä ei ole hyvä tai edes mahdollinen vaihtoehto. Kokonaan oma hallittavuuden maailma voidaan tiivistää WCAG:n määrittelemään näppäimistöhallittavuuteen (Keyboard Operable). Tämän tuen kautta huolellisesti muotoiltu ja toteutettu sivusto mahdollistaa navigoinnin jopa pelkällä imu/puhalluskytkimellä.
Suuri osa käyttäjistä navigoi sivustoja jo mm. seuraavissa tilanteissa:
- Vierittämällä sivua ylös tai alas nuolinäppäimillä
- Liikuttamalla kursoria tekstikentän sisään nuolinäppäimillä oikealla tai vasemmalle
- Valitsemalla sarkaimella lomakkeissa seuraavan täytettävän kentän
- Lomakkeiden lähettäminen rivinvaihtoa painamalla
Joskus sivustot eivät reagoi tyypillisiin näppäimistön käskyihin, jotka tulevat käyttäjillä ikään kuin lihasmuistista. Tämä laskee käytettävyyttä. Lisäksi huomattava osa käyttäjistä klikkaa linkkejä ja muita elementtejä muulla kuin hiirellä tai kosketusnäytöllä. Mikäli nämä elementit eivät ole näppäimistöntuen saavutettavissa, käytettävyys laskee huomattavasti tai on jopa mahdotonta.
Käyttöliittymän kaikkia interaktiivisia elementtejä tulee pystyä käyttämään näppäimistöllä.
Näppäimistöhallittavuudessa on olemassa pienempiä ja isompia käytettävyyshaasteita. Henkilöille, jotka eivät fyysisesti kykene käyttämään mitään osoitinvälineitä, päivittäiset, äärimmäisen hankalat käyttökokemukset tai suoranainen mahdottomuus käyttää sivustoa näppäimistötuen kautta, on helposti jokapäiväinen ongelma. Samojen haasteiden kanssa painivat he, joilla on pysyvä tai ohimenevä lääketieteellinen tila, joka vaikuttaa motoriikkaan, ja siten kykyyn käyttää hienomotoriikkaa vaativia osoittimia.
Juuri tämä on se syy, miksi kaikkien klikattavien elementtien tulee olla käytettäviä myös pelkällä näppäimistöllä. Useimmissa selaimissa sarakkeen painaminen ei ainoastaan valitse seuraavaa lomakkeen elementtiä: se voi valita seuraavan linkin, painikkeen tai jonkin muun interaktiivisen elementin. Erittäin yleinen virheellinen toteutustapa on ei-interaktiivisen HTML-elementin, kuten spanin tai divin muuntaminen klikattavaksi Javascriptillä, jolloin se toimii osoitinlaitteella, muttei ole näppäimistötuen saavutettavissa.
Ajatellaan esimerkiksi liikkumista päävalikon alasvetovalikossa: käyttämällä HTML:n painike-elementtejä ylätason linkkien rinnalla, alasvetovalikko on mahdollista avata painikkeesta myös näppäimistötuen kautta. On melko tyypillistä, että tällaista painiketta ei ole ja alasvetovalikon saa auki vain pitämällä hiiren osoitinta valikon linkin päällä. Tai sitten alasvetovalikon avaava painike ei ole todellinen painike, eikä siihen siksi pääse käsiksi näppäimistötuen kautta.
Avustavat teknologiat pohjautuvat näppäimistöhallittavuuteen
Interaktiivisten elementtien näppäimistöhallittavuus ei vielä täysin riitä: joidenkin käyttöliittymäelementtien, kuten välilehtien odotetaan toimivan tietyllä tapaa. Myös näppäimistötuen kohdistusjärjestyksen tulee olla ennalta-arvattava (eli mikä elementti valikoituu seuraavaksi, kun saraketta painetaan). Tästä syystä natiiveissa HTML-elementeissä pysyminen on erittäin suositeltavaa. Niistä löytyvä näppäimistötuki on yllättävän monimutkainen kokonaisuus. Siksi on todella aikaa vievää yrittää toteuttaa räätälöityjä käyttöliittymätoteutuksia saavutettavasti. Tämä on monesti väistämätöntä, mutta sitä kannattaa välttää.
Mikäli aivan ehdottomasti on tarve räätälöidylle käyttöliittymäelementille, niin on olemassa oppaita miten erilaisten käyttöliittymäratkaisujen odotetaan toimivan, ja miten niissä tulee hyödyntää niin kutsuttuja ARIA-attribuutteja. Näiden avulla viestitään avustaville teknologioille mikä elementti on kyseessä ja missä tilassa se on kulloinkin. W3C kutsuu näitä “widgeteiksi”. Näiden kanssa tulee kuitenkin olla erittäin valppaana, sillä pienikin virhe ARIAn käytössä voi olla kriittinen, aiheuttaen huomattavia käytettävyysongelmia. Tästä syystä on tärkeää käyttää widgettien toteutukseen referenssejä, jotka ovat luotettavista lähteistä. W3C tarjoaa kattavan englanninkielisen listan aiheeseen liittyen täällä.
Hyvä ja kattava tuki näppäimistölle takaa luotettavan pohjan myös monelle avustavalle teknologialle. Esimerkiksi, jos päävalikon alasvetovalikon avaaminen onnistuu näppäimistötuella, se yleensä toimii myös muilla avustavilla teknologioilla. Tämä ei vielä kuitenkaan riitä täyteen saavutettavuuteen, vaan avustavalle teknologialle tulee viestiä alasvetovalikon painikkeen tila eli onko se suljettu vai laajennettu. Tämä onnistuu ARIA-attribuutilla “aria-expanded”.
Käyttöliittymän ja sen sisältöjen saavutettavuutta käsitellään tarkemmin WCAG 2.1:n kriteeristön osioissa 1. Havaittava ja 3. Ymmärrettävä.
Useampi tapa
Eräs yleinen ja tärkeä kriteeri hallittavuuteen liittyen löytyy WCAG:n kohdasta 2.4.5 “Multiple Ways” (Useampi tapa). Jotta tämän suosituksen kriteerit täyttyvät sivustolla, täytyy olla enemmän kuin yksi mahdollinen tapa navigoida kaikkeen sisältöön. Lyhykäisyydessään tämä tarkoittaa sitä, että käyttäjän tulisi tarvittaessa säästyä monimutkaisilta tai kohtuuttoman työläiltä käyttöliittymiltä. Esimerkiksi monitasoisten valikoiden käyttäminen voi olla erittäin turhauttavaa avustavien teknologioiden avulla, vaikka se teknisesti olisikin mahdollista.
Käyttötapojen moninaisuus on myös eräänlainen turvaverkko. Jos yksi tapa käyttää ei jostain syystä toimi, toisella tavalla käyttö onnistuu edelleen. Ja hyvin usein: mitä useampi käyttötapa on, sitä helpommin navigointi sivuilla onnistuu ihan kaikilta.
Yksi laajalti käytössä olevista tavoista navigoida sivuilla on hakutoiminnon hyödyntäminen. Toinen on ihan perinteinen sivukartta, joka on suunniteltu ihmisille (eri asia kuin XML sivukartta, joka on hakukoneita varten).
Informaatiosivustolla on lisäksi suositeltavaa muotoilla polku sisältöön etusivulta asti hyödyntäen sisältönostoja ja linkkilistoja. Tällä tavoin sivustolla liikkuminen voi olla monelle luontevampaa kuin monimutkaisen valikon käyttö.
Pähkinänkuoressa: On aina erittäin hyvä idea varmistaa, että sisällöt ovat saavutettavissa vähintään kahdella eri tavalla.
3. Understandable = ymmärrettävä
Tiedon ja käyttöliittymän toiminnan tulee olla käyttäjälle ymmärrettävää. Melko itsestäänselvä toteamus, mutta se ei siltikään aina toteudu.
Ymmärrettävyys on myös aihe, johon erityisesti muotoilijoiden ja sisällöntuottajien tulisi panostaa. Kyseessä on myös hyvin kompleksinen kokonaisuus, johon ei ole olemassa yksiselitteisiä oikeita vastauksia tai linjauksia. Muotoilijat ovat jo pitkään tutkineet ymmärrettävyyttä, eikä kyseessä ole vain saavutettavuuden yhteydessä esiintyvä aihe.
Monimutkaiset kielelliset rakenteet ovat yleisin kompastuskivi sivustoilla, jotka sisältävät paljon informaatiota. Oikeastaan ainoa mitä tämän tyyppisissä tilanteissa voi tehdä, on sisällöntuottajien tietoisuuden lisääminen aiheesta. Mikäli sivustolla käsiteltävä aihe itsessään on monimutkainen, ymmärrettävän kokonaisuuden luominen on sekä entistä haastavampaa että tärkeämpää. Yksittäisenä vinkkinä mainittakoon lyhyiden lauserakenteiden suosiminen. Yksi asia yhdessä lauseessa.
Perinteisesti käyttöliittymän ymmärrettävyys pohjaa UX-muotoiluun (user experience). Esimerkiksi Nielsen Norman Group on tehnyt merkittävän määrän tutkimustyötä vuosien ajan ja tarjoaa tietoa julkisesti internetissä. He tuottavat artikkeleita käyttöliittymien haasteista ja vertailevat eri ratkaisumallien heikkouksia ja vahvuuksia. Voisikin sanoa, että ymmärrettävyys on jo verrattain monen muotoilijan hallussa.
Lopulta kyse on siitä, että ymmärtääkö käyttäjä sivuston sisältöä ja miten sivustoa käytetään. Onneksi tämä on selvitettävissä sivustoa rakentaessa, kunhan vain UX-muotoilijoille annetaan tarpeeksi resursseja käyttäjien tarpeiden prosessointiin, tutkimusten lukemiseen ja käyttäjätestaukseen.
Yksi huomionarvoinen ymmärrettävyyteen liittyvä asia on inklusiivisen muotoilun periaate. Muotoillessa palveluita ja käyttöliittymiä tulee huomioida mahdollisimman kattavasti ihmisten erilaisuus ja mahdolliset erikoistarpeet. Muotoilu, joka nojaa hiirellä tai kosketusnäytöllä navigointiin ja on tahattomasti suunnattu nuorille, hyvin näkeville diginatiiveille ei taatusti ole kaikille toimiva ratkaisu. Kun sen sijaan alunperinkin oletetaan käyttäjien poikkeavan toisistaan paljon, luomme ymmärrettävämpiä ratkaisuja kaikille. Mitä aikaisemmassa vaiheessa muotoilua muistetaan ottaa huomioon erilaiset ihmiset, sitä suuremmalla todennäköisyydellä emme palvele joitain ihmisiä toissijaisina käyttäjinä, joille lopputulos on hankalampi ymmärtää.
Ymmärrettävyyteen on onneksi myös muutamia melko yksiselitteisiä ohjenuoria. Lomakekentät tulee aina nimetä ja ohjeistaa hyvin. Sivuston sisällöissä tapahtuvien muutosten tulee olla käyttäjälähtöisiä tai muuten loogisia. Yksi tärkeimmistä suosituksista erityisesti monikielisillä sivuistoilla on sivuston kielen tunnistaminen ohjelmallisesti. Avustaville teknologioille ja käännössovelluksille on elintärkeää tietää sivun kieli tai ne eivät välttämättä toimi oikein.
4. Robust = lujatekoinen
Web-alalla on yleisesti tunnettua, että eri selaimien ja käyttöjärjestelmien yhdistelmät käyttäytyvät keskenään eri tavoin. Joskus tämä johtuu verkkosivuston standardista poikkeavasta toteutuksesta ja toisinaan taas selaimet noudattavat itse standardeja hieman eri tavalla. Tämä aiheuttaa ikäviä bugeja ja harmaita hiuksia kehittäjille.
Lujatekoisuus ei ole uusi konsepti; se koskee nimenomaan toteutuksen standardinmukaisuutta. Saavutettavuuden kohdalla se ulottuu selaimia pidemmälle; se käsittää myös avustavat teknologiat, jotka ovat riippuvaisia HTML:n tasosta.
Edellä mainittu selainten välinen haaste liittyy usein CSS:ään ja Javascriptiin. HTML ei tyypillisesti ajateltuna aiheuta kehittäjille ongelmia. Kun asiaa tarkastellaan avustavien teknologioiden näkökulmasta, tilanne on aivan toinen. Nämä teknologiat, kun ovat hyvinkin riippuvaisia HTML:n tasosta. Eli aivan kuten epätasainen CSS- ja/tai Javascript-tuki, myös huolimattomasti laadittu HTML voi aiheuttaa käytettävyysongelmia.
Tuplatunnisteet, liiallinen määrä HTML-elementtejä ja epävalidit attribuutit ovat omiaan sekoittamaan avustavia teknologioita. Pahimmillaan ne eivät toimi lainkaan, jos HTML:n taso on liian heikko.
Mainitsin tässä artikkelissa aikaisemmin ARIA-attribuuttien roolin ja tärkeyden; erityisesti jos sivustolle toteutetaan räätälöityjä käyttöliittymäelementtejä eli “widgettejä”. Näiden erikoisratkaisuiden kohdalla on aina se riski, että ne toimivat moitteetta joissakin ympäristössä ja samalla eivät lainkaan toisessa. Ne voivat siis olla hyvinkin heikkotekoisia ratkaisuja.
Kaikista näistä neljästä POUR-periaatteesta lujatekoisuuden testaaminen ohjelmallisesti on kaikista yksinkertaisinta. HTML-validointityökaluja on ollut olemassa jo vuosia. Automaattisista saavutettavuustyökaluista mainittakoon mm. aXe ja Wave. Muiden WCAG-vaatimusten lisäksi nämä testaavat ARIA-attribuuttien validiteettia ja osaavat etsiä mm. puuttuvia lomakekenttien nimilappuja. Ohjelmat eivät tietenkään pysty testaamaan semantiikkaa ja ymmärrettävyyttä. Ainakin toistaiseksi ne kykenevät validoimaan ainoastaan HTML:ää, osin CSS:ää ja näistä yksinkertaisesti johdettua tietoa, kuten tekstikontrasteja.
Jos POUR kiinnostaa sinua pintaa syvemmältä, niin täältä löydät englanninkielisen WCAG-ohjeistuksen kokonaisuudessaan täältä.
Lista on pitkä, mutta on huojentavaa tietää, etteivät kaikki suositukset ole relevantteja kaikille elementeille kaiken aikaa. Voit myös keskittyä vain muutaman osion opiskeluun. Tutustu myös jokaista ohjesääntöä tarkentaviin sivuihin “How to meet the guideline” ja “Understanding guideline”.
Yksittäisistä ohjesäännöistä suosittelisin aloittaa seuraavista:
- 1.1.1 Non-text Content
- 1.3.1 Info and Relationships
- 1.4.3 Contrast
- 2.1.1 Keyboard
- 2.4.6 Headings and Labels
- 2.4.7 Focus Visible
- 3.2.1 On Focus
- 4.1.2 Name, Role, Value
Lisäksi hyvä suomenkielinen lähde on saavutettavuuslain voimaantulon yhteydessä julkaistu Saavutettavuusvaatimukset-sivusto, joka sisältää tietoa sekä laista että saavutettavuudesta itsestään.
Suositusten ymmärtäminen on hyvä alku. Niiden noudattaminen poistaa monia saavutettavuuden haasteita. Kun pitää mielessä, että muodon tulee olla alisteinen toiminnallisuudelle, kuten muotoilussa aina, niin pääsee jo todella pitkälle.
Me Wunderilla teemme ahkerasti töitä sen eteen, että digitaalisuus kuuluisi kaikille. Vahvuutemme on saavutettavien ja visuaalisesti eheiden kokonaisuuksien muotoilu ja toteutus. Autamme mielellämme myös sinua muokkaamaan verkkopalvelusi saavutettavaksi, tyyliä unohtamatta.