Planning for the Accessibility Lab Plugin - CourtneyR.dev's 2nd Brain

Planning for the Accessibility Lab Plugin ![rw-book-cover](https://s.w.org/images/home/wordpress-default-ogimage.png) 🔗 **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 do not know how to solve is very possibly exactly the kind worth raising. ## 📰 Newsletter **A WordPress plugin whose success metric is learning, not fixing** [This week's Make Accessibility post](https://make.wordpress.org/accessibility/2026/09/09/planning-for-the-accessibility-lab-plugin/) is 207 words of meeting logistics with one paragraph that is worth the click: > 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! Read that second sentence again. It inverts the usual rule of open-source issue triage. Normally a good issue comes with a reproduction and a proposed fix, and "I don't know how to solve this" is what gets a ticket closed as unactionable. Here it is the *qualifying* condition. That only makes sense because of the third goal listed for the scoping meeting: > For each goal, establish what we aim to learn by shipping the feature in the plugin, and how we can measure success. Per feature, before building: what is shipping this supposed to teach us, and how will we know. That's a research posture, and it's what makes "don't bring me solved problems" coherent rather than just contrarian. **Two practical notes.** The plugin has moved to [github.com/WordPress/accessibility-lab](https://github.com/WordPress/accessibility-lab). And the meeting is **17 September, 15:00 UTC** in #accessibility on Slack — co-located with the existing bi-weekly team meeting rather than added on top of it, with comment and issue routes offered for anyone the timezone excludes. Small courtesies, but they're the difference between an open process and one that's open on paper. If you've got an accessibility problem you've been stuck on for years, this is explicitly the venue. ## ✅ Action Items #### DevRel - Flag the 17 September meeting to anyone sitting on an unsolved accessibility problem; the post explicitly wants those. - The learning-objective-per-feature framing is a reusable pattern for any experimental feature plugin. #### OSPO - Worth noting as a governance pattern: an explicitly bounded experimentation vehicle, separate from production fixes, with the boundary stated in every announcement. #### Community - The asynchronous participation routes are a model for meeting announcements generally. Copy the pattern: fixed-time link plus comment plus issue. #### WordPress - **Accessibility** — the owning team; the scope boundary needs restating at each meeting or it will erode, which is presumably why it appears here. - **Plugins** — a feature plugin whose purpose is research rather than remediation is worth understanding as a category, since directory users will read it as a fix-it tool. - **Core** — findings from the lab are the intended input to core; the measurement plan is what makes that transfer possible. - **Documentation** — "what do we aim to learn, and how will we measure it" belongs in feature-plugin guidance generally. - **Training / Community / Meta** — signal-boost the meeting and the asynchronous routes. - **Design** — likely participants in feature brainstorming. - **Core Performance / Core AI / Core Program Team / Mobile / Playground / Marketing / Support / Photos / TV / Polyglots / CLI / Hosting / Tide / Openverse / Themes** — not applicable to this source. #### The WPOCC - The bounded-experiment model, with stated learning goals, is a pattern worth borrowing for programme design. ### FAIR - Not applicable to this source. ## 🧪 Hypotheses 1. **The scope boundary erodes without repetition.** It appears in this post because it has already had to be defended; expect it in every subsequent one. Testable by reading the next few announcements. 2. **Issues arrive as solved problems anyway.** Contributors are trained by every other repository to bring fixes. Testable against the issue tracker's first fifty items. 3. **The measurement requirement is the part that slips.** Stating what a feature should teach is easy at brainstorm time and hard to enforce at merge time. Testable against whether shipped features carry stated learning goals. 4. **Asynchronous contributions outnumber synchronous ones.** A single 15:00 UTC slot excludes much of the Americas and Asia-Pacific. Testable by comparing comment and issue volume against meeting attendance. 5. **The GitHub move increases contribution from outside the regular team.** Testable by contributor overlap between the repo and the Slack channel. ### 📊 Methodology - **Source type.** An official team meeting announcement on make.wordpress.org, 207 words, published 2026-09-09. Reader recorded the author as the domain; no individual byline captured, which is normal for Make posts and does obscure who is accountable for the scope decision. - **What it establishes.** That the meeting is scheduled, that the repository has moved, and what the team states the plugin is for. - **What it does not establish.** Any outcome. No features are named, no decisions are made, and nothing is measured — the post is an invitation, not a report. - **Verification performed for this note.** All four links extracted and checked. The post's length was confirmed against the source rather than assumed from the capture, because a 207-word result would otherwise be indistinguishable from a truncated one — and treating a complete short post as a scraping failure is the mirror error of accepting a truncated one. - **No conflicts identified.** A project team announcing a meeting about its own plugin, with nothing sold and nothing claimed. ### ❓ Questions - What features are actually under consideration? The post deliberately does not say, since that is the meeting's purpose. - How will "what we aim to learn" be enforced at merge time rather than at brainstorm time? - What is the intended path from a lab finding to a core change, and who decides? - Does the plugin ship to the directory, and if so how will its purpose be communicated to users who will read it as a fix-it tool? - Why 15:00 UTC, and is the slot reviewed for regional exclusion? - What happens to an explored problem that turns out to have no good solution — is that a publishable result? ### 🔮 Future Research - Read the 21 August announcement for the plugin's fuller rationale; this post assumes it. - Follow the first issues in the repository and check whether they match the stated "no clear answer" preference or default to solved problems. - Track whether shipped features carry stated learning objectives, which is the measurable test of whether the third goal survived. - Compare against other WordPress feature plugins to see whether any has previously defined itself by what it will not fix. ### 💡 Implications - **Practice.** For anyone running an experimental project: state what each feature is meant to teach and how you will know, before building. That single requirement changes what gets proposed. - **Policy.** Separating an exploration vehicle from a remediation one, explicitly and repeatedly, is a governance pattern that keeps a research project from being consumed by support demand. - **Security.** Not applicable to this source. - **Education.** The inversion — unsolved problems are the welcome ones — is a genuinely useful thing to teach contributors who have been trained that a good issue comes with a patch. - **Funding.** Not applicable to this source. ### 🧠 Learning Styles Assessment #### 👀 Visual learners Not served, and not needing to be. No diagrams, and nothing in 207 words of logistics requires one. #### 🔊 Aural learners Not served in the post; the actual discussion is synchronous in Slack, which is text rather than audio. #### 🗣️ Verbal learners Well served. Plain, direct, and short enough to read in under a minute. #### 🧩 Kinesthetic learners Well served in the sense that matters here — every route to participating is concrete and linked: a meeting, a comment box, an issue tracker. #### 🧠 Logical learners Well served. Three numbered goals, a stated scope boundary, and a rationale that connects them. #### 🧑‍🤝‍🧑 Social learners Well served. The whole post is an invitation to a group discussion, with the channel named. #### 🧘‍♀️ Solitary learners Well served, and deliberately — the asynchronous routes mean participation does not require being in a room. #### 🌿 Naturalistic learners Not applicable to this source. **Reading level estimate.** Roughly grade 9–11. Short sentences and everyday vocabulary. The prerequisites are organizational rather than linguistic: knowing what a feature plugin is, what Make WordPress is, and what the Accessibility Team does. A first-time contributor will follow the words and may not grasp what they are being invited into — which the linked August announcement presumably addresses. ### 📊 Accessibility Assessment #### Screen reader semantics Appropriate. A short post with a three-item list and no headings, which is correct at this length — imposing heading structure on 207 words would add navigation overhead without benefit. #### Keyboard navigation Four links, all with descriptive anchor text. The meeting-time link carries the full date and time as its anchor rather than "here," which reads correctly out of context. #### Contrast and readability Not assessable from extracted HTML; the Make network uses a consistent theme. Recorded as **not evaluated**. #### Text resizing and reflow Not assessable from the captured content. The post has no tables, code blocks, or wide elements, so reflow is very unlikely to be a problem. #### Media and captions No images, video, or audio in the post. **Not applicable** — and worth stating positively rather than as an absence, since a post with no media has no media accessibility debt. #### Forms and interactions No forms in the post body. Comments are the participation mechanism and were not evaluated. #### Standards reference Against WCAG 2.2 AA: nothing in the captured markup indicates a failure, and **SC 2.4.4 Link Purpose passes clearly** — the timezone-converter link is a particularly good instance, carrying the date and time in the anchor itself. SC 1.4.3, 1.4.4, and 2.4.7 **not evaluated** without the rendered page. For a post from the Accessibility team, the absence of findings is the expected and appropriate result. ### 🌍 DEIB Assessment #### Cultural breadth Better than most meeting announcements. The fixed-time converter link acknowledges a global contributor base, and the asynchronous routes acknowledge that a single UTC slot cannot serve it. The slot itself still favours European and African timezones over the Americas and Asia-Pacific, which the post does not address. #### Inclusive language Neutral and plain. Second person, no idiom, no jargon beyond unavoidable project terms. Readable by a non-native English speaker. #### Neurodiversity support Good, and structurally so. Explicit numbered goals, an explicitly stated scope, and written asynchronous participation routes all reduce the load on anyone for whom a live Slack discussion is difficult. The stated welcome for problems without known solutions also lowers the bar for contributing something uncertain, which is its own accessibility gesture. #### Representation No individuals named — standard for Make posts, and it does make accountability for the scope decision diffuse. On the other hand, an unsigned invitation from a team reads as more open than one from a named gatekeeper, so the trade is not one-directional. #### Psychological safety **The post's strongest DEIB feature.** Telling contributors that not having an answer is a qualification rather than a disqualification directly reduces the fear of proposing something naive. In accessibility work specifically — where practitioners frequently encounter problems nobody has solved — that invitation is substantive rather than decorative. ### ✅ Logical Validity #### Strong reasoning - **The scope boundary is stated positively and negatively**, so there is no ambiguity about what the plugin is for. - **The third goal justifies the boundary.** Requiring a learning objective per feature is what makes "not a place to fix common problems" coherent rather than arbitrary. - **The sequencing is explained** — 7.1 shipped, so scoping can begin. - **Participation constraints are anticipated and answered** in the same post rather than left to a follow-up. #### Fallacies - **None identified**, and the category barely applies. The post makes no argument requiring support: it announces a meeting, states a scope, and invites input. - **One unstated assumption** worth naming: that contributors will read and honour the scope boundary. The "Remember that" opening implies this has been an issue already, and repetition is the only enforcement mechanism the post has. That is a weakness in the situation, not an error in the writing. - **One undefined term.** "Common accessibility problems" marks the excluded category and is not defined anywhere in the post, which leaves the boundary's edge to be negotiated case by case. #### Tone of voice Practical and welcoming, with one exclamation mark doing deliberate work at the end to signal that an unsolved problem is genuinely wanted rather than grudgingly tolerated. No jargon, no gatekeeping, no assumed familiarity beyond project basics. For a post whose main job is to prevent a certain kind of contribution, it manages to read as an invitation. ### 🛡️ DARVO Analysis **Not applicable to this source.** DARVO describes a defensive pattern deployed by someone facing an accusation of harm. This is a meeting announcement for a volunteer project. No accusation, no defence, no victim-offender relation available to invert. **Deny** — Not present. The post asserts a scope rather than denying anything. **Attack** — Not present. No party is criticized. The closing "Remember that" gently corrects an anticipated misunderstanding, which is redirection rather than attack. **Reverse Victim and Offender** — Not present. Recorded for structural consistency across the vault. ## 🎯 Conclusion **Bottom line.** A 207-word meeting announcement carrying one disciplined product decision: the Accessibility Lab plugin is a research vehicle, not a remediation tool, and issues without a known solution are the ones it wants. **The mechanism that makes that credible** is the third scoping goal — for each feature, state what shipping it should teach and how success will be measured. Without that, "we don't fix common problems here" would be a refusal; with it, it is a method. **What to watch** is whether the boundary survives contact with contributors trained everywhere else to arrive with a patch, and whether the learning objectives that are easy to state at brainstorm time are still attached at merge time. **Next steps.** 1. If you have an accessibility problem you have been stuck on, the 17 September meeting is explicitly for it — or file it as an issue if the time does not work. 2. Read the 21 August announcement for the rationale this post assumes. 3. Borrow the learning-objective-per-feature requirement for any experimental work, regardless of domain. ## 🔄 Refactor Appendix — Planning for the Accessibility Lab Plugin > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Resonance filter: if you can't articulate in one line why a claim matters, drop it. ### 📚 Literature Atoms (H3) #### [H1] The plugin is defined by what it will not do > [!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. **Context & use**: - A negative definition stated in a routine announcement, which suggests it has already needed defending. - The boundary that keeps a research vehicle from being consumed by support demand. **Tags**: #xref  #### [H2] An unsolved problem is the qualifying condition > [!quote] > 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! **Context & use**: - Inverts the normal open-source triage rule, where an issue without a proposed fix gets closed as unactionable. - Directly lowers the barrier for contributors sitting on hard problems they cannot articulate a solution to. **Tags**: #xref #aphorisms  #### [H3] Each feature must state what shipping it should teach > [!quote] > For each goal, establish what we aim to learn by shipping the feature in the plugin, and how we can measure success. **Context & use**: - A per-feature learning objective and measurement plan, required before building. - The requirement that makes the exploration-only scope coherent rather than merely restrictive. **Tags**: #xref  #### [H4] Asynchronous participation is named in the announcement > [!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. **Context & use**: - Two written routes offered alongside a synchronous meeting, in the same post rather than on request. - The difference between a process that is open and one that is open only to people in compatible timezones. **Tags**: #xref  ### 🧠 Permanent Candidates (H4) #### [P1] An Experiment Needs a Stated Learning Goal or It Becomes a Feature Request Queue **Claim** (one sentence, Courtney's voice): A project framed as exploration drifts into ordinary delivery unless every proposed piece of work states what shipping it is meant to teach and how that will be measured, because without that test there is no principled way to decline useful-sounding work that would answer no question. **Evidence pointer**: [[#H1]] [[#H3]] — a plugin defined as not-for-fixing, paired with a per-feature requirement to name the learning objective and success measure. **Scope & conditions**: Holds for any effort whose value is knowledge rather than output — research spikes, prototypes, pilot programmes, feature plugins. The learning goal has to be enforced where work is accepted, not only where it is proposed, or it becomes a form filled in at brainstorm time and forgotten at merge. Does not apply to delivery work, where "what will this teach us" is the wrong question and shipping the thing is the point. The negative definition is the enforcement surface: it gives a reviewer something concrete to decline against. **Links** (≥1 with annotation): - [[3. Resources/Permanent Notes/Accessibility Enforced at Authoring Time Beats Post-Hoc Auditing]] — the production-side counterpart; this note covers the exploration vehicle that finds what should later be enforced. - [[3. Resources/Permanent Notes/A Repeatable Workflow Becomes Capacity Only When It Becomes a Skill]] — the same distinction between exploratory and operational work, from the other end. - [[3. Resources/Permanent Notes/A Feature Plugin's Name Sets Expectations Its Code Cannot Meet]] — the risk this scope boundary runs into once the plugin reaches users who read it as a fix.  #### [P2] Inviting Unsolved Problems Surfaces What Solution-Shaped Issue Templates Filter Out **Claim** (one sentence, Courtney's voice): Asking contributors for problems they cannot solve surfaces a class of issue that normal triage discards, because requiring a proposed fix silently selects for problems that are already tractable and hides the ones worth research. **Evidence pointer**: [[#H2]] — "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." **Scope & conditions**: Works only where a venue exists that can absorb unsolved problems without being overwhelmed — which is why it is paired with a bounded experimentation vehicle rather than opened on a production tracker. The selection effect it corrects is invisible by construction: nobody files the issue they cannot articulate a fix for, so the gap never appears in the backlog as a gap. Strongest in domains like accessibility where practitioners routinely hit problems with no known good answer. **Links** (≥1 with annotation): - [[3. Resources/Permanent Notes/Absence of Testimony Indicates Absence of Invitation]] — the same mechanism: what is missing from a record reflects who was asked, not what exists. - [[3. Resources/Permanent Notes/Recruit Accessibility Testers by Input and Output Needs Not by Diagnosis]] — the same correction applied to who is recruited rather than to what is solicited. - [[3. Resources/Permanent Notes/Issue Structure Raises Agent Fix Quality More Than Model Choice]] — the contrasting case, where a highly structured issue is exactly what is wanted; the two apply to different kinds of work.  ### ✏️ Fleeting Queue - [F1] 17 September 2026, 15:00 UTC, #accessibility Slack — the scoping meeting. Asynchronous routes exist if the time does not work. #xref - [F2] Read the 21 August Accessibility Lab announcement for the rationale this post assumes. #xref - [F3] Watch the first fifty issues in github.com/WordPress/accessibility-lab: do they match the stated "no clear answer" preference, or default to solved problems? That is the testable version of whether the boundary holds. #articleseed - [F4] "Common accessibility problems" is the excluded category and is never defined — worth asking where the edge sits. #xref - [F5] Does the learning objective survive to merge time, or is it a brainstorm-time formality? The measurable test of the third goal. #xref ### → Things 3 (max 2 actions) - [ ] Note the 17 September 15:00 UTC Accessibility Lab scoping meeting, or file an issue if the time does not work. #wordpress #things - [ ] Adopt the learning-objective-per-feature requirement for any experimental work in the vault's own projects. #writing #things  📄 **Full text:** [[Full Document Contents/Articles/Planning for the Accessibility Lab Plugin.md|Planning for the Accessibility Lab Plugin by Make WordPress Accessibility]] ## Highlights - For each goal, establish what we aim to learn by shipping the feature in the plugin, and how we can measure success. ([View Highlight](https://read.readwise.io/read/01m28wk47pngpmeg4dcd0ehstt)) - Note: A per-feature learning objective and measurement plan, required before building. This is what makes the exploration-only scope coherent rather than merely restrictive — and the part most likely to slip between brainstorm and merge. - Tags: open-source-process, product-scoping - 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! ([View Highlight](https://read.readwise.io/read/01m28wjy68hqcb87dkezseeeac)) - Note: Inverts the normal open-source triage rule, where an issue without a proposed fix gets closed as unactionable. Here it's the qualifying condition — which only works because each feature must state what shipping it should teach. - Tags: product-scoping, experimentation