--- title: "WordPress Block Accessibility: The Practical Checklist" date: 2026-03-10 author: "Imtiaz Rayhan" featured_image: "https://wpblocksuite.com/wp-content/uploads/2026/08/featured-wordpress-block-accessibility-checklist.png" categories: - name: "Block Editor" url: "/blog/category/block-editor.md" --- # WordPress Block Accessibility: The Practical Checklist WordPress block accessibility depends on the rendered combination of content, blocks, plugins, and theme. Test the public page using keyboard, zoom, screen readers, and automated tools. No editor badge can guarantee conformance. Real interaction reveals the remaining barriers. ## Start with the rendered outcome The block editor stores content and settings. The frontend combines many independent layers. A sound block can become inaccessible through theme CSS. Good content can enter a broken widget. Inspect the final public experience. Do not stop after editor checks. ## Use WCAG 2.2 as reference WCAG organises accessibility under perceivable, operable, understandable, and robust principles. The [WCAG 2.2 Recommendation](https://www.w3.org/TR/WCAG22/) defines testable success criteria and conformance requirements. This checklist supports review. It does not replace applicable legal or specialist advice. ## Define an accessibility target Name the standard and conformance level your project targets. Document any additional requirements. Use the same target across design, development, content, [procurement](https://wpblocksuite.com/blog/wordpress-plugin-procurement-checklist/), and testing. A vague promise produces inconsistent decisions. A documented target creates accountable review. ## Assign responsibility by layer Editors own headings, link text, alternatives, tables, and media descriptions. Theme teams own landmarks, focus styling, responsive behaviour, and many global controls. Plugin teams own custom interactions. Site owners still own final selection and validation. ## Set the page language The page needs an accurate language declaration. Themes normally render this from site settings. Mark meaningful language changes inside content where needed. Pronunciation can otherwise become confusing. Test multilingual templates. Do not assume translated content changes the document declaration automatically. ## Give every page a useful title The browser title should identify the page and site. Duplicate titles hinder orientation. WordPress themes and SEO plugins often share this responsibility. Check the rendered title element. Do not confuse the title element with the visible H1. Both need deliberate wording. ## Check landmark structure Headers, navigation, main content, complementary regions, and footers support quick orientation. The theme usually owns landmarks. Custom blocks should not create confusing duplicate main regions. Inspect the accessibility tree. Visual containers do not always become meaningful landmarks. ## Provide bypass navigation Keyboard users need a way past repeated navigation. A functional skip link commonly helps. The target must receive appropriate focus or navigation. Sticky headers must not cover it. Test skip links on every template. Hidden controls should become visible when focused. ## Use one clear H1 A clear H1 identifies the main page topic. Theme templates may render it automatically. Do not add a decorative duplicate inside content. Inspect the public heading outline. Special templates can justify different patterns. Keep hierarchy understandable and consistent. ## Build logical heading levels Headings describe content hierarchy. Choose levels by structure, not appearance. Do not jump levels merely for smaller text. Adjust typography through styles. Review headings through List View and the frontend outline. Reusable patterns can introduce surprises. ## Write descriptive links Link purpose should remain understandable within context. Repeated “learn more” links create ambiguity. Name the destination or action. Avoid pasting raw URLs when readable text works. Opening new windows needs a genuine reason and clear warning. Preserve expected browser behaviour. ## Use buttons for actions Links navigate. Buttons perform actions. Styling should not reverse those semantics. Button names must explain outcomes. An icon-only control needs an accessible name. Disabled states need understandable alternatives. Do not rely on faded colour alone. ## Test all functions by keyboard Every interactive function should work without a mouse. Use Tab, Shift+Tab, Enter, and Space. Complex widgets may support additional keys. Their behaviour should follow established patterns. Post 089 will cover the complete keyboard workflow. This checklist confirms release coverage. ## Prevent keyboard traps Users must enter and leave every component using expected keys. Focus cannot become stuck. Test embeds, sliders, dialogs, menus, and code editors carefully. Third-party content still matters. If unusual exit keys are required, explain them. Simpler established behaviour is safer. ## Preserve logical focus order Keyboard focus should follow content meaning and visual order. CSS rearrangement can create divergence. Avoid positive `tabindex` values. They create brittle manual sequences. Test responsive layouts separately. Mobile reordering can change visual expectations. ## Keep focus visible Focused controls need a visible indicator. Removing outlines without replacement creates a serious barrier. Test indicators against every background and state. Theme colours can weaken contrast. Do not limit strong focus styles to editors. Frontend users need them. ## Keep focused controls unobscured WCAG 2.2 added Focus Not Obscured at Level AA. Author content cannot hide focus entirely. Sticky headers, cookie banners, and chat widgets can cover focused elements. Test complete keyboard paths with overlays active. Closing overlays should restore sensible focus. The full walkthrough is in [how to test WordPress blocks with a keyboard](https://wpblocksuite.com/blog/test-wordpress-blocks-keyboard/). ## Write useful image alternatives Informative images need alternatives serving the same purpose. Decorative images usually need empty alternatives. Do not repeat nearby captions automatically. Describe meaning within the page context. Post 091 will cover the complete block-editor workflow. This audit checks frontend output. ## Handle complex images Charts and diagrams may need longer descriptions. Concise [alt text](https://wpblocksuite.com/blog/alt-text-workflows-wordpress-block-editor/) cannot carry every relationship. Provide equivalent data or explanation nearby. Keep that content crawlable and accessible. Test SVG titles and descriptions carefully. Browser and embedding behaviour can differ. ## Check text contrast Text needs sufficient contrast across normal, hover, focus, disabled, and visited states. Overlays and background images can change effective contrast. Test representative pixels. Post 090 will cover repeatable contrast measurement. This checklist prevents skipped states. ## Check non-text contrast Meaningful controls, boundaries, icons, and focus indicators also need adequate distinction. A visible label may reduce reliance on an icon. Essential states still need perceptible cues. Test custom form and slider controls. Browser defaults can disappear under theme styling. ## Do not rely on colour alone Colour cannot be the only carrier of errors, status, categories, or selection. Add text, icons, patterns, or structural cues as appropriate. Keep every cue understandable. Test links inside body text. Colour differences alone may not provide sufficient identification. ## Test text resizing Resize text without losing content or functionality. Fixed-height containers often clip enlarged copy. Buttons, cards, and navigation must expand. Decorative text should not cover controls. Test browser zoom and text-only enlargement where relevant. Different failures can appear. ## Test responsive reflow Content should reflow without unnecessary two-dimensional scrolling. Tables and diagrams need thoughtful exceptions. Columns can become illogical after stacking. Check source order and reading sequence. Test narrow viewports with zoom. Mobile preview alone does not simulate every condition. ## Test text spacing overrides User spacing adjustments should not clip or overlap content. Fixed components commonly fail. Check buttons, badges, navigation, accordions, and cards. Allow content-driven height. Do not suppress user styles aggressively. Flexibility supports varied reading needs. ## Control moving content Automatically moving content needs pause, stop, or hide controls when criteria apply. Carousels, tickers, animations, and videos can distract or block reading. Prefer no autoplay. Respect reduced-motion preferences for non-essential animation. ## Avoid dangerous flashing Flashing content can trigger serious harm. Do not publish rapid decorative flashes. Review uploaded media and animations, not only block settings. Third-party embeds need scrutiny. When uncertain, remove the effect. Decoration does not justify health risk. ## Label form fields properly Every input needs a programmatically associated label. Placeholder text cannot replace it. Group related choices using meaningful structures. Explain formats and required status before errors occur. Test autocomplete and password-manager behaviour. Helpful automation can reduce repeated entry. ## Write useful form errors Identify the field, problem, and correction. Colour alone cannot carry errors. Move or announce focus appropriately after submission. Preserve correct user input. Provide prevention and confirmation for important transactions. Test every validation path. ## Build accessible tables Use tables for data relationships, not layout. Header cells need correct associations. Provide captions when they help identify purpose. Keep complex tables understandable. Post 092 will cover the detailed table workflow. This checklist confirms purpose and output. ## Provide accessible media alternatives Prerecorded video generally needs captions. Audio content may need transcripts or other alternatives. Audio description may be needed when visuals convey essential information. Player controls must work by keyboard. Captions need accurate timing and wording. ## Test accordions and Details blocks Disclosure controls need names, keyboard activation, and exposed expanded states. Opening content should not move focus unexpectedly. Closed content should not receive hidden focus. Native Details elements reduce custom scripting. They still need readable summaries and styling. ## Test sliders and carousels Provide keyboard controls, visible labels, pause controls, and understandable position information. Autoplay should not steal attention or hide content. Swipe cannot be the only control. Post 093 will cover accessible slider construction. This audit checks release readiness. ## Test navigation menus Menus need predictable keyboard behaviour, focus order, names, and expanded states. Mobile toggles need accessible labels. Escape behaviour should match the implemented menu pattern. Current-page indication cannot depend on colour alone. Test nested items carefully. ## Test dialogs and popups Dialogs need a name, focus entry, contained interaction, and dependable dismissal. Closing should restore focus sensibly. Background content should not remain accidentally interactive. Test cookie notices and promotions too. Business importance does not excuse barriers. ## Check target sizes WCAG 2.2 added a Level AA minimum target-size criterion with defined exceptions. The general minimum is 24 by 24 CSS pixels. Spacing can also affect eligibility. Measure small pagination, carousel dots, close controls, and inline actions. Review exceptions carefully. ## Provide alternatives to dragging WCAG 2.2 requires single-pointer alternatives where dragging is used, with exceptions. Sliders, sortable lists, maps, and comparison controls can depend on dragging. Add buttons or direct inputs where appropriate. Keyboard access alone may not satisfy pointer needs. ## Support different orientations Do not restrict content toward portrait or landscape without an essential reason. Test media, tables, navigation, and overlays after rotation. Layout changes can hide controls. Device assumptions exclude mounted or fixed-screen use. Responsive design should remain flexible. ## Expose name, role, and value Custom controls need programmatic names, roles, states, and changing values. Native HTML controls provide much of this behaviour. Custom div-based widgets need extra engineering. Inspect the accessibility tree. Visual resemblance does not prove semantic equivalence. ## Announce important status messages Dynamic success, error, loading, and cart messages may need programmatic announcement. Do not move focus for every update. Use suitable status patterns. Test timing with a screen reader. Messages should remain understandable without visual discovery. ## Run automated tests Automated tools find missing labels, invalid relationships, contrast issues, and certain structural defects. Run them across representative templates and states. One homepage scan gives narrow evidence. Review findings manually. Tools can produce false positives and miss contextual failures. ## Run manual keyboard tests 1. Start at the browser address bar. 2. Enter the page normally. 3. Use the skip link. 4. Follow every focusable control. 5. Activate menus and disclosures. 6. Complete important forms. 7. Open and close dialogs. 8. Confirm focus remains visible. 9. Confirm nothing traps focus. Repeat important paths at mobile widths. Responsive menus often create separate failures. ## Run screen-reader checks Check landmarks, headings, links, forms, tables, dialogs, and dynamic messages. Use combinations representing your audience and support scope. One pairing cannot prove universal behaviour. Do not treat speech output as the whole experience. Keyboard and visual checks remain necessary. ## Test complete user journeys A page can pass isolated checks while its task still fails. Test complete journeys. Include discovery, selection, form completion, confirmation, and error recovery. Prioritise revenue, support, authentication, and legal workflows. Barriers there carry greater consequences. ## Test after every component update Core, theme, and plugin updates can change markup or interaction. Regressions happen quietly. Keep a representative [smoke-test](https://wpblocksuite.com/blog/smoke-test-checklist-block-based-pages/) set. Run it on staging before production updates. Retest production after caches clear. Staging parity is never perfect. ## Evaluate block plugins before adoption Test actual frontend examples, not accessibility claims alone. Inspect keyboard and screen-reader behaviour. Review update history and support responses. Ask how reported accessibility defects receive priority. Prefer native controls and simpler markup where requirements match. Complexity increases test scope. ## Plan plugin deactivation Deactivation can leave unsupported blocks, raw content, or missing interactions. Test it on staging. Ensure essential information survives or has a migration path. Export custom data beforehand. Accessibility ownership continues during migration. A broken replacement is not progress. ## Record defects and decisions Log the affected component, criterion, user impact, severity, owner, and retest evidence. Temporary workarounds need review dates. Do not let exceptions become permanent silently. Share patterns across teams. Repeated defects usually indicate a system problem. ## Know what native blocks cannot prove Core blocks can reduce certain risks through established HTML. They cannot control every theme style. Editors can still create poor headings, links, alternatives, and tables. This is the honest weak case. Native primitives help but never guarantee site-level conformance. ## Use the block accessibility checklist 1. Set the page language. 2. Write a useful title. 3. Check landmarks and bypass links. 4. Build logical headings. 5. Write descriptive links and buttons. 6. Test every keyboard path. 7. Keep focus visible and unobscured. 8. Provide meaningful image alternatives. 9. Check text and control contrast. 10. Test zoom, reflow, and spacing. 11. Control motion and flashing. 12. Label forms and errors. 13. Build semantic tables. 14. Provide media alternatives. 15. Test every custom interaction. 16. Check target sizes and dragging. 17. Expose names, roles, and states. 18. Run automated and manual tests. 19. Complete important user journeys. 20. Retest after every update. ## Frequently asked questions Are core WordPress blocks automatically accessible? No. Core primitives help, while content, themes, and configurations still affect outcomes. Can an automated test prove WordPress accessibility? No. Automated tests need manual keyboard, visual, screen-reader, and journey checks. Where should WordPress block accessibility be tested? Test the anonymous rendered frontend across representative templates, states, and devices. What changed in WCAG 2.2 for block interfaces? New criteria include focus obstruction, dragging alternatives, and minimum target sizes. Who owns WordPress site accessibility? Editors, developers, designers, vendors, and site owners share responsibilities by layer. ## The verdict Verdict **Test the complete output:** accessibility belongs to the rendered experience across every layer. **Make it repeatable:** combine automated checks with keyboard, zoom, screen-reader, and journey testing. Core blocks reduce unnecessary complexity. Test free plugins before expanding your stack. Then [compare the $299 lifetime suite](https://wpblocksuite.com/#pricing) when several Pro blocks pass your accessibility checks.