Contact is the last point at which you can lose a customer. Earlier obstacles can be worked around: a product description can be read elsewhere, an image can be skipped, and a specification table can be reconstructed from text. No one can work around a form that cannot be submitted. A person who has read your entire offer but cannot send an enquiry will not report the problem—they will simply disappear.
Why contact is the real bottleneck
Accessibility legislation has inspired countless guides to contrast, headings and alternative text. All of these topics matter, but all of them overlook the place where inaccessibility costs the most. Content can be read in several ways. An enquiry can be sent only through a form, chat or phone system that someone had to build for use without a mouse.
It is worth setting the language of obligation aside. Accessible contact paths simply mean more people can write to you. They also support temporary situations in which anyone may be left with only a keyboard: a broken touchpad, working on a train or completing a form with one hand.
- Screen readerA blind person hears the page in the order in which it was built, not the order in which it appears visually.
- Keyboard onlyLimited mobility or hand tremors can make a mouse imprecise or impossible to use.
- Page zoomAt 200% zoom, floating elements can cover half the form and its submit button.
- Temporary circumstancesA broken arm, bright sunlight on the screen or an old laptop with a faulty touchpad. It can happen to anyone.
This article is not a substitute for a full website audit—it concerns contact paths only. If you are still designing the form itself, begin with the fields and microcopy covered in our guide to contact forms for websites, then return here for the test.
The reference standard for web accessibility is WCAG. Since 28 June 2025, some private companies have had obligations in this area under legislation implementing the European Accessibility Act, but the scope and exemptions depend on the type and size of the business. Check what applies to your company with a lawyer—this article covers practical testing only and does not constitute legal advice.
A ten-minute keyboard test
You need no tools or technical knowledge. You need ten minutes and a mouse placed out of reach—literally, because the impulse to grab it is stronger than good intentions. Follow the complete path as if you were a customer with one question to ask.
- Put the mouse aside.Open the home page and, from that point on, navigate with only the Tab, arrow and Enter keys.
- Reach the contact option.Count how many times you must press Tab to reach the contact or chat button. If focus enters the menu and will not leave, you have found the first problem.
- Watch the outline.At every step, you must be able to see where you are. If the focus outline disappears on even one element, a person without a mouse is navigating blind.
- Activate it with Enter.Anything that looks clickable must respond to Enter, and a button must also respond to the Space bar. If it does not, it is usually an ordinary block of text masquerading as a button.
- Check that you can leave.After opening the chat window, a pop-up or a menu, press Escape. It should close, and focus should return to the element that opened it.
- Send the enquiry all the way through.Do not stop after opening the form. Complete it, deliberately trigger an error, correct it and submit. The confirmation must also be reachable without a mouse.
Write down where you lost focus, where Escape failed to let you leave, and which element you could not activate. Those three notes are enough to form a task list for the person responsible for your website.
Test the sequence separately. Tab should move through elements in the same order in which they appear on the screen. If it jumps from the header to the footer and then returns to the middle of the form, someone rearranged the visual layout without changing the document structure.
Forms: labels, error messages and their connection to fields
Form accessibility comes down to three details: whether each field has a persistent label associated with it, whether errors are announced rather than merely shown in red, and whether the submit button is reachable.
The most common failure looks like this: a screen-reader user completes the form, presses Enter and hears no change. Visually, red text has appeared beneath two fields. The form is filled in, but the user has no idea why it was not submitted. They try twice more before giving up.
Scroll the table sideways to see all columns.
| Symptom | What it means for a screen reader | Fix |
|---|---|---|
| A field described only by grey text inside it | The description disappears after the first character and is not read when the user returns to the field | A persistent label above the field, associated with it using the for attribute |
| An error shown only by a red border | The error information does not exist at all | Error text beside the field, associated by an identifier, plus a message after a failed submission |
| An asterisk as the only indication of a required field | It may be read as a meaningless symbol or skipped entirely | The word “required” in the label and the required property on the field |
| Consent represented by an image or a custom toggle | An element with no role and no intelligible selected state | A standard checkbox with a label that can be clicked and reached with Tab |
| A submit button made up solely of an image | It is read as a filename or as the word “button” with no content | Visible text on the button, such as “Send enquiry” |
- Clicking a label places the cursor in the field—the simplest proof that the label is associated with it.
- After a failed submission, focus moves to the first invalid field or to an error summary.
- The error text says what to correct, not merely that something is wrong.
- Entered data does not disappear after a failed submission.
- The form can be submitted with Enter from the final field.
- The submission confirmation remains on screen as text rather than disappearing after two seconds.
Meetlead provides three parallel contact routes: chat, a callback request and an offline form that creates a ticket. Navigate each one using only a keyboard before declaring the work complete. See the contact channels.
When preparing screenshots for instructions, use the guide: Screenshots in help instructions: make steps work without images.
The chat window and floating elements
A chat window, consent banner and discount pop-up have one thing in common: they appear above the content and demand attention. For someone without a mouse, the difference between a well-built and a poorly built floating element is the difference between “I closed it in a second” and “I cannot get out of this.”
- Focus trapThe Tab key cycles endlessly inside the window and never returns to the page. Closing the browser tab becomes the only way out.
- No Escape-key exitA close icon that is visible to mouse users but unreachable from the keyboard prevents some people from making contact.
- Obscured contentAfter the page is zoomed, a floating element may cover a form field or the phone number in the footer.
- An unnamed buttonAn icon alone may be read as “button” or as a filename. A name such as “Open chat” solves the problem in one line.
The opening sequence presents another trap. If focus remains on the page after the user presses Enter on the chat button while the window opens somewhere else, a screen-reader user will not know that anything happened. The correct behavior is simple: focus enters the window, its title is announced, Escape closes it, and focus returns to the button that opened it.
It also helps to understand why a mock-up and a live website can behave differently. The Meetlead widget mounts inside a shadow root, so the website's global styles do not affect its contents. This removes one class of surprises, but it does not remove the need to test the entire keyboard path on your own site. When a website's availability schedule has no open time slots, its callback card is blocked semantically with the disabled state and aria-disabled attribute, not merely greyed out.
Chat, callback requests and the offline form work in a single window mounted inside an isolated shadow root. See the product.
On a phone, the same floating element also competes for space with the on-screen keyboard and browser bar. We cover the usual collisions in our article on mobile conversion.
Alternative contact methods as practical accessibility
The cheapest route to accessible contact is not a perfect widget but a second option. If someone cannot use the form, they should find a phone number, email address and callback request beside it—presented as ordinary text rather than hidden in an image.
A phone number displayed as an image is a classic mistake: it cannot be selected, read or clicked. The same applies to an email address split into pieces “to protect against spam.” You protect yourself from a bot while excluding a person who wanted to write.
- Step one
A screen-reader user reaches the contact section and hears three options: chat, phone and a callback request.
- Step two
They open the chat with Enter. Focus moves to the message field, and the window's name is announced.
- Step three
Typing is slow, so instead of holding a conversation, they choose the callback request and enter their number in a single field.
- Step four
They close the window with Escape and return to exactly the same place on the page. Contact was established without a single mouse click.
A callback request is often the simplest channel for people who find typing difficult because it requires one field instead of four. We explain the mechanics and pitfalls in our article on website callbacks.
One contact path navigated by keyboard from beginning to end is worth more than three checked only superficially. Book an implementation.
A checklist to run once a quarter
The accessibility of contact paths breaks silently: when a new banner appears, a plugin is updated or a button is replaced with a prettier one. This is not a one-off task but a short review performed on a regular schedule.
- The contact button can be reached with Tab alone, with no traps along the way.
- The focus outline is visible on every element in the contact path.
- The Tab order matches the order of elements on the screen.
- The chat window and other floating elements close with Escape.
- After the window closes, focus returns to the button that opened it.
- Every form field has a persistent label, and clicking it places the cursor in the field.
- Error messages have meaningful text, are associated with their fields, and receive focus.
- Buttons and icons have names that describe their action rather than merely the image.
- The phone number and email address are text that can be selected and clicked.
- At 200% page zoom, the form can still be completed and submitted.
- Someone has followed the entire path from entry to submission confirmation without using a mouse.
Quarterly is a sensible rhythm because that is usually enough time for a new integration or changed template to appear on the website. If you want to go one step further and see how people actually cope with your contact options, add a few observed sessions. We explain how to run them in our guide to website usability testing.
The result of this work is invisible in reports because you cannot count enquiries that arrived simply because something worked. You can see the other side, however: every repaired item on the list represents a group of people who no longer hit a barrier at the final step.
