The desktop interface is still useful. It is no longer the default assumption.

If most of your visitors arrive through a laptop, you should still make the site good on a laptop. Wide screens, a mouse and a physical keyboard remain valuable for comparison, research, long forms and office work.

The mistake is treating that setup as the definition of a normal visitor. Someone may open your page inside a social app, use a phone with one hand, dictate a search, navigate with a screen reader, enlarge the text, or move between touch and keyboard input during the same task. They are not asking for a separate version of your website. They need the same task to remain possible through a different route.

The practical answer is therefore not “design for voice instead of screens.” It is to design an interface with a clear semantic structure, ordinary controls and a short path to the important action. That gives a mouse user precision, a keyboard user order, a voice user recognizable labels and an assistive technology user something meaningful to interpret.

This is also why a text-first fallback matters. If an interactive quote tool, map or booking widget fails inside an embedded browser, the visitor should still find the address, phone number, service area or enquiry form. We have made the same case in A Small-Business Website Should Keep a Text-First Path When Interactive Tools Fail. The fallback is not a concession. It is part of the interface.

The numbers say “support both,” not “mobile has won.”

Global device-share data is often used to argue that desktop design is finished. The current picture is less tidy. StatCounter’s worldwide platform measure for August 2026 put mobile at 50.13% and desktop at 49.87%. That is close enough to make a universal design decision from it a bad idea. The mix varies by country, industry, season and task. A local plumber, commercial accountant and wedding photographer will not have the same device pattern as a social publisher. (gs.statcounter.com)

Google’s mobile-first indexing guidance still matters, though. Google indexes the mobile version of a site, and its documentation recommends responsive pages that serve the same core content across device types, including non-visual browsers. That is a search-engine requirement, but it is also a useful design constraint: do not hide the service description, proof, pricing context or contact route on the narrow version of the page. (developers.google.com)

Embedded browsers make the device question messier. Android Custom Tabs keep a visitor inside the app while offering a browser-like experience. Apple’s SFSafariViewController does something similar inside an app. The visitor may arrive without the navigation habits, stored context or screen space you expect from a full browser. The page still needs to load cleanly, expose its purpose quickly and avoid assuming that every browser feature behaves exactly as it does on your development laptop. (developer.android.com)

So keep the desktop layout where it helps. Do not let it control the content hierarchy. Put the essential explanation, evidence and next step into a structure that survives a narrow viewport and a reduced browser context.

Which interface assumption survives real-world use?

Voice changes the markup more than the visual design.

“Voice” covers several different things, and they should not be lumped together. A voice assistant may answer a question without sending anyone to your website. Speech-to-text may fill a form. Voice-control software may let someone say “click Search” or “choose Plumbing.” Only the last two are primarily interface problems, and both reward ordinary HTML more than a special voice interface.

WCAG 2.2’s Label in Name guidance is unusually practical here. If a button visibly says “Request a quote,” its programmatic name should contain those words. If the visible label says “Get directions” but the accessible name is “open location module,” a speech-input user may say the words on screen and get nowhere. The same mismatch can confuse screen readers and people who use both speech and vision. (w3.org)

That makes several familiar choices more important than voice-search headlines. Use real buttons for actions and real links for navigation. Associate labels with form fields. Keep the visible wording stable. Do not replace a clear text label with an icon that only makes sense after explanation. Give focus a visible state. Avoid drag-only controls, hover-only information and gestures that require a precise sequence.

The result does not have to look plain. You can use animation, cards, filters and branded controls. The rule is that the visual layer must not be the only layer carrying meaning. If a visitor can understand the page by reading its headings, follow its links, tab through its controls and submit its form without guessing, voice support is usually moving in the right direction.

Assistive technology is not an edge case you can measure from traffic reports.

Analytics will usually tell you the visitor’s browser, device category and page path. It will not reliably tell you whether a person is using VoiceOver, NVDA, a switch device, browser zoom or speech recognition. Treating an unmeasured need as an unimportant need is a category error.

WebAIM’s tenth screen-reader survey collected 1,539 responses in late 2023 and early 2024. It found that 91.3% of respondents used a screen reader on a mobile device, with VoiceOver the most common mobile screen reader among respondents at 70.6%. The survey is not a census of all website visitors, and it should not be turned into a claim about your audience share. It is useful practitioner evidence that mobile and assistive technology are not separate worlds. (webaim.org)

The broader web is still performing badly on basic accessibility. WebAIM’s 2025 Million analysis found detectable WCAG failures on 94.8% of the top one million home pages. It found an average of 51 detectable errors per page, while warning that automated testing cannot find every problem. The most common categories included low contrast, missing alternative text and missing form labels. (webaim.org)

For a small business, this is good news in one sense. You do not need to begin with an expensive redesign or a catalogue of advanced assistive technology. Start with the things customers already need: readable type, sensible contrast, headings that describe the page, labelled forms, useful link text, a visible focus indicator, predictable error messages and a contact route that does not depend on a single widget.

Then test the actual journeys. Can someone reach the enquiry form with a keyboard? Can they tell which field has an error? Can a screen reader user skip repeated navigation? Can a voice user activate the visible button label? Those checks reveal more than a decorative accessibility badge.

Build the interface around tasks, then test the routes

1. Name the important tasks

   Write down what a visitor must be able to do: call, request a quote, find a service area, compare options or book a first conversation.

2. Give each task a text path

   Put the explanation, requirements and next step in ordinary page content before adding maps, calculators, carousels or other interaction.

3. Use native controls first

   Prefer headings, links, buttons, labels, lists and forms that browsers and assistive technologies already understand.

4. Check narrow and embedded contexts

   Open the page on a phone and from an app link. Look for clipped controls, missing context, blocked pop-ups and forms that are difficult to complete.

5. Test without a mouse

   Use the keyboard from the address bar through submission. Confirm focus order, visible focus, escape behaviour and error recovery.

6. Test the spoken interface

   Read visible labels aloud as commands. If “Contact,” “Pricing” or “Request a quote” does not identify the control, revise the label or accessible name.

7. Review the content after launch

   A later plugin, form replacement or redesign can break the semantic path even when the original page was sound.

The unobvious risk is overbuilding the interface for people who already know how it works.

Large-screen interfaces often accumulate hidden assumptions. A mega-menu assumes the visitor can see and interpret several columns at once. A map assumes location is the first useful answer. A calculator assumes the visitor knows which inputs matter. A chat bubble assumes the visitor wants a new interaction before they have understood the offer.

These choices can create friction for everyone, not only people using assistive technology. A person standing in a noisy workshop may not want a voice interaction. A person arriving from a social app may not see the browser chrome. A person with a physical keyboard may still prefer a mouse for one task and speech for another. W3C explicitly describes concurrent input methods and situational changes as normal, including switching between mouse, touch, keyboard and speech input. (w3.org)

The strongest small-business interface is usually less clever than the owner expects. It says what the business does, who it is for, where it works, what happens next and how to make contact. It lets a visitor choose the route that suits the moment. The design can still have personality, but personality should sit on top of clarity rather than replace it.

That is the real answer to the question. Do not assume a mouse, keyboard and large screen. Do not throw them away either. Build one clear, responsive, semantic path, then allow different devices and input methods to express that path.

The figures worth keeping in view