WanderQ-Web2.0/site-audit.md

WanderQ site-wide UX, visual, and accessibility audit

Date: 2026-08-22
Surface: local WanderQ website at http://127.0.0.1:5175/
Goal: help an international visitor understand the three Guizhou experience directions, trust the local team, and reach a workable inquiry path.

Audit scope

• Combined UX, visual-consistency, responsive, and screenshot-based accessibility review.
• Desktop viewport: 1512 × 1000 CSS px.
• Mobile viewport: 390 × 844 CSS px.
• Routes scanned at both breakpoints: homepage, Guizhou Experiences, two experience details, one landscape detail, Hotels, Food, About, Service Cases, FAQ, Trade Portal, and Contact.
• Browser-rendered screenshots and DOM/interaction checks were captured in the current audit run.

1. Homepage entry — healthy

The desktop hero has a clear destination promise, strong photography, and one dominant journey-planning action. The mobile hierarchy reflows cleanly without losing the promise or CTA.

2. Guizhou Experiences selection — healthy

The three-category model is easy to scan and remains consistent across desktop and mobile. All cards remain inside the viewport and point to the expected category or detail content.

3. Representative experience detail — healthy after navigation cleanup

The detail page has a clear hero, readable activity positioning, and useful in-page navigation. Route-pairing cards previously used removed /safaris/ destinations; they now return visitors to the correct merged experience category. English culture-detail breadcrumbs no longer contain an untranslated Chinese category label.

4. Menu and search — healthy after accessibility cleanup

The full menu exposes the current information architecture without the removed Transport or standalone Routes categories. Search has a clear empty state. Menu and search triggers now expose dialog state, dialogs have programmatic names, keyboard focus loops inside each dialog, Escape closes them, and focus returns to the opening control.

5. Contact page — healthy after form polish

The inquiry page explains the three-step process and keeps the form visible against the photographic background. Field names are now present for form semantics, the travelers example no longer truncates on desktop, native required-field validation focuses the first invalid field, and mobile reflow has no horizontal overflow.

6. No-backend submission recovery — workable fallback

The project still has no inquiry backend, so direct online delivery cannot be guaranteed. Instead of leaving visitors at a generic failure message, the error state now offers a prefilled email containing all form values and the destination address travel@wanderq.com.

7. Cross-route integrity scan — healthy

All 12 representative routes were checked at desktop and mobile widths. No broken images or horizontal overflow were found. The production build and lint checks pass.

Strengths

• The homepage now forms a coherent five-part funnel: promise, three experience choices, planning method, local-team trust, and inquiry.
• The green/cream/forest palette, square corners, editorial display type, and supporting sans type are consistent across the main journey.
• Navigation terminology matches the simplified information architecture.
• Real project imagery is used throughout the primary customer journey.
• English is the default, and checked Chinese states preserve the same structure and meaning.

Issues fixed during this audit

1. P1 — inquiry dead end without a backend: added a prefilled email recovery path with the submitted details.
2. P2 — removed route links still exposed in detail pages: mapped legacy route cards to the three merged experience anchors.
3. P2 — untranslated English breadcrumbs: replaced the hard-coded culture category with bilingual content.
4. P2 — truncated traveler guidance: shortened the placeholder to a scannable example.
5. P2 — modal state and focus behavior: added dialog relationships, expanded state, focus containment, Escape close, and focus restoration.

Accessibility evidence and limits

• Confirmed from rendered DOM and interactions: labeled form controls, native required validation, dialog naming, dialog trigger relationships, focus containment, Escape close, focus restoration, responsive reflow, and no hidden horizontal content at tested widths.
• Screenshots and DOM checks cannot establish full WCAG compliance, screen-reader announcement quality across platforms, color contrast ratios in every state, or performance on all devices. Those require dedicated automated and assistive-technology testing.

Remaining product dependency

The email fallback is honest and usable for a frontend-only site, but a seamless successful submission still requires a real backend or third-party form delivery service.