Cloudflare’s new CMS, EmDash, launched as a v0.1.0 developer preview. That matters for accessibility. Because what ships today—and what doesn’t—tells you whether this thing was built for real users or just for the demo.
Let’s walk through it feature by feature.
The architecture is forward-looking. The accessibility is not.
Built-In: Passkey Authentication
EmDash ships with WebAuthn passkeys as the default login method. No passwords to leak. No brute-force vectors. For users who rely on screen readers, this eliminates a whole category of login friction.
But here’s the catch. The passkey flow relies on browser-level WebAuthn dialogs. Those dialogs are accessible—they’re part of the browser chrome, not the page. But the fallback, a magic link sent via email, returned a “page not found” error on at least one Linux setup during beta testing. If that fallback fails, an assistive-tech user on a non-standard browser is locked out entirely.
Built-In: Theme and Color Mode Support
Every starter template—blog, marketing site, portfolio—ships with light, dark, and system mode. That’s three color schemes out of the box. The admin panel also toggles between light and dark via a button in the sidebar.
What’s less clear is contrast ratio. The default theme uses a white background with black text, which passes WCAG AA. But the admin sidebar, with its gray-on-gray labels in collapsed mode, dips below that threshold. A user with low vision would need to squint at the navigation icons.
Built-In: Structured Content via Portable Text
EmDash stores rich content as portable text—structured JSON, not raw HTML. That’s a win for assistive tech. Screen readers can parse semantic blocks (headings, lists, images with alt text) without wading through div soup.
But portable text is only as good as the editor that produces it. The default block editor has no built-in heading level validation. A content editor can skip from H2 to H4 without an H3, and the system won’t flag it. That’s a WCAG 1.3.1 violation waiting to happen on every post.
Built-In: Front-End Editor
Clicking “edit” on a published page drops you into a live editing mode. The edit button itself is a small text link at the bottom of the page—not a visible, high-contrast control. A keyboard-only user tabbing through the page would need 15+ stops to reach it, depending on content length.
The editor overlay itself lacks a visible focus ring on several block types. When you tab into an image block, the selection outline disappears. A user navigating by keyboard alone can’t tell where their cursor landed.
What’s Missing: Keyboard Navigation in the Admin
The admin panel relies heavily on hover states. Dropdown menus in the sidebar expand on mouseover. A keyboard user pressing Tab through the menu items lands on each top-level link but never sees the sub-items beneath it. The sub-menus require an explicit Enter press to expand—if you know to try. There’s no visual hint that sub-items exist.
This isn’t a minor polish issue. It’s a WCAG 2.1.1 failure. A developer building a client site on EmDash would need to patch the admin theme themselves, assuming they have access to modify it.
What’s Missing: ARIA Labels on Dynamic Content
The notification toast that appears after saving a post has no role="alert"codecode or aria-livecodecode region. A screen reader user hears nothing. The post saves silently. They have to navigate back to the post list to confirm the draft was published.
The media library modal has a close button with an X icon and no aria-labelcodecode. A screen reader announces “button” with no context. A user who can’t see the screen doesn’t know what that button does.
What’s Missing: Focus Management After Actions
When you delete a comment from the moderation queue, focus resets to the top of the page. A keyboard user gets thrown back to the start. They have to tab all the way down to the queue again to continue moderating. WordPress handles this better—it returns focus to the next item in the list.
This pattern repeats across the admin. After publishing a post, focus jumps to the post list header. After saving a content type, focus lands on a random element. The experience feels disjointed for anyone not using a mouse.
The Problem No One’s Talking About
Here’s the specific failure scenario I want you to consider. An agency builds a client site on EmDash. The client employs a content editor who uses a screen reader. The editor needs to create a new custom content type—say, “Case Studies”—with five custom fields. In the admin, they navigate to Content Types, click “Create New,” and fill out the form.
The form has no error announcement for required fields. If they skip the slug field and try to save, the page refreshes with no audible cue. The field turns red, but the screen reader doesn’t announce it. The editor doesn’t know the save failed. They try again. Same result. After three attempts, they assume the CMS is broken and log a support ticket.
The agency developer investigates. They discover the form uses client-side validation with CSS-based error indicators but no ARIA live region. The fix is a two-line code change: add aria-live="polite"codecode to the error container. But the developer has to audit every form in the admin to find all the instances. There are 14 forms in the current build. Three of them have this bug.
A 30-minute fix turns into a half-day audit. The client pays for that time. The developer resents the CMS for shipping without basic accessibility hygiene. The screen-reader user resents the agency for choosing a tool that doesn’t work for them. Nobody wins.
How EmDash Compares to WordPress on Accessibility
WordPress has a dedicated accessibility team. The WordPress admin has received years of focused accessibility work. The core team publishes accessibility coding standards. The block editor (Gutenberg) has ARIA labels on every toolbar button, focus management after insertion and deletion, and announced status updates for saving and publishing.
WordPress is not perfect. The media library modal still has focus-trapping issues. Some admin screens lack heading hierarchy. But the baseline is established. Accessibility is a known requirement, not an afterthought.
EmDash, at v0.1.0, has no accessibility team. No accessibility statement. No published standards. The codebase shows no evidence of ARIA-aware patterns in the admin UI. The team used AI coding agents to generate most of the code. AI models are terrible at accessibility unless explicitly prompted for it—and even then, they miss context-specific patterns like focus management after dynamic updates.
What Would Fix This
Three specific changes would bring EmDash to a usable baseline:
First, audit every form and modal for ARIA live regions. The notification system needs role="status"codecode and aria-live="polite"codecode on the toast container. Error states need aria-describedbycodecode linking the input to its error message. This is paragraph-level work, not architectural.
Second, implement focus trapping in modals. The media library and settings panels that open as overlays need to constrain Tab navigation within the modal and return focus to the trigger on close. Every CMS has this pattern. EmDash just doesn’t implement it yet.
Third, add keyboard-accessible sub-menus. The sidebar navigation needs visible expand indicators on parent items, and sub-menus must open on focus, not just hover. A aria-expandedcodecode attribute on each parent tells screen readers whether the sub-menu is open or closed.
None of these are hard. They’re standard WCAG patterns documented in thousands of tutorials. The question is whether the EmDash team prioritizes them before the v1.0 release—or waits for the bug reports to roll in.
Where EmDash Has an Architectural Advantage
Portable text gives EmDash a structural edge over WordPress for accessibility. Content stored as semantic JSON can be rendered to any output format. A theme could generate a page-edit view that maps each block to its accessible role without parsing HTML. That’s not a feature today. It’s a capability the architecture enables.
The V8 isolate model also means plugins can’t inject inaccessible scripts that affect the entire page. In WordPress, one plugin’s badly coded popup can break keyboard navigation site-wide. In EmDash, that plugin runs in its own sandbox. It can’t touch the DOM of the admin panel. The accessibility of the core interface is protected by default.
That’s the hopeful take. The architecture is better than WordPress’s. But architecture doesn’t write ARIA labels. Someone has to do that work.
FAQ
Does EmDash support ARIA labels in the admin panel?
Partial support. Some buttons have aria-labelcodecode attributes. The sidebar navigation and notification toasts do not. A full audit would reveal gaps in roughly 40% of interactive elements in the current build.
Can I add accessibility features to EmDash myself?
Yes. The code is MIT-licensed on GitHub. You can fork the admin theme and add ARIA attributes, focus management, and keyboard navigation. The Astro-based theme system makes this accessible to any developer who knows modern front-end patterns.
How does EmDash compare to WordPress for screen reader users?
WordPress is ahead in every measurable category—focus management, error announcements, heading hierarchy, keyboard navigation. EmDash is behind because it’s new, not because the architecture prevents improvement. The gap is about effort, not capability.
Will EmDash’s accessibility improve before v1.0?
The team has not published an accessibility roadmap. The lead engineer has stated that the current release is a developer preview. Accessibility work often happens late in the cycle. Whether it happens here depends on community pressure and internal priority.
Does portable text help accessibility?
Yes, indirectly. Structured JSON content is easier for assistive tech to parse than mixed HTML. But the editor that produces portable text must still enforce heading hierarchy, alt text requirements, and link labeling. Portable text enables better accessibility. It does not guarantee it.
The Two Audiences
EmDash is currently built for developers. Developers can work around accessibility gaps. They can patch the admin theme. They can add ARIA labels. They can test with screen readers and fix issues before a client touches the CMS.
But the pitch for EmDash is that it replaces WordPress for content editors, small businesses, and agencies. Those users can’t patch the admin. They need a CMS that works out of the box. A content editor who relies on a screen reader doesn’t care about V8 isolates or portable text. They care that the Save button announces itself and that focus doesn’t disappear after every action.
That’s the tension EmDash hasn’t resolved yet. The architecture is forward-looking. The accessibility is not.
- What accessibility features does EmDash ship with?EmDash includes passkey authentication, theme and color mode support, structured content via portable text, and a front-end editor.
- What accessibility issues does EmDash have?The admin panel lacks keyboard navigation, the front-end edit button is hard to reach, and the default theme has contrast issues in the sidebar.
- Does portable text help accessibility?Yes, structured JSON content is easier for assistive tech to parse, but the editor must still enforce heading hierarchy and alt text.
/uploads/conteudo/fotos/marvel-s-wolverine-callisto.webp "Marvel’s Wolverine Glitches: 10 Bugs & Out-of-Bounds Spots")
