Perusteet: rakennelman vahvistustietueen lukeminen

Kolme viikkoa sitten rakensin varauswidgetin ystävälleni, joka pyörittää joogastudiota — chatin, suunnitelman, jonka hyväksyin nopeasti koska olin keskellä jotain muuta, ajon, ja sitten versiokortin vihreällä valintamerkillä, jota vilkaisin ja jatkoin eteenpäin. Tiistaina hän tekstasi kysyen, voisiko hän osoittaa toisen studion sivuston samaan rakennukseen. Ennen kuin sanoin kyllä, palasin katsomaan, mitä "varmennettu" oikeasti oli tarkoittanut kolme viikkoa aiemmin, ja silloin luin ensimmäistä kertaa oikeasti yhden näistä tallenteista pelkän valintamerkin luottamisen sijaan.

Se löytyy suoraan versiokortilta, esikatselun ja koodin toimintojen vierestä — samasta paikasta, josta menisit uudelleenkäyttöönottoon tai palauttamiseen. Ensimmäinen asia, jonka huomasin: se on rajattu siihen yhteen versioon, ei koko keskusteluun. Olin iteroinut tätä rakennusta viisi kertaa jahdaten rikkinäistä päivämääränvalitsinta, ja odotin puoliksi, että tallenne kertoisi minulle koko edestakaisen tarinan. Se ei kerro. Version 4 tallenne kuvaa vain versiota 4. Sillä ei ole muistia siitä, että versio 2 julkaistiin kirjautumislomakkeella, joka epäonnistui äänettömästi, eikä se kerro, että versio 5 hiljaa korjasi jotain, minkä versio 3 rikkoi. Jokainen tallenne on tilannekuva, ei diff eikä muutosloki — jos haluan historian siitä, mikä muuttui julkaisusta toiseen, se on täysin eri näkymä. Tämä vastaa vain kysymykseen "onko tämä yksittäinen kunnossa".

Alaspäin vieritettäessä tallenne jakautuu kuuteen riviin:

Kaikki kuusi olivat vihreitä, ja ensimmäinen vaistoni oli sama väärä vaisto, joka luultavasti useimmilla olisi: tietoturva läpäisi, joten se on turvallinen; saavutettavuus läpäisi, joten se on saavutettava. Kumpikaan näistä tulkinnoista ei kestä tarkastelua sitä vasten, mitä tarkistukset oikeasti tekevät. Tietoturvatarkistus tarkoittaa, ettei pintapuolinen ongelma — merkkijonojen yhdistäminen kyselyyn, API-avain paljaana asiakaspuolen paketissa, eval jollekin käyttäjän syöttämälle — noussut esiin. Se ei ole päivä penetraatiotestaajan kanssa. Ystäväni studio ei ota maksuja tämän widgetin kautta, vain nimiä ja aikoja, joten taso riitti hänelle. Jos kyseessä olisi ollut maksutapahtuma, olisin halunnut enemmän kuin lattiatason varmistuksen.

Saavutettavuus oli se, joka sai minut oikeasti pysähtymään ja tarkistamaan asian, koska "axe-läpäisy" kuulostaa kattavalta, mutta ei ole. Axe — automaattinen moottori konepellin alla — nappaa luotettavasti jotain kolmasosan ja puolikkaan väliltä WCAG-hyväksymiskriteereistä: puuttuvat alt-tekstit, huonot kontrastisuhteet, nimeämättömät lomakekentät, ilmeisen väärä ARIA-käyttö. Se ei kerro, onko pyytämäni mukautettu päivämääränvalitsimen pudotusvalikko käytettävissä ruudunlukijalla, laskeutuuko monivaiheisen varausprosessin läpi sarkaimella navigointi järkevästi, tai onko "vahvistettu" vs. "odottaa" -tilan värittäminen vihreällä ja keltaisella ongelma jollekin, jolla on puna-vihersokeus. Ne vaativat ihmisen, joka käy rakennuksen läpi työkaluilla, joita vammaiset käyttäjät oikeasti käyttävät. Axe on todellinen signaali, ei tyhjää — se on saavutettavuuden oikeinkirjoitustarkastintaso, ei toimittaja.

Vaatimustenmukaisuus oli rivi, jonka melkein ohitin, koska se kuulostaa byrokraattiselta — "sisältää sen, mitä suunnitelma lupasi" — kunnes muistin, että hyväksymäni suunnitelma kirjoitettiin, kun olin ajatuksissani muualla, enkä muistanut, olinko pyytänyt sähköpostivahvistuksia vai pelkkää tekstiviestiä. Tämä on kerros, joka tarkistaa buildin suunnitelmaa vasten, ei todellista aikomustani vasten, ja se meni läpi, mikä kertoi, että build vastasi sitä, mihin olin sanonut kyllä — ei välttämättä sitä, mitä olin tarkoittanut. Olen kuullut buildeista, jotka olivat toiminnallisesti kunnossa ja turvallisia, mutta silti epäonnistuivat tässä kerroksessa, koska ominaisuus jäi huomaamatta pois aikapaineen alla. Tämä kerros pitää buildin rehellisenä sitä keskustelua kohtaan, joka sen synnytti, vaikka keskustelu itsessään olisi ollut hieman huolimaton.

Kuuden rivin alla oli pidempi lista, jaettuna kahteen ryhmään, ja tähän käytin eniten aikaa. Pakolliset korjaukset eivät ole asioita, jotka ovat tällä hetkellä vialla buildissa — ne ovat kuitteja. Yhdellä rivillä luki, että tarkistuskerros oli havainnut tapauksen, jossa päivämäärämerkkijono interpoloitiin suoraan kyselyyn, ja se oli jo korjattu ennen kuin tämä versio merkittiin valmiiksi. En katsonut avointa haavaa; katsoin arpea. Tällä erolla on väliä, sillä jos luet pakollisen korjauksen rivin aktiivisena varoituksena, kulutat aikaa huolehtimalla jostain, mikä on jo suljettu.

Neuvoa-antava lista oli pidempi, ja se koostui suurimmaksi osaksi asioista, joita olisin itsekin sanonut arvioidessani kollegan koodia haluamatta estää yhdistämistä: "harkitse toistuvan aikapaikkojen renderöintilohkon eriyttämistä jaetuksi komponentiksi", "tässä päätepisteessä ei ole pyyntörajoitusta, mikä on ok sisäiselle varaustyökalulle, mutta kannattaa harkita uudelleen, jos se julkaistaan yleisölle". Mikään listalla ei ollut vika. Ne olivat harkintakysymyksiä, joita tarkistaja teki vain suunnitelman ja koodin perusteella, ja joogastudion sisäiselle ajanvarausjärjestelmälle jokainen niistä osui järkevälle puolelle. Jos ystäväni studio olisi ollut ketju, jonka widget olisi upotettuna viidellekymmenelle sijaintisivulle, olisin halunnut kyseenalaistaa pyyntörajoitusasian — luokittelu riippuu kontekstista, jota tarkistaja voi vain arvailla, ja kun arvaus vaikuttaa sinusta väärältä, oikea toimenpide on sanoa se chatissa, ei olettaa, että merkintä on lopullinen.

Se, mikä minua yllätti, kun katsoin melko pitkää neuvoa-antavaa listaa puhtaan pakollisten korjausten sarakkeen vieressä, oli se, että olisin melkein tulkinnut sen pituuden huonoksi uutiseksi. Ei se ole. Buildilla, jossa on nolla neuvoa-antavaa merkintää, on joko saanut suppean tarkastuksen tai käynyt tuuria; buildi, jossa on kasa "harkitse"-kohtia eikä mitään avoinna pakollisissa korjauksissa, on sellainen, jota on todella tarkasteltu huolellisesti. Neuvoa-antava sarake on se, mitä pitäisi jäädä jäljelle, kun oikeat ongelmat on poistettu.

Toinen asia, jonka pakotin itseni tekemään, koska tämä tietue oli kolme viikkoa vanha, oli tarkistaa, mitkä kerrokset todella ajettiin ennen kuin luotin tuloksiin ollenkaan. Kaikki kuusi olivat läsnä tässä, mutta olen sittemmin nähnyt buildin, jossa saavutettavuus oli listalla yksinkertaisesti poissa sen sijaan, että se olisi merkitty läpäisyksi tai epäonnistumiseksi — se ei ole sama asia kuin tarkistuksen ohittaminen merkityksettömänä, vaan merkki siitä, ettei tarkistus ajettu kyseiselle sivutyypille tai lippukokoonpanolle, ja poissaolon tulkitseminen hiljaiseksi läpäisyksi on juuri se virhe, johon tämä muoto houkuttelee, jos vilkuilee pintapuolisesti.

Mikään tästä ei kertonut minulle, konvertoiko joogastudion ajanvarauspolku todella, luopuvatko ihmiset siitä aikapaikan valintavaiheessa, vai oliko koko ajatus mukautetusta widgetistä pelkän Calendly-linkin sijaan alun perin oikea ratkaisu. Vahvistus todistaa, että build toimii luvatulla tavalla — ei sitä, että lupaus oli oikea annettavaksi, ja nämä ovat erillisiä kysymyksiä. Olen nähnyt buildien läpäisevän jokaisen kerroksen puhtaasti ja silti epäonnistuvan oikeiden käyttäjien kanssa, koska "toimii oikein" ja "ratkaisee oikean ongelman" eivät ole niin lähellä toisiaan kuin toivoisi. Se puoli tästä, joka todella vastaa toiseen kysymykseen, on mittaussilmukka, ja nämä kaksi on tarkoitus lukea yhdessä. Puhdas vahvistustietue ominaisuudesta, jota kukaan ei varaa, on silti ominaisuus, jota kukaan ei varaa.