Näin suunnittelet responsiivisen sivuhierarkian, jota on helppo silmäillä ja ymmärtää

Toimiva responsiivinen sivuhierarkia antaa käyttäjälle nopeasti neljä vastausta: mikä sivun tarkoitus on, mikä näyttö tukee sen väitteitä, mitä vaihtoehtoja on tarjolla ja mikä on seuraava askel. Tämä järjestys ratkaistaan ennen sommittelua. Muuten tyylikäs työpöytänäkymä voi muuttua kapealla tai suurennetulla näytöllä pitkäksi moduulipinoksi, jossa johdanto, todisteet, kolme palvelupakettia, kelpoisuustiedot ja painikkeet vaativat yhtä paljon huomiota. Responsiivisuus ei silloin epäonnistu vain ulkonäössä: käyttäjän on vaikeampi suunnistaa, vertailla ja edetä.

Mitä responsiivisen sivuhierarkian pitää auttaa ymmärtämään?

Hierarkian pitää auttaa tunnistamaan sivun tarkoitus, löytämään olennainen näyttö, ymmärtämään valinnat ja näkemään seuraava askel ilman suunnittelijan selitystä. Neljän kysymyksen testi on toimituksellinen synteesi, ei W3C:n, Nielsen Norman Groupin tai GOV.UK:n nimeämä menetelmä. Sen hyöty on käytännöllinen: se muuttaa keskustelun siitä, näyttääkö sommittelu tasapainoiselta, kysymykseksi siitä, säilyvätkö merkitys ja tehtävän suunta leveässä, kapeassa, suurennetussa ja linearisoidussa esityksessä.

W3C:n täydentävä kognitiivisen saavutettavuuden ohje korostaa selkeää sivuotsikkoa, joka auttaa tunnistamaan sijainnin ja sivun tarkoituksen. Se ei ole WCAG-onnistumiskriteeri. Nielsen Norman Group puolestaan kuvaa kerroskakkumaista silmäilyä, jossa käyttäjä käy läpi erottuvia ja sisältöään oikein kuvaavia väliotsikoita. Havaintoa ei pidä muuttaa yleispäteväksi F- tai Z-malliksi, sillä silmäilyyn vaikuttavat muun muassa tehtävä, kieli, sisältö, tuttuus ja asettelu.

Kolmen yritystuen palvelupaketin sivulla testi paljastaa ongelman nopeasti. Jos johdanto, kelpoisuusnäyttö, pakettien kuvaukset, yksityiskohdat ja kaikki painikkeet näyttävät yhtä tärkeiltä, käyttäjä ei tiedä, mikä auttaa valitsemaan ja mikä vain täydentää päätöstä. Kapeassa näkymässä tasavahvat alueet eivät muutu selkeämmiksi vaan peräkkäiseksi jonoksi. Korjaus alkaa siis prioriteetista, ei uusista korteista, suuremmasta otsikosta tai uudesta taitekohdasta.

Mitä tiimin pitää päättää ennen sivun tyylittelyä?

Tiimin pitää sopia sivun tehtävä, sisältöjen prioriteetti, olennaiset suhteet ja vähintään yksi merkityksellinen ohjelmallinen lukemisjärjestys. Palvelupakettisivun sopimus voidaan kirjoittaa näin: auta ostajaa valitsemaan sopiva tukitaso, pidä kelpoisuusnäyttö sen väitteen yhteydessä, jota se tukee, tee kolmesta paketista vertailukelpoiset ja osoita arviointipyynnön olevan sivun ensisijainen jatkotoimi. Sopimus kertoo myös, mitä ei saa kadottaa, kun palstat, rinnakkainen sijoittelu tai koristeellinen rajaus poistuvat.

Pidä erillään kolme päätöstä, jotka sekoittuvat helposti. Sisältöprioriteetti määrittää, mitä käyttäjän on ymmärrettävä ensin. Semanttinen rakenne kertoo ohjelmallisesti otsikot, ryhmät, nimilaput ja suhteet. Visuaalinen hierarkia tekee saman järjestyksen havaittavaksi koolla, tilalla, sijoittelulla ja kontrastilla. WCAG-ohjeistus edellyttää, että tärkeät visuaaliset suhteet ovat myös ohjelmallisesti selvitettävissä tai saatavilla tekstinä. Kun järjestys muuttaa merkitystä, vähintään yhden oikean lukemisjärjestyksen on säilyttävä.

1. Aloita orientaatiosta: kerro sivun tarkoitus ja se, kenelle valinta on tarkoitettu.
2. Sijoita päätöstä tukeva näyttö väitteen yhteyteen sekä rakenteessa että sanamuodossa.
3. Esitä kunkin paketin vertailtavat ominaisuudet samassa ymmärrettävässä järjestyksessä.
4. Pidä pakettikohtainen toiminto sen paketin asiayhteydessä ja erota se sivutason arviointipyynnöstä.

Työpöytänäkymän vasemmalta oikealle etenevä sommittelu ei automaattisesti määrää kapean näkymän pinoamisjärjestystä. Lähdejärjestyksen pitää olla ymmärrettävä silloinkin, kun CSS-sijoittelu, palstat ja taustat poistuvat. Toisistaan riippumattomien alueiden keskinäiselle järjestykselle voi silti olla useita oikeita vaihtoehtoja. Tavoitteena ei ole yksi jäykkä jono, vaan oikean asiayhteyden säilyminen siellä, missä otsikon, väitteen, näytön, arvon tai toiminnon järjestys vaikuttaa merkitykseen.

Miten visuaalisten signaalien tulee paljastaa hierarkia?

Visuaalisten signaalien tulee tehdä sovittu rakenne nopeasti havaittavaksi ilman, että yksikään niistä kantaa merkitystä yksin. Aloita otsikoista, jotka ennakoivat sisältöä: esimerkiksi ”Valitse sopiva tukitaso” kertoo enemmän kuin ”Palvelut”, ja ”Tarkista kelpoisuusehdot” enemmän kuin ”Lisätiedot”. Erottuva otsikko ei kuitenkaan auta, jos se kuvaa osiota väärin tai jos otsikkotaso puuttuu ohjelmallisesta rakenteesta. Sanamuodon, semantiikan ja visuaalisen roolin on osoitettava samaan suuntaan.

Rakenna hillitty typografia-asteikko todellisella kirjaintyypillä, sisällöllä ja käyttöliittymäleveydellä. Säilytä roolien keskinäinen ero, vaikka pistekoot ja välit mukautuvat. GOV.UK Design System tarjoaa yhden tuotantoesimerkin, jossa nimetyt typografiaroolit ja pystysuuntainen rytmi säilyvät kokojen muuttuessa pienellä näytöllä. Sen arvoja ei pidä kopioida yleisratkaisuksi: suomen pitkät yhdyssanat, muut kielet, kirjoitusjärjestelmät, brändifontti ja tuotteen todelliset otsikot on testattava erikseen.

Käytä välistystä kahteen tarkoitukseen: pieni, ennakoitava väli kertoo kuuluvuudesta ja suurempi väli osioiden rajasta. Linjaus auttaa vertaamaan samoja ominaisuuksia; rajaus ja tausta voivat näyttää, mikä näyttö kuuluu mihinkin väitteeseen. GOV.UK:n välistysasteikko havainnollistaa, kuinka suuret erot voivat pienentyä kapealla näytöllä pienten suhdevälien pysyessä vakaina, mutta sen mitat ja taitekohta ovat järjestelmäkohtaisia. Mittakaava, väri, sijoittelu ja kontrasti ohjaavat huomiota vasta, kun tehtäväprioriteetti on jo perusteltu.

Miten näyttö, vaihtoehdot ja seuraava toiminto erotetaan toisistaan?

Näyttö, vaihtoehdot ja seuraava toiminto erotetaan antamalla niille selkeät tehtäväroolit ja säilyttämällä niiden asiayhteys. Korjatussa leveässä näkymässä palvelunvalinnan tarkoitus aloittaa sivun. Kelpoisuusnäyttö sijaitsee sen väitteen vieressä, jota se tukee, ja kolme pakettia muodostavat yhden nimetyn vertailualueen. Visuaalinen läheisyys ei yksin riitä: myös tekstin tai ohjelmallisen rakenteen pitää ilmaista, mihin pakettiin, väitteeseen tai ehtoon näyttö kuuluu.

Esitä kustakin paketista samat päätökselle olennaiset ominaisuudet samassa järjestyksessä. Näin ostaja vertaa samanlaisia asioita eikä etsi yhtä palvelutasoa hinnan, toista vasteen ja kolmatta kelpoisuusehtojen kautta. Älä nosta yhtä pakettia suositukseksi ilman tehtävä- tai käyttäjänäyttöä. Paketin valitseminen, ehtojen lukeminen ja sivutason arvioinnin pyytäminen voivat kaikki olla tarpeellisia toimintoja, mutta niiden ei tarvitse näyttää yhtä ensisijaisilta. Painotus kuvaa tehtäväroolia, ei organisaation sisäistä myyntitoivetta.

Kirjoita toimintoteksti niin, että käyttäjä tietää, mitä tapahtuu seuraavaksi: ”Pyydä soveltuvuusarvio” on informatiivisempi kuin ”Jatka”. GOV.UK:n ohje varoittaa useista yhtä korostetuista päätoiminnoista ja liian monista toissijaisista painikkeista, mutta sääntö ei tarkoita vain yhtä sallittua toimintoa. Täydentävä näyttö on alempana prioriteetissa, ei arvotonta. Sen voi tiivistää tai avata pyynnöstä vain, jos käyttäjä löytää sen, tunnistaa suhteen oikeaan väitteeseen ja pystyy käyttämään avausta.

Mitkä responsiiviset muutokset säilyttävät merkityksen?

Merkityksen säilyttävä responsiivinen muutos pitää tiedon, toiminnallisuuden, suhteet ja tehtäväprioriteetin ymmärrettävinä uudessa esityksessä. Hyvä lähtökohta on kapea yhden palstan rakenne, johon lisätään rinnakkaisuutta vain, kun se parantaa pakettien vertailua tai näytön yhdistämistä oikeaan väitteeseen. GOV.UK käyttää tätä lähestymistapaa omassa järjestelmässään, mutta sen ruudukko ja mitat eivät ole yleisiä sääntöjä. Leveä näkymä on parannus vain, jos se tekee päätöksen helpommaksi rikkomatta lähdejärjestystä.

• Säilytä alue ennallaan, kun sisältö, suhde ja tehtävärooli toimivat uudessa tilassa ilman vältettävää kaksiulotteista vieritystä.
• Pinoa alueet, kun niiden järjestys on oikea ja jokainen alue säilyy ymmärrettävänä sekä käytettävänä yhden suunnan lukemisessa.
• Siirrä alue vain, jos ohjelmallinen lukemisjärjestys pysyy merkityksellisenä ja otsikot, arvot, näyttö sekä toiminnot säilyttävät asiayhteytensä.
• Tiivistä toistoa tai esitystapaa, mutta älä poista päätökselle olennaista tietoa tai toiminnallisuutta.
• Avaa yksityiskohtia pyynnöstä vain, jos avausohjain on kuvaava, käytettävä ja selvästi yhteydessä sisältöönsä.

WCAG:n mukautumista koskeva ohje edellyttää testiehtojensa puitteissa, ettei tietoa tai toiminnallisuutta menetetä eikä tavallinen lukeminen vaadi kaksiulotteista vieritystä. Poikkeus koskee esityksiä, joissa kaksi ulottuvuutta on merkitykselle tai toiminnalle välttämätön, kuten joitakin datataulukoita. Sellaista sisältöä ei pidä pakottaa naiivisti yhdeksi jonoksi. Myös monimutkainen käyttöliittymä voi vaatia toiminnallisen muutoksen pelkän pinoamisen sijaan. Jokainen ratkaisu tarkistetaan lisäksi kapeana, suurennettuna ja ohjelmallisessa lukemisjärjestyksessä.

Responsiivinen hierarkia ei ole työpöytälaatikoiden romahtamisjärjestys vaan järjestys, jossa merkitys säilyy.

Miten tiimin kannattaa auditoida ja hallita hierarkiaa?

Tiimin kannattaa auditoida hierarkia toistamalla sama neljän kysymyksen tehtävä leveässä, kapeassa, suurennetussa ja linearisoidussa esityksessä. Pyydä arvioijaa nimeämään sivun tarkoitus, löytämään merkityksellinen kelpoisuusnäyttö, tunnistamaan kolme pakettivaihtoehtoa ja osoittamaan arviointipyynnön toiminto ilman suunnittelijan johdatusta. Kirjaa erikseen sisällön katoaminen, kaksiulotteinen vieritys, väitteestä irronnut näyttö, rikkoutunut vertailu, keskenään kilpailevat toiminnot ja liian syvälle painunut seuraava askel.

Tarkista ohjelmallinen lukemisjärjestys erillään näkyvästä sommittelusta. Kuvaavat otsikot auttavat löytämään tietoa, mutta eivät korvaa oikeita otsikkotasoja, ryhmiä tai nimilappujen suhteita. Seuraa linearisoituna, pysyvätkö paketin nimi, ominaisuudet, arvot, kelpoisuusnäyttö ja toiminto yhdessä ymmärrettävänä kokonaisuutena. Keskity järjestyksiin, jotka vaikuttavat merkitykseen; riippumattomien alueiden ei tarvitse noudattaa yhtä mielivaltaista järjestystä. Tarkista mukautumisessa aina sekä tiedon että toiminnallisuuden säilyminen, ei vain moduulien mahtumista näkymään.

Täydennä asiantuntija-arvio edustavien ostajien tehtäväpohjaisilla kokeilla. Havainnoi, pystyvätkö he orientoitumaan, löytämään päätöstä tukevan näytön, vertaamaan tarvittavia ominaisuuksia ja etenemään ilman vältettävää epävarmuutta. WCAG-vaatimusten täyttäminen on saavutettavuuden lähtökohta, ei todiste siitä, että käyttäjät ymmärtävät sivun tai suorittavat tehtävän. Luokittele löydökset hierarkiasopimuksen mukaan ja vie toistuvat korjaukset sisältömalleihin, sivupohjiin, komponentteihin, katselmointikriteereihin ja julkaisun tarkistuslistaan.

Ota käyttöön yksi hallintasääntö: jokainen sivutason hierarkiapäätös on voitava perustella hierarkiasopimuksella, edustavalla käyttäjätehtävällä ja havaitulla tuloksella, ei pelkällä maulla. Kun tiimiltä puuttuu näyttöä tai se ei pysty luotettavasti arvioimaan monimutkaisia suhteita ja responsiivista käyttäytymistä, ota mukaan saavutettavuuden tai käyttäjätutkimuksen asiantuntija. Näin yksittäinen auditointi muuttuu ylläpidettäväksi toimintatavaksi, jossa sama merkitys kestää uudet sisällöt, kielet, näkymät ja julkaisukierrokset.