,

Kiinnostaako tekoälyoptimointi? Älä unohda saavutettavuutta

Sama koodi, jonka ansiosta ruudunlukija pystyy käyttämään sivuasi, ratkaisee nyt myös sen, osaavatko tekoälyjärjestelmät lukea, siteerata ja käyttää sivustoasi.

Markkinoijat HOX, tämä on just teidän asiaa. 🚨

Mitä saavutettavuus tarkoittaa?

Saavutettavuus tarkoittaa, että verkkosivua voi käyttää mahdollisimman moni riippumatta siitä, miten hän näkee, kuulee, liikkuu tai ymmärtää sisältöä. Käytännössä se on esimerkiksi kuvien tekstivastineita (alt-tekstejä), selkeä otsikkorakenne, riittävä kontrasti sekä painikkeet ja lomakekentät, joilla on nimi ja jotka toimivat näppäimistöllä.

Saavutettavuus rakentuu pitkälti oikeasta HTML:stä: painike on painike, linkki on linkki ja lomakekentällä on selite. Ruudunlukijat, joita esimerkiksi heikkonäköiset käyttäjät hyödyntävät, nojaavat täsmälleen samaan rakenteeseen. Se on myös se, mitä Googlen Lighthouse ja muut auditointityökalut tarkistavat.

Tiesitkö tämän: Tekoälyagentit lukevat saavutettavuuspuuta

Selaimet rakentavat koodistasi saavutettavuuspuun (accessibility tree): roolit, nimet, tilat, otsikot ja maamerkit. Ruudunlukijat käyttävät sitä, ja nyt myös tekoälyagentit. Playwright osaa tallentaa puun rakenteisena tekstinä, ja Cloudflare tarjoaa agenttien käyttöön oman rajapinnan saavutettavuuspuulle.

Liikenne on jo muuttunut. Cloudflare Radarin datan mukaan, kuten BotRank raportoi, botit tekivät 57,2 % HTML-pyynnöistä touko–kesäkuun vaihteessa 2026, ihmiset 42,8 %. Sama artikkeli viittaa WebAIMin helmikuun 2026 Million-raporttiin: 95,9 %:lla miljoonan suosituimman sivuston etusivuista oli havaittavia WCAG-virheitä, alt-teksti puuttui 53,1 %:lta ja tyhjiä painikkeita oli 30,6 %:lla.

Rikkinäinen koodi tarkoittaa rikkinäistä puuta. div-elementistä tehty painike, nimeämätön kenttä, kuva ilman alt-tekstiä: ruudunlukijan käyttäjä kompastuu niihin, ja niin kompastuu myös agentti, joka yrittää vertailla, siteerata tai ostaa sivultasi.

Uutta: Lighthousessa on nyt agenttikategoria

Chrome on lisännyt Lighthouseen kokeellisen Agentic Browsing -kategorian, joka mittaa, kuinka hyvin sivusto on rakennettu koneiden käytettäväksi. Se vaatii Chrome 150:n tai uudemman, perustuu ehdotettuihin standardeihin ja on vielä kokeellinen. WebMCP-tarkistukset vaativat lisäksi rekisteröitymisen WebMCP origin trial -kokeiluun.

Kuvassa Google Lighthouse raportin Agenttinen selaus -osio tuloksella 3/3

Kategoriassa ei ole perinteistä 0–100 pistettä. Raportti näyttää sen sijaan murtolukuna, montako agenttivalmiuden tarkistusta sivu läpäisee, sekä virheet ja varoitukset. Chromen oman dokumentaation mukaan agentit käyttävät saavutettavuuspuuta ensisijaisena tietomallinaan.

Osa-alueMitä tarkistetaan
WebMCPSivun rekisteröimät työkalut, lomakkeet joilta puuttuu deklaratiivinen WebMCP, WebMCP-skeeman kelvollisuus
LöydettävyysOnko domainin juuressa koneluettava llms.txt-yhteenveto
Saavutettavuus agenteilleJokaisella interaktiivisella elementillä on nimi, roolit ja suhteet ovat kelvolliset, interaktiivista sisältöä ei ole piilotettu saavutettavuuspuusta
Asettelun vakausCLS: elementit eivät liiku sen jälkeen, kun agentti on ne löytänyt

Tämä on merkittävää, koska Chromen oma työkalu mittaa nyt saavutettavuutta ja asettelun vakautta osana agenttivalmiutta. Tulokset voivat vaihdella ajokerrasta toiseen esimerkiksi silloin, kun sivu rekisteröi työkalunsa JavaScriptillä eri aikaan.

Perinteinen Lighthouse-saavutettavuuspisteytys

Lighthousen saavutettavuuspistemäärä on painotettu keskiarvo läpi/ei läpi -tarkistuksista, ja painotus perustuu axe-työkalun arvioon käyttäjävaikutuksesta. Osittaisesta läpäisystä ei saa pisteitä: jos osalla painikkeista on nimi mutta osalla ei, sivu saa nollan koko tarkistuksesta. Nämä tarkistukset rikkovat useimmin agentin näkemyksen sivusta:

Lighthouse-tarkistusPainoMikä menee rikki
Image elements have [alt] attributes10Kuvat ovat näkymättömiä tekstiä lukeville
Buttons have an accessible name10Agentti ei tiedä, mitä painike tekee
Form elements have associated labels10Kenttiä ei voi tunnistaa eikä täyttää
Links have a discernible name7”Klikkaa tästä” ei kerro, minne linkki vie
Background and foreground colors have a sufficient contrast ratio7Teksti on vaikea lukea ihmiselle ja kuvaa tulkitsevalle mallille
<html> element has a [lang] attribute7Sivun kieli jää epäselväksi
Document should have one main landmark3Varsinaisen sisällön alku ei erotu
Heading elements appear in sequentially-descending order3Sivun jäsennys on sekaisin

Core Web Vitals: vakaus on tärkeää myös agenteille

Googlen Core Web Vitals -mittarit ovat kolme kenttämittaria, joita jokaisen sivuston omistajan kannattaa seurata.

MittariMitä mittaaHyvä
Largest Contentful Paint (LCP)Latautuminen2,5 sekuntia tai alle
Interaction to Next Paint (INP)Vuorovaikutteisuus200 ms tai alle
Cumulative Layout Shift (CLS)Visuaalinen vakaus0,1 tai alle

Lighthouse ei pysty mittaamaan INP:tä, koska laboratorioajossa ei ole oikeaa käyttäjän syötettä. Se raportoi sen sijaan Total Blocking Time -mittaria korvikkeena.

CLS ylittää rajan ihmisten ja agenttien välillä. Lighthousen agenttiauditit sisältävät sen, koska asettelun siirtymät voivat liikuttaa elementtiä sen jälkeen, kun agentti on sen löytänyt, mutta ennen kuin se ehtii klikata. Yleisimpiä syitä ovat mainokset, kuvat ilman mittoja ja dynaamisesti lisätty sisältö. Kun ne korjataan, hyötyvät ihmiset, Google ja agentit.

Miksi markkinoijan kannattaa välittää tästä

Jos agentit valitsevat, vertailevat ja suosittelevat, botti lukee sivustosi ennen ostajaa. Saavutettavuus on ollut jo pidempään kehittäjien tehtävälistalla ja lakitarkistuslistalla julkisrahoitteisilla organisaatioilla. Nyt se on osa löydettävyyttä, joten se kuuluu myös sinun tontillesi olit julkissektorilla tai et.

Yksi rehellinen huomio tähän kohtaan: en ole löytänyt vielä mitään julkista todistetta siitä siitä, että korkeampi Lighthouse-pistemäärä yksin toisi enemmän tekoälysiteerauksia. Perustelu nojaa puhtaasti siihen, miten agentit lukevat sivuja, ja Googlen omiin työkaluihin, ei ranking-tutkimukseen. Korjaaminen on silti halpaa, helppoa ja hyödyttää jokaista kävijää.

Aloita tästä. Kolme ensimmäistä askelta onnistuu ilman kehittäjää, viimeiseen tarvitset ehkä apua.

  1. Testaa viisi tärkeintä sivuasi. Avaa jokin sivu (esim. etusivu), paina F12 ja valitse Lighthouse-välilehti tai navigoi Chromesta Näytä > Kehittäjille > Kehittäjätyökalut. Rastita ”Accessibility” ja ”Agentic Browsing” ja klikkaa ”Analyze page load”. Jos et näe Agentic Browsing -vaihtoehtoa, päivitä Chrome. Tee sama etusivulle, tärkeimmille palvelu- tai tuotesivuille ja yhteydenottosivulle.
  2. Kirjaa ylös punaiset kohdat. Raportit kertovat suomeksi sanottuna, mikä sivulla on rikki: esimerkiksi kuva ilman kuvausta, painike tai linkki ilman nimeä tai lomakekenttä ilman selitettä. Agentic Browsing näyttää lisäksi murtolukuna, montako tarkistusta sivu läpäisee. Kopioi lista ja anna se kehittäjälle sellaisenaan, ja pidä luku lähtötasona, johon voit verrata myöhemmin.
  3. Hoida omat tekstisi kuntoon. Lisää jokaiseen uuteen sisältöön kuville lyhyt kuvaus (alt-teksti), linkeille teksti, joka kertoo minne ne vievät (”Lue hinnasto”, ei ”Klikkaa tästä”), ja otsikot järjestykseen: yksi pääotsikko ja sen alle alaotsikot (h1-h5). Tämä on sinun osuutesi, ja se onnistuu heti.
  4. Kysy kehittäjältä muut Agentic Browsing -kohdat. Raportissa on myös tarkistuksia, jotka vaativat teknistä työtä: koneluettava llms.txt-tiedosto ja WebMCP, jolla sivusto kertoo agenteille, mitä niillä on lupa tehdä. WebMCP on vielä kokeilussa, joten se voi odottaa, mutta llms.txt kannattaa ottaa puheeksi.

Tarvitsetko apua? Kysy lisää

Et tiedä, mistä aloittaa? Tai raportti näyttää liian monta punaista kohtaa? Ota yhteyttä. Käyn tulokset kanssasi läpi ja kerron, mitkä korjaukset kannattaa tehdä ensin ja mitkä voivat odottaa.


Lähteet