Treat keyboard access as part of customer service
A local-service website should not assume every visitor taps a phone in the same way. Some people browse with a keyboard because of a motor, vision, or temporary access need; others use a laptop at work before calling a tutor, accountant, electrician, photographer, or consultant. If the menu, price guide, portfolio, or contact form works only with a mouse or precise tapping, a ready customer can be shut out before they learn whether the service fits. Keyboard access is therefore not a technical extra. It is part of making the first conversation possible.
Start with the small customer journey your site is meant to support. Can someone understand the service, compare the relevant options, find opening hours or service area, and send an enquiry without touching a mouse? Do not promise formal accessibility conformance unless you have carried out the appropriate assessment. Begin by removing obvious barriers from the public pages that matter most.
Run the Tab-key test before redesigning anything
Open the site in an ordinary desktop browser, click away from the page, and press Tab. Each press should move through interactive items in a sensible order: skip link if present, navigation, main calls to action, links, form fields, and submit controls. Shift+Tab should move backwards. Use Enter or Space where expected to open a menu, activate a button, or choose an option. If focus disappears, gets trapped in a pop-up, jumps unpredictably, or lands on a decorative icon with no useful action, note the page and control rather than trying to remember it later.
Test a real task, not just the home-page menu. For example, look for a home-cleaning package, open its details, choose the contact route, fill the required fields, correct one intentional error, and submit a harmless test request if the workflow permits. A freelance professional can test the path from a case study to an enquiry form. This exposes practical problems such as a modal that cannot close, an accordion that will not open from the keyboard, or a calendar that traps focus. Fix the route that customers actually need before polishing low-priority interactions.
Make focus visible, ordered, and unobscured
People using a keyboard need to see where they are. Do not remove the browser focus outline unless an equally clear replacement is already in place. A distinct ring, border, or background change around a link, button, field, or menu item gives a visitor confidence to continue. Current W3C WCAG 2.2 guidance also calls attention to focus that is hidden by author-created content. Check sticky headers, chat buttons, cookie notices, promotional bars, and floating WhatsApp controls: a focused control should not vanish entirely behind them.
Keep the visual and keyboard order aligned whenever possible. A layout that looks left-to-right but tabs through the footer before the main offer is confusing. Avoid using positive `tabindex` values to force an order; they often create a brittle path when content changes. Instead, use native links for destinations, native buttons for actions, and a document order that matches the reading order. If a custom component is essential, make its open, close, and escape behaviour deliberate. A simpler interface with ordinary controls is usually easier to maintain than a clever one with hidden rules.
Give forms labels, useful errors, and a recoverable path
A contact form is frequently the first operational handoff, so each field needs a persistent, visible label. Placeholder text disappears when someone begins typing and should not be the only instruction. State which fields are required, use plain labels such as ‘Phone number’ or ‘Describe the service you need’, and keep optional fields clearly optional. A screen reader and a keyboard user both benefit when the label and help text are correctly associated with the control. Do not use a colour change alone to announce a problem; explain what needs attention in words.
When validation fails, move the person to a clear error summary or the first field that needs correction, without erasing the details they already entered. Say what is wrong and how to fix it: ‘Enter a phone number with at least 10 digits’ is more useful than ‘Invalid input’. After a successful request, show a confirmation that explains what happens next and provides a genuine alternative for urgent matters. This reduces duplicate calls and uncertainty for every customer. It also prevents an accessible interface from ending in an inaccessible, vague confirmation screen.
Keep touch targets and mobile content comfortable too
Keyboard access and phone usability reinforce one another. Small, crowded controls are difficult for someone using a pointer, a thumb, or a hand with limited precision. WCAG 2.2 added a minimum target-size criterion at the AA level, with exceptions, and its practical lesson is straightforward: give important buttons and links enough space to use without accidentally activating a neighbour. Check phone, WhatsApp, booking, menu, close, and form-submit controls at normal zoom on a modest phone. A tiny icon with no text is rarely the best primary action.
Do not hide the information that makes an enquiry possible on mobile. Google’s current mobile-first guidance recommends responsive design and equivalent primary content across mobile and desktop. That is not a reason to cram every desktop layout onto a small screen. It is a reason to keep the service description, contact route, meaningful headings, and image alt text available even when the layout changes. A tidy accordion can save space, but it must open with the keyboard and should not conceal the only answer about price approach, area served, or expected response time.
Create a light review routine the business can sustain
Put a 10-minute accessibility check into the same routine used to verify phone numbers, hours, and booking links. Once a month, Tab through the homepage, one main service page, and the contact page. Check that focus remains visible, the menu and any pop-up can close, headings describe their sections, and the form can be completed without a mouse. Then repeat one useful task on a phone: read the offer, tap the main action, and make sure the text stays legible. Record the date and any issue in the site-maintenance notes so changes do not get lost between busy weeks.
Ask a developer or accessibility specialist for help when a custom booking tool, payment step, map, document viewer, or complex widget fails the basic check. Do not quietly replace useful text with an image or tell customers to call if the website is difficult to use; improve the route itself. Accessibility work will not guarantee search rankings or enquiries, and a short checklist is not a certification. Its practical value is more direct: more people can understand the service, take the next step without unnecessary friction, and reach the business with realistic expectations.
Ready to make your own page clearer?
Create a site with PaperChai