1 Minute Summary
1 Minute Summary
The Problem
Airbnb publicly committed to WCAG compliance, but it was unclear whether their web experience actually met those standards for users relying on assistive technologies and keyboard navigation.
My Approach
Conducted a multi-method audit of two Airbnb pages — the homepage and help center — using six evaluation methods including WCAG manual checks, automated tools, and firsthand screen reader testing.
The Outcome
Identified issues across all for POUR principles, with 71 parsing errors across both pages and 8 actionable recommendations to close the gap between Airbnb's stated commitment and actual compliance.
Want the full story?
The sections below dives deeper into research, design decisions, iterations, and learnings.
About
My Role
Solo Evaluator
Audit Design, Manual Testing, Screen Reader Testing, Analysis
project type
Accessibility Audit
pages evaluated
2 pages
airbnb.com • airbnb.com/help/home
standard
WCAG 2.0
POUR principles
Methods
6 evaluation methods
Manual, Automated, Cognitive, Screen Reader
Status
Evaluation Complete
Report Delivered
Airbnb committed to WCAG compliance, this audit tested whether that promise held..
Airbnb has operated as an online lodging and experience marketplace since 2008. With a global
user base spanning tourists, travelers, and hosts across every device and context, accessibility
isn't a nice-to-have — it's a core equity issue. On their accessibility page, Airbnb explicitly
states they are working toward WCAG compliance and investing in automated testing tools.
That stated commitment was the starting point for this evaluation. The goal was not to
prove Airbnb had failed, but to assess how close the live experience was to the standard they
had set for themselves. The homepage and help center page were selected as
representative surfaces, one discovery-oriented and one task-oriented.
Airbnb's target users include tourists, travelers, and anyone renting temporary housing globally. For assistive technology users, a booking experience that isn't keyboard accessible or screen-reader compatible isn't just inconvenient — it's a barrier to entry.
Methods
Six evaluation methods, each targeting a different layer of accessibility stack.
- W3 Easy Checks/WCAG 2 Checklist
- Manual review against WebAIM's WCAG 2 Checklist to assess compliance with POUR guidelines across both pages.
- W3 HTML/CSS Validator
- Source code validation via validator.w3.org to surface parsing errors, malformed markup, and non-standard CSS values.
- ARIA Manual Check + Wave
- Checked ARIA implementation agaisnt Google's Introduction to ARIA guide and verified with Wave automated evaluation tool.
- Cognitive Level Test
- Used Readable.io's website readability feature to assess reading grade level across Airbnb's homepage content.
- Automated Evaluations
- Ran both Wave and TAW Web to cross-reference automated findings against four POUR primiciples idependently.
- Screen Reader (VoiceOver)
- Used macOS VoiceOver to test the actual assistive technology experience firsthand — navigating both pages end to end.
Screen Reader Note
The VoiceOver experience was immediately overwhelming — the reader launched without pause on page load and read content from carousel sections that wasn't visually displayed. Navigation required learning to use the tab key to move between sections. While the screen reader correctly identified buttons, headers, links, and navigation, the cognitive load of the experience surfaced usability gaps that automated tools alone would not have caught.
Findings
Issues identified across all four POUR principles
- Finding 1:
-
46 Parsing errors on the homepage
- Finding 2:
-
25 Parsing errors on the help center page
- Finding 3:
-
96 Total warnings across both pages
- Finding 4:
-
5.2 Average reading grade level (homepage)
Images missing alt text and long descriptions
TAW flagged 3 errors for non-text content. Stay and experience listing images had empty alternative text attributes, leaving them invisible to screen readers. Neither page grouped consecutive text and image links pointing to the same resource — a pattern that creates redundant or confusing navigation for assistive technology users.
Empty list element under "Search Suggestions" ARIA label
Both pages contained an empty <ul>
element nested under the ARIA label "Search Suggestions." An empty list with a meaningful label
creates a false expectation for screen reader users — they hear a label and receive nothing.
Homepage reads at a 5th grade level — generally accessible
Readable.io assessed the homepage at an average grade level of 5.2. WCAG 3.1.5 recommends that when content requires more than a lower secondary education reading level, supplemental content or a simplified version should be available. At 5th grade, Airbnb's homepage is generally accessible to a broad audience — this is a low-risk finding, but worth tracking as content complexity grows.
71 combined parsing errors — elements misused, duplicate IDs, bad attribute values
The W3 validator found 46 parsing errors and 51 warnings on the homepage, and 25 parsing errors and 45 warnings on the help center. Recurring issues included elements used as invalid children of other elements, undefined used as a CSS value where a number was expected, non-digit characters where digits were required, and duplicate IDs throughout both pages. Duplicate IDs in particular can cause assistive technologies to target the wrong element.
Frames missing titles; user interface components lack name/role/value
TAW found 15 Robust problems on the homepage and 22 on the help center. Both pages shared the same pattern: frames without titles (making them inaccessible to screen readers) and interactive components where name, role, and value were not properly exposed to assistive technologies. TAW also flagged failed CSS validity as contributing to 4.1.1 parsing failures.
Recommendations
Eight changesthat would close the most significant compliance gaps
Findings were assessed for impact and prioritized based on their effect on assistive technology users. The keyboard and navigation issues present the highest barrier. They prevent users from completing core tasks entirely. The parsing and markup issues create compounding risks as screen reader interpretation degrades with malformed code.
Fix the 71 parsing errors
Address child element misuse, bad attribute values, and undefined CSS values across both pages. These create an unstable foundation that other accessibility fixes depend on.
Fix the skip navigation link
Give it a valid target anchor and ensure it is reachable by keyboard. This is one of the most impactful single-line fixes available — it restores a critical shortcut for keyboard-only and screen reader users.
Resolve the carousel keyboard trap
Allow keyboard users to exit the carousel via arrow keys or Escape without tabbing through every item. Consider implementing a roving tabindex pattern so only one carousel item is in the tab sequence at a time.
Add text and long descriptions to listing images
Add an aria-label="Airbnb home" or visible sr-only text so the link has a meaningful, communicable purpose for assistive technologies.
Add alt text and long descriptions to listing images
Every stay and experience image should have descriptive alt text. For images that serve as primary content (not decorative), long descriptions should convey the content a sighted user would receive.
Remove duplicate IDs
IDs must be unique per HTML spec. Duplicates cause assistive technologies to unpredictably target the wrong element, especially in forms and interactive components
Give all frames title attributes
Every <iframe> should have a descriptive title attribute so screen readers can communicate the frame's purpose before a user enters it.
Populate or remove the empty "Search Suggestions" list
An ARIA-labeled list with no items creates a misleading expectation. Either populate it dynamically when suggestions exist, or remove the empty <ul> from the DOM until it has content.
Reflection
What the screen reader experience taught me that no automated tool could
The most significant learning from this audit wasn't a guideline violation — it was the firsthand experience of navigating both pages with VoiceOver. The screen reader started reading immediately on page load with no pause. The voice was difficult to parse at default speed. Carousel content that wasn't visually present was being read aloud. Knowing how to slow it down or pause it wasn't obvious.
That experience reframed every finding in the report. A broken skip link isn't just a code error — it's the difference between a 2-second shortcut and tabbing through an entire navigation menu to reach the content you came for. A keyboard trap isn't just a WCAG 2.1.2 issue — it's getting stuck in a carousel with no obvious way out.
Airbnb's target users include tourists, travelers, and anyone renting temporary housing globally. For assistive technology users, a booking experience that isn't keyboard accessible or screen-reader compatible isn't just inconvenient — it's a barrier to entry.
Airbnb's issues were, by the standards of the web, relatively contained — nothing catastrophic, and their reading level was genuinely accessible. But the gap between "we're working toward WCAG compliance" and the actual keyboard and screen reader experience on their live pages was meaningful. Accessibility commitments need to be tested, not just stated.
Thank you for reading!
Contents
don't be a stranger!
Let's collaborate and create something amazing!