The AccessibilityAccessibilityAccessibility (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) Team shares their expertise to improve the accessibility of WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and resources.
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.
The important details for theme authors and reviewers to know:
With this change, no themes will be delisted from the directory because they have not yet met the requirements for the accessibility-ready tag.
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.
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 accessibilityAccessibilityAccessibility (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.
In the meantime, take a moment and check out the schedule for WordPress Accessibility Day 2026, which starts this Wednesday! We’ve got a schedule packed with great information covering a wide range of accessibility topics – if you haven’t registered yet, it’s not too late!
When we announced the new accessibility-ready theme guidelines in May, the accessibilityAccessibilityAccessibility (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) time set an ambitious timeline to re-review all themes and require action from theme authors by June 30th of this year.
Well, that date fled by three weeks ago, and the team hasn’t taken action yet to delist any themes.
The team has found that we need more time to be able to reasonably go through all themes and make progress, so we’re extending this deadline until September 30th, 2026.
What does this deadline mean?
As a theme author, we expect you to have contacted the accessibility ready team using our theme accessibility review request form. That review indicates that you have taken steps to improve your theme and move towards the new requirements, and are engaging on the process. As long as you have submitted the form and begun the process of fixing your theme, your theme will not be delisted from the directory.
On October 1st, any theme that has the accessibility-ready tag and has not requested a re-review will be de-listed.
What does “delisting” a theme mean?
Your theme is no longer visible in the theme directory. You are still able to submit updates to your theme, and all existing installations of your theme will still receive updates. But it will not appear in any theme directory searches or tag views.
What if my theme meets the requirements, anyway?
If you believe your theme meets the requirements, then submit the request form! We’re logging all the requests, so we have records of everybody who has made this request.
If I meet the old requirements, will I meet the new requirements?
No.
There are several new requirements that did not apply to the tag previously, so we expect that all authors will need to make theme updates.
Introducing the AccessibilityAccessibilityAccessibility (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) Lab pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.! The plugin aims to offer a combination of CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. related experiments and practical tools that solve shared problems for all to benefit from. The goal is not to move accessibility fixes out of Core and into a separate plugin.
Please consider this plugin an early approach to gather around and improve before we add it to the plugin repository as a canonical plugin.
Why a canonical plugin
The Accessibility Lab plugin follows the approach of two existing plugins in the WordPress project: Performance Lab plugin and the AI plugin. Each plugin provides a combination of features and experiments that anyone can help test and use. Each plugin is also maintained by their respective team.
From the Performance Lab plugin, the Accessibility Lab plugin takes inspiration from how they ship individual modules as a way to test and get feedback for features slated for Core that can’t exist in Core for different reasons. Unlike Performance Lab, the features won’t be broken into individual plugins. They’ll stay bundled in a single Accessibility plugin for ease of use.
From the AI plugin, it borrows the idea of bringing solutions together. When someone in the community has already built something that works well and wants to contribute it back to the wider community, it makes more sense to give it an official, centralized home. Accessibility needs come up again and again across WordPress in schools, agencies, and everywhere in between. This plugin is a way to collect that work in one place for all to benefit from.
Together, these two ideas shape what this plugin is for: a new contribution pathway for folks who want to test early items headed to Core, and a reliable community resource for features that solve problems shared across the project.
What is the Accessibility Lab plugin
This plugin aims to have every module fall into one of these two buckets:
Core experiments: this includes features that are architecturally hard to get right (a real migrationMigrationMoving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies., schema change, or performance tradeoff) and need a working implementation gathering real data before Core can responsibly commit to them. This ensures that the best option ships in Core based on real-world usage.
Practical tools: this includes both features developed directly in the plugin or bringing in plugins already doing real, useful accessibility work in the wild with full credit to the people who built them. These items do not necessarily come with an implied promise that they’re trying to land in Core and are instead meant to be shared utilities for the community to benefit from.
This means success looks like a combination of the following:
Features are proposed and merged into Core from the Accessibility Lab plugin, based on real-world testing and experimentation in the plugin first.
Practical tools that solve shared problems are ready for the broader community to benefit from with a community-backed option that can be relied upon.
Solid adoption of the plugin to ensure greater testing and confidence in different features.
More folks contribute to Accessibility efforts, with the Accessibility Lab plugin being an additional option to contribute over just Core.
What it’s not
This is not “install this plugin to have accessibility needs met” or “to make WordPress accessible”. That approach causes real harm.
The Accessibility Lab plugin is not a substitute for fixing accessibility in Core. It is a place to test new ideas, gather feedback, and develop features that need real-world testing before they are ready for Core.
If a feature or fix does not clearly fit into one of the purposes described above, it does not belong in Accessibility Lab, no matter how useful it might be.
Straightforward accessibility bugs should still be fixed directly in WordPress Core or GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/. They do not need to become Accessibility Lab modules first. Examples include adding or correcting ARIA attributes, using the proper HTMLHTMLHTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. elements and semantics, fixing missing accessible names or labels, correcting keyboard interactions, or resolving other clear failures of established accessibility standards.
Accessibility Lab is most useful when a solution needs more discussion, testing, or feedback from real users. It gives the Accessibility Team a way to try solutions without delaying smaller accessibility fixes.
The goal is to improve accessibility throughout WordPress, not to move accessibility fixes out of Core and into a separate plugin. When the right solution is clear, the fix should happen where the problem exists.
WordPress’s media library now defaults to infinite scroll as of WordPress 7.1, with an opt-out available in user profiles. There’s an active conversation happening in Core right now about the right long-term UIUIUI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. for surfacing this choice differently (PR #12795 and Trac #65775). This option in the Accessibility Lab plugin goes beyond turning infinite scroll on/off in the Media Library and includes additional view options to control how many items show by default, the density level, and whether to always show file names. Bringing in feedback from folks using this option can help shape the placement and the approach for an iteration on where and what surfaces in Core for the Media Library.
BlockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Accessibility Checks
To help address the shared problem of inaccessible content going out with things like missing alt text or skipped heading levels, an additional module brings in the great work from Troy Chaplin. His Block Accessibility Checks plugin brings a real-time, three-tier WCAGWCAGWCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. validation for blocks, metaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. fields, and document structure, with a hook system open enough that blocks from other plugins get checked too. Troy was game for this to be added to the Accessibility Lab plugin so a higher ed accessibility office and a hobbyist blogger can point to the same trusted answer to this problem (and ideally help improve it). The block accessibility validation tools are a practical exploration for providing authors with better accessibility tools. It’s not currently slated for inclusion into core, but different pieces can be evaluated in the future.
Heading-order validation
Skipping heading levels (ex: an H2 followed by an H4) breaks the document outline that screen readers and other assistive tech use to summarize and navigate a page. WCAG 1.3.1 (Info and Relationships) treats it as a failure, and it’s one of the most common accessibility mistakes editors make without realizing it. There’s a longstanding proposal to fix this in #10581 that asks for a hierarchy-checker notice inside the Heading block settings so writers see the problem as they set the level. #69891 also covers surfacing the same errors from the Document Outline panel. Both are open, and neither has landed yet. This module ships a version people can rely on now with a real-time editor warning as soon as a heading block introduces a gap, so writers can correct the outline in the moment rather than discovering the issue in a later accessibility audit. It builds on the plugin’s Block Validation Framework, so warnings share the same UI and severity controls as every other check the framework surfaces.
Ideas for what’s next
Searchable alt text is the clearest example of where this work could go next. Shout out to Joe Dolson for flagging this. For context, alt text lives in postmeta today, which is why it can’t be searched at scale. Trac #39004 has been asking for exactly this for years, tangled up with the broader postmeta search performance problem tracked in Trac #39358. It’s precisely the kind of problem this plugin exists for: worth fixing, and architecturally hard enough that Core can’t move forward without a real implementation to test against first.
If you know of other Core accessibility problems stuck in that same spot, please share below. I’d love a running list of ideas and problems to tackle as the plugin takes shape.
How you can help
Test the plugin as it’s in the prototype stage. File ideas as GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ issues. Open PRs. If you want to help shape what comes next, join the #accessibility channel and introduce yourself to get started.
Effective today, the theme accessibilityAccessibilityAccessibility (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)-ready guidelines have been updated. The new guidelines more closely adhere to Web Content Accessibility Guidelines (WCAGWCAGWCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/.) expectations, although it continues to be the case that WCAG does not apply directly to themes; WCAG is a measurement for content, and themes are only a wrapper for your content.
Why are the accessibility-ready requirements changing?
The original requirements were written in 2011, and added to the theme review process in 2012. This was before WCAG 2.1 or WCAG 2.2 were published, and before HTML5 or ARIA had wide support and adoption.
Since 2012, general awareness of accessibility has increased, and the capabilities for creating more accessible websites have also improved. It’s become increasingly important for WordPress’ Accessibility-ready requirements to modernize, to ensure that people implementing accessibility-ready themes are getting the best experiences.
Where can I find the new accessibility-ready requirements?
You should read the requirements for full details on what has changed. At a high level, here is a summary of changes:
Guidelines for themes have been updated to only include requirements, and “recommendations” have been removed. Some recommendations have been made requirements; other recommendations have been removed as they are best practices and not blockers to receiving accessibility-ready tag approval.
Requirement titles have been rewritten to clearly summarize the expectation.
All guidelines now follow a standard format with the following sections:
Basic principle: explains what the requirement is and why it matters.
Testing: includes a list of tools needed for the testing process and detailed, numbered, step-by-step explanations on how to test the requirement, with clear pass/fail criteria at each step.
WCAG resources: links to relevant WCAG docs that apply to our requirement, for people who want to learn more.
A standard process has been established for documenting testing in a Google Sheet, with a copyable template. The aim of this process is to make it easier for anyone to test, even without prior accessibility knowledge, and to ensure that theme developers receive consistent feedback, regardless of who tests their theme.
The documentation is very detailed, and covers how to test each requirement. However, to help users understand the process from the beginning, @alh0319 will be hosting a webinar on Thursday, May 21st – Global Accessibility Awareness Day. She’ll walk through the entire process of testing a theme for accessibility-ready standards, and attendees will be able to learn by testing themes during the webinar.
If enough people sign up for the webinar, the aim is to get all of the current 108 accessibility-ready themes re-tested against the new requirements. @rianrietveld and @joedolson will be available to provide support and help testers work through challenges!
How does this impact my live accessibility-ready theme?
All accessibility-ready themes will be expected to update their themes to meet the new standards. Many of the requirements are essentially the same, but there are some new requirements as noted above.
Theme authors will have until June 30th, 2026 to begin the process of getting their themes updated — either to update their accessibility, or to remove the tag.
Read the requirements, update your theme, then please request a review when you’re ready!
The primary work on the new accessibility-ready guidelines was done by Amber Hinds, with assistance from Joe Dolson. However, many others have contributed to the long process of developing the requirements and the process for testing:
Did you help with this process, but don’t see yourself in the list? Please comment below to let us know!
Additional thanks are owed to InstaWP, for donating their services to mount testing sites. You may wonder why this process isn’t using Playground, which is already available on WordPress.org. Unfortunately, Playground renders inside an iframeiframeiFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser., which breaks a number of key testing tools used to examine the content, particularly bookmarklets. It is possible to test within Playground, but considerably more labor-intensive.
The goal is to make it easier for anyone to contribute to theme accessibility-ready testing using common tools, and InstaWP makes this possible.
Updating AccessibilityAccessibilityAccessibility (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) Contributor Badge Criteria
There has been a rise in one-off contributors requesting badges, increasing workload for reviewers. The team discussed creating more scalable and meaningful badge criteria. Proposed updates include:
Requiring around 5 minor contributions (such as testing, documentation clarifications) OR
2 major contributions (significant patches, substantial documentation updates)
WordPress 7.0 Admin Redesign – “Coat of Paint”
The team discussed the ongoing work toward visually reskinning the WP Admin for 7.0.
Key points:
Changes are mainly CSSCSSCSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. and UIUIUI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. refresh, not functional overhauls.
The color palette will shift to the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ palette.
This will require heavy accessibility testing, especially around color contrast, design consistency, and any missed regressions due to wide UI updates
Checkout TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/.ticket for more details.
@rianrietveld had already shared an update about the docs team beforehand.
wpaccessibility.org has a new design and improved search.
Feedback from WordCampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Netherlands highlighted the need for “why accessibility matters” resources.
Multiple documentation pages have been added or updated recently.
Some major new features like the Tabs blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. have landed and will require accessibility review.
@joedolson shared that the work is progress on updating theme review guidelines for accessibility. This is expected to be a major documentation focus in December.
NOTE: If you’d like to have a topic added to the agenda for our next meeting, please mention it in the comments on an upcoming agenda.
We’re excited to share the AccessibilityAccessibilityAccessibility (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) Team Reps for the September 2025 – September 2026 term! Muhammad Yeasin (@thisisyeasin) and Krupa Nanda (@krupajnanda) will serve as Accessibility Team Reps, and Nasim Miah (@muddassirnasim) will join the team to contribute and gain experience in the role.
This structure will add strong organizational skills while creating opportunities for new contributors to grow within the team.
Yeasin is from Bangladesh and has built his professional career around partnerships, affiliate management, digital marketing, and business development in the WordPress and SaaS ecosystem. He has contributed to the Photos and Polyglots teams, volunteered at multiple WordCamps, served as table lead at several events, organized WordCampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. NEO, and will organize WordCamp Dhaka 2025.
He also co-organizes the WordPress Dhaka MeetupMeetupAll local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. chapter and is currently focused on expanding the CampusConnect program in Bangladesh, encouraging students and young professionals to contribute to open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL.. Yeasin is eager to deepen his involvement with the Accessibility team to make WordPress more inclusive for everyone.
Krupa has spent over 7 years focusing on testing, ensuring products don’t just work, but work beautifully and inclusively for everyone. She is currently serving as the Test Team Representative for 2024–2025 and recently led the testing efforts for the WordPress 6.8 release.
Krupa’s journey in the WordPress community includes co-organizing local meetups and WordCamps, volunteering, and speaking at community events. She is passionate about creating seamless, inclusive experiences, where accessibility and usability are central to product quality. As an Accessibility Team Representative, she looks forward to helping build a web that works for all users, regardless of ability.
Nasim is a WordPress developer based in Malaysia with 6 years of experience building websites, plugins, and themes for individuals, companies, and nonprofits. He began contributing to WordPress in 2023, supporting CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., Training, Translation, and Test teams, and has developed custom plugins and themes with a focus on performance, responsiveness, and SEO.
Nasim is active in the community as a mentor in the Training Team Guide Program, organizer of WordCamps, and host of meetups and presentations. He is passionate about accessibility and looks forward to contributing to the Accessibility Team, blending technical expertise and community engagement to help make WordPress more inclusive for everyone.
The Make WordPress Accessible team is looking for two new Team Reps to step into this important role. Our current reps, @nhrrob and @rcreators, will be wrapping up their term at the end of August after serving for a year. Now it’s time to pass the torch!
What is a Team RepTeam RepA Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts.?
Ideally, all Make WordPress teams should have two representatives which allows them to share responsibilities, divide tasks, and cover each other when needed.
Team Reps work with other teams across the project, share key updates across all contributor teams, and generally help to support the team as a whole.
Team Rep is an organizational role that is mostly administrative in nature; it is not a Lead role.
Letting go of the Team Rep title is not a loss of status, just a handing off of responsibilities.
Someone who is a leader in a team can lead whether they are doing the team rep job or not.
What to Expect in the Role?
Expectations vary from team to team, but here are some of what to expect:
Prepare meeting agenda by requesting updates from AccessibilityAccessibilityAccessibility (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) working groups;
Conduct the team’s bi-weekly meetings on the Make Accessibility SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/ channel; and
Document meeting notes and share updates with other teams as necessary
This would be a great opportunity to move the Meeting time to accommodate other time zones around the world, continue increasing participation and incorporate new voices.
Are YOU interested in contributing? Just provide a name in the comments section of this post and plan on joining us at our Friday, August 6, 2025 Meeting at 15:00 UTC.
If you would like to be considered for the role or know someone who would be a great fit, you have the opportunity to nominate yourself or others by adding a comment to this post. Remember that, if someone nominates you, but you don’t feel like accepting, you should feel more than free to say no: your nomination be considered only if you explicitly agree.
This is the proposed agenda for the weekly AccessibilityAccessibilityAccessibility (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) Team meeting on Wednesday, November 06, 2024, 15:00 UTC.
Updates from working groups
Design
Documentation
General
GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/
Media
MetaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.
Themes
New Time for Accessibility Office Hours Meeting
Twenty Twenty-Five Theme Accessibility Testing
Open floor
If you want to have a topic added to the agenda, please mention it in the comments of this post.
The Accessibility Team bug scrub has moved to Tuesdays, 16:00 UTC.
Following discussion with @nhrrob, one of our current team representatives, he has determined that he is still able to participate. The complications surrounding the vagueness of the login gatekeeping are still present; but he has concluded for himself that he is comfortable logging in. If this changes, we will once again suspend accessibilityAccessibilityAccessibility (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) meetings. Since there has been no guidance given regarding the definition of “affiliation” with WP Engine, this will continue to be an individual choice that may change in an ongoing manner.
This leaves us with one active team representative and one inactive team representative. We all continue to have the same overarching motivation: making WordPress more accessible.
With only one available team representative, we will be temporarily reducing to one meeting per month. The next team meeting will take place on November 6th.
Historically, getting anybody willing to be the team representative has been a hard challenge. We’re all busy doing the daily work of improving accessibility, and it’s hard to find people who are willing to coordinate meetings. The willingness of @rcreators and @nhrrob to take on this management task is greatly appreciated.
Feel free to comment on this post with your opinions on this path. Please restrict your comments to productive ideas about ways to move forward and make WordPress more accessible.
As neither of the current AccessibilityAccessibilityAccessibility (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) team representatives are able to log-in to WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, team meetings are suspended until further notice. Bug scrubs will continue to run as normal.
