Landing Page Accessibility Checklist for Service Businesses

A landing page accessibility checklist for service businesses covers the structural, visual, and interactive elements that make a page usable by everyone before design and build begins. Getting this right before you write a line of code saves rework, improves clarity for all users, and avoids the costly discovery that your page fails basic usability checks after launch. The core areas: semantic structure, color contrast, keyboard navigation, form labeling, focus states, alt text, and motion controls. None of this requires a specialist. It requires deliberate decisions made early.

Why accessibility belongs before design, not after

Most teams treat accessibility as a cleanup task. They finish the design, build the page, then run it through a tool that surfaces 30 problems they now have to fix. That’s backwards.

Accessibility decisions made at the structure stage cost almost nothing. The same decisions made after build can mean significant rework: changing heading hierarchies, rebuilding form components, replacing hard-coded colors, adding skip links that should have been there from the start.

This checklist is for service businesses who want to catch those decisions before design begins. You don’t need to be a WCAG expert. You need a clear list of things to verify or decide before the first Figma frame is opened.

Accessibility isn’t a feature you add at the end. It’s a set of design decisions you make or skip at the beginning.

What this checklist actually covers

The Web Content Accessibility Guidelines (WCAG) are the technical reference. But for most service business landing pages, the practical scope is narrower than the full spec.

You’re not building a complex web application. You’re building a page that explains what you do, builds trust, and gets someone to take an action. That means the checklist concentrates on a few specific areas:

Heading structure and semantic HTML
Color contrast for text and interactive elements
Keyboard navigability through the page and form
Focus indicators that are visible and logical
Form labels and error messages
Image alt text
Motion and animation controls
Touch target sizing for mobile

Each section below covers what to decide or verify before design starts.

Landing page accessibility checklist for service businesses: structure and content

Heading hierarchy

Decide your heading structure before designing. An H1 for the page title, H2 for major sections, H3 for subsections inside those. Don’t choose heading levels for visual size. That’s a CSS decision, not a structure decision.

Checklist:

One H1 per page, used for the primary headline
H2s used for each major section (problem, solution, proof, pricing, FAQ, CTA)
No skipped levels (H1 to H3 with no H2)
Section headings are descriptive, not clever

If you’re still figuring out your page sections, the landing page above-the-fold checklist covers how to structure what comes first. Heading decisions flow from that structure.

Meaningful link text

Every link needs to make sense when read out of context. Screen readers pull all links from a page into a list. If your links say “click here” or “read more,” that list is useless.

Checklist:

No generic anchor text (“click here,” “learn more,” “this page”)
Links describe their destination (“View the landing page service,” “Read the FAQ”)
Repeated links to the same destination use consistent anchor text

Reading order and DOM order

Visual design can reorder elements on screen using CSS. But the DOM order, the order elements actually appear in the HTML, controls what screen readers and keyboard users experience.

Checklist:

DOM order follows logical reading sequence
Visual reordering (CSS flex/grid order) is documented and reviewed against DOM order
Hero content comes before secondary content in the DOM, not just visually

Landing page accessibility checklist for service businesses: visual design decisions

Color contrast

Landing page accessibility checklist for service businesses: visual design decisions

This is one of the most common failures on service landing pages. Light gray text on a white background looks clean. It’s also often unreadable for users with low vision.

WCAG 2.1 defines minimum contrast ratios:

Normal text (under 18pt): 4.5:1 ratio
Large text (18pt+ or 14pt bold): 3:1 ratio
UI components and focus indicators: 3:1 ratio

Checklist:

Primary body text passes 4.5:1 against background
Heading text passes 3:1 minimum (aim for 4.5:1)
Button labels pass 4.5:1 against button background
Placeholder text in forms passes 4.5:1 (often fails)
Contrast decisions are documented before visual design starts, not after

A free tool like WebAIM’s Contrast Checker makes this fast to verify.

Color as the only signal

Red for errors. Green for success. These work if the user can distinguish colors. If not, the page conveys nothing.

Checklist:

Error states use text labels or icons, not just red borders
Required fields are marked with text (“required”) not just color
No information is conveyed by color alone

Text sizing and zoom

Text set in fixed pixel units breaks when a user overrides font sizes in their browser.

Checklist:

Body text uses relative units (rem, em), not fixed pixels
Page layout doesn’t break at 200% zoom
Text doesn’t overflow containers at larger sizes

Typography and readability

Contrast ratios pass the math, but typography choices affect readability beyond that. Thin font weights, tight line spacing, and very long line lengths all create friction for users with dyslexia or cognitive load issues.

Checklist:

Body font weight is at least 400 (avoid 300 or lighter for body copy)
Line height is at least 1.5 for body text
Line length is between 60 and 80 characters for comfortable reading
Justified text is avoided (it creates uneven word spacing that’s harder to track)
Font choice is legible at small sizes, not just decorative

These aren’t strict WCAG requirements at AA level, but they’re the difference between a page that technically passes and one that actually reads well for everyone.

Landing page accessibility checklist for service businesses: interactive elements

Some users don’t use a mouse. They navigate with a keyboard, moving through focusable elements in DOM order using Tab and Shift+Tab. Every interactive element needs to be reachable this way.

Checklist:

All links are focusable and activatable with Enter
All buttons are focusable and activatable with Enter or Space
Form fields are focusable and usable with keyboard only
Modals or drawers trap focus while open and release it on close
Navigation menus are keyboard-operable

Focus indicators

When a user tabs to an element, the browser adds a visible focus indicator. Many designs suppress it with outline: none because it “looks bad.” That decision makes the page unusable for keyboard users.

Checklist:

Focus indicators are never suppressed without a visible replacement
Custom focus styles have at least 3:1 contrast against surrounding colors
Focus order matches the visual layout logically

Forms

This is where most service business landing pages fail hardest. Forms built quickly without labels, with placeholder-only hints, or with unclear error messages break for screen reader users and cause friction for everyone.

The landing page form checklist covers what to include in your form before you build it. From an accessibility angle, add these checks:

Checklist:

Every input has a visible <label> element associated via for/id, not just placeholder text
Placeholder text is not used as a substitute for labels
Required fields are marked with text, not just a color or asterisk without explanation
Error messages are specific (“Email address is required,” not “Invalid input”)
Errors are associated with the relevant field, not just displayed near the top
Success confirmation is conveyed via text, not just a color change

Buttons and CTAs

Checklist:

Buttons have descriptive text (“Get a quote” not “Submit”)
Icon-only buttons have an accessible label (aria-label or screen-reader text)
Button touch targets are at least 44x44 CSS pixels on mobile
Disabled buttons explain why they’re disabled (or better, are not disabled at all)

Landing page accessibility checklist for service businesses: images and media

Alt text for informational images

Checklist:

Every <img> element has an alt attribute
Decorative images have empty alt="" so screen readers skip them
Informational images have descriptive alt text that conveys the same meaning
Charts or graphs have alt text or an adjacent text description
Logos used as links have alt text describing the destination (“Dee Agency homepage”)

Video and motion

Checklist:

Videos have captions (auto-generated captions need human review)
No content auto-plays with sound
Animations can be paused, or respect the user’s prefers-reduced-motion setting in CSS
Parallax and large scroll-triggered animations have a reduced-motion fallback

The CSS for this is straightforward:

@media (prefers-reduced-motion: reduce) {
 * {
 animation-duration: 0.01ms !important;
 animation-iteration-count: 1 !important;
 transition-duration: 0.01ms !important;
 scroll-behavior: auto !important;
 }
}

That single block disables most animation for users who have requested it in their OS settings.

Landing page accessibility checklist for service businesses: page-level decisions

When a keyboard user loads a page, they have to tab through every nav link before reaching the main content. A skip link at the top of the page lets them jump directly to the content.

Checklist:

A “Skip to main content” link is the first focusable element on the page
The skip link is visible on focus (it can be hidden visually until focused)
The target is the <main> element or a logically equivalent container

Language declaration

Checklist:

The <html> element has a lang attribute set to the correct language code (for example, lang="en")
If sections of the page are in a different language, those sections have their own lang attributes

Page title

Checklist:

The <title> element is descriptive and unique to the page
It follows the pattern: “Page topic | Brand name”

ARIA landmarks and roles

ARIA landmarks help screen reader users understand the structure of the page and jump between regions quickly. For a landing page, this is mostly about using the right HTML elements, which carry implicit ARIA roles automatically.

Checklist:

The page uses semantic HTML elements: <header>, <main>, <footer>, <nav>, <section>, <article> where appropriate
There’s one <main> element per page
Navigation regions use <nav> with a descriptive aria-label if there are multiple nav elements
Generic <div> and <span> elements are not used where semantic elements would work
Custom interactive widgets (carousels, accordions, tabs) have appropriate ARIA roles and states

Most of this comes for free if you use semantic HTML from the start. The problems usually appear when everything is built as nested divs with click handlers added via JavaScript.

What to do with this checklist before design starts

Practically, here’s how to use this list. Before any visual design or wireframing:

Confirm heading structure with whoever is writing the copy
Document color palette decisions and run contrast checks before locking brand colors
Decide form field structure and labeling conventions
Confirm motion/animation scope and whether reduced-motion will be supported
Agree on link text conventions with whoever writes the CTAs
Decide which images are informational and which are decorative, so alt text gets written as content rather than retrofitted

This takes maybe two hours at the start of a project. Skipping it and finding the issues after build takes much longer.

If you’re also thinking about how the page performs technically and whether it converts, there’s overlap worth reviewing. The what makes a landing page convert piece covers the structural decisions that drive both usability and conversion. Most of them align with accessibility anyway: clear headlines, visible CTAs, readable copy.

Need help with landing page design and build? Dee Agency’s $3,000 flat-fee landing page service covers structure, accessibility, and conversion from the start. Share your project details.

Tools to validate before launch

These aren’t replacements for manual review, but they catch the obvious automated issues quickly:

axe DevTools, browser extension for automated accessibility scanning
WAVE Web Accessibility Evaluation Tool, visual overlay showing errors and warnings
WebAIM Contrast Checker (linked above), manual color contrast verification
Built-in browser keyboard testing, literally unplug your mouse and navigate the page

Automated tools are useful, but they miss many issues; research from Deque found manual review still catches problems automated scans do not. Keyboard testing, screen reader checks, and human review are still necessary.

Manual testing doesn’t need to be elaborate. Tab through the entire page without touching your mouse. Check that every interactive element gets focus, that the focus indicator is visible, and that you can activate buttons and submit the form using only the keyboard. That alone surfaces many practical failures on a typical service landing page.

If you want to go further, VoiceOver on macOS and NVDA on Windows are both free screen readers. Running through the page with one gives you a direct experience of what assistive technology users actually encounter.

Frequently asked questions

Does my landing page need to be WCAG compliant?

Accessibility requirements vary by country, industry, and organization size. The Americans with Disabilities Act has been interpreted to apply to websites in various court cases, but there’s no single universal compliance mandate for all private service businesses. The practical answer: building to WCAG 2.1 AA standards is the clearest baseline, and the decisions required are mostly good usability decisions anyway. For legal guidance specific to your situation, consult a lawyer.

How do I check if my landing page is accessible?

Start with a browser extension like axe DevTools or run the page through WAVE. Then manually tab through every interactive element without using your mouse. Run all text colors through a contrast checker. These three steps surface the majority of practical issues on most service landing pages.

Does accessibility affect landing page conversion?

Accessibility improvements tend to improve usability for all users, not just those with disabilities. Clearer form labels reduce errors. Visible focus states reduce confusion. Sufficient contrast improves readability. The relationship isn’t a direct one-to-one, but these decisions generally help rather than hurt conversion.

What’s the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 was published in October 2023 and adds nine new success criteria, primarily around focus appearance, target size, and removing authentication friction. WCAG 2.1 AA remains the most common compliance baseline. If you’re building a new page, checking 2.2 AA is worth the incremental effort.

Accessibility overlay widgets are controversial. Research from the accessibility community consistently shows they don’t reliably fix accessibility problems and can introduce new ones. Building accessibility into the page from the start is more reliable than patching it with a third-party script.

How long does it take to build an accessible landing page?

When accessibility decisions are made before design starts, the incremental time is minimal. The checklist above adds a couple of planning hours upfront. Retrofitting a finished page with poor accessibility can take significantly longer depending on how much needs to change.

Ready to build an accessible, conversion-focused landing page? Dee Agency’s Landing Page Design & Build service covers structure, design, and build for $3,000, flat fee. Start the conversation.

Why accessibility belongs before design, not after

What this checklist actually covers