A11Y in E11Y: Why Accessibility Is a Platform Responsibility

A11Y in E11Y: Why Accessibility Is a Platform Responsibility

There is a common assumption among plugin platform teams: accessibility is the plugin developer's job. The platform provides surfaces. Developers build on them. If a plugin has a contrast problem, a missing label, or a broken keyboard path, that is the developer's problem to fix.

This assumption is expensive to discover wrong after you have shipped a marketplace.

Accessibility failures in your plugin ecosystem are platform failures. Not because every plugin is yours to audit, but because the architecture that makes accessibility possible, or impossible, is entirely your design. The extension points, the runtime, the messaging contracts, the default SDK patterns: all of it comes from you. If that architecture creates accessibility barriers, no amount of developer documentation fixes them downstream.

What breaks at the boundary

Most iFrame-based plugin systems rely on the browser's cross-origin boundary as their security model. That same boundary creates an accessibility problem that platform teams rarely plan for.

ARIA semantics do not cross iFrame boundaries.

If the host application has a coherent landmark structure, a

, a , a properly announced dialog, none of that context is visible inside the plugin's iFrame. A screen reader moving through the host page encounters the iFrame as a foreign object. If the iFrame has a meaningful title attribute, the screen reader announces it. If not, the plugin surface is announced as an unlabelled frame, and the user loses context entirely. This means platform teams are responsible for the semantics of the iFrame container at minimum. The title attribute must describe what the plugin is doing in the context of the page. The host's landmark structure must correctly scope where the plugin surface sits. These are not defaults a plugin developer can set. They are owned by whoever controls the host DOM.

The keyboard contract

WCAG 2.1.2 requires that keyboard users can move focus away from any component. In practice, when a keyboard user tabs into an iFrame, focus enters the plugin's browsing context. Getting out requires a defined mechanism. Without that mechanism, the plugin's iFrame is a keyboard trap. The user is stuck until they navigate by browser shortcut, which many screen reader users cannot easily do mid-flow. This contract cannot be designed by the plugin developer alone. It requires coordination between the plugin's postMessage layer and the host application's focus management. When a plugin signals it is done, or that focus should leave the surface, the host must receive that signal and move focus to the correct next element. The host must also define what happens when the user presses Tab or Shift+Tab at the edge of the plugin surface. That is a platform API decision. When you design an extension point, you are also designing a keyboard navigation contract, whether you intend to or not.

The announce layer

When content changes inside a plugin, the host application's screen reader context does not automatically know. An aria-live region inside an iFrame announces updates to users within that iFrame's browsing context. But status messages, error states, or confirmation feedback that the host needs to reflect for the user's broader session require an explicit bridge. Platforms that do not design this bridge produce experiences where assistive technology users miss updates entirely. A plugin that completes an action, saves data, or surfaces an error has no reliable way to tell the host's screen reader stack unless the platform defines the message schema. This is the same postMessage architecture you would use for resize events, theme tokens, or any other host-plugin coordination. Accessibility signals belong in the same layer. The platform team writes the spec. Plugin developers implement it.

What platform teams must own

The responsibility is specific, not general. Platform teams do not need to build every plugin. They do need to own: The iFrame title contract. Every plugin surface should receive a descriptive title from the extension point definition. Not blank. Not the generic string "iframe". Something that tells a screen reader where the user is and what the surface is for. The focus entry and exit model. How focus enters a plugin surface, and how a keyboard user can leave it, must be defined at the platform level. This is an API contract, not a documentation suggestion. The announce bridge. Define message types that plugins use to send semantic announcements to the host. The host implements the aria-live region. Plugins call the message. This means even a plugin with a poorly built UI can still surface critical state changes accessibly, because the channel is platform-owned. Accessible defaults in the SDK. If your plugin SDK ships with sample code, UI component patterns, or starter templates, those defaults set the floor for your ecosystem's accessibility. Bad defaults compound at scale. Accessible defaults do not guarantee compliant plugins, but they prevent the baseline from starting at zero.

How mature platforms handle this

Shopify publishes explicit accessibility guidelines for Shopify app developers, covering keyboard navigation patterns, focus management requirements, WCAG conformance targets, and screen reader behaviour. That documentation is not a transfer of responsibility to the developer. It reflects that Shopify has already made decisions about the keyboard contract and the ARIA context, and is publishing the spec for developers to implement against. Salesforce maintains a platform accessibility status page and has formal requirements for apps listed on AppExchange. Enterprise procurement teams routinely include accessibility compliance requirements, and a marketplace that cannot demonstrate platform-level accessibility governance is at a disadvantage in those conversations. These are commercial decisions as much as technical ones. The European Accessibility Act became enforceable across EU member states in 2025. It applies to digital products and services, including platforms and the ecosystems they host. Legal exposure for accessibility failures no longer sits only with the end deployer. It follows the product architecture.

Forge and E11Y

E11Y is Beach's accessibility evaluation platform. The connection between Forge and E11Y is not incidental. Hosting a site on Forge and running it through E11Y closes a loop that most plugin platform teams leave open: automated accessibility checking against what is actually rendered, including plugin surfaces. The more useful integration, and the one this series is building toward, is designing plugin extension points with accessibility contracts already in them. E11Y checks then confirm compliance rather than discover its absence after the fact.

Design the contract before you need it

Extension points are design commitments. As covered in the anatomy of an extension point, every extension point has a trigger, a contract, and a boundary. Accessibility belongs in all three. The trigger defines what activates the plugin surface. The contract defines what the plugin can access and what the platform provides. The boundary defines what the plugin cannot touch. If your contract does not include a keyboard navigation protocol and a semantic announcement bridge, it is incomplete. Most platform teams discover this late. After thousands of plugins have shipped against the original spec, retrofitting accessibility into a published extension API is exactly as painful as it sounds. Every change to the message schema breaks existing plugin implementations. Every new ARIA requirement needs adoption campaigns across a developer ecosystem that has no obligation to move quickly. The iFrame runtime model is one of the better choices for UI extension surfaces, precisely because its isolation properties are clear and predictable. But isolation does not solve the accessibility contract problem. It just makes it easier to reason about where the boundaries are. Shopify, Salesforce, and Figma each solved this by designing accessible extension points before the ecosystem grew large enough to make change expensive. Not by writing thorough documentation after the fact, but by making platform-level decisions about keyboard behaviour, ARIA structure, and announcement patterns early. The earlier you make that decision deliberately, the less you pay for it later.