← Back to blog
Local visibility

Accessible SME websites: Can customers complete the enquiry?

Test zoom, keyboard operation, form errors and contrast across the whole customer journey rather than checking the homepage alone.

Wide light ramp through a dark stone arch beside a narrow staircase

Your website may look tidy on your own screen while preventing customers from making an enquiry. At 150 per cent zoom, text disappears behind a photograph. A keyboard user cannot reach the calendar. A form error clears everything they entered. For an SME, accessibility starts with a practical question: can someone understand the offer, ask their question and complete the next step without another person helping?

You do not need a new visual style to answer that question. You need a testable route through the existing site. Take your most important enquiry or booking journey and follow it from entry to confirmation. A collection of attractive screenshots cannot demonstrate that the journey works with magnification, keyboard navigation or assistive technology.

Test a task rather than an impression

Define a task such as “Request a repair callback without knowing the exact model number.” Include the offer page, action button, form, privacy explanation, error state and confirmation. Reviewing the homepage alone may never expose the inaccessible date selector or the model field that unexpectedly becomes compulsory.

For every step, record the information required and a possible dead end. A supposedly optional field can still block submission. A chat launcher can cover the final button. An embedded booking service can make an otherwise usable website fail at the decisive moment. Treat third-party components as part of the customer journey rather than excluding them from the review.

Zoom should rearrange content safely

Browser zoom reduces the space available in CSS pixels. Text wraps differently, navigation may switch to its mobile form and columns need to stack. Those changes are expected. Trouble starts when a fixed height clips the longer text or an absolutely positioned photograph extends over the following section.

The W3C explanation of reflow uses 320 CSS pixels of width as a technical reference, equivalent to 400 per cent zoom on an initial 1280-pixel viewport. Certain content, including complex tables, has exceptions. That is not a blanket legal statement about every Swiss SME. It does provide a concrete reference for testing an ordinary enquiry journey.

Start with 100, 110, 125, 150 and 200 per cent browser zoom, then test a narrow screen. Begin at the top each time. Check headings, image boundaries and the transition into the next section. A wide data table may need its own scrolling container; that should not make the entire page scroll sideways. Give content room to grow when translated text or a different font takes more space.

Reach confirmation using the keyboard

Put the mouse aside. Use Tab to move between controls and the relevant activation key to operate links and buttons. You should always be able to see where you are. Removing the focus outline removes a position indicator. The order should follow both the visible arrangement and the actual task.

Open the menu, language selector, date picker and any dialog. Check that you can enter and leave each component. A closed dialog should not leave invisible controls in the tab order. Closing it should return focus somewhere sensible. A control that responds only to hovering needs a usable alternative for people who do not operate a mouse.

A form should explain what it needs

Name, telephone and enquiry fields need visible labels that are programmatically connected to their inputs. A placeholder disappears as the person types and is not an adequate replacement. Explain required information before submission. If a particular format is needed, provide a clear example and accept ordinary variations where the receiving system can handle them.

Put an understandable error beside the relevant field and say how to fix it. “Invalid” offers little guidance. “Please provide a telephone number where we can reach you” gives the person a task. Keep the other correct entries. Also check whether assistive technology can identify error and success messages without requiring the person to discover them by chance elsewhere on the page.

Contrast depends on the current state

Check text against its actual background in both light and dark themes. A light button on a dark section may keep white lettering after a theme change, resulting in white on white. Review hover, keyboard focus, selected filters and disabled fields too. The rendered state matters more than the colour recorded in a design file.

Measure contrast using the relevant foreground and background values. Information should remain identifiable through something other than colour. A red outline around a required field does not explain the problem. A filter that merely becomes a little darker may not communicate its selection. A label or another visible state indicator makes the interface easier to understand for everyone.

A small acceptance checklist

TestExpected resultEvidence
Zoom and narrow widthText, image and following section stay separate.Browser, width, zoom and affected URL.
Keyboard onlyThe enquiry reaches confirmation.Sequence of steps taken.
Incorrect inputError explained; correct entries preserved.Field, message and correction.
Both themesControls and states remain readable.Contrast measurement and visible state.

Add a screen-reader review and, where possible, feedback from people who use these tools in everyday life. Automated scanners can detect some technical faults. They cannot reliably establish whether wording makes sense or whether the complete task remains understandable. Passing a scanner is useful evidence for its specific checks, not a complete acceptance decision.

Set priorities and name the owner

Repair blockers in the main customer journey first, then less frequent detail problems. Record each issue with reproducible steps and an expected outcome. “Strange on my laptop” is difficult to act on. “Firefox, 125 per cent zoom, callback button covered by the image” is a practical repair brief. After the change, repeat the original case and neighbouring widths.

The Swiss federal accessibility office’s digital communication resources offer further orientation. Within your company, someone should still own acceptance of the actual journey, even when an agency or external booking provider implements the components.

Our article on website friction covers other obstacles between a visit and an enquiry. For web design and branding, bring your main customer task and one reproducible failure. That gives the improvement a concrete scope and lets you verify what changed.

Platform choice also affects continuing editorial work. The comparison of WordPress, Webflow and custom websites tests real editing tasks, multilingual publication and a verifiable handover.

FAQ

Does an automated scan prove accessibility?

It checks specific technical criteria. Understanding and complete operation also need manual review and, where possible, feedback from affected users.

Should the page look identical when zoomed?

No. Text can wrap and columns can change. Content, controls and completion of the task must remain accessible.

Who checks an external booking component?

Its supplier provides technical information. Your team should also test the actual embedded journey and own its acceptance.

Check your main customer journey

Bring a typical enquiry and a reproducible interaction failure.

Start the Business Check →

Read more from the AlpenAgent blog

More articles on voice AI, chatbots, automation, and lead workflows.

Browse all articles →

Privacy & Cookies

We use cookies to improve your experience. By using the site you agree to our privacy policy.