Business and Service Websites: Improving Site Search and Filtering Usability across Devices

Business websites often rely on search and filter tools to help users find services or products. However, these tools can be difficult to use on mobile devices or for people relying on keyboards. This article outlines practical steps to make search inputs clearer and interactions more predictable, ensuring that all visitors can navigate your site effectively regardless of their device or method of input.

Understanding the Role of Accessible Search Inputs in Business Websites

As a hypothetical illustration, imagine a writer at a mid-sized service company preparing a search box for a site that lists consulting, maintenance, and training offerings. They have three placeholder headings from an early wireframe: “Find a service,” “Search our offerings,” and “What do you need help with?” Each label implies a slightly different scope. The first sounds like a directory lookup, the second suggests a broad catalog, and the third invites a plain-language description of a problem. The writer has not decided which phrasing matches the content structure, and that choice affects how the input itself should look.

The same draft contains two candidate filter groups. One is a short set of service categories such as advisory, on-site support, and instruction. The other is a set of audience types such as small teams, departments, and public-sector groups. Combining both in one panel would create a dense grid on a narrow phone screen, while placing them on separate steps could hide useful options behind an extra tap. The unresolved question is whether the first screen should show categories only or offer both groups with a clear way to narrow further.

For the input control, the draft sketches a single-line field with a visible label, a button, and a short hint beneath it. The hint text is still marked as a placeholder: “Try a service name or a short description.” No decision has been made about whether the hint stays visible after typing begins or whether it should collapse to save vertical space. On a phone, a persistent hint could push results below the fold; on a desktop, removing it may leave the field looking bare.

The writer also has a rough accessibility note attached to the field: a label that remains programmatically associated with the input, a button with an explicit name, and a status message area for “no results” or “loading.” The note does not yet specify how that status area behaves when filters change, and it does not settle whether suggested terms appear below the field or within the results list. These are drafting choices for explaining the problem, not findings from a live site or a completed trial.

Implementing Predictable Autocomplete Behaviors for User Convenience

The W3C combobox pattern treats autocomplete as a behavior choice rather than a single default. Its documentation describes four forms: no autocomplete, list autocomplete with manual selection, list autocomplete with automatic selection, and list with inline autocomplete. When a combobox is editable and has any form of list autocomplete, the popup may appear and disappear as the user types; for example, a string that matches no suggestions may close it, and any inline completion string disappears.¹

The pattern also sets expectations for triggers and keyboard use. The popup is hidden by default, with expansion conditions specific to each implementation, such as pressing the Down Arrow or activating an Open button. Escape dismisses a visible popup, and optionally clears the combobox when the popup is hidden beforehand.¹

For the autocomplete suggestion list in your own draft, you can start by writing six candidate entries and then shortening each one. A draft entry such as “Training services for teams that need help with new internal systems” might become “Team training for new systems.” If a shortened entry no longer matches what a visitor would type, you might keep the fuller phrase as supporting text rather than as the suggestion itself.

You can also compare ordering choices on paper before settling on one. Suppose the six entries include two service types and four locations. You might list the service types first, then the locations, and write a one-line note beside the list explaining that choice. A different order is also reasonable; what matters is that the order follows a rule you can state plainly and keep consistent.

For empty results, consider drafting a short message plus two alternate actions, such as broadening the query or browsing a category. Write both versions and pick the one that reads naturally in the context of your page. You might mark the chosen message as provisional until the fuller page draft is ready.

Finally, note questions worth returning to later: whether suggested entries should update as a visitor types, and how the list should behave when it is too long for a small screen. Record these as open items rather than resolved answers.

Ensuring Clear Keyboard Focus Indicators for Navigation

A keyboard user needs to be able to tell the keyboard focus indicator apart from other parts of the visual design, since subtle changes in response to focus movement can cause users to lose track of where focus is. The page guidance advises relying on the default focus indicators provided by browsers; if overriding them, it notes that colors and gradients can disappear in high contrast modes, and that focus must remain distinguishable from selection, especially when a component containing selected elements does not contain focus.²

An active element must always have a visual focus indicator, and authors need to manage events that remove or hide the active element, such as closing a dialog or deleting an item from a list, so that focus does not fall back to the body element. Because interaction with ARIA widgets such as menus and grids depends on code rather than browser defaults, the guidance also covers deciding when disabled interactive elements should be focusable.²

Take the navigation block from your own draft and mark every element a visitor can reach with the keyboard—the logo link, the main menu items, the submenu links, and the button that opens the mobile menu. Then add a short written note beside each item saying what a visible focus cue should look like when the visitor tabs onto it. You can choose cues that fit your site's palette: a two-pixel outline in a contrasting color, a solid underline offset from the text, or a background block behind the label. Whatever you pick, apply the same cue across desktop and mobile versions of the same component so a visitor moving between devices meets one consistent signal.

Next, revise one concrete label before you touch the others. Suppose your draft reads “Services & Solutions” in the main navigation. You might shorten it to “Services” and keep the fuller phrase in the page heading, then check that the focus ring still sits comfortably around the shorter word without clipping. This small edit shows whether your cue survives text length changes; if it crowds the letters, widen the offset. You can decide per item whether the cue is an outline or an underline, but writing the choice down next to each entry keeps the set coherent.

As a paper exercise, sketch the mobile menu open state with ten items listed. Note where the focus cue falls on the first, middle, and last item, and whether a visitor can tell which one is active. You might jot down that the last item's cue overlaps the menu edge; if so, adjust the spacing in your sketch rather than the cue itself. These notes are preparation, not a finished test—keep them with the draft so the next revision starts from a written choice rather than a guess.

Using Standard HTML Attributes to Identify Input Purposes

The H98 technique adds the appropriate autocomplete token to each form field, which makes the identified inputs programmatically determinable. Its stated objective is to link a predefined, published taxonomic term to the input so it can also be machine-interpreted, giving the input a common, referable, identifiable value regardless of the language or the visible on-screen label.³

The technique applies to HTML form fields that map to the Input Purposes for User Interface Components. Under the Success Criterion, autocomplete is not assumed on form fields that do not correspond to a field described in the HTML autocomplete attribute specification; if the field describes a custom taxonomy rather than the specified one, the rule may produce incorrect results. The technique should only be used when asking for data about the person filling in the form, not for other people.³

Take one search input from your own draft and write down what kind of information it expects: a service name, a location, a reference number, or an email address. You can then rename the field in plain words that match that purpose. A draft label such as “Search everything” might become “Search services or locations” when the field accepts both, while a field that takes only codes could read “Enter a reference number.” Choose whichever wording fits the material you actually have.

Next, compare the visible label with the hint text underneath. If both repeat the same instruction, you might keep the label short and let the hint say how the value is formatted, for example “Try a service name or a city.” You can also note whether the field groups several kinds of input into one box; if it does, consider splitting the draft into two labelled fields and compare which version a reader could complete from memory.

For each field, add a private note about the expected input type and whether the label still makes sense when read alone. Try covering the surrounding paragraph and reading only the label and hint aloud; if the purpose is unclear, revise the words rather than adding more explanation.

Maintaining Native Semantics When Enhancing Interactive Widgets

The Using ARIA document sets a conditional order for widget authors: if a native HTML element or attribute already provides the required semantics and behavior, use it rather than repurposing an element and adding an ARIA role, state, or property. The document names narrow exceptions where this may not be possible—when the HTML feature exists but is not implemented or lacks accessibility support, when visual design constraints rule out a native element, or when the feature is not currently available in HTML.⁴

The second rule says not to change native semantics unless there is real need. The document's example is a developer building a heading that acts as a tab: it rejects placing role=tab on an h2 element and instead shows a div with role=tab containing the h2 heading. A related note states that if a non-interactive element is used as the basis for an interactive element, developers must add the semantics with ARIA and the appropriate interaction behavior with scripting, and that for a button it is better and easier to use a native HTML button.⁴

For keyboard use, the third rule states that all interactive ARIA controls must be usable with the keyboard. If users can click, tap, drag, drop, slide, or scroll a widget, they must also be able to navigate to it and perform an equivalent action with the keyboard. The document says interactive widgets must be scripted to respond to standard keystrokes or keystroke combinations where applicable; its role=button example requires the element to receive focus and the action to be activatable with both the enter or return key and the space key.⁴

The fourth rule prohibits role=presentation or aria-hidden=true on a focusable element, because some users would focus on nothing. The same cautions apply to applying aria-hidden to a parent or ancestor of a visible interactive element. The document notes that an element hidden with display:none or visibility:hidden is not focusable or in the accessibility tree, making aria-hidden=true or tabindex=-1 unnecessary.⁴

Take the interactive widget from your own draft and mark one structural question before changing its appearance: what will the underlying control be when scripting or styling is stripped away? For a search field, you might decide it stays a labeled text input with a submit button, then treat any suggestion list as an addition rather than the only path to results. For a filter group, you can write down whether the choices are checkboxes, links, or a grouped set of options, and note which one still communicates selection without custom behavior.

As a short paper exercise, choose one widget and draft two versions of its plain form. Suppose your filter panel has three service categories and a location choice. Version A could keep the categories as checkboxes with visible group labels; Version B could present the same choices as links to results pages. Compare which version makes the current selection obvious when read aloud or scanned with styles absent. This is your own comparison, not a claim about how any user will respond.

You might also revise one line near the widget so it names the action plainly. If a draft heading reads “Refine your results,” consider “Filter services by type and location.” Keep the choice yours, and jot a private note about whether the widget still makes sense when its scripted layer is removed.

Verifying Device Compatibility Through Basic Interaction Checks

Take the search field and filter panel from your own page draft and write a short interaction script next to them: the taps, typing, and scrolling a visitor would perform to go from landing on the page to reading one result. Keep it on paper for now, and mark each step with the device you had in mind—phone, tablet, or desktop. This gives you a concrete list to review before you change any layout.

For the search field, you might write the steps as a numbered sequence. A draft snippet could read: tap field, type “maintenance”, wait for suggestions, tap the second suggestion, scroll results, open one. Then read it back and mark where a thumb would cover the hint text or where the suggestion list would push the results too far down. If you picture a phone in portrait orientation, note whether the field and its button still fit on one line or whether the button wraps below. Consider whether that wrap is acceptable or whether the label should shorten instead—your choice.

For the filter panel, write a parallel sequence: open filters, choose a service type, choose a location, apply, then clear. Note the number of taps and whether the apply action sits at the bottom of a long list. You can also note a question to answer yourself later: does the panel stay open after applying, and would that help or hinder? Write one sentence for each answer, then pick the version you prefer and revise the draft to match.

Finally, choose one result row and write what a visitor needs to see to decide: service name, location, price or duration, and one action. Read it aloud as if describing it to a colleague on a phone call. If any item feels missing or out of order, adjust the row text in your draft and note the change beside it. You can leave the rest of the page unchanged for now and treat this row as the reference for the others.

Frequently asked questions

How can I clarify what kind of information my own search field expects before renaming it?

Take one search input from your own draft and write down what kind of information it expects: a service name, a location, a reference number, or an email address. You can then rename the field in plain words that match that purpose.

What private note can I add for each field about its expected input type and whether the label works alone?

For each field, add a private note about the expected input type and whether the label still makes sense when read alone.

How should I draft an interaction script for the search field and filter panel in my own page draft?

Take the search field and filter panel from your own page draft and write a short interaction script next to them: the taps, typing, and scrolling a visitor would perform to go from landing on the page to reading one result. Keep it on paper for now, and mark each step with the device you had in mind—phone, tablet, or desktop.