Homepage Accessibility Audit — Case Study

This case study documents a manual accessibility and UX audit of a high-traffic commercial services website. The goal was to identify barriers for keyboard-only and screen reader users and provide actionable recommendations aligned with WCAG 2.1 Level A and AA.

Role: Accessibility & UX Auditor · Tools: NVDA, Keyboard Testing · Standard: WCAG 2.1 AA · Dates: Dec 2025–Jan 2026

Project snapshot

  • Scope: Homepage navigation, service selection, primary CTAs
  • Users impacted: Keyboard-only users, screen reader users, users with cognitive load
  • Deliverables: Documented key issues, WCAG 2.1 A/AA mapping, prioritized recommendations, post-update review
  • Methods: Keyboard testing · NVDA · WCAG 2.1 AA

Context

The website serves a broad audience of individuals, freelancers, startups, and businesses seeking essential services. Because it functions as a gateway to important workflows, accessibility is critical to ensure equitable access.


Problem

While the site appeared visually polished, testing revealed several interaction patterns that were not accessible to users relying on assistive technologies. Core navigation elements and service selectors created friction, confusion, or complete blockers for keyboard and screen reader users.

These barriers can exclude users with disabilities, reduce usability for all users, and introduce compliance risk.


Methodology

  • Keyboard-only testing: Tab, Shift+Tab, Enter, arrow keys
  • Screen reader testing: NVDA for roles, labels, and announcement behavior
  • Standards review: WCAG 2.1 Level A and AA

Testing focus

  • Navigation order and focus management
  • Accessible names, roles, and labels
  • Keyboard operability and escape mechanisms
  • Clarity and predictability of interactive elements

Key Findings

A. Keyboard navigation barriers

  • Missing a “Skip to main content” link, requiring users to tab through navigation on every load.
  • A horizontally scrollable tab list created a keyboard trap and slowed access to primary content.
  • Arrow controls used to scroll the list were not keyboard operable.

WCAG: 2.4.1 Bypass Blocks (A) · 2.1.1 Keyboard (A) · 2.1.2 No Keyboard Trap (A)

B. Confusing or misleading accessible names

  • Service icons were announced by visual metaphor rather than functional meaning (e.g., “handshake”).
  • A navigation arrow link was announced as “northeast,” providing no meaningful context.
  • A language selector was announced as “language en link” instead of clearly indicating “English.”

WCAG: 1.1.1 Non-text Content (A) · 2.4.4 Link Purpose (A)

C. Misleading interaction cues

  • An arrow button next to the email field appeared to submit the form but did not trigger submission.

WCAG: 3.2.4 Consistent Identification (AA) · 4.1.2 Name, Role, Value (A)


Post-Audit Update Review (January 2026)

Following completion of the initial accessibility audit, the website underwent a partial redesign and staggered rollout. A brief follow-up review was conducted to observe how these changes affected accessibility outcomes. While some structural and visual improvements were present, several core accessibility issues persisted, particularly for keyboard-only and screen reader users.

This reinforced the importance of treating accessibility as an ongoing practice throughout design and deployment cycles rather than a one-time review.


Impact

  • Blocked or slowed access for users with motor, visual, or cognitive disabilities
  • Reduced clarity and predictability in core workflows
  • Increased the risk of accessibility non-compliance
  • Undermined inclusiveness for a broad user base

Recommendations

  • Add a visible-on-focus “Skip to main content” link.
  • Ensure all interactive elements are keyboard operable and escapable.
  • Use meaningful, functional labels for icons and links.
  • Avoid announcing visual metaphors instead of purpose.
  • Align interactive controls with user expectations (e.g., submit buttons should submit).

Supporting documentation

Download the full audit spreadsheets (Excel):


Reflection

This audit reinforced that accessibility barriers often come from design choices that prioritize visual presentation over inclusive interaction patterns. Treating accessibility as part of the design and development lifecycle helps reduce friction, improve clarity, and ensure services are usable by everyone.