Skip to main content

Search input present on every browsing page without required scrolling on mobile

ab-001053 · directory-search-discovery.search-input.search-present-mobile
Severity: criticalactive

Why it matters

Directory users arrive with intent — they want to find a specific listing, not browse aimlessly. When search is hidden below the fold on mobile, buried in a hamburger menu, or missing from category pages entirely, users bounce before they engage. Mobile traffic typically drives 60-70% of directory sessions, and forcing a scroll-then-tap-menu-then-tap-search sequence collapses conversion. This is a core user-experience failure mode that directly reduces listing views, claim rates, and advertising revenue.

Severity rationale

Critical because the search bar is the primary entry point to the directory's value and hiding it on mobile cuts conversion at the top of the funnel.

Remediation

Place the search input inside a sticky header that renders on every browsing page and stays visible in the initial 320px viewport. Avoid tucking search inside a collapsed navigation drawer. See components/Header.tsx:

<header className="sticky top-0 z-50 bg-white shadow">
  <SearchInput aria-label="Search listings" placeholder="Search..." />
</header>

Confirm visibility at 320px width before shipping.

Detection

  • ID: directory-search-discovery.search-input.search-present-mobile

  • Severity: critical

  • What to look for: Enumerate all relevant files and Load the directory's main browsing page(s) on a mobile device (320px width) or use browser dev tools to simulate a mobile viewport. Check whether a search input field is visible in the viewport without scrolling. Verify that the search input is present on every page where users can browse listings (e.g., category pages, search results pages, main directory page). Quote the exact code pattern or configuration value found.

  • Pass criteria: At least 1 conforming pattern must exist. A search input is visible within the initial 320px mobile viewport (no scrolling required) on all browsing pages. The input is labeled, has a placeholder or label text indicating it's for search, and is interactive.

  • Fail criteria: Search input is not visible on mobile without scrolling (e.g., hidden below the fold or in a collapsed menu that requires interaction), or search input is missing from one or more browsing pages. A partial or incomplete implementation does not count as pass.

  • Skip (N/A) when: The directory has no search functionality at all (search is completely absent from the UI). Signal: no search input component found in any page or layout.

  • Cross-reference: For deeper accessibility evaluation of search and filter components, the Accessibility Basics audit covers ARIA patterns and keyboard navigation.

  • Detail on fail: Specify which pages lack visible search inputs and where the input appears on mobile. Example: "Search input only appears after scrolling past the header on /listings page. Not visible on mobile viewport at 320px." or "Search bar visible on home page but missing from /category/restaurants page."

  • Remediation: Make sure your search input is in a fixed or sticky header that remains accessible at the top of the page on mobile. In a React-based directory:

    // components/Header.tsx
export function Header() {
  return (
    <header className="sticky top-0 z-50 bg-white shadow">
      <SearchInput />
      {/* navigation below */}
    </header>
  )
}

    On mobile (≤640px), prioritize the search input in the header space. If you have a navigation drawer, the search should appear above or alongside the menu toggle, not inside it.

Taxons

user-experience

History