Give every button, link and form field a name that a person and a program can both read. A button gets its name from its text, a link from its link text, and a form field from a visible label tied to it in the code.
The first check takes about ten minutes, and you do not need to be a developer to start.
You may have heard that AI agents will soon book appointments and buy things on websites. So, the question that matters is whether the contact, booking, quote or checkout form on your own site makes sense to a tool that cannot see it the way a customer does. A screen reader faces the same problem, and the fixes are the same.
Start with the one page that earns you money. If a few buttons turn out to be unnamed, that is a small repair, and it does not call for a rebuild.
Key Takeaways
Buttons need clear text, links need descriptive link text, and each form field needs a visible label tied to it with a matching for and id.
Run Lighthouse on your contact page, look at one button and one field in Chrome's Accessibility tab, then tab through the form with the keyboard.
Missing labels and unnamed icon buttons are small edits; custom widgets, booking or payment systems and repeated breakage are where paid help earns its fee.
Give every button, link and field a name that people and programs can read
Software identifies a control by its accessible name, which W3C describes as the short text a program uses to label it. With native HTML controls you rarely write that name separately. You write ordinary, visible words, and the browser passes them along. The W3C guidance on names and descriptions says a button normally takes its name from its text, and a link from its link text.
A form field works a little differently. The W3C forms tutorial says to "Provide labels to identify all form controls," and it covers text fields, checkboxes, radio buttons and dropdowns. The label's for value has to match the field's id exactly, or the two are not connected. WCAG 2.2 asks for the same thing in plain terms: Success Criterion 3.3.2 requires labels or instructions when content asks people for input.
A short example shows the pattern. A field labeled "Email address" has a visible label with those words, and the label points to the input's id. A button reads "Send message" in its own text. A link reads "Read our pricing guide," not "Click here." That is the whole idea.
When the design cannot show text, as with a small icon, W3C allows aria-label or aria-labelledby to supply the name. Visible text and native HTML come first, though, because the button pattern computes a button's label from its text by default.
Find the unnamed buttons and unlabeled fields in about ten minutes
You can run this check on your contact page today, with a free browser. Chrome's own documentation covers each tool: Lighthouse for the automated report and the Accessibility tab in DevTools for the details of a single control.
- Open the page: Load your contact, booking or quote page in Chrome.
- Run Lighthouse: Press Ctrl+Shift+I, open the Lighthouse panel, select only Accessibility, and run the report.
- Read the form and button items: Look for failures such as "Buttons do not have an accessible name," "Form elements do not have associated labels," "Links do not have discernible names," and "Elements with visible text labels have matching accessible names."
- Inspect one control: Select a flagged button or field in the Elements panel, open the Accessibility tab, and turn on Show accessibility tree to see the name Chrome computed for it.
- Tab through the page: Press Tab from the address bar and watch focus move. Every link, button, field, menu and dialog should receive it, in an order that makes sense, with a focus outline you can see.
- Submit with the keyboard: Fill in the form, trigger an error on purpose, then send it. The error should point to the right field, and the success message should be easy to spot.
Lighthouse is automated and catches many problems, but it cannot test everything, and Chrome's scoring documentation says as much. The keyboard pass covers what the report misses. A score of 100 is a good sign, and it is not proof that the form works for everyone or for every agent.
Fix the usual builder problems without rebuilding the site
Website builders and page templates tend to repeat the same handful of mistakes. They are easy to spot once you know their shape, and each one has a standard repair. The job size varies from a one-line edit to a small project, so it helps to sort what you find before you call anyone.
Icon-only buttons
A menu, close, search or calendar button drawn as an icon often has no text, so a screen reader has nothing to announce. Add visible text where the design allows it. If it does not, give the button a precise aria-label, such as "Open menu," and keep it working with the keyboard.
Placeholder-only fields
Placeholder text sits inside the field and disappears as soon as someone types. Add a visible label that stays on the page, and keep the placeholder only as an example of the format. Text placed near a field that only looks like a label may not be connected to it in the code, so check with the Accessibility tab.
Clickable div elements
A div styled to look like a button does not tell software it is a button, and it may not respond to the keyboard. Replace it with a real button or link where you can. If you cannot, it needs a role, keyboard behavior, focus and state added by hand, which is more work.
Popups and dialogs
A popup needs a name, focus has to move into it when it opens, stay inside while it is open, and return to the page when it closes. The W3C dialog pattern lays out that behavior. Test any newsletter or cookie popup with the keyboard, because background controls that stay reachable behind it are a common failure.
| Problem | Typical fix | Usual job size |
|---|---|---|
| Missing field label | Add a visible label with a matching for and id | Small edit per field |
| Icon-only button | Add visible text or a precise aria-label | Small |
| Empty link | Write descriptive link text | Small |
| Placeholder-only field | Add a persistent visible label | Small to medium, depending on the builder |
| Clickable div | Swap for a real button or link | Medium |
| Popup with no name or focus handling | Name it and manage focus | Medium to large |
| Third-party widget | Ask the vendor for an accessible version, or replace it | Varies |
The sizes are approximate and depend on your builder and theme. A form built from a plugin you cannot edit may need a vendor request rather than a code change, and that is worth knowing before you plan a weekend of fixes.
Keep the problem in proportion with what WebAIM measured
These gaps are common, so finding some on your own site does not mean you did something unusual. WebAIM's Million report, from February 2025, ran automated checks on the home pages of one million websites and counted the failures it detected. These figures are WebAIM's, and they cover home pages, not every contact or checkout page.
| Failure detected | Share of one million home pages |
|---|---|
| Missing form input labels | 48.2% |
| Empty links | 45.4% |
| Empty buttons | 29.6% |
The WebAIM Million report also found more pages failing on low contrast and missing image descriptions, but those fall outside buttons and forms. All three failures in the table show up in a Lighthouse run. They are failures detected by an automated scan of home pages.
Spend your effort where AI agents and screen readers actually benefit
Adding aria-label to every control does not make a site readable to AI agents by itself. W3C recommends native HTML and visible text first, and ARIA only where the native element falls short.
On the agent side, OpenAI's announcement of its Computer-Using Agent on January 23, 2025 says the agent interprets screenshots and works graphical interfaces, including buttons, menus and text fields. Clear visible labels and button text matter for an agent like that, and they should match what the code says. OpenAI's system card for Operator describes tasks such as booking reservations and buying tickets, and it does not promise that every interface will work.
Chrome's DevTools documentation describes the accessibility tree as a subset of the page's structure that holds information useful to screen readers. Building controls with native elements, visible labels and correct names helps that tree, and it helps people who use assistive technology today. No published standard guarantees that an agent will finish a booking or purchase, so treat agent benefits as possible and the screen-reader benefit as certain.
If you want the wider picture, a website accessibility checklist covers the rest of the page, and you can see which AI agents visit your website to learn whether any are arriving. Questions about whether ChatGPT and Google AI can read your website are separate from form labels, and AI shopping agents and your online store is where checkout comes in.
Keep the money in your pocket when a few fixes are all you need
If your Lighthouse run shows two unnamed buttons and one unlabeled field, fix them yourself or ask whoever maintains the site to make the edits. A handful of small items does not call for a full redesign.
Professional help earns its fee when the problems stretch beyond one page. That includes issues repeated across several templates, custom widgets, booking or payment systems from a third party, multilingual pages, complicated validation, or the same problems returning after every update. In those cases the value is systematic repair, testing across templates, written results and upkeep, and not a secret AI setting.
Finish the week with a short plan. Test your contact or booking form on Monday. Fix the small items by Wednesday. Decide by Friday whether the rest needs a targeted review. ADA.gov's web guidance points to WCAG as a useful technical standard for accessible web services, which makes it a sensible yardstick for that review. Accessible names help screen-reader users and may help some browser agents, and no result is guaranteed.
Can your buttons and forms be read?
Pick an answer to begin.
1. What gives a form field its accessible name in the cleanest way?
2. What does a Lighthouse score of 100 tell you?
3. Which situation most justifies paying for professional help?
Frequently Asked Questions About Readable Buttons and Forms
What is an accessible name?
It is the short text software uses to identify a control, such as "Send message" on a button or "Email address" on a field.
How should I label a form field?
Use a visible label and tie it to the field with a for value that matches the field's id. W3C's forms tutorial describes this pattern.
Can placeholder text replace a label?
No. Placeholder text disappears while someone types. Use a label that stays on the page and keep the placeholder only as an example of the format.
How do I label an icon-only button?
Add visible text where the design allows it. If it cannot, give the button an accurate name with aria-label or aria-labelledby, such as "Open menu."
Does Lighthouse prove my site is accessible?
No. Lighthouse catches many problems automatically but cannot test everything. Add a keyboard pass through the form and, where you can, testing with a screen reader.
What should I fix first?
Fix missing labels and unnamed buttons and links first. Then check keyboard access, visible focus, form error messages and popup behavior.
Moving Forward
Every button, link and form field needs a name a person and a program can read. Buttons and links take it from their text, and fields take it from a visible label tied to them in the code. A Lighthouse run, one look at Chrome's Accessibility tab and a keyboard pass through the form show you where the gaps are, and the usual builder culprits are icon-only buttons, placeholder-only fields, clickable divs and unnamed popups.
The payoff is a form that more visitors can finish, including people using screen readers, keyboards or voice control, and possibly some browser agents. No one can promise an agent will complete a booking on your site, but a clearly named form gives it a fair chance and gives your human visitors a better one.
If your check turns up problems across templates, custom widgets or a booking system, Web Leveling can review the pages that matter and fix them as part of our web design work, and we will tell you plainly when a few small edits are all you need. We work with small and medium businesses across the country and overseas. Tell us which form worries you, and we will start there.
Terms
Words used in this post
Tap a term to see what it means.
Accessible name. The short text software uses to identify a button, link or form field.
Accessibility tree. A subset of the page's structure that holds the information useful to screen readers, shown in Chrome's Accessibility tab.
Screen reader. Software that reads a page aloud or to a braille display for people who cannot see the screen.
aria-label. An attribute that supplies an accessible name when a control has no visible text.
Placeholder. Hint text shown inside an empty form field that disappears once someone types.
Lighthouse. A free audit tool built into Chrome that runs automated accessibility checks on a page.
