How to Design an Accessible Website: Step by Step

A customer emails to say they can’t read your menu. A screen reader user bounces off your checkout page in ten seconds. Most website owners discover an accessibility problem this way – through a frustrated visitor who can’t use the site.

Here’s what actually works: designing an accessible website means moving through seven ordered steps. Fix your color contrast first. Build a logical heading structure. Enable full keyboard navigation. Write meaningful alt text. Make your forms work for everyone. Choose readable typography and spacing. Then test with real tools and real people, before you call the design finished.

I built this checklist from years of client work: custom WordPress themes, UI/UX redesigns, and small business sites that never had a developer on staff to catch accessibility problems. None of it is theoretical. Each step below includes the mistake I see most often, the fix, and the quick check I run on live projects.

Step 1: Sufficient Color Contrast Makes Text Readable

Color contrast is the ratio between your text color and its background. The WCAG 2.2 standard, maintained by the W3C, sets practical minimums:

• Normal body text (under ~18pt): 4.5:1
• Large text (18pt+/24px+, or bold 14pt+): 3:1
• Buttons, form outlines, and other UI elements: 3:1

The mistake appears on almost every client site I audit: light gray text (#999999 or similar) on a white or off-white background. It looks clean in Figma and modern on screen. It fails the 4.5:1 minimum almost every time, and it’s usually the single biggest reason a polished site scores poorly on an accessibility audit.

Quick check: Open WebAIM’s Contrast Checker, enter your hex codes, and read the pass/fail result. Do this before you finalize your color palette, not after the site launches. It takes thirty seconds.

Step 2: Organize Content With Logical Heading Levels

A semantic heading structure means your H1, H2, and H3 tags describe the actual outline of your content, not just the largest text on the page. Screen reader users jump between headings the way sighted users skim a page, so a broken hierarchy is disorienting.

Use this pattern:

1. One H1 per page: your main title.
2. H2 for each major section.
3. H3 for subsections within an H2, never skipping from H1 straight to H3.
4. Visual size and heading level should match. If something needs to look smaller, use CSS. Don’t pick an H4 tag just because it renders at your preferred font size.

I’ve audited sites where a designer chose an H4 purely to match a mockup’s font size, skipping H2 and H3 entirely. Sighted visitors never noticed. A screen reader user navigating by heading jumps from page title straight into what sounds like a deeply nested subsection. Think of it like a table of contents: H1 is the book title, H2s are chapters, H3s are sections within chapters.

Step 3: Make Every Control Keyboard-Accessible

Keyboard navigation means every interactive element – links, buttons, menus, form fields – can be reached and activated using only Tab, Shift+Tab, Enter, and Space, with no mouse at all. This matters for people with motor impairments, people using switch devices, and keyboard power users.

Two elements make or break this step:

• Tab order should follow the visual and logical reading order of the page, left to right, top to bottom. If CSS reorders elements visually without matching the HTML order, keyboard users get a confusing jump around the page.
• Focus indicators show which element currently has keyboard focus. A visible outline or highlight proves to a sighted keyboard user exactly where they are on the page.

I’ve found more than one client site where the theme’s default focus outline was stripped entirely – usually by a CSS reset or plugin that added outline: none for a "cleaner" look, with nothing put in its place. Restoring a visible focus state was step one of that rebuild, before touching anything else.

Every WordPress theme needs a skip-to-content link: a hidden link, visible only on keyboard focus, that lets keyboard and screen reader users jump past the header and navigation menu straight to main content. Without it, keyboard users tab through every navigation item on every page just to reach the article.

Try it yourself: Set aside your mouse and tab through your entire homepage using only Tab and Enter. Can you reach the menu, open dropdowns, fill out forms, and submit them? If you get stuck, so will your visitors.

Step 4: Write Alt Text That Describes What Matters

Alt text is a written description attached to an image in the HTML. Screen readers read it aloud, and it displays if the image fails to load.

First, decide whether an image is decorative or informative:

• Decorative images (background textures, purely stylistic dividers, stock photos that add nothing) should have an empty alt attribute (alt="") so screen readers skip them entirely.
• Informative images (product photos, charts, screenshots, named portraits) need alt text that conveys what a sighted user gets from looking at the image.

Write as if describing the image to someone on the phone, skip phrases like "image of" or "picture of" – screen readers already announce it’s an image – and be specific about what makes this image matter on this page:

Example	Result
alt="image1234.jpg"	Bad: meaningless filename
alt="photo"	Bad: technically present, functionally useless
alt="woman smiling"	Weak: true but no context
alt="Client reviewing finished WordPress theme on laptop, giving thumbs up"	Good: specific and contextual

Where this breaks down on real sites: product galleries where every image gets the same generic alt text, or WordPress media libraries where filenames get auto-populated and nobody fixes them. In the WordPress block editor, the Image block has a dedicated Alt Text field in block settings. Fill it in on every image, not just new uploads.

Step 5: Make Forms and Buttons Easy to Use

An accessible form gives every input field a visible, programmatically connected label. Errors are announced in plain language. Clickable elements are large enough and clear enough to use without guessing.

Here’s what that means in practice:

• Labels must be visible and linked in code using the <label for=""> attribute tied to the input’s id, not just placeholder text that disappears as soon as someone starts typing. Placeholder-only forms look fine in a demo and fall apart when a user with attention difficulties needs to double-check what a field was asking for.
• Error identification tells the user exactly what went wrong and how to fix it, not just turning a field’s border red. "Please enter a valid email address" works. A red outline with no text does not.
• Buttons and tap targets should be at least 44×44 pixels, with enough space between adjacent buttons so someone with limited fine motor control doesn’t accidentally trigger the wrong one.
• Icon-only buttons (a magnifying glass for search, a hamburger menu, an X to close a modal) need an ARIA label like aria-label="Search" or aria-label="Close menu", since there’s no visible text for a screen reader to read.

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that adds information for screen readers when visible text can’t do the job alone. The rule I follow: use ARIA labels only where there is no visible text equivalent, like icon buttons. Don’t use ARIA to fix a structural problem that semantic HTML would solve better, like using a styled <div> instead of an actual <button> element.

Step 6: Build Readable Typography and Spacing

Readable typography is a design decision, not an afterthought. It affects far more visitors than people assume, including anyone reading on a small screen, in bright light, or simply tired at the end of a long day.

Build every project around these minimums:

• Body text: at least 16px (roughly 1rem), never smaller for primary reading content.
• Line-height: at least 1.5 times the font size for body paragraphs, giving lines enough breathing room that eyes don’t lose their place.
• Letter and word spacing: avoid cramming text tightly. WCAG’s text spacing criteria recommend content should still work if users increase letter and line spacing through their browser or assistive tool.
• Responsive reflow: your layout should hold together with no horizontal scrolling or clipped content when a user zooms the browser to 200%. Test this manually – it takes two minutes and reveals problems fast.
• Avoid justified text, which creates uneven gaps between words that are harder to track visually. Use restraint with all-caps styling, since long strings of capitals are measurably slower to read.

If your design leans heavily on tiny captions or dense paragraphs squeezed into narrow columns, fix it before launch, not after a complaint arrives.

Step 7: Test With Real Tools and Real People

Testing is where most guides end without actually doing it. Here’s the exact sequence I run on every client project:

1. Automated scanner. Run WAVE, axe DevTools, or Google’s Lighthouse accessibility audit (built into Chrome DevTools). These catch missing alt text, contrast failures, and missing form labels fast. They won’t catch everything – treat a clean report as a floor, not a finish line.
2. Keyboard-only navigation pass. Unplug the mouse again and tab through every page template: homepage, blog post, product page, contact form, checkout if applicable. Confirm focus is always visible and tab order makes sense.
3. Screen reader spot check. Turn on a screen reader – NVDA (free, Windows) or VoiceOver (built into macOS and iOS) – and listen to your homepage and one key conversion page. Does the heading structure make sense? Does every button announce what it does?
4. Real user feedback. Automated tools and a solo screen reader test catch a lot, but they don’t replace feedback from someone who relies on assistive technology every day. Where budget allows, this validation layer matters most.

Three Changes That Solve Most Problems

Limited time and budget is real. If a full audit isn’t possible right now, prioritize in this order: fix color contrast on primary text and buttons, restore visible focus indicators if a plugin or theme has stripped them, and add proper alt text to every image on your homepage and top landing pages. Those three changes alone resolve the majority of accessibility complaints I see.

Accessibility Built Into Your WordPress Theme

Every step maps directly onto decisions in the WordPress block editor. Heading blocks let you set H2, H3, and H4 levels explicitly, so there’s no excuse for skipping levels for a font-size shortcut. The Image block has a dedicated alt text field. Button and Group blocks inherit your theme’s focus and color styles, which means contrast and focus visibility get checked at the theme level, not just per page.

The real failure point across dozens of WordPress builds isn’t the block editor – it’s inherited theme CSS. A theme customized from a marketplace template often carries baked-in low-contrast text colors or a global outline: none rule from years ago that nobody thought to remove. That’s exactly why accessibility has to be a design decision made at theme-build stage, not bolted on after launch.

If you’re rebuilding a theme with these principles in mind, or converting a Figma design into a WordPress site that respects contrast, structure, and keyboard access from day one, that’s the work that actually changes how sites convert and perform.

At Ivory Miracle, this checklist isn’t a marketing point – it’s the actual list I run through on every project through our web design and UI/UX services. Accessibility and good design aren’t competing goals. A site built with genuine attention to contrast, structure, and navigation almost always converts better, which is really the same underlying discipline behind designing a website that works.

Accessibility Checklist for Project Launch

A condensed version of everything above – the same list I run through before calling any client project finished:

• Body text contrast is at least 4.5:1; large text and UI elements are at least 3:1
• One H1 per page, no skipped heading levels
• Every interactive element is reachable and usable by keyboard alone
• Focus indicators are visible and never removed without a replacement
• A skip-to-content link exists and works
• Every informative image has specific, functional alt text
• Decorative images have an empty alt attribute
• Every form field has a visible, programmatically linked label
• Form errors are described in text, not color alone
• Icon-only buttons have ARIA labels
• Body text is 16px minimum with 1.5x line-height
• Layout holds together at 200% browser zoom
• Site passes an automated checker, a keyboard pass, and a screen reader spot check

WCAG Success Criteria Referenced in This Guide

Criterion	Plain-language rule	Why it matters
1.1.1 Non-text Content	Images need alt text or an empty alt for decorative ones	Screen readers need something to announce, or nothing at all for decoration
1.4.3 Contrast (Minimum)	4.5:1 for normal text, 3:1 for large text	Low vision and color blindness make low-contrast text unreadable
1.4.11 Non-text Contrast	3:1 for UI components and graphical objects	Buttons and form outlines need to be visible
2.1.1 Keyboard	All functionality available via keyboard	Not everyone can use a mouse or touchscreen
2.4.3 Focus Order	Focus order follows a logical sequence	Confusing tab order disorients keyboard users
2.4.6 Headings and Labels	Headings and labels describe topic or purpose	Screen reader users navigate by heading and label text
3.3.1 Error Identification	Errors are described in text	Color alone doesn’t communicate to everyone

For full criterion language, see the WCAG 2.2 specification maintained by the W3C.

Frequently Asked Questions

Is WCAG legally required for my website?

WCAG itself is a technical standard, not a law. Various countries and jurisdictions reference WCAG when defining what "accessible" means under broader civil rights or anti-discrimination law, but whether a specific requirement applies to your site depends on your location, industry, and audience. Consult a qualified attorney if legal exposure is a concern.

What is the difference between WCAG and ADA?

WCAG is a technical standard published by the W3C describing how to make web content accessible. The Americans with Disabilities Act (ADA) is U.S. civil rights law. The ADA doesn’t spell out technical web specifications itself; U.S. courts and the Department of Justice have referenced WCAG as a benchmark in web accessibility cases, but they remain two separate things.

What are the core principles of accessible design?

Accessible design rests on four principles known as POUR: Perceivable (content must be presentable in ways users can perceive), Operable (interface elements must be usable), Understandable (content and operation must be clear), and Robust (content must work reliably across current and future assistive technologies). Every step in this guide maps back to one or more of these principles.

Should I follow WCAG 2.1 or WCAG 2.2?

Follow WCAG 2.2, published by the W3C in October 2023, since it’s the current version and backward-compatible with 2.1, meaning anything that passes 2.2 also satisfies 2.1’s requirements.

What color contrast ratio do I need?

Normal body text needs a contrast ratio of at least 4.5:1 against its background. Large text (roughly 18pt or 14pt bold and up) needs at least 3:1. Buttons, form borders, and other meaningful UI graphics also need at least 3:1 against adjacent colors.

Do I need alt text on every image?

Every informative image needs descriptive alt text. Purely decorative images should have an empty alt attribute (alt="") instead, so screen readers skip them.

What’s the easiest first step?

Run your homepage through a free automated checker like WAVE, then fix whatever contrast and missing alt text issues it flags. Those two categories are usually the fastest to fix and most common on existing sites.

Moving Forward With Accessible Design

Accessible design isn’t a separate checklist bolted onto "real" design work – it’s part of the same craft as good typography, clear navigation, and thoughtful spacing. Sites that handle it well tend to be better designed across the board, easier to scan, easier to navigate, and easier to trust.

If you’re rebuilding a theme with these principles in mind, or converting an existing design into a WordPress site that respects contrast, structure, and keyboard access from day one, start with Step 1, work through the list in order, and test before you launch, not after someone tells you it’s broken.

Sources

• WCAG 2.2 Specification, W3C
• Understanding Success Criterion 1.4.10: Text Spacing, W3C
• Guidance on Web Accessibility and the ADA, ADA.gov
• WebAIM Contrast Checker, WebAIM
• WAVE Web Accessibility Evaluation Tool, WebAIM
• axe DevTools, Deque Systems
• Lighthouse Accessibility Audits, Chrome Developers
• NVDA Screen Reader, NV Access