Accessibility-Ready Directory Changes Coming!  🔗 **Source:** [Accessibility-Ready Directory Changes Coming!](https://make.wordpress.org/accessibility/2026/10/05/accessibility-ready-directory-changes-coming/#full-text) > [!note]+ Document Notes > tags: [wordpress-theme-directory, accessibility-ready-tag, theme-review, wordpress-accessibility-team, meta-trac] > author: WordPress Accessibility Team > source: Make WordPress Accessibility > reference: https://make.wordpress.org/accessibility/2026/10/05/accessibility-ready-directory-changes-coming/ > date created: 2026-10-05 14: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. > > # 🏷️ Title: Accessibility-ready directory changes coming! > <!-- deep-read:sections start --> ## 🧭 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) - [🔄 Refactor appendix](#-refactor-appendix--accessibility-ready-directory-changes-coming) ## 📝 Summary This is a descriptive reading of a short announcement, not an endorsement of the policy. The WordPress Accessibility Team published it on Make WordPress Accessibility (make.wordpress.org/accessibility) on 2026-10-05. The captured text carries no byline, so the author field names the team. It is a community team announcement, not commentary, and it covers the Theme Directory's accessibility-ready tag. The capture runs 8 paragraphs and about 245 words. - **What happened.** The team says work is largely completed for making the accessibility-ready tag conditional in the theme directory, "as proposed in meta trac ticket #8427" (¶1). It says a little more work remains to set up the changes, which will briefly delay implementing the updates to which themes the tag lists (¶1). - **The claim.** Three points are given for theme authors and reviewers (¶3-¶5). No theme will be delisted from the directory for not yet meeting the tag's requirements. Adding the tag will not delay theme approval and will be treated as an application to be added to the listings. The tag's value as a signal of trust will be higher because the team will be able to directly remove the listing from themes that do not meet its accessibility guidelines. - **Stated now versus still to do.** The post states as done: work "largely completed" (¶1). It states as plans or promises: the changes will be implemented after a brief delay (¶1), no delisting (¶3), no approval delay (¶4), and removal of the tag from non-meeting themes (¶5). It gives no date, no definition of "briefly," no requirements text, and no description of how an application or a removal works. It does not say what happens to themes that carry the tag today. - **Why it matters.** The tag becomes something a theme applies for and can lose, so a tag listing is meant to carry more weight as a signal. The post's own framing is that the tag's value as a signal of trust rises. - **Key stakeholders.** Theme authors, theme reviewers, the Accessibility Team, and people who filter the directory by the tag. The post does not name individuals. - **Risks and tradeoffs.** "Considerably higher" (¶5) is a prediction with no measure. The post gives no appeal route and no timeline for removals. These are gaps in the announcement, not findings about the policy. - **Bottom line.** A short, plain announcement with three reassurances and one promise of enforcement. The details a theme author needs to act on are not in the captured text. The linked trac ticket exists (see References), and this analysis does not describe its contents. ## 📖 Main content **Where the work stands (¶1).** The team reports the work as largely completed and says more setup remains. The remaining work "is going to briefly delay implementing the updates to what themes will be listed in the tag." That sentence separates two things: building the conditional-tag mechanism (largely done) and changing which themes appear under the tag (delayed). The post does not say which parts of the setup remain or how long "briefly" is. **Points for theme authors and reviewers (¶2-¶5).** The post introduces them as "the important details for theme authors and reviewers to know." Each of the three is a forward statement: 1. No themes will be delisted from the directory because they have not yet met the accessibility-ready requirements (¶3). The post does not say whether a theme that currently carries the tag keeps it. 2. Adding the tag will not delay approval, and the addition will be treated as an application to be added to the listings (¶4). The post does not say who reviews the application, to what standard, or how long it takes. 3. The tag's value as a signal of trust will be higher because the team will be able to directly remove the listing from themes that do not meet the accessibility guidelines (¶5). That is a stated capability and an expected effect, both in the future tense. The post names no removal process. **Plan versus done.** Paragraph 1 is the only status report. Paragraphs 3-5 use "will," so they are commitments or expectations, not descriptions of current behavior. A reader who treats them as already live would be reading ahead of the post. **Event promotion (¶6).** The post closes with a pointer to the schedule for WordPress Accessibility Day 2026, which it says starts "this Wednesday." The post is dated Monday 2026-10-05, so that points to 2026-10-07 by calendar reckoning. The post itself gives no date. The event is not connected to the directory change in the text. **Page furniture (¶7-¶8).** The capture ends with the tag line "#accessibility-ready" and a "Login to Reply" prompt. Neither is body content. **A capture artifact in ¶5.** The sentence "do not meet our accessibility guidelines" is interrupted in the capture by a glossary-style definition of "Accessibility," including a Wikipedia URL. The definition text is not the author's sentence. It looks like inline glossary markup flattened into the text by the REST API fetch. This is a property of the capture and possibly of the published page's markup, which the capture cannot show. ## 🗒️ Notes #### 📄 ¶1-¶2 Status and the setup of the list - The post states work on the conditional tag is "largely completed" and ties it to meta trac ticket #8427. - More setup remains, and the post says it will briefly delay implementing the updates to what themes will be listed in the tag. - ¶2 is a lead-in line ending in a colon: the important details for theme authors and reviewers follow. #### 📄 ¶3-¶5 The three points - ¶3: no themes will be delisted from the directory for not yet meeting the tag's requirements. A promise. - ¶4: adding the tag will not delay approval and will be treated as an application to be added to the listings. A promise about process, with no process described. - ¶5: the tag's value as a trust signal will be higher because the team will be able to directly remove the listing from themes that do not meet the guidelines. An expectation plus a stated future capability. #### 📄 ¶6-¶8 Event pointer and page elements - ¶6 promotes WordPress Accessibility Day 2026, "this Wednesday," and says it is not too late to register. - ¶7 is the "#accessibility-ready" tag line. ¶8 is the "Login to Reply" prompt. - None of the three adds a claim about the directory change. ## 📚 References Links below come from the supplied link list (4 entries). Anchor text is the article's. **Article** - [Accessibility-ready directory changes coming!](https://make.wordpress.org/accessibility/2026/10/05/accessibility-ready-directory-changes-coming/), WordPress Accessibility Team, Make WordPress Accessibility, 2026-10-05. **Links in the captured markup** - "meta trac ticket #8427" (¶1): https://meta.trac.wordpress.org/ticket/8427. This is the post's own source for the proposal. The post says the change was "proposed" there. This analysis did not read the ticket and does not describe its contents beyond what the post says. - "schedule for WordPress Accessibility Day 2026" (¶6): https://wpaccessibility.day/2026/schedule/. The event's schedule page. It is relevant to the closing promotion only. - "#accessibility-ready" (¶7): https://make.wordpress.org/accessibility/tag/accessibility-ready/. The site's tag archive for the post's tag. - "Login to Reply" (¶8): a login.wordpress.org link with a redirect back to the post's comment form. It is page furniture, not a source for any claim. **Claims with no link in the captured markup.** The three points in ¶3-¶5, the statement that no themes will be delisted, the approval and application treatment, and the removal capability have no link in the captured markup to a written policy, requirements document, or handbook page. The post attributes the proposal to the trac ticket but does not point to any requirements text. The Wikipedia URL in ¶5 appears inside glossary-style text in the capture, not as a linked anchor in the link list. ## 🗣️ Paraphrase The WordPress Accessibility Team says it has largely finished the work to make the Theme Directory's accessibility-ready tag conditional, as proposed in a Meta trac ticket, and that a bit more setup will briefly delay changes to which themes appear under the tag. It lists three things theme authors and reviewers should know. No theme will be removed from the directory for not yet meeting the tag's requirements. Adding the tag will not slow approval and will be handled as an application to be listed. And because the team will be able to remove the tag listing from themes that fall short of its accessibility guidelines, the tag should be a stronger trust signal. The post ends by promoting WordPress Accessibility Day 2026, which it says starts this Wednesday. ## 📰 Newsletter **The accessibility-ready tag is about to become conditional.** The WordPress Accessibility Team announced on 2026-10-05 that work to make the Theme Directory's accessibility-ready tag conditional is largely complete, with some setup left that will briefly delay the change to which themes the tag lists. The post gives theme authors and reviewers three points. No theme gets delisted from the directory for not yet meeting the tag's requirements. Adding the tag won't delay approval and will be treated as an application. And the team says it will be able to remove the tag listing from themes that don't meet its accessibility guidelines, which it expects to raise the tag's value as a trust signal. All three are stated in the future tense, and the post gives no dates or requirements text, so treat them as the team's plan. Read the original: [Make WordPress Accessibility](https://make.wordpress.org/accessibility/2026/10/05/accessibility-ready-directory-changes-coming/). ## ✅ Action items These items concern the reader's own practices. They don't set requirements for any team. #### DevRel - Developer advocacy: when you cite the change, say it is announced and not yet live, and quote the post's "will" statements as plans. - Education: draft a short guide for theme authors on what the accessibility-ready requirements are, sourced from the Theme Directory handbook and not from this post, which does not list them. - Developer experience: no direct action from this source; nearest relevance is a checklist theme authors can run before applying for the tag. - Developer marketing: avoid describing the tag as "conditional now." The post says implementation of the list changes is briefly delayed. - Community management: when sharing, note that no delisting is promised and the removal capability is described as a future one. - Internal/external: if asked how applications work, answer that the post does not say. #### OSPO - Policy and governance: if your organization ships themes, record that the tag is moving to an application model and re-check status after the team announces the go-live. - License compliance: no direct action from this source. - Security management: no direct action from this source. - Software inventory: list which of your themes carry the accessibility-ready tag today, so you can compare after the change. - Developer support: prepare a plain answer for "will my theme lose its tag," using the post's own words: unspecified. - Community engagement: no direct action from this source; nearest relevance is WordPress Accessibility Day 2026, the post's closing pointer. - Strategic alignment: no direct action from this source. #### Community - Maintainers: if you maintain a tagged theme, audit it against the published accessibility-ready requirements now. The post says removal is coming for themes that don't meet them. - Contributors: no direct action from this source; nearest relevance is helping reviewers test themes against the requirements. - Sponsors: no direct action from this source. - Ecosystem: no direct action from this source. #### WordPress - Core: no direct action from this source. - Core Performance: no direct action from this source. - Core AI: no direct action from this source. - Core Program Team: no direct action from this source. - Mobile: none. - Playground: none. - Community: none directly; see Community headings above. - Training: no direct action from this source; nearest relevance is teaching theme authors how to meet accessibility-ready requirements. - Marketing: none. - Support: keep a short answer ready for "what does the accessibility-ready tag mean after this change." Today, the post's answer is that the details are to come. - Design: none directly; nearest relevance is that theme designs submitted for the tag need to meet the requirements. - Documentation: the post names no handbook page for the requirements. If one exists, link it from the announcement. If it doesn't, that is a documentation gap to raise. - Photos: none. - TV: none. - Polyglots: none. - Accessibility: the post's author team. Nearest relevance is the open items in the Questions section: requirements link, timeline, removal process, appeal path. - Meta: the post cites meta trac ticket #8427 as the proposal's source. Nearest relevance is confirming the ticket status matches "largely completed." - CLI: none. - Hosting: none. - Tide: none. - Openverse: none. - Themes: the Themes team's review process is where applications for the tag land. The post says adding the tag will not delay approval. Confirm with the team how reviewers handle the application step. - Plugins: none. #### The WPOCC - Programs: no direct action from this source. - Projects: no direct action from this source. - Funding experiments: none. ### FAIR - Technical independence: no direct action from this source. - Policies and covenants: no direct action from this source. - Productized governance artifacts: no direct action from this source; nearest relevance is that the tag is a directory-level quality signal that other directories would need to define for themselves. ## 🧪 Hypotheses 1. Once the tag is an application and removal is possible, the share of directory themes carrying the tag drops in the first review cycle and then rises as authors apply. 2. Theme authors who currently hold the tag will be more likely to audit their themes after the announcement than before it. 3. Adding the tag as an application does not change median theme approval time. 4. Themes removed from the tag listing will appear in support requests citing confusion about the criteria more than citing disagreement with the criteria. 5. A requirements link placed directly in the announcement would reduce "what are the requirements" questions in the comments. ## 📊 Methodology - **H1.** Count tagged themes in the directory before the go-live and at 30, 60, and 90 days after. Report the net change and the number of applications, if the team publishes it. - **H2.** Survey tagged theme authors before and after the announcement on whether they ran an accessibility audit in the prior 30 days. Compare proportions. - **H3.** Collect theme submission-to-approval times for 90 days before and 90 days after, split by whether the tag was requested. Compare medians. - **H4.** Code support-forum and Slack posts about tag removals by reason: criteria unclear, criteria disputed, process unclear. - **H5.** Compare comment counts asking for requirements on this post with comment counts on an equivalent announcement that links the requirements. ## ❓ Questions - Where are the accessibility-ready requirements written down, and does the post's "requirements" refer to that page? - Does a theme that carries the tag today keep it until the list changes are implemented? - How long is "briefly delay," and where will the go-live be announced? - Who reviews an application for the tag, and against what checklist? - What triggers a removal, and what notice does a theme author get? - Is there a way to dispute a removal or reapply? - What does "directly remove that listing" mean for a theme's directory page versus the tag filter? - Does "will be treated as an application" mean the tag disappears from a theme's page until approved? ## 🔮 Future research - **Tag outcomes.** Track whether the conditional tag changes the accessibility of themes users actually install, not only the count of tagged themes. - **Signal value.** Test whether users filtering by the tag trust it more after removal becomes possible, since ¶5 predicts that effect. - **Announcement clarity.** Compare how well announcements that list requirements inline versus by link inform authors, using this post as the baseline. - **Review capacity.** Measure reviewer time per application once applications exist. ## 💡 Implications - **Practice.** Theme authors who want the tag will need to apply and keep meeting the guidelines. The post does not say how often meeting them is checked. - **Policy.** The post separates directory listing from the tag: no delisting for missing the tag's requirements. That keeps the accessibility signal from becoming a gate on publishing. - **Security.** No direct implication from the post. - **Education.** The post names no learning resource for the requirements, so authors rely on existing handbook pages. The Accessibility Day pointer in ¶6 is the only learning link. - **Funding.** The post mentions no funding and no reviewer capacity. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid Grade Level of about 11.8 and Flesch Reading Ease of about 45, from a simple syllable heuristic on about 195 words of body text (the glossary definition and page furniture excluded). Two long sentences (¶1, ¶5) raise the level. The three bullet-like points are short. #### 👀 Visual learners - Present: no figure, diagram, or image appears in the captured text. - Improve: a small before/after table of the tag's behavior (today versus after the change) would show the three points at a glance. #### 🔊 Aural learners - Present: no audio is referenced in the captured text. The linked Accessibility Day event is a separate resource. - Improve: no audio version of the announcement is mentioned. #### 🗣️ Verbal learners - Present: short paragraphs, one claim each, with a lead-in sentence (¶2) before the three points. - Improve: define "accessibility-ready tag" and "delisted" in a clause each for readers new to the directory. #### 🧩 Kinesthetic learners - Present: no exercise or tool in the post. - Improve: link a checklist an author can run against their own theme. #### 🧠 Logical learners - Present: the three points are discrete and numbered in effect, so a reader can check each separately. - Improve: state what is done, what is planned, and what is unknown in separate lines. The post mixes tenses in ¶1 and ¶5. #### 🧑‍🤝‍🧑 Social learners - Present: a "Login to Reply" prompt invites comments, and ¶6 invites readers to an event. - Improve: no discussion question is posed in the captured text. #### 🧘‍♀️ Solitary learners - Present: the post is self-contained for a reader who knows the directory, with one external link for the proposal. - Improve: a reader new to the tag has no explanation of what it currently means. #### 🌿 Naturalistic learners - Present: none; the content is about directory policy. - Improve: not applicable. ## 📊 Accessibility assessment This section judges the post as published, from the captured text and link list only. Rendered contrast, focus order, and image alt text are unknowable from this capture. It is kept separate from the policy being announced: nothing here is a view on the accessibility-ready tag change itself. #### Screen reader semantics - Present: the capture shows no heading text inside the body. The title is a sentence ending in an exclamation mark ("coming!"), which is a plain title and names the topic. ¶2 ends with a colon and introduces ¶3-¶5. The capture flattens lists, so whether ¶3-¶5 are a real list element or three separate paragraphs is not visible. - Improve: if the three points are a list, mark them up as one (WCAG 2.2 AA 1.3.1 Info and Relationships) so a screen reader announces "list, 3 items." If they are paragraphs, the lead-in colon in ¶2 loses its structure for assistive technology. - The glossary-style text in ¶5 is the main semantic concern. The capture shows a full definition of "Accessibility," with a Wikipedia URL, running into the sentence "do not meet our accessibility guidelines." If a screen reader reads that definition inline, the sentence is interrupted by a 50-word definition and the repeated word "Accessibility Accessibility." If it is a tooltip or description attached to the term, it may not be announced at all. The capture cannot show which. Check against 1.3.1 and 3.1.3 Unusual Words (AAA, a useful benchmark, not an AA requirement). #### Keyboard navigation - Present: the link list has four ordinary anchors as far as the capture shows. - Improve: not verifiable from text. Check 2.1.1 Keyboard and 2.4.7 Focus Visible, including whether the glossary term is keyboard-reachable and whether its definition is available on focus as well as hover (1.4.13 Content on Hover or Focus). #### Contrast and readability - Present: unknowable from the capture. Paragraphs are short, with one claim each. - Improve: verify 1.4.3 Contrast (Minimum) on body text and link color, including any dotted or styled glossary term. #### Text resizing and reflow - Present: the content is text only, so it should reflow. - Improve: verify 1.4.4 Resize Text and 1.4.10 Reflow at 320 CSS px and 200% zoom. #### Media and captions - No media referenced in the captured text. The post links to an event schedule (¶6) but embeds no video or audio, and the text does not mention captions or transcripts. #### Forms and interactions - Present: the capture shows a "Login to Reply" link, which leads to a login page that redirects back to the comment form. The comment form itself is not in the capture. - Improve: link text "Login to Reply" states its purpose and passes 2.4.4 Link Purpose (In Context). The tag link "#accessibility-ready" (¶7) reads as a hashtag. Its destination, a tag archive, is not stated by the text, so check 2.4.4 and consider "Posts tagged accessibility-ready." - The two body links ("meta trac ticket #8427" and "schedule for WordPress Accessibility Day 2026") have descriptive text. They pass 2.4.4 on their face. #### Standards reference - Likely items to verify against WCAG 2.2 AA: **1.3.1** for the list structure of ¶3-¶5 and the glossary term in ¶5. **1.4.13** for hover and focus content if the definition is a tooltip. **2.4.4** for "#accessibility-ready." **1.4.3**, **1.4.4**, and **1.4.10** need the rendered page. Plain-language content (short sentences, defined terms) supports 3.1 Readable at a general level, with 3.1.3 and 3.1.5 as AAA benchmarks only. ## 🌍 DEIB assessment #### Cultural breadth - Present: the post addresses the global theme-author community and uses no regional idiom beyond "take a moment and check out." - Improve: a global event is promoted with "this Wednesday" and no date or time zone. Readers outside the publishing time zone or reading later cannot tell which Wednesday. #### Inclusive language - Present: no exclusionary language in the captured text. "Meets our accessibility guidelines" assumes the reader knows which guidelines. - Improve: "Accessibility-ready" and "delisted" are insider terms. A clause defining each would help new authors. #### Neurodiversity support - Present: short paragraphs, a lead-in line, and three separate points support scanning. - Improve: separate what is done from what will happen, since mixed tenses in ¶1 and ¶5 add load for readers who parse tense literally. #### Representation - Present: the post names no individuals, so no pronouns appear and none are inferred. - Improve: not applicable beyond noting the team publishes under its own name. #### Psychological safety - Present: ¶3 reassures authors that no theme is delisted for not meeting the tag's requirements. The tone is neutral and invites registration for the event. - Improve: ¶5 says the team can "directly remove that listing" with no stated process, which could leave an author unsure about notice or recourse. This is a gap in the announcement, not a judgment on the policy. ## ✅ Logical validity #### Strong reasoning - **Scope separation, ¶3.** The post separates delisting from the tag. No delisting for missing the tag's requirements keeps the tag from acting as a publishing gate. - **Process reassurance, ¶4.** The post says the tag application will not delay approval, which addresses the most likely author concern directly. - **Honest status, ¶1.** The team says the work is "largely completed" and that more remains, and it names the cause of the delay. - **Source named, ¶1.** The proposal is tied to meta trac ticket #8427, which the link list confirms is linked. #### Fallacies No formal fallacies. The post is a short announcement, not an argument. What I checked: whether the reason in ¶5 follows from the stated capability, whether tenses are consistent, and whether promises are labeled as such. Points about framing: - **Prediction stated as consequence, ¶5.** "The value of the accessibility-ready tag as a signal of trust will be considerably higher" is a prediction presented as the direct result of the removal capability. The post gives no measure of "considerably" or of the current value. *Fix:* "should be higher" and say how the team will check. - **Capability without process, ¶5.** "We will be able to directly remove that listing" says the team can remove, not when or how. A reader can't tell from the post whether removal is routine or exceptional. *Fix:* link the criteria and the notice step. - **Undefined timing, ¶1.** "Briefly delay" has no date. A reader can't plan around it. *Fix:* give a target week or say none is set. - **Requirements assumed, ¶3.** "The requirements for the accessibility-ready tag" appears with no link in the captured markup. *Fix:* link the requirements page. Where the post uses "considerably" (¶5), it is an unmeasured qualifier from the author. This analysis does not adopt it. #### Tone of voice - Plain, friendly, and brief. It reads as one team speaking in first-person plural ("our accessibility guidelines," "we've got a schedule"). The closing event promotion (¶6) shifts to a promotional register with "packed with great information." The post takes no view beyond the team's own plan. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response pattern to an accusation, and this is a neutral announcement. - **Deny.** None. No accusation is addressed. - **Attack.** None. No person or group is criticized. - **Reverse victim and offender.** None. - **Reassurance, ¶3-¶4.** The post preempts likely author concerns (delisting, approval delay). That is anticipatory reassurance, not a DARVO move. ## 🎯 Conclusion The post says the work to make the Theme Directory's accessibility-ready tag conditional is largely done and that a little more setup will briefly delay the change to which themes the tag lists. It gives three points as plans: no delisting for unmet requirements, no approval delay from adding the tag, and the team's ability to remove the tag listing from themes that fall short, which it expects to raise the tag's trust value. What the post does not establish: a date, the requirements text, how an application or a removal works, whether themes with the tag today keep it, or any appeal path. The linked trac ticket is the post's source for the proposal, and this analysis does not describe its contents. As published, the post is clear and short, with one capture-visible concern: a glossary definition running into a sentence in ¶5, which may be a screen reader problem depending on the page's markup. **Next steps for readers:** if you maintain a tagged theme, check it against the published requirements now. Watch for a go-live announcement. Treat every "will" statement as the team's plan until it is implemented. ## 🔄 Refactor Appendix — Accessibility-ready directory changes coming! > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 4 Literature, 1 Permanent. Resonance filter applied: the event promotion > and page furniture were dropped as unrelated to the directory change. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] The team promises no delisting for unmet requirements > [!quote] [¶3] > With this change, no themes will be delisted from the directory because they have not yet met the requirements for the accessibility-ready tag. **Context & use**: - ¶3, first of three points for theme authors and reviewers. A promise in the future tense. - It separates directory listing from the tag. The post gives no requirements link. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Tag applications are promised not to slow approval > [!quote] [¶4] > Adding the accessibility-ready tag will not delay getting your theme approved, and will be treated as an application to be added to the listings. **Context & use**: - ¶4, a process promise with no process described. - Use with H1 when contrasting what the post promises with what it leaves undefined. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H3] The team predicts a stronger trust signal > [!quote] [¶5] > The value of the accessibility-ready tag as a signal of trust will be considerably higher **Context & use**: - ¶5, a prediction. The post gives no measure of "considerably" or of the tag's current value. - The stated mechanism, directly removing the listing from themes that fall short, follows in the same sentence. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H4] The post reports work as largely complete > [!quote] [¶1] > There’s a little bit more work to be done to set up the changes, which is going to briefly delay implementing the updates **Context & use**: - ¶1, the only status report in the post. It separates what is done from what is delayed. - "Briefly" has no date. This is the main item to watch for a follow-up announcement. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Announce the plan, the status, and the gaps separately **Claim** (one sentence, Courtney's voice): A policy announcement is easier to act on when it labels what is done, what is promised, and what is not yet defined, instead of mixing them in future-tense sentences. **Evidence pointer**: [[#H1]] · [[#H3]] · [[#H4]] **Scope & conditions**: Holds for short community announcements that ask readers to change behavior. Weakens when a linked document already states the requirements and timeline. This post links only a trac ticket for the proposal, and the captured text points to no requirements page. **Links**: - [[Reading policy announcements]] — because extends - [[Plan versus status in release notes]] — because contrasts on tense and dates - [[Theme directory quality signals]] — because applies-in the accessibility-ready tag <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Find the written accessibility-ready requirements and check whether the announcement needs to link them — https://make.wordpress.org/accessibility/2026/10/05/accessibility-ready-directory-changes-coming/ #fleeting #inbox - [F2] Watch for a go-live announcement and compare it to the "briefly delay" in ¶1 #fleeting #inbox - [F3] Open question: do themes with the tag today keep it until the list changes are implemented? #fleeting #inbox - [F4] Check how the glossary term in ¶5 is announced by a screen reader on the published page #fleeting #inbox - [F5] Article seed: "Done, planned, undefined," a short note on labeling status in announcements #fleeting #inbox #articleseed ### → Things 3 (max 2 actions) - [ ] Look up the accessibility-ready requirements and compare them to my own themes before the go-live — theme audit, 30 min #things - [ ] Test the ¶5 glossary term on the published post with a screen reader and keyboard — accessibility check #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Accessibility-Ready Directory Changes Coming!.md|Accessibility-Ready Directory Changes Coming! by WordPress Accessibility Team]] ## Highlights - Work is largely completed for making the accessibility-ready tag conditional in the theme directory, as proposed in meta trac ticket #8427. There’s a little bit more work to be done to set up the changes, which is going to briefly delay implementing the updates to what themes will be listed in the tag. ([View Highlight](https://read.readwise.io/read/01m46mbh932d73pkg7s8dttwxe)) - Note: [H4] The post reports work as largely complete - Tags: atom/literature/h3 - - With this change, no themes will be delisted from the directory because they have not yet met the requirements for the accessibility-ready tag. ([View Highlight](https://read.readwise.io/read/01m46mb9s9am6q19xtxay4ep11)) - Note: [H1] The team promises no delisting for unmet requirements - Tags: atom/literature/h1 - - Adding the accessibility-ready tag will not delay getting your theme approved, and will be treated as an application to be added to the listings. ([View Highlight](https://read.readwise.io/read/01m46mbbyxptfk9ksy5fp781qz)) - Note: [H2] Tag applications are promised not to slow approval - Tags: atom/literature/h2 - - The value of the accessibility-ready tag as a signal of trust will be considerably higher, as we will be able to directly remove that listing from themes that do not meet our accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) guidelines. ([View Highlight](https://read.readwise.io/read/01m46mbef2jnbk9xdvzs5r9jyh)) - Note: [H3] The team predicts a stronger trust signal - Tags: atom/literature/h3