Is your small business website AI-ready? The accessibility basics AI agents rely on

More people now ask an AI assistant to find a business, compare options or fill in a booking form for them. Those tools have to work out what each part of your page is and what each button does. Much of that information comes from the same place screen readers use: the page's headings, labels, alt text and the roles of its buttons, links and form fields. Making your site accessible to people is also the most reliable thing you can do to make it understandable to software.

What the AI companies themselves say

• OpenAI's publisher FAQ says making your website more accessible helps the ChatGPT agent in its Atlas browser understand it, that Atlas uses ARIA labels and roles (the ones that support screen readers) to interpret page structure and interactive elements, and it recommends descriptive roles, labels and states on buttons, menus and forms (OpenAI Publishers and Developers FAQ).
• Google's image guidance says it uses alt text, together with computer vision and the page content, to understand what an image is about (Google image SEO best practices).

Neither of these is a promise of more traffic or a higher ranking, and AI tools change quickly. What they show is that the basics below are read by machines as well as by people.

1. Real buttons and links, with names

An agent (or a screen reader) needs to know that something is a button and what it does. Use real <button> and <a> elements, and give icon-only ones a name:

<!-- Hard to understand: a clickable div with an icon -->
<div class="btn" onclick="openBooking()"><svg>…</svg></div>

<!-- Clear to people and software -->
<button type="button" onclick="openBooking()">Book an appointment</button>
<a href="tel:+19185550100" aria-label="Call us at 918-555-0100">☎</a>

More examples in our link and button text guide.

2. Form fields with real labels

Booking, quote and checkout forms are where an agent is most likely to act for a customer. Every field needs a label tied to it, not just grey placeholder text, and required fields and errors should be stated in words:

<label for="date">Preferred date</label>
<input id="date" name="date" type="date" required>

See accessible contact forms.

3. Menus, tabs and pop-ups that report their state

A hamburger menu should say whether it is open. Native HTML does most of this for you; where you build your own control, follow the W3C ARIA Authoring Practices and use HTML first (web.dev on ARIA and HTML):

<button aria-expanded="false" aria-controls="menu">Menu</button>
<nav id="menu" hidden>…</nav>

Cookie banners and chat bubbles that cover the page get in the way of agents as much as keyboard users: see our pop-up and chat widget guide.

4. Headings and page regions that outline the page

One H1 that says what the page is, H2s for sections, and <header>, <nav>, <main> and <footer> regions give any reader a map of the page. See heading structure.

5. Alt text that says what an image shows

"Tulsa dental office front desk with step-free entrance" tells a person and a machine something; "IMG_2231" tells neither. Text inside images (menus, price lists, flyers) should also be on the page as real text. Our alt text examples and free alt text checker help here.

6. Key facts as text, not only in pictures, maps or PDFs

Hours, address, service area, prices and how to book should be plain text on the page. An agent asked "are they open Saturday?" can't read a hours graphic, and neither can a screen reader. Scanned PDFs are pictures too: see accessible PDFs and menus.

A 10-minute check

1. Run a free homepage scan and look for unnamed buttons and links, unlabelled fields and missing alt text.
2. Press Tab through your booking or contact form: can you reach and use every field and button? (keyboard test)
3. Turn on a screen reader for two minutes and listen to your menu and main button (screen reader test).
4. Check that your hours, address and booking steps exist as text.

What a scan can and can't check here

Our scan uses axe-core to check the published code for the machine-detectable parts of this list: buttons and links without names, form fields without labels, images without alt text, heading order, missing page regions, page language and title. It can't tell whether your labels and alt text are accurate, whether a custom widget reports its state correctly in every step, or how any particular AI tool will treat your site, and it doesn't test pages behind a login. We don't claim that fixing these items will get you recommended by any AI assistant or search engine.

This is general technical guidance, not legal advice.

Want the fixes written for you?

Start with a free homepage snapshot. The $149 Fix-Pack scans up to 10 pages and gives copy-paste fixes for your platform within 48 hours, with a 14-day refund promise. See a sample report first.

This is general technical guidance, not legal advice, and it does not certify compliance with the ADA or any law.

Related guides

• WCAG 2.2 explained for small-business websites
• Squarespace accessibility fixes: alt text, contrast, forms and more
• Wix accessibility fixes: a practical checklist
• WordPress accessibility fixes (block editor and themes)

All guides

This guide is general technical information, not legal advice. Following it does not certify ADA or any legal compliance. Automated checks find only part of accessibility barriers.