Slik sjekker du et sides tilgjengelighetstre i AmICited

AI-agenter ser ikke siden din slik en nettleser gjengir den — de navigerer via tilgjengelighetstreet: rollene, navnene og strukturen bak HTML-en.

Hva er tilgjengelighetstreet?

Tilgjengelighetstreet er en forenklet, strukturert representasjon av en nettside som nettlesere bygger parallelt med den visuelle DOM-en. I stedet for piksler, farger og layout fanger den opp hvert elements rolle (er dette en knapp, en overskrift, et navigasjonslandemerke, en liste?), dets navn (den tilgjengelige etiketten en skjermleser eller agent ville lest opp), og dets tilstand (er det utvidet, deaktivert, valgt?). Den ble opprinnelig bygget for hjelpeteknologi — skjermlesere for blinde og svaksynte brukere — men den har blitt like viktig for et nyere publikum: AI-agenter og store språkmodeller som «leser» en side programmatisk i stedet for å gjengi den visuelt.

Når ChatGPT, Perplexity, Gemini eller en autonom nettleseragent besøker en side, tolker den vanligvis ikke et skjermbilde. Den parser den underliggende markeringen, og et velformet tilgjengelighetstre er ofte den reneste, minst tvetydige versjonen av den markeringen som finnes. En side med tydelig overskriftshierarki, merkede knapper, beskrevne bilder og fornuftige landemerkeregioner (<nav>, <main>, <article>) produserer et tilgjengelighetstre som klart formidler hva siden handler om og hvordan delene henger sammen. En side bygget av generisk <div>-suppe, ikonknapper uten etiketter og overskrifter som kun brukes for visuell størrelse i stedet for logisk struktur, produserer et tre som er vanskelig for noe — menneske eller maskin — å forstå.

Dette har direkte betydning for AI-søkesynlighet: disiplinen som handler om å måle og forbedre hvor ofte AI-assistenter siterer, nevner eller anbefaler merkevaren din i svarene sine, ofte kalt generativ søkemotoroptimalisering eller GEO. Hvis en AI-agent ikke kan tolke rent hva en side er, hva den tilbyr, og hvordan innholdet er organisert, er det langt mindre sannsynlig at den henter ut korrekte fakta fra den eller siterer den som kilde. Tilgjengelighet og AI-lesbarhet overlapper nesten fullstendig: de semantiske HTML-praksisene som gjør en side brukbar med en skjermleser — riktige header-tagger , beskrivende alt-tekst på bilder, merkede skjemakontroller, meningsfull lenketekst — er de samme praksisene som gjør en side lesbar for en crawler eller en agent som tolker den via tilgjengelighetstreet i stedet for et gjengitt skjermbilde. Dette er en del av grunnen til at en AI-tilgjengelighetsrevisjon har blitt en standardkomponent i teknisk beredskapsarbeid, sammen med sjekker som robots.txt-konfigurasjon, gjennomsøkbarhet og strukturerte data .

Det praktiske resultatet er at tilgjengelighetsarbeid, som mange team behandler som en avkrysningsboks for compliance eller juridisk risiko, nå også er en synlighetsspak. Å fikse manglende etiketter og flate ut et forvirrende overskriftshierarki er ikke bare god praksis for brukere av hjelpeteknologi — det er en av de mer direkte måtene å hjelpe AI-systemer med å forstå og korrekt representere innholdet ditt.

Hvor du finner det

Tilgjengelighetstre-sjekkeren finnes i Tilgjengelighetstre-delen av Revisjon → Agent-tilgjengelighet. Den kjører mot startsiden din som standard første gang du åpner den, og inkluderer en URL-boks slik at du kan teste enhver annen side ved behov — en produktside, en prisside, en viktig landingsside, eller en lengre artikkel du håper en AI-assistent vil sitere.

Hva den sjekker

Som delen forklarer: “Hvor lesbar siden din er for AI-agenter — de navigerer via tilgjengelighetstreet (roller, navn, struktur), ikke piksler.” Konkret vurderer den om sidens semantiske struktur gjør innholdet og formålet tydelig for en ikke-visuell leser — samme linse en AI-agent bruker når den tolker HTML-en din i stedet for å gjengi den. Dette inkluderer om overskriftene følger en logisk rekkefølge, om interaktive elementer har tilgjengelige navn, om landemerkeregioner finnes slik at sidens hoveddeler er identifiserbare, og om den samlede strukturen ville la noe som kun leser roller og navn forstå hva siden er og gjør.

Dette er atskilt fra, men utfyller, sjekker som ser på sidestruktur på nettstedskart- eller navigasjonsnivå. Tilgjengelighetstre-sjekkeren opererer ett nivå dypere — inne i markeringen til en enkelt side — for å se om innholdet i seg selv er lesbart når du strekker bort den visuelle stylingen.

Slik bruker du den

1. Gå gjennom startsideresultatet som lastes som standard. Dette gir deg en grunnlinje for hvordan din viktigste side fremstår for en AI-agent som navigerer etter struktur.
2. Sjekk en annen side. Lim inn en URL i https://dinndomene.no/side som skal sjekkes-boksen og klikk Sjekk URL for å teste en bestemt viktig side — en produktside, en sammenligningsside, eller en nøkkelartikkel du vil at en assistent skal kunne sitere korrekt.
3. Les funnene for strukturelle svakheter — uklare eller hoppede overskriftsnivåer, umerkede kontroller (knapper eller lenker uten tilgjengelig navn), manglende landemerkestruktur, eller bilder uten meningsfull alt-tekst.
4. Fiks semantikken. Bruk riktige overskrifter, etiketter og roller slik at tilgjengelighetstreet tydelig formidler sidens mening. Dette betyr vanligvis: én <h1> per side, overskrifter som nøster logisk (ikke hopp fra <h2> til <h5>), aria-label eller synlig tekst på hver interaktive kontroll, og alt-attributter som beskriver hva et bilde formidler i stedet for å gjenta filnavnet.

Prioriter sidene du mest ønsker at AI-assistenter skal finne og sitere — de som er målrettet av dine sporede prompter — før du går gjennom resten av nettstedet. En side med et rent tilgjengelighetstre har større sannsynlighet for å bli tolket korrekt, oppsummert nøyaktig, og referert med riktig kontekst når en AI-agent genererer et svar.

Hvorfor dette bidrar til den bredere beredskapsscoren din

Bedre tilgjengelighet hjelper menneskelig hjelpeteknologi og AI-agenter på én gang — og det mater Tilgjengelighet-flisen i beredskapsoppsummeringen din. Den oppsummeringen finnes fordi AI-lesbarhet ikke er én ting; det er en sammensetning av tekniske faktorer inkludert gjennomsøkbarhet, strukturerte data, sidehastighet og semantisk markering, og Tilgjengelighetstre-sjekkeren er én linse blant flere revisjonssjekker i AmICited som utgjør det fullstendige tekniske bildet. Team som ønsker å systematisk optimalisere nettstedet sitt for AI-agenter jobber generelt gjennom hver av disse sjekkene i tur og orden i stedet for å fikse tilgjengelighet isolert, fordi en side kan bestå én sjekk og likevel feile på en annen av urelaterte grunner — ren semantisk HTML hjelper ikke hvis siden også er blokkert i robots.txt, for eksempel.

Det er også verdt å forstå hvordan dette passer inn i det bredere arbeidet med å strukturere innhold slik at AI-modeller faktisk kan sitere det : et rent tilgjengelighetstre gjør innholdet ditt uthentbart, men uthentbarhet er bare halve kampen. Innholdet selv må fortsatt svare på spørsmålene folk faktisk stiller AI-assistenter, som er der tekniske SEO-faktorer krysser innholdsstrategi i stedet for å erstatte den.

Hvor dette leder videre avhenger av hva du prøver å bevise. Hvis du reviderer en enkelt side før en lansering, er det å fikse de strukturelle problemene sjekkeren avdekker vanligvis en oppgave en utvikler kan løse på én dag. Hvis du prøver å forstå om tilgjengelighetsfikser faktisk flytter nålen på hvor ofte merkevaren din blir nevnt av ChatGPT, Perplexity eller Gemini, er det et spørsmål for løpende AI-synlighet -overvåking i stedet for en engangsrevisjon — spor promptene og siteringene dine før og etter en fiks for å se om den forbedrede strukturen oversettes til flere nevnelser. Og hvis du er en SEO-praktiker som legger denne typen teknisk arbeid til en eksisterende revisjonsprosess, passer det naturlig inn sammen med en AI-rangeringssporer -arbeidsflyt, siden de samme sidene du prøver å rangere i AI-svar er de som er verdt å prioritere for opprydding av tilgjengelighetstreet først — et mønster AmICiteds verktøy for SEO-fagfolk er bygget rundt.