Planning for the Accessibility Lab Plugin  🔗 **Source:** [Planning for the Accessibility Lab Plugin](https://make.wordpress.org/accessibility/2026/09/09/planning-for-the-accessibility-lab-plugin/) > [!note]+ Document Notes > --- > tags: [wordpress-accessibility, feature-plugin, experimentation, product-scoping, contributor-onboarding, accessibility-lab, open-source-process] > author: Make WordPress Accessibility > source: make.wordpress.org > reference: https://make.wordpress.org/accessibility/2026/09/09/planning-for-the-accessibility-lab-plugin/ > date created: 2026-09-11 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > [!note] On the length of this source > > The post is 207 words and that is its complete published length — verified against a direct > > fetch, not truncated in capture. A short meeting announcement carries one genuinely load-bearing > > idea, and the sections below are sized to what is actually there rather than padded to match > > the template's usual density. Where a section does not apply, it says so. > # 🏷️ Title: Planning for the Accessibility Lab Plugin > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#️-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > **Four outbound links, all functional rather than decorative.** Verified by extracting every `<a href>`. > - [The original Accessibility Lab announcement, 21 August 2026](https://make.wordpress.org/accessibility/2026/08/21/help-shape-the-accessibility-l) — the prior context. > - [Meeting time as a timezone-aware fixed-time link](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20260917T1500) — 17 September 2026, 15:00 UTC. Linking a UTC time to a converter rather than stating it bare is a small, real accessibility and inclusion practice for a global contributor base. > - [The #accessibility tag on Make](https://make.wordpress.org/accessibility/tag/accessibility/). > - [github.com/WordPress/accessibility-lab](https://github.com/WordPress/accessibility-lab) — the plugin's new home. > ## 📝 Summary > - **What happened.** With WordPress 7.1 shipped, the Accessibility team is scoping the first features for the Accessibility Lab plugin, announced 21 August. A discussion meets 17 September at 15:00 UTC in the #accessibility Slack channel, sharing the slot with the bi-weekly team meeting. The plugin has moved to the WordPress GitHub organization. > - **Why it matters.** For one sentence at the end, which does real work: the plugin is explicitly **not** for fixing known accessibility problems. It is a vehicle for exploration, and issues without a clear solution are stated as the *preferred* kind. > - **Key stakeholders.** The WordPress Accessibility team; contributors who can participate synchronously in Slack and those who cannot, for whom two asynchronous paths are provided; and eventually the plugin's users, whose role is to generate evidence rather than to receive fixes. > - **Risks and tradeoffs.** An experimentation vehicle invites scope creep toward becoming a fix-it plugin, which is precisely what the closing paragraph pre-empts. Whether the boundary holds is the thing to watch. > - **Bottom line.** A routine meeting announcement carrying an unusually disciplined product decision: a plugin whose success criterion is learning, with each proposed feature required to state what shipping it is meant to teach and how that will be measured. > ## 📖 Main Content > The post does three things in 207 words. > **It sets a decision point.** WordPress 7.1 is done, so the plugin's first features can be scoped. The meeting is 17 September at 15:00 UTC, deliberately co-located with the existing bi-weekly Accessibility Team meeting rather than adding a new commitment to contributors' calendars. > **It states three goals, and the third is the unusual one.** Brainstorm candidate features; decide which to prioritize for an initial release; and — for each — establish what the team aims to learn by shipping it, and how success will be measured. Most feature-scoping sessions stop at the first two. Requiring a stated learning objective and a measurement plan before building is a research posture rather than a delivery one, and it is what makes the closing scope boundary coherent rather than merely restrictive. > **It keeps participation open to people who cannot attend.** Ideas can arrive as a comment on the post or as a new issue in the repository. For a global volunteer project where a fixed UTC slot excludes whole regions, naming asynchronous paths in the announcement itself is the difference between an open process and a nominally open one. > Underneath all of it sits the closing paragraph, which defines the plugin by what it is not. > ### 🗒️ Notes > - **The trigger and the timing.** Release work first, exploration after — the sequencing is stated rather than assumed. > > [!quote] > > The Accessibility Lab plugin was announced on August 21st, and now that WordPress 7.1 is wrapped up, it’s time to start scoping out the first features to target for release. > - **The meeting, co-located with an existing commitment.** > > [!quote] > > we’ll meet on Thursday, September 17, 2026 at 03:00 PM UTC in the #accessibility channel on Slack. This is the same time as the bi-weekly Accessibility Team meeting. > - **The third goal, which is the process discipline.** Note that it applies "for each goal" — the learning objective is a per-feature requirement, not a project-level aspiration. > > [!quote] > > For each goal, establish what we aim to learn by shipping the feature in the plugin, and how we can measure success. > - **The move to the WordPress GitHub organization**, which changes who can contribute and under what governance. > > [!quote] > > Since the original announcement, the plugin has been moved to the WordPress Github repository. > - **Asynchronous participation, named explicitly.** > > [!quote] > > If you are unable to attend the meeting, your brainstorming ideas and priorities can be shared either in a comment on this post or as a new issue in the plugin repository. > - **The scope boundary — the reason to keep this post.** It defines the plugin negatively and then inverts the normal issue-quality signal. > > [!quote] > > Remember that the goal for this plugin is to provide a mechanism for exploration and experimentation, and not a place to fix common accessibility problems. If you don’t have a clear answer to how a problem might be solved, that is very possibly exactly the type of issue we want to explore! > ## 📚 References > Listed in the in-page References section. One practice worth naming: the meeting time links to a timezone converter rather than stating a bare UTC figure. For a contributor base spread across every timezone, that is a two-second courtesy that removes a genuine barrier, and most announcements skip it. > ## 🗣️ Paraphrase > The Accessibility Lab plugin was announced on 21 August, and with WordPress 7.1 finished it is time to scope the first features for release. > An initial discussion will run on Thursday 17 September at 15:00 UTC in the #accessibility Slack channel, in the same slot as the bi-weekly Accessibility Team meeting. > The discussion has three goals: brainstorm the features to develop; decide which to prioritize for an initial release; and, for each, establish what the team wants to learn by shipping it and how success will be measured. > The plugin has moved to the WordPress GitHub organization since the announcement. > Anyone who cannot attend can share ideas and priorities as a comment on the post or as a new issue in the repository. > The plugin exists for exploration and experimentation, not for fixing common accessibility problems. An issue you The [Accessibility Lab plugin was announced on August 21st](https://make.wordpress.org/accessibility/2026/08/21/help-shape-the-accessibility-lab-plugin/), and now that WordPress 7.1 is wrapped up, it’s time to start scoping out the first features to target for release. For an initial discussion, we’ll meet on [Thursday, September 17, 2026 at 03:00 PM UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20260917T1500) in the [#accessibility](https://make.wordpress.org/accessibility/tag/accessibility/) channel on Slack. This is the same time as the bi-weekly Accessibility Team meeting. The discussion has three initial goals: 1. Brainstorm the features we want to develop. 2. Decide which features should be prioritized to prepare for an initial release. 3. For each goal, establish what we aim to learn by shipping the feature in the plugin, and how we can measure success. Since the original announcement, the plugin has been moved to the [WordPress Github repository](https://github.com/WordPress/accessibility-lab). If you are unable to attend the meeting, your brainstorming ideas and priorities can be shared either in a comment on this post or as a new issue in the plugin repository. Remember that the goal for this plugin is to provide a mechanism for exploration and experimentation, and not a place to fix common accessibility problems. If you don’t have a clear answer to how a problem might be solved, that is very possibly exactly the type of issue we want to explore!, Planning for the Accessibility Lab Plugin, Make WordPress Accessibility, 01m28vdtnmmar2r60trprtt9rf.