Appearance
Accessibility and Standards Compliance
An accessible landing page reaches more people, converts better, and protects your organization from legal risk — accessibility is good business.
Why This Matters
- 💻 Dev: You write the code that makes a page accessible or not. ARIA labels, keyboard handlers, focus management, and semantic HTML are your responsibility. Retrofitting accessibility is ten times harder than building it in from the start.
- 📋 PM: Over one billion people worldwide live with some form of disability. That is 15% of your potential market you are excluding with an inaccessible page. Beyond the moral case, accessibility lawsuits are increasing — ADA digital accessibility cases exceeded 4,000 in recent years.
- 🎨 Designer: Accessibility starts in design, not in code. Your color choices, font sizes, touch targets, and interaction patterns determine whether the page is usable by everyone. An accessible design is almost always a better design for all users.
The Concept (Simple)
Think of a building with ramps, elevators, and braille signs.
These features were designed for people who use wheelchairs, have mobility challenges, or are visually impaired. But look at who actually uses them: parents with strollers use the ramps, travelers with luggage use the elevators, and everyone benefits from clear signage.
This is the curb cut effect — features designed for accessibility end up helping everyone.
On a landing page, the same principle applies:
- High contrast text helps users with low vision AND anyone reading on a phone in bright sunlight
- Keyboard navigation helps users who cannot use a mouse AND power users who prefer the keyboard
- Clear form labels help screen reader users AND anyone who has ever been confused by a form
- Captions on videos help deaf users AND anyone watching without sound in a meeting
Accessibility is not a feature you bolt on. It is a quality that makes everything better for everyone.
How It Works (Detailed)
WCAG 2.2 AA: The Standard You Need to Meet
WCAG (Web Content Accessibility Guidelines) 2.2 Level AA is the widely accepted standard. Here are the requirements that matter most for landing pages:
╔══════════════════════════════════════════════════════════════════╗
║ WCAG 2.2 AA — LANDING PAGE ESSENTIALS ║
╠══════════════════════════════════════════════════════════════════╣
║ ║
║ PERCEIVABLE OPERABLE ║
║ ┌─────────────────────────┐ ┌─────────────────────────────┐ ║
║ │ ☐ Color contrast 4.5:1 │ │ ☐ Keyboard navigable │ ║
║ │ ☐ Alt text on images │ │ ☐ Visible focus indicators │ ║
║ │ ☐ Video captions │ │ ☐ Skip navigation link │ ║
║ │ ☐ Do not rely on color │ │ ☐ No keyboard traps │ ║
║ │ alone for meaning │ │ ☐ Touch targets >= 24x24px │ ║
║ │ ☐ Text resizable to │ │ ☐ Enough time to read │ ║
║ │ 200% without breaking │ │ ☐ No seizure-causing flash │ ║
║ └─────────────────────────┘ └─────────────────────────────┘ ║
║ ║
║ UNDERSTANDABLE ROBUST ║
║ ┌─────────────────────────┐ ┌─────────────────────────────┐ ║
║ │ ☐ Page language set │ │ ☐ Valid HTML │ ║
║ │ ☐ Form labels present │ │ ☐ ARIA used correctly │ ║
║ │ ☐ Error messages clear │ │ ☐ Landmarks defined │ ║
║ │ ☐ Consistent navigation │ │ ☐ Works with assistive tech │ ║
║ │ ☐ Input purpose defined │ │ ☐ Status messages announced │ ║
║ └─────────────────────────┘ └─────────────────────────────┘ ║
║ ║
╚══════════════════════════════════════════════════════════════════╝Color Contrast Requirements
CONTRAST RATIOS
────────────────────────────────────────────────────
Normal text (< 18pt / 14pt bold): 4.5 : 1 minimum
Large text (≥ 18pt / 14pt bold): 3.0 : 1 minimum
UI components and graphical objects: 3.0 : 1 minimum
┌──────────────────────┐ ┌──────────────────────┐
│ │ │ │
│ Light gray text │ │ Dark text on white │
│ on white bg │ │ background │
│ │ │ │
│ #999 on #FFF │ │ #333 on #FFF │
│ Ratio: 2.8:1 │ │ Ratio: 12.6:1 │
│ │ │ │
│ ✗ FAILS │ │ ✓ PASSES │
│ │ │ │
└──────────────────────┘ └──────────────────────┘Common mistakes:
- Light gray placeholder text in form inputs
- Low-contrast "subtle" body text
- Colored buttons where the text does not contrast enough with the button background
- Information conveyed only through color (red = error, green = success) without an icon or text label
Keyboard Navigation
Every interactive element on your landing page must be operable with a keyboard alone. Here is the expected tab order:
TAB ORDER FLOW
══════════════════════════════════════════════════
[Tab 1] Skip to main content link (hidden until focused)
│
▼
[Tab 2] Logo / Home link
│
▼
[Tab 3] Nav item: Features
│
▼
[Tab 4] Nav item: Pricing
│
▼
[Tab 5] Nav CTA: "Start Free Trial"
│
▼
[Tab 6] ─── SKIP LINK JUMPS HERE ───
│
▼
[Tab 7] Hero CTA button: "Get Started"
│
▼
[Tab 8] Secondary link: "Watch Demo"
│
▼
[Tab ...] Continue through interactive elements
│
▼
[Tab N] Footer linksKey requirements:
- Visible focus indicators — never set
outline: nonewithout providing an alternative. The focus ring should be clearly visible (use a 2px solid outline with offset). - Skip navigation link — the first focusable element should be a "Skip to main content" link, visible on focus, that jumps past the navigation.
- No keyboard traps — if a user tabs into a modal or dropdown, they must be able to tab or Escape out.
- Logical tab order — follows the visual layout, not the DOM order (unless they match, which they should).
Screen Reader Support
Screen readers announce content based on HTML structure and ARIA attributes. Here is what your landing page needs:
| Element | Requirement |
|---|---|
| Images | alt text describing content (empty alt="" for decorative) |
| Icons | aria-label or visually hidden text |
| Buttons | Clear text label or aria-label |
| Links | Descriptive text (not "click here" or "read more") |
| Form inputs | Associated <label> element via for/id |
| Required fields | aria-required="true" and visual indicator |
| Error messages | aria-describedby linking error to input, role="alert" |
| Landmark regions | <header>, <main>, <nav>, <footer> |
| Dynamic content | aria-live="polite" for status updates |
| Modals | role="dialog", aria-modal="true", focus trap |
Form Accessibility
Forms are the most critical interactive element on landing pages — they are where conversion happens. An inaccessible form means lost conversions.
╔══════════════════════════════════════════════════════════════════╗
║ ACCESSIBLE FORM CHECKLIST ║
╠══════════════════════════════════════════════════════════════════╣
║ ║
║ ☐ Every input has a visible <label> ║
║ (Do NOT rely on placeholder text as the label) ║
║ ║
║ ☐ Required fields are marked with both: ║
║ - Visual indicator (asterisk or "required" text) ║
║ - aria-required="true" ║
║ ║
║ ☐ Error messages appear: ║
║ - Adjacent to the field (not just at the top) ║
║ - Linked via aria-describedby ║
║ - Announced via role="alert" or aria-live ║
║ - Described in text (not just red border) ║
║ ║
║ ☐ Input types match content: ║
║ - type="email" for email fields ║
║ - type="tel" for phone numbers ║
║ - autocomplete attributes set correctly ║
║ ║
║ ☐ Submit button has clear text: ║
║ - "Start Free Trial" not just "Submit" ║
║ ║
║ ☐ Success/error states are announced to screen readers ║
║ ║
╚══════════════════════════════════════════════════════════════════╝Motion and Animation
Some users experience motion sickness, seizures, or distraction from animations. The prefers-reduced-motion media query lets you respect their preferences:
- Disable parallax scrolling when reduced motion is preferred
- Replace sliding transitions with simple fades or instant changes
- Stop auto-playing videos and carousels
- Never use flashing content faster than 3 times per second (seizure risk)
WCAG Criteria Mapped to Landing Page Elements
| Landing Page Element | WCAG Criteria | What to Check |
|---|---|---|
| Hero image | 1.1.1 Non-text Content | Alt text if meaningful, alt="" if decorative |
| Hero headline | 1.3.1 Info and Relations | Proper H1 tag, not just styled div |
| CTA button | 2.1.1 Keyboard | Focusable, operable with Enter/Space |
| CTA button | 1.4.3 Contrast | Text-to-background ratio >= 4.5:1 |
| Navigation | 2.4.1 Bypass Blocks | Skip link available |
| Form inputs | 1.3.5 Input Purpose | autocomplete attributes, proper labels |
| Error messages | 3.3.1 Error Identification | Text description, not just color |
| Testimonial carousel | 2.2.2 Pause, Stop, Hide | User can pause auto-advancing |
| Social proof logos | 1.1.1 Non-text Content | Alt text: "Trusted by Shopify" not "logo3.png" |
| Video | 1.2.2 Captions | Closed captions for all video content |
| Pricing toggle | 4.1.2 Name, Role, Value | ARIA state communicated (monthly/annual) |
| Cookie banner | 2.1.1 Keyboard | Dismissable via keyboard |
| Mobile menu | 2.4.3 Focus Order | Focus trapped in open menu, restored on close |
Testing Tools
┌────────────────────────┬────────────────────────────────────────┐
│ Tool │ What It Catches │
├────────────────────────┼────────────────────────────────────────┤
│ axe DevTools │ Automated WCAG violations, best │
│ (browser extension) │ automated coverage available │
├────────────────────────┼────────────────────────────────────────┤
│ Lighthouse (Chrome) │ Accessibility score, common issues │
│ │ Good for quick audits │
├────────────────────────┼────────────────────────────────────────┤
│ WAVE │ Visual overlay showing issues on the │
│ (browser extension) │ page — good for designers │
├────────────────────────┼────────────────────────────────────────┤
│ VoiceOver (macOS) │ Real screen reader testing │
│ NVDA (Windows) │ Essential — no automated tool catches │
│ JAWS (Windows) │ everything a screen reader reveals │
├────────────────────────┼────────────────────────────────────────┤
│ Colour Contrast │ Quick contrast ratio checking │
│ Analyser (app) │ Test any color combination │
├────────────────────────┼────────────────────────────────────────┤
│ Keyboard only │ Tab through the entire page without │
│ (manual testing) │ a mouse — can you do everything? │
└────────────────────────┴────────────────────────────────────────┘Important: Automated tools catch roughly 30–50% of accessibility issues. Manual testing with a keyboard and screen reader is essential. At minimum, tab through your entire page and verify you can complete the primary conversion action without a mouse.
In Practice
Airbnb: Accessibility That Improves Conversion
Airbnb invested heavily in accessibility after recognizing that their platform needed to work for everyone — hosts and guests with disabilities are a significant portion of their user base. Their landing page work included:
- Comprehensive keyboard navigation — every listing card, filter, and search element is fully keyboard-operable. They found that improving keyboard navigation also improved the experience for power users who preferred keyboard shortcuts.
- High-contrast design system — their design team rebuilt color palettes to meet WCAG AA contrast requirements. The result was not just accessible — it was more readable for all users, especially on mobile in outdoor lighting.
- Focus management in search flows — when users apply a filter, focus moves to the results area with an
aria-liveannouncement of how many results were found. This pattern improved engagement metrics for all users, not just screen reader users.
The business result: Airbnb reported that their accessibility improvements correlated with increased conversion rates across all user segments. Making forms more accessible (clearer labels, better error messages, proper input types) reduced form abandonment for everyone.
GOV.UK: The Gold Standard for Accessible Pages
The UK Government Digital Service (GDS) publishes some of the most accessible pages on the web. Their design system is built on principles that every landing page team can learn from:
- Content-first design — pages are designed to work without CSS or JavaScript, then enhanced. This ensures the core content is always accessible.
- Progressive enhancement — interactive features are layered on top of working HTML. If JavaScript fails, the page still works.
- Rigorous testing protocol — every component is tested with multiple screen readers (JAWS, NVDA, VoiceOver), keyboard-only navigation, and users with disabilities.
- Public accessibility statements — they publish detailed accessibility statements that document known issues and plans to fix them.
The lesson: Accessibility is not about checking boxes. GOV.UK treats it as a fundamental design constraint, not an afterthought. The result is pages that work well for everyone, load fast, and are resilient to failures.
Key Takeaways
- Accessibility is not a feature — it is a quality attribute that improves the experience for all users, not just those with disabilities
- WCAG 2.2 Level AA is the standard to meet: 4.5:1 contrast for text, keyboard navigability, screen reader support, and clear form design
- The curb cut effect means accessible design benefits everyone: high contrast helps in sunlight, keyboard nav helps power users, clear labels reduce form confusion
- Automated tools (axe, Lighthouse) catch only 30–50% of issues — manual keyboard and screen reader testing is essential
- Forms are where conversions happen, so form accessibility deserves the most attention: labels, error messages, input types, and required field indicators
- Respect user preferences: honor
prefers-reduced-motion, do not auto-play media, and let users control their experience - Build accessibility in from the start — retrofitting is far more expensive than doing it right the first time
Action Items
┌──────────┬──────────────────────────────────────────────────────┐
│ 💻 Dev │ ☐ Run axe DevTools on your landing page and fix all │
│ │ critical and serious violations │
│ │ ☐ Tab through the entire page with keyboard only — │
│ │ verify every interactive element is reachable and │
│ │ the focus indicator is visible │
│ │ ☐ Add a skip navigation link as the first focusable │
│ │ element on the page │
│ │ ☐ Test with VoiceOver (macOS) or NVDA (Windows) — │
│ │ can a screen reader user complete the signup flow? │
├──────────┼──────────────────────────────────────────────────────┤
│ 📋 PM │ ☐ Add WCAG 2.2 AA compliance to your acceptance │
│ │ criteria for all landing page work │
│ │ ☐ Include accessibility testing in your QA process │
│ │ — keyboard test and screen reader test at minimum │
│ │ ☐ Review your legal exposure — consult legal counsel │
│ │ on ADA/EAA compliance requirements for your market │
│ │ ☐ Publish an accessibility statement on your site │
│ │ documenting your commitment and contact info │
├──────────┼──────────────────────────────────────────────────────┤
│ 🎨 Design│ ☐ Audit all text and UI element colors against WCAG │
│ │ contrast requirements (4.5:1 text, 3:1 large text) │
│ │ ☐ Ensure touch targets are at least 24x24px (44x44 │
│ │ recommended) with adequate spacing │
│ │ ☐ Design focus states for every interactive element │
│ │ — do not rely on browser defaults being visible │
│ │ ☐ Create reduced-motion alternatives for animations │
│ │ and transitions │
└──────────┴──────────────────────────────────────────────────────┘