Determine plan for block patterns when doing accessibility-ready reviews

[amberhinds]

Currently we have these instructions in the setup for accessibility-ready theme reviews:

1. Go to the Block Patterns page (/accessibility-ready-test-pages/block-patterns/).
2. Edit the Block Patterns page.
3. In the editing screen, click the Block inserter (+) in the top-left corner.
4. Click the Patterns tab.
5. Insert all available patterns into the page. Do not change any content or settings for the patterns.
6. Save the page.

Questions:

1. Should core patterns be tested or only patterns created by the theme?

2. Does the theme developer need to ensure that all core patterns are free of accessibility errors?
   Here is a concrete example. Twenty Twenty-Five offers these patterns with large white text over an image with a colored overlay:

After activating a different theme, I see these patterns are still available in the block inserter; however, they now have black text, which fails contrast and makes them very difficult to read.

Should the failures in these patterns stop the theme from getting an accessibility-ready tag? If so, we'll need to update our guidance for theme developers to either ensure accessibility in core patterns or deregister them so they no longer appear in the inserter.

If we are going to say these patterns are not the responsibility of theme developers, then we should remove them from our testing template site to reduce confusion for testers.

[joedolson]

I think we might want to require theme authors to check for color contrast problems, which are easy to remedy - the above example is presumably because the theme has heading styling that is overriding the pattern.

But I don't think it's reasonable to expect them to override structural problems or replace images, which is probably outside the reasonable scope.

Historically, the expectation has been that theme defaults need to be accessible - and I think that should be extended to cover core patterns and blocks.

[shivashankerbhatta]

Thanks for opening this discussion — I think the important nuance here is that core patterns themselves are generally accessible when authored, but their accessibility can be broken by theme-level design decisions, especially colors, overlays, and typography.

In the example shared, the contrast failure is not caused by the core pattern logic, but by the way the active theme applies global styles to it. This makes it very difficult to assign responsibility to theme authors for content they did not create and cannot reasonably control in every context.

From a scalability and maintenance perspective, I believe:

• Theme-registered patterns, templates, and demos must be accessibility-ready, and failures there should block the tag.

• Core patterns should not block the accessibility-ready tag, even if a theme’s design system causes them to fail contrast or other requirements.

• Theme developers should be expected not to include or adapt core patterns with known accessibility issues inside their own patterns or templates, but not required to fix or deregister all core patterns shown in the inserter.

If core patterns are out of scope for theme responsibility during reviews, reviewer guidance should be updated to clearly state this, or core patterns should be excluded from the accessibility-ready test pages to avoid confusion and inconsistent outcomes.

This approach keeps accessibility accountability aligned with authorship, while acknowledging that theme design systems can unintentionally affect shared core content.

[muddassirnasim]

I think the key distinction here is authorship vs. implementation.

Core block patterns should be considered accessible as authored (markup, semantics, defaults), and failures caused by theme-level design decisions (colors, overlays, typography, filters) shouldn’t block an accessibility-ready tag. Otherwise, themes are effectively being held responsible for behavior they don’t control.

[joedolson]

@muddassirnasim That's only partially true. If a theme design decision causes a failure in a core block, then that is the fault of the theme.

If a core block is not materially changed by the theme, but fails, then I agree that's a core issue. But if the block is changed by the theme in a way that introduces a failure, then that is a failure.

[rianrietveld]

Reading through the comments, I agree with:

• Theme-registered patterns, templates, and demos must be accessibility-ready, and failures there should block the accessibility-ready tag.
• Accessibility issues in core patterns/blocks itself should not block the accessibility-ready tag.
• But if theme design decision causes the failure in a core block, then that is the fault of the theme and must block the accessibility-ready tag.