Otos koostuu 50 Figma-tiedostosta 28 tuotantotiimiltä SaaS-, vähittäiskauppa-, fintech-, julkishallinto- ja koulutustekniikka-aloilta. Neuvottelimme katseluoikeuden ei-nimeämisperiaatteella: mikään tässä artikkelissa ei tunnista brändiä, tiimiä tai suunnittelijaa. Tiedostot valittiin kuvaamaan sitä, mitä kehittäjä todellisuudessa vastaanottaisi käsikirjoituksessa — ei portfoliosivuston kiillotettua tapaustutkimusta — joten pyysimme kutakin tiimiä jakamaan tiedoston, josta viimeisin ominaisuus oli toimitettu, ei tiedoston, josta he olivat ylpeimpiä. Kaksitoista tiedostoista oli tiimeiltä, joilla on erillinen design-system-käytäntö; loput 38 olivat tuotetason tiedostoja, jotka toivat kirjastosta komponentteja tai rakensivat niitä suoraan tiedostoon.

Kävimme jokaisen tiedoston läpi etsimällä viittä saavutettavuusominaisuutta: kohdistustilan suunnittelu jokaisessa interaktiivisessa komponentissa, alt-tekstimerkinnät kaikissa kuvissa tai ei-koristeellisissa kuvakkeissa, lukemisjärjestyksen dokumentaatio layoutin yli, liikeasetusten käsittely animoiduille tai siirtyville elementeille, sekä tummaväriteeman kontrastispesifikaatio kaikille molempiin valoihin ja pimeisiin teemoihin toimitetuille komponenteille. Kullekin ominaisuudelle tiedosto sai pisteen “dokumentoitu” vain jos pätevä kehittäjä pystyisi toteuttamaan suunnitelman ilman vastauksen keksimistä itse. “Mainittu muistilapussa” ei kelvannut. “Heksadesimaaliksi määritelty yhdessä hover-tilassa” ei kelvannut. Vaatimus oli: onko päätös tiedostossa muodossa, jonka kehittäjä pystyy toteuttamaan kysymättä?

Päätutkimustulos on, että käsikirjoituksesta puuttuvat saavutettavuuspäätökset paljon useammin kuin ne sisältyvät siihen. Kohdistustilan suunnittelu esiintyi noin 40 %:ssa interaktiivisista komponenteista koko aineistossa. Alt-tekstimerkinnät esiintyivät noin 22 %:ssa kuvista, jotka niitä tarvitsivat. Lukemisjärjestys oli eksplisiittisesti dokumentoitu 16 %:ssa tiedostoista. Liikeasetusten käsittely mainittiin 10 %:ssa. Tummaväriteeman kontrasti — 31:lle tiedostolle, jotka toimittivat molemmat teemat — oli määritelty 30 %:ssa komponenteista. Aukko ei ole missään yksittäisessä ominaisuudessa. Se on kaikissa viidessä, ja kehittäjä jää sulkemaan sen yksi harkintapäätös kerrallaan.

Aineiston noin 1 800 interaktiivisesta komponentista — painikkeista, linkeistä, syöttökentistä, valintaruuduista, kytkimistä, välilehdistä, yhdistelmälaatikoista, valikkokohdista, korttipohjaisista painikkeista, kaikesta, mitä näppäimistön käyttäjä voi saavuttaa — noin 40 % toimitti suunnitellun kohdistustilan. Loput 60 % toimittivat oletustilan, aktiivisen tilan ja hover-tilan, ja sitten pysähtyivät. Kehittäjä, joka rakentaa komponentin, valitsee kohdistuksen ääriviivan toteutushetkellä — yleensä kopioimalla selaimen oletuksen — yleensä tarkistamatta, onko oletuksella 3:1 kontrasti komponentin pintaa vasten sekä vaaleassa että tummassa teemassa, jotka tiedosto toimittaa.

Miltä “ei kohdistustilan suunnittelua” näyttää käytännössä? Se näyttää painike-komponentilta, jossa on kolme varianttia kankaalla — lepotila, hover, painettu — ilman neljättä varianttia. Se näyttää syöttökentältä, jossa on tyylitelty reunus eikä toista reunustyyliä kohdistettuun tilaan. Se näyttää valintaruutu-primitiiviltä, jossa on kohdistusrengas vain lepotilavariantissa, ja kehittäjälle jätetään arvattavaksi, pitäisikö sama rengas esiintyä valitussa tai epämääräisessä tilassa. Kuvio toistuu komponenteista toisiin, tiimistä tiimiin, sektorista sektoriin. Se on aineiston suurin saavutettavuusaukko ja helpoin suunnitella sisälle.

Tiimeillä, jotka suunnittelivat kohdistustilat hyvin, oli toinen kahdesta asiasta. Ensimmäinen oli eksplisiittinen design-system-sääntö: jokaisen interaktiivisen komponentin on toimitettava variantti, jonka nimi alkaa focus-:lla, eikä komponenttia julkaista kirjastoon ennen kuin variantti on olemassa. Toinen oli Figma-komponentin ominaisuus nimeltä state, jossa focus, focus-visible ja focus-within ovat lueteltuja arvoja, joten tiedoston komponenttiselain tuo puuttuvat variantit visuaalisesti esiin. Tiimeillä, joilla ei ollut kumpaakaan rakennetta, kohdistustila jäi kehittäjälle noin yhdeksän kertaa kymmenestä.

Aineiston tiedostoista, jotka sisälsivät sisältökuvia — tuotekuvia, hero-illustraatioita, kuvake-painikkeita, infograafikuvia — 78 %:lla ei ollut alt-tekstimerkintöjä kuvakerrostumilla. Kuva oli sijoitettu, mitoitettu ja tyylitelty; tekstivastine, jonka kehittäjän odotettiin asettavan renderöityyn <img>-elementtiin, ei ollut tiedostossa. Kahdeksalla 50:stä tiedostosta oli alt-teksti joissain kuvissa muttei kaikissa — yleensä hero-illustraatio oli merkitty ja sisältökuvat olivat tyhjiä. Kolmella tiedostolla oli alt-teksti kaikissa kuvissa. Kehittäjän odotettiin 47:ssä tiedostossa 50:stä keksivän alt-teksti itse — ja käytännössä se usein periytyi tiedostonimestä, kuvatekstistä tai merkkijonosta, joka sopi visuaaliseen rytmiin.

Aukko on rakenteellinen Figma:n kuvaprimiitiivissä. Kuvatäytöllä tai kuvakerrostumalla ei ole natiivista “alt”-ominaisuutta; alt-teksti täytyy kuljettaa kerrostuman nimenä, kommenttina, muistilapuna, erillisenä spesifikaatioasiakirjana tai liitännäisen lisäämänä kenttänä. Mikään näistä ei kulje tarkastuspaneelin kautta oletuksena, joten tiedoston tarkastusnäkymässä lukeva kehittäjä ei näe alt-tekstiä vaikka suunnittelija olisi kirjoittanut sen muualle. Tiimit, jotka sulkivat aukon johdonmukaisesti, käyttivät yhtä kolmesta kiertoratkaisusta: liitännäisenhallinnoidut alt-tekstikentät jokaisessa kuvavariantissa, dokumentoitu käytäntö, jonka mukaan kerrostuman nimi on alt-teksti, tai erillinen alt-tekstilaskentataulukko kuvanimiä avaimina käyttäen, joka toimitettiin tiedoston rinnalla.

Kuvake-painikkeet olivat alatason epäonnistuminen tässä vikakuviossa. 41:ssä 50:stä tiedostosta kuvake-painikkeilla — haku-suurennuslasilla, hampurilaisvalikolla, sulku-X:llä, jako-nuolella — ei ollut saavutettavaa nimeämismerkintää, jolloin kehittäjälle jäi kirjoittaa aria-label=“Haku” visuaalisesta kontekstista ilman vahvistusta, että “Haku” oli oikea sana brändin äänessä (oliko se “Etsi”? “Selaa”? ei mitään, koska painike avaa muualla nimetyn paneelin?). Kuvakkeiden nimeäminen on täsmälleen sellainen mikrotekstin päätös, josta hyötyisi suunnittelijan kynä, ja täsmälleen se, jonka käsikirjoitus menettää.

Kolmella muulla ominaisuudella oli erilaiset epäonnistumismuodot. Lukemisjärjestys — järjestys, jossa ruudunlukuohjelma kertoo sivun, joka modernien responsiivisten layouttien tapauksessa ei enää välttämättä vastaa visuaalista ylhäältä-alas-järjestystä — oli dokumentoitu 16 %:ssa tiedostoista. Dokumentaatio, jos sellainen oli, oli yleensä numeroitu peite kankaalla (1, 2, 3 …) lisättynä liitännäisellä. Muut 84 % jättivät kehittäjälle kartoittaa lukemisjärjestyksen sattumalta kirjoittamastaan DOM-järjestyksestä, joka CSS Grid -layoutissa eksplisiittisellä rivi-ja-sarake-sijoittelulla voi poiketa visuaalisesta layoutista kokonaisen sarakkeen verran.

Liikeasetusten käsittely pärjäsi heikoiten. Kymmenessä prosentissa tiedostoista mainittiin prefers-reduced-motion lainkaan. Loput 90 % määrittelivät animaatioita ja siirtymiä — modaalin sisääntuloja, akkordeonin laajennuksia, väliaikaisten ilmoitusten liukuksia, sivujen siirtymiä — ilman, että määrittelivät, mitä saman komponentin pitäisi tehdä, kun käyttäjä on ottanut käyttöön vähennetyn liikkeen. Kehittäjä joko rakensi vähennetyn liikkeen tapauksen toteutushetkellä (usein ilman visuaalista viitettä) tai toimitti saman animaation kaikille, mikä on oletusarvo ja joka rikkoo 2.3.3 (Animation from Interactions) käyttäjille, jotka asettivat kyseisen asetuksen.

Tummaväriteeman kontrasti oli määritelty 30 %:lle komponenteista tiedostoissa, jotka toimittivat molemmat teemat. Loput 70 % määrittelivät vaalean teeman kontrastin — yleensä Stark- tai kontrastin tarkistus -merkinnällä tiedostossa — ja julkaisivat sitten tumman teeman heksadesimaalien peilatulla paletilla, jolloin kehittäjälle jäi tarkistaa, läpäiseekö käännetty pari edelleen 4,5:1 leipätekstillä ja 3:1 käyttöliittymäkomponenteilla. Noin viidenneksessä 31:stä kaksiteemaisesta tiedostosta ainakin yksi komponentti alitti kontrastitason tummassa teemassa, koska tumma pinta ja tumma teksti oli viritety vaalean teeman kontrastimatemaatikkaan eikä tumman teeman.

Kaksi liitännäistä, jotka esiintyvät aineistossa useimmin, ovat Stark ja Able. Molemmat ovat kypsymättömiä, molempia pidetään arvossa, ja molemmat toimittavat ominaisuuksia, jotka sulkevat useita edellä dokumentoituja aukkoja. Stark lisää kontrastin tarkistimen, kohdistusjärjestyksen peittokuvan, vähennetyn liikkeen esikatselun ja alt-tekstimerkintäkentän kuvakerrostumilla. Able lisää värikontrasti-inspektoijan, näkösimulaatioperittokuvan ja kosketusmaalin tarkistimen. Kumpi tahansa liitännäinen, johdonmukaisesti tiedostossa käytettynä, nostaisi sen tiedoston pois aineiston alimmasta neljänneksestä.

Johdonmukaisesti käytettynä on operatiivinen lause. 50:stä tiedostosta Stark oli asennettu ja näkyvästi käytetty 18:ssa ja Able 11:ssä. Tiedostoissa, joissa liitännäistä käytettiin, sitä käytettiin yleensä hero-komponentissa ja ensisijaisessa CTA:ssa — komponenteissa, jotka todennäköisimmin olivat kankaalla, kun suunnittelija avasi liitännäisen — ja muualla vain satunnaisesti. Kuusi tiedostoa käytti Starkia globaaliin läpikäyntiin; yksi käytti Ablea globaaliin läpikäyntiin. Kuvio on: liitännäiset ovat olemassa, suunnittelijat tietävät niistä, ne vedetään esiin pikatarkistuksia varten, ja sitten pikatarkistus pysähtyy komponentteihin, joita suunnittelija sattui katsomaan liitännäisen ollessa auki.

Kaksi tiimiä, jotka sulkivat auditoinnin liitännäisten käytön osalta, tekivät yhden asian toisin: he ajoi liitännäisen auditoiniominaisuuden jokaisella tiedoston sivulla julkaisuportin askeleena ennen kuin tiedosto jaettiin suunnittelutiimille. Auditointi ajettiin tiedostossa, tuotti raportin, ja raportin piti olla tyhjä (tai sen poikkeukset dokumentoitu) ennen kuin tiedosto siirtyi “suunnittelussa” -tilasta “valmis kehitykseen” -tilaan. Tämä on liitännäinen-työnkulkuna eikä liitännäinen-pikatarkistuksena, ja se on ero 80 %:n kattavuuden ja 20 %:n kattavuuden välillä meidän otoksessamme.

Auditointi tuottaa tarkistuslistan ja sopimuksen. Tarkistuslista on se, mitä suunnittelijan pitäisi pystyä rastittamaan ennen kuin tiedosto jaetaan kehitykselle. Sopimus on muoto, jossa design-tokeneja kuljetetaan tiedoston rinnalla, jotta kehittäjä kartoittaa Figma-muuttujat CSS-mukautettuihin ominaisuuksiin keksimättä välittäviä arvoja. Molemmat ovat tarkoituksella lyhyitä: jokainen tarkistuslistan kohta on ominaisuus, jota auditointi mittasi, ja jokainen sopimuksen token on arvo, joka sulki aukon aineistossa.

50 tiedoston auditointi päättyy yksinkertaiseen havaintoon. Käsikirjoitus epäonnistuu saavutettavuudessa ei siksi, että suunnittelijat eivät välitä, eikä siksi, että kehittäjät eivät välitä, vaan siksi, että tiedosto — Figma-tiedosto, se yksittäinen artefakti, jota kaikki osapuolet lukevat — ei kanna saavutettavuuspäätöksiä ensisijaisina ominaisuuksina. Kohdistustilat, alt-tekstit, lukemisjärjestys, liikeasetukset, tummaväriteeman kontrasti: jokainen on suunnittelupäätös, jokainen kuuluu tiedostoon, jokainen on tällä hetkellä muualla. Muistilapussa, Slack-viestissä, erillisessä laskentataulukossa, kehittäjän päässä perjantai-iltapäivänä kello 16.

Korjaus ei ole sankarillinen suunnittelija tai sankarillinen kehittäjä. Se on työnkulun muutos tiimitasolla: jokainen interaktiivinen komponentti toimittaa focus-variantin, jokaisessa kuvassa on alt-teksti yhdessä liitännäisenhallinnoidussa sijainnissa, lukemisjärjestys on peitetty ei-triviaalilla sivulla, animaatiot määrittelevät vähennetyn liikkeen vastineensa, tummaväriteeman kontrasti tarkistetaan erikseen vaaleasta, ja tiedosto toimitetaan token-sopimuksen kanssa, joka nimeää jokaisen muuttujan, johon toteutus sitoutuu. Mikään näistä vaiheista ei ole uusi, mikään ei vaadi työkalua, jota meillä ei jo ole, ja mikä tahansa tiimi, joka omaksuu ne julkaisuportin askeleina, sulkee suurimman osan mittaamistamme aukoista yhdessä julkaisukierroksessa.

Syvempi havainto on, että design-system-tiimit tekevät tämän jo noin kaksinkertaisella tahdilla verrattuna tuotantotiimeihin. Nosto, jonka design-system-tiimit tarjoavat, on täsmälleen se nosto, jonka järjestelmän rakentamisen kurinalaisuus pakottaa: komponentit nimetään, ominaisuudet luetellaan, variantit ovat näkyvissä, tokenit ovat eksplisiittisiä. Saman kurinalaisuuden tuominen tuotetason tiedostoihin — edes ilman täydellistä design-järjestelmää alla — sulkee suurimman osan käsikirjoitusaukosta. Se ei ole enää työkaluongelma. Se on työnkulun valinta.