Rayetun Accessible Blocks combines two things in one plugin: accessible blocks, and a toolkit for checking and improving the accessibility of your whole site.

Accessible blocks. Interactive components — modals, sliders, tables, mega menus, carousels, before/after, and more — built to be keyboard-operable and screen-reader-correct against WCAG 2.2 Level AA, each with a published Accessibility Conformance Report you can hand to a compliance team.

An accessibility toolkit. An accessibility panel in the editor as you write, a site-wide axe-core scan with a dashboard and trend history, a front-end inspector that outlines problems on the live page, an image alt-text audit and bulk editor, readability and contrast help, scheduled email summaries, and an exportable accessibility report.

Every feature described here is included in the plugin — there are no locked panels or upgrade prompts. A separate add-on aimed at agencies (managing many client sites from one place, branded client reports, and the like) may follow later; it would only add to what is already here.

How Rayetun Accessible Blocks is organised

Accessible by default — WCAG 2.2 AA is the definition of done, not a setting you switch on
Local first — scan results, findings, and settings live in your own database; nothing is sent anywhere
Built on core APIs — the WordPress Interactivity API, Block API v3 (block.json), and server-side rendering. No jQuery, no framework runtime; each block’s script loads only where it’s used
Honest by design — it fixes markup, it never masks problems with an overlay, and it makes no compliance claim on your behalf

🧱 The Blocks

🪟 Modal — built on the native <dialog> element: focus handled correctly, Escape always closes, focus returns to the trigger, background made inert. No focus-trap hacks.
🎠 Slider (with Slide) — an accessible carousel where each slide holds any blocks. Choose how many slides show per view on desktop, tablet, and mobile; add a slide with one button. It’s a genuine keyboard-scrollable region (nothing hidden from screen readers), with real prev/next and dot controls, arrows below or on the sides, and opt-in auto-advance that ships a real pause button and never runs under reduced motion.
📊 Data Table — a real, optionally sortable table with a caption, proper column and row header scopes, sort changes announced to screen readers, and a focusable scroll region for narrow screens.
💳 Pricing Table (with Pricing Plan) — plans with a real monthly/annual toggle (a keyboard-operable radio group, not a fake switch), the price change announced to screen readers, and the recommended plan marked with a text badge — never colour alone.
🗂️ Query Grid — a post grid with accessible filters: real labelled filter buttons (not clickable spans), the result count announced to screen readers, and a semantic list. Adds front-end post filtering, done accessibly.
🧭 Mega Menu (with Mega Menu Section) — a mega menu that goes inside core’s Navigation block rather than replacing it. Two layouts: a single disclosure panel, or a category rail built as a real ARIA Tabs widget with arrow-key navigation. Deliberately not role="menu" — that role promises application-menu keyboard behaviour a panel of links can’t honour.
🎬 Video Popup — a video lightbox in a native <dialog>: the player loads only when the visitor opens it — no third-party requests, cookies, or autoplay on page load — and closing actually stops playback. Focus is moved in and returned. YouTube (via the no-cookie domain), Vimeo, or a self-hosted file.
⏳ Countdown — a countdown timer with three presets (Cards, Solid, Minimal). The ticking digits are hidden from screen readers, so a screen-reader user isn’t read a new number every second, while a text alternative gives the real deadline and the end is announced once. Counts to the same instant for everyone (resolved in your site’s timezone).
🔀 Before / After — an image comparison you can operate with the keyboard, not just the mouse. It’s built on a real range slider, so arrow keys move the divider, dragging works, and a screen reader announces the position — and both images are described, so a blind user gets the comparison too. Horizontal or vertical.
📍 Image Hotspot — pin clickable spots on an image, each opening a titled tooltip with optional text, an image (with an accessible lightbox), and a link. Every pin is a real keyboard-operable button (Escape closes and returns you to the pin), and — optional, on by default — every hotspot is also listed as plain text below the image, so the information never depends on a mouse or on seeing the picture. Markers clear the 24px target-size minimum; the optional pulse never runs under reduced motion.
🧭 Table of Contents — built automatically from your headings, as a real navigation landmark. Three styles (Card, Bordered, Plain) with an accent colour, bullet/number markers, an optional collapse toggle, and a sticky option. Headings get anchors on their own, the current section is marked as you scroll, and clicking a link moves focus into that section — so keyboard users land where they meant to, not back at the list.
💬 Testimonial — a testimonial or review in three presets (Card, Review, Quote). Built on a real <figure>/<blockquote>/<figcaption>, with the star rating exposed to screen readers as “Rated 5 out of 5” rather than five unlabelled symbols.
🗣️ Testimonials — lay out Testimonial items as a grid or carousel: choose how many show per view, with prev/next, dot pagination, and arrows below or on the sides.
🛍️ Product Card — a product card in three presets (Standard, Horizontal, Overlay). The title is a real heading, the image has proper alt text, a sale is announced as “Original price … Sale price …”, and each button’s name includes its product so identical “View product” links stay distinct. Author-populated — no WooCommerce needed.
🎠 Products — lay out Product Cards as a grid or a carousel. Grid wraps into rows (choose how many per view, per breakpoint). Carousel is a genuine scroll region — labelled, keyboard-scrollable, nothing hidden — with prev/next buttons, dot pagination, and arrows below or on the sides.

Both carousels respect prefers-reduced-motion, and every dot and arrow meets the WCAG 2.2 24×24px target-size minimum.

🎛️ Works on Every Block

These apply to any block — ours or WordPress’s own.

👁️ Conditional Display
Show or hide any block by login state or user role. Hidden blocks are removed on the server, so screen readers, search engines, and feeds all see the same page a visitor does — not content hidden with CSS that assistive tech still reads out.

A note on Conditional Display: it controls presentation, not access. Hidden text still exists in the post, so it can surface in site search or an export. It’s stronger than CSS-hiding and weaker than a membership plugin — please don’t use it to protect genuinely private content.

✨ Motion
Entrance animations, parallax, and sticky positioning on any block. Every effect is skipped entirely for visitors who ask their system for reduced motion, and the code loads only on pages that actually use it.

🔍 In-Editor Accessibility Checker

Every block this plugin adds gets an “Accessibility” panel that checks its setup as you build, and shows a clear all-clear when it’s right.

Flags what only the block author can fix — a dialog that only the Escape key can close, a table with no caption, a slide with no content, auto-advance set too fast, a control colour pairing below the contrast minimum
Reading-level readout — an advisory Flesch–Kincaid estimate over your prose (WCAG 3.1.5). Advisory only: it never gates or fails anything
Stays in its lane — interactive configuration, so it complements full-content checkers like Block Accessibility Checks rather than duplicating them

📊 Site-Wide Accessibility Scan

An Accessibility screen in wp-admin scans your published pages with axe-core against WCAG 2.2 AA and keeps the results.

Site-wide totals — errors, warnings, and dismissed findings, with a severity breakdown
Worst-first page list — see which pages need attention, with per-finding detail and the offending markup
Dismissed-issues log — dismiss a finding with a written reason; it’s kept with a timestamp, never silently dropped
Admin status column — accessibility status next to each page in your post list
Uncapped counts — totals are computed across the whole site, never a capped page, so nothing is quietly under-reported

🖍️ Front-End Inspector

The same checks, on the live rendered page — for logged-in editors only.

In-context outlines — each flagged element is boxed where it actually sits, with a popover explaining the problem
Contrast fix suggestions — for a colour-contrast failure, it computes the nearest passing colour (nudged toward black or white, whichever changes it least) and offers it with a swatch. A suggestion, never an automatic change
Never shown to visitors — gated on a real capability check in PHP, not just hidden with CSS

This is the opposite of an accessibility overlay. It changes nothing a visitor sees; it shows problems to the person who can fix them.

📧 Scheduled Email Reports

Have a summary of your accessibility findings emailed to you weekly or monthly. Off by default; you choose the address.

The email reports your last stored scan — it does not run a new one, because a real scan needs a real browser to render your pages. The email says so itself, and the settings screen tells you when the last scan actually ran.

📋 Accessibility Conformance Reports

Each block ships a published ACR documenting how it meets each relevant WCAG 2.2 AA success criterion, the testing environment, and any known limitations — including defects found and fixed during screen-reader testing.

Each block has been tested with a real screen reader (NVDA + Firefox), and its report records the testing environment along with any defects found and fixed during that testing.

🧭 What Rayetun Accessible Blocks Will Not Do

Worth stating plainly, so you know what to expect:

❌ No overlay or accessibility widget — no floating toolbar, no “profiles” for blindness or dyslexia. Rayetun Accessible Blocks fixes the underlying markup rather than layering a widget over it
❌ No compliance claim — no plugin can make a site ADA or EAA compliant, and Rayetun Accessible Blocks does not claim to
❌ No auto-fix of your content — the inspector suggests; you decide. Silent rewrites hide problems instead of solving them
❌ No data collection — no telemetry, no phone-home, no account

Automated checks are a floor, not a certificate. They catch a portion of WCAG failures; the rest needs a keyboard and a screen reader. A clean scan does not mean a page is accessible, and Rayetun Accessible Blocks says that on the dashboard itself.

Compatible With

Block themes and classic themes — blocks inherit your theme’s colours, spacing, and typography via theme.json/global styles
WordPress core Navigation block (Mega Menu inserts inside it)
Block Accessibility Checks and other full-content checkers — complementary, not overlapping
Any standard block editor workflow — no page builder required

External Services

Rayetun Accessible Blocks itself sends no data anywhere. Scan results, findings, and settings are stored only in your own WordPress database. There is no telemetry, no account, and no phone-home.

One block can embed third-party video — and only then, and only for a visitor who chooses to watch:

YouTube / Vimeo — Video Popup block (only when a visitor plays a video)
When you set a YouTube or Vimeo URL on a Video Popup block, the player is requested from that provider only when a visitor opens the popup, never on page load. At that point the visitor’s browser contacts YouTube (through the privacy-friendly youtube-nocookie.com domain) or Vimeo (with Do Not Track requested) to stream the video.
Data sent: the visitor’s IP address and their playback interactions, sent by their own browser to the provider.
Sent when: only when a visitor opens a Video Popup that points at a YouTube or Vimeo URL. A self-hosted video file, or a popup no visitor opens, contacts no external service.
Service URL: https://www.youtube.com — https://vimeo.com
Terms of Service: https://www.youtube.com/t/terms — https://vimeo.com/terms
Privacy Policy: https://policies.google.com/privacy — https://vimeo.com/privacy

Video thumbnail import (optional, editor-initiated)
If you use the Video Popup block’s optional “Use video thumbnail” button in the editor, your site fetches the poster image from the provider once, server-side, and saves it to your Media Library. The poster is then served from your own site, so visitors’ browsers do not contact the provider on page load. This request happens only when you click that button.

Development

Rayetun Accessible Blocks is open source and built with the official @wordpress/scripts toolchain (webpack). The complete, unminified source — every block, the editor checks, and the dashboard — ships in the plugin’s src/ directory; the files in build/ are compiled from it. Nothing is obfuscated.

To build from source:

npm install && npm run build

That regenerates everything in build/. npm test runs the unit suite. No build step is needed to use the plugin — the compiled output is included.

Credits

Rayetun Accessible Blocks bundles axe-core by Deque Systems, Inc., which powers the accessibility scan. axe-core is licensed under the Mozilla Public License 2.0 (MPL-2.0); its copyright and license notice are preserved in build/axe.min.js. Everything else is original work under GPL-2.0-or-later.

Rayetun Accessible Blocks & Accessibility Toolkit