WordPress Accessibility Checklist for Designers and Site Owners

wordpress accessibility checklist for designers and site owners — use this guide to get practical, prioritized checks you can run yourself or hand to a developer. I’ve focused on UX-forward items that improve usability, reach, and conversion while avoiding needless technical detail. Read through the at-a-glance checklist, then follow the detailed sections and examples. Test regularly and hire help if fixes require theme or plugin changes or server-side work.

Table of contents

• Why Accessibility Matters For WordPress Sites
• Quick Accessibility Checklist (At A Glance)
• Visual Design Checks
• Structure and Navigation Checks
• Content and Media Checks
• Forms, Inputs and Interactive Elements
• Responsive and Mobile Accessibility
• Themes, Plugins and Code Practices
• Testing and Tools
• Launch, Maintenance and Regression Testing
• Examples and Before-After Fixes
• Implementation Plan and Prioritization
• FAQ
• When To Hire A Developer

Why Accessibility Matters For WordPress Sites

Who Should Use This Checklist

This checklist is for designers, site owners, content editors, and project managers who want a practical, prioritized route to improving accessibility on WordPress. Use it during design reviews, content edits, QA, or before launch. If you’re running an agency project, assign items to designer, editor, and developer roles below.

What Accessibility Means For WordPress

Accessibility means making your content and interactions perceivable, operable, understandable, and robust for people using assistive technologies, different devices, or alternative input methods. For WordPress sites that means choosing accessible themes and plugins, producing accessible content, and testing both automated and manually.

WCAG Overview And Levels (A, AA, AAA)

WCAG success criteria are the common baseline used worldwide. Most businesses aim for AA as a practical standard. This checklist focuses on AA-level outcomes that improve usability and reduce legal risk, but some organizations may require higher or lower targets depending on local rules.

Design Versus Development Responsibilities

Accessibility is a shared responsibility. Designers set color, typography, layout, and interaction patterns that make content discoverable and readable. Developers implement semantic markup, keyboard support, ARIA attributes when necessary, and ensure plugins and themes behave correctly. During design reviews, link visual decisions to implementation requirements so developers can deliver accessible HTML and scripts. For guidance on homepage UX and accessible CTAs, see our notes on homepage design for above- and below-the-fold elements in case you need to align copy and layout with accessibility goals: homepage UX and accessibility guidance.

Quick Accessibility Checklist (At A Glance)

Must-Fix High Priority Items

• Ensure meaningful alt text on all non-decorative images.
• Fix low color contrast for text and controls (AA: 4.5:1 for normal text).
• Confirm keyboard access to all interactive elements; visible focus indicators must be present.
• Use semantic headings (H1-H6) in logical order and ensure page has one primary heading.
• Label form fields and provide clear error messages and instructions.
• Provide captions/transcripts for important videos.

Good-To-Have Improvements

• Skip links to bypass repetitive navigation.
• Accessible ARIA roles for widgets when native controls aren't available.
• Short, descriptive link text for screen reader users.
• Accessible PDFs or HTML alternatives for documents.

Testing Frequency And Ownership

• Content editors: quick checks (contrast, alt text, headings) every content update.
• Designers: review accessibility during design sign-off and component library updates.
• Developers: run automated tests and manual keyboard/screen reader checks during QA and before deploy.
• Full audit: schedule every 6–12 months or after major redesigns.

Visual Design Checks

Color Contrast And Text Visibility

Check foreground and background contrast for body text, headings, links, and buttons. Use automated contrast tools during review and verify edge cases (hover, active, focus states). If you’re not coding, extract hex colors from designs and plug them into a contrast checker. For typography and sizing guidance that supports contrast and legibility, review our deeper typography notes: font sizes and typography guidance.

Font Sizes And Readability

Ensure base font size allows comfortable reading on desktop and mobile. Use relative units (rem/em) in code so users can magnify text without layout breaking. For designers, avoid very small body text and test long-form paragraphs for line length and spacing.

Focus Indicators And Visible States

Keyboard users must see which element is focused. Don’t remove or hide focus outlines. Design visible focus styles for links, buttons and form controls that meet contrast requirements. Focus should be clear during hover, active, and pressed states. These practices also help conversion by making CTAs discoverable—see our landing page design tips for overlap between conversion and accessibility: conversion-focused guidance.

Avoiding Color-Only Information

Do not rely on color alone to convey state or meaning. Add icons, patterns, or text labels to communicate status (errors, success, required fields).

Structure And Navigation Checks

Semantic Headings And Landmark Roles

Use headings (H1-H6) in logical order. Ensure each page has one clear primary heading. Add landmarks (header, main, nav, footer) via proper HTML or ARIA landmark roles so screen readers can navigate quickly.

Keyboard Navigation And Skip Links

Test full keyboard navigation: tab, shift+tab, enter, space, arrow keys where appropriate. Add a skip-to-main link that becomes visible on focus to let users bypass repetitive navigation.

Consistent Navigation And Breadcrumbs

Keep navigation structure consistent across pages. For complex sites, breadcrumbs help orientation and can be implemented in accessible markup inside the footer or header. For ideas on logical footer structure and which links to include or remove, check our footer design notes: footer structure tips.

Logical Tab Order

Tab order should follow visual order. Avoid using tabindex values except to integrate third-party widgets responsibly; arbitrary tabindex can confuse keyboard users.

Content And Media Checks

Alt Text For Images And Decorative Images

Provide meaningful alt text for informative images and empty alt (alt="") for decorative images so screen readers skip them. Alt text should describe the content and purpose succinctly, not repeat surrounding text.

Accessible Documents And PDFs

Prefer HTML over PDFs. If you must use PDFs, ensure they are tagged, have searchable text, and include a text alternative or summary on the page so users who can’t open the PDF still get the content.

Video Captions, Transcripts, And Audio Description

Provide captions for all video content and transcripts for audio. For critical visual information, consider audio description or an alternative text summary so blind users can access the same information.

Descriptive Link Text And CTAs

Link text should describe destination or action — avoid "click here." For blog and list layouts, descriptive links help screen reader users and improve clarity. For content layout ideas, see our blog layout guidance: accessible content layout tips.

Forms, Inputs And Interactive Elements

Labels, Placeholders, And Instructions

Use visible labels for form fields. Placeholders are not a substitute for labels — they disappear when typing and can be low contrast. Provide inline instructions or help text for complex inputs and associate them with fields via aria-describedby if needed. For contact forms and trust elements, review practical form design guidance: contact form best practices.

Error Messages, Validation, And ARIA Alerts

Provide clear, actionable error messages near the field and ensure errors are announced to screen readers using live regions or ARIA alerts. Describe what went wrong and how to fix it.

Accessible Buttons And Custom Controls

Use native controls where possible (button, input, select). If you implement custom controls, ensure keyboard operability, focus management, and correct ARIA roles and states.

CAPTCHAs And Accessible Alternatives

Avoid image-only CAPTCHAs. Use accessible alternatives such as time-based checks, honeypots, or accessible CAPTCHA services and always provide audio or text alternatives.

Responsive And Mobile Accessibility

Touch Targets And Spacing

Make touch targets large enough (recommend minimum 44px) and spaced to avoid accidental activation. Buttons, links, and form controls should be comfortably tappable on small screens.

Viewport And Zoom Behavior

Do not disable pinch-zoom. Ensure layouts work with browser zoom and that text reflows without loss of functionality.

Responsive Layout Considerations

Ensure content order and navigation remain logical when stacked vertically. Use responsive patterns that keep headings, main content, and CTA order consistent. For implementation tips on responsive WordPress design, refer to our mobile responsive guide: mobile responsive practices.

Testing On Mobile Screen Readers

Test with device screen readers (VoiceOver on iOS, TalkBack on Android) to confirm focus order, labels, and announcements behave as expected.

Themes, Plugins And Code Practices

Choosing An Accessible Theme

Select themes that advertise accessibility support and include semantic HTML, keyboard support, and test results. Review demos using keyboard and screen reader tests before committing.

Plugin Compatibility And Accessibility Flags

Evaluate plugins for accessibility claims and test them in your staging environment. Some plugins add complex widgets (carousels, sliders, builders) that need careful accessibility review.

Avoid Problematic Patterns (Popups, Autoplay)

Modal dialogs and popups must trap and return focus correctly. Avoid autoplaying audio or video without controls and a visible pause/stop option.

Practical ARIA Use And When To Avoid It

Prefer native HTML semantics. Use ARIA only when necessary and ensure it reflects the control state. Incorrect ARIA can harm accessibility; consult developer guidance when applying ARIA roles.

Testing And Tools

Automated Tools (Lighthouse, axe, WAVE)

Run automated scanners for quick coverage but do not rely on them alone. They surface obvious issues like contrast and missing alt attributes but miss many interaction and semantics problems. Use a combination of tools during QA.

Manual Tests (Keyboard, Screen Readers Like NVDA/VoiceOver)

Manual testing is essential. Keyboard-only navigation and basic screen reader runs (NVDA on Windows, VoiceOver on macOS/iOS) reveal real-world problems automated tools miss.

Browser And Device Matrix

Test on Chrome, Firefox, Safari across desktop and mobile, and include at least one screen reader on each platform. Consider testing on low-bandwidth and slow CPU devices to verify performance and accessibility tradeoffs.

User Testing With People Who Use Assistive Tech

When possible, include real users with disabilities in testing. Their feedback uncovers practical barriers and helps prioritize fixes.

Launch, Maintenance And Regression Testing

Accessibility Statement And Feedback Channel

Publish a short accessibility statement that explains your commitment, known limitations, and how users can report issues. Provide a feedback channel and acknowledge reports promptly.

Monitoring And Regression Tests

Add automated checks to your CI or QA routines to catch regressions. Keep a simple manual checklist for design and content updates so editors don’t introduce new barriers.

Staging, Backups And Rollback Steps

Test accessibility fixes on staging and back up before deploying. If a fix causes regressions, roll back and refine. Always document changes and test again after deployment.

When To Hire A Developer

Stop DIY when fixes require theme or plugin changes you can’t safely implement, when ARIA roles or script-driven focus management is needed, or when an accessibility audit identifies systemic issues. If you need professional help implementing fixes, you can Request a WordPress website quote for design and development support.

Examples And Before-After Fixes

Small Fix Examples (Contrast, Alt Text)

• Contrast: change link color from light grey (#a9a9a9) on white to a darker blue that meets 4.5:1 ratio.
• Alt text: replace img alt="team" with alt="Three-person product team collaborating around a laptop" for context.

Code Snippet: Skip Link And Landmarks

Implement a visible skip link and landmark elements in your template so keyboard users can jump to main content quickly. Add a skip link visible on focus that points to an element with role="main" or id="main".

Common Theme Issues And How To Patch Them

Common issues include removed focus outlines, inaccessible sliders, and poor heading structure. Patches range from CSS to restore focus styles, to replacing slider plugins with accessible alternatives, or editing templates to output semantic headings.

Implementation Plan And Prioritization

Two-Week Implementation Checklist

1. Week 1: Run automated scans and fix high-priority contrast, missing alt attributes, and labeling issues. Content editors check top 10 pages for headings and alt text.
2. Week 2: Developer implements keyboard fixes, skip links, and focus styles; test contact forms and media captions.
3. End of sprint: run manual keyboard and screen reader checks, and deploy to staging for final verification.

Prioritization Matrix: Impact Vs Effort

• High impact / low effort: alt text, contrast fixes, visible labels, and simple focus styles — tackle first.
• High impact / high effort: redesigns, major theme/plugin replacements — plan as part of a larger project.
• Low impact / low effort: decorative image cleanup, minor ARIA improvements.

Assigning Tasks For Designers, Content Editors, And Developers

• Designers: set accessible color palette, focus styles, and component specs.
• Content editors: add alt text, use descriptive links, verify headings.
• Developers: ensure semantic markup, implement skip links, fix keyboard traps, and integrate captioning where needed.

FAQ

What is the difference between accessibility and usability for a WordPress site?

Accessibility ensures people with disabilities can use your site; usability ensures anyone can use it easily. They overlap: accessible sites are usually more usable. Accessibility has technical criteria; usability is broader and can include persuasion and conversion goals.

Which WCAG level should my WordPress site aim for?

Most organizations aim for WCAG 2.1/2.2 AA as a practical baseline. Legal or sector requirements may demand different levels—check local rules and consult legal advice if necessary.

How do I test color contrast on my site without coding knowledge?

Extract hex codes from your design or use a browser extension or online contrast checker to compare foreground and background colors. Focus on body text, headings, and controls first.

Do I need a special WordPress theme to be accessible?

No special theme is required, but choose themes that advertise accessibility support and use semantic HTML. Even accessible themes need content and plugin-level checks.

How can I check that my contact forms are accessible?

Confirm every field has a visible label, instructions are clear, error messages are descriptive and tied to fields, and the form is usable with keyboard only. Test with a screen reader to ensure announcements are meaningful.

What are simple keyboard-accessibility tests I can run?

Try navigating the site using Tab, Shift+Tab, Enter, and arrow keys. Ensure all interactive elements are reachable, focus is visible, and modals trap and restore focus correctly.

Which automated tools should I use and what do their results mean?

Use tools like Lighthouse, axe, and WAVE for quick checks. They flag clear issues (contrast, missing alt) but will not catch all accessibility problems. Treat automated results as a starting point for manual testing.

How do I write good alt text for images used on my WordPress site?

Describe the image purpose briefly and avoid redundancy with nearby text. For decorative images, use an empty alt attribute (alt="") so assistive tech skips them.

Are captions and transcripts required for videos on my site?

Captions are required for users who are deaf or hard of hearing to access spoken content. Transcripts are helpful for search and users who prefer text. For important content, provide both when possible.

How often should I run accessibility tests and audits?

Automated checks can run as part of regular QA. Manual audits are recommended every 6–12 months and after major redesigns or functionality changes.

What should an accessibility statement include for a WordPress site?

State your commitment, the scope of the statement (which parts of the site it covers), any known issues, how users can report problems, and contact details for feedback.

When should I stop DIY troubleshooting and hire a developer?

Hire a developer when accessibility fixes require theme or plugin code changes, ARIA and JavaScript focus management, or when an audit finds systemic issues beyond content edits. If you prefer someone to implement prioritized fixes, you can Request a WordPress website quote.

When To Hire A Developer

If fixes involve template edits, component library changes, complex ARIA or script behavior, or plugin replacements, bring in a developer with accessibility experience. Professional help reduces risk, ensures proper staging/backups, and delivers robust, testable solutions.

Next step: If you want help turning this checklist into a prioritized plan or need an audit and fixes, Request a WordPress website quote and we’ll provide a scope and timeline tailored to your site.