Rian Rietveld 9:36 am on October 29, 2025
Tags: wp-a11y-docs

WP A11y Docs update October 2025

This update informs you about:

publishing of new documentation has started;
the 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) of wpaccessibility.org itself;
presentations at WP Meetups about the project;
how you can help.

Accessibility information for web forms

We started publishing documentation in the section Standards and best practice.

Three topics are now published:

Standards and best practice / Frontend code: Accessible name.
Standards and best practice / Web forms: Input field and form label.
Standards and best practice / Web forms: Input field and description.

For the pages about web forms we need examples of how WP plugins handle this (or don’t handle this).

Accessibility of wpaccessibility.org

@joedolson is working on making the search option at the top of each page, fully accessible. We hope to finish that soon. After that Level Level will perform an official WCAG EM audit. Because we need to practice what we preach.

Making noise

Rian gave two presentations at the WP Meetups, in Amsterdam and Utrecht about the project; This resulted in more readers and reviewers of new documentation and also possibly one more sponsor. The next talk will be November 27 ’25 at WordCamp Netherlands.

How can you help?

Read new content and let us know what you think. We write for you! Can you understand it, is it helpful, do you need more or different examples. New content doesn’t starts with the alert “This content needs to be reviewed and expanded”.

For the pages about web forms we need examples of how plugins handle accessibility. Do you use or work for one of the major WordPress Form plugins and want to help? Please contact us, we need your expertise.

Plans for november 2025

Continue to write the documentation about web forms.
Make sure wpaccessibility.org is WCAGWCAG WCAG 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/. 2.2 AA accessible.

#wp-a11y-docs

Rian Rietveld 6:16 am on September 30, 2025
Tags: accessibility ( 109 ), make.wordpress.org/updates ( 22 ), wp-a11y-docs

WP A11y Docs update September 2025

This update informs you about:

The Knowledge Base is ready to contribute.
Issues on GitHubGitHub GitHub 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 be the repository owner. https://github.com/ with what needs to be written or reviewed.
The work planned for October 2025.
How you can help.

Knowledge Base is ready to contribute

In September we made the website wpaccessibility.org ready to contribute. All 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) content from the current handbook is copied into this website. Also new placeholder pages are made, for new content.

Yoren Chang @1fixdotio worked hard to create a preview option for pull requests for the site, so everyone can review proposed content without needing a local installLocal Install A local install of WordPress is a way to create a staging environment by installing a LAMP or LEMP stack on your local computer.. She is really amazing.

The How to contribute pages are written, also for contributors who don’t work with GitHub and just want to write or review.

GitHub issues with what needs to be written or reviewed

Rian wrote issues on GitHub for each documentation page belonging to Standards and best practice. For review and rewrite of the content. Each issues is labeled by topic.

For example the page Headings in the content now has an alert, about what needs be done with the content and a link to the related GitHub issue.

How can you help?

On How to contribute you can read the different ways to contribute to this project. If you want to help writing, pick an issue from the list of Todo issues on the projectboard Wp A11y Docs. Only contribute if you know the topic well or have good resources to share.

Note: Please write the content yourself and use AI only to translate or to check the quality of your English.

Plans for October

@rianrietveld will start writing content for the Knowledge Base, now everything is mapped out. She will also give presentations about the project at the WPMeetup020 (Amsterdam) and WPMeetup030 (Utrecht). You can help her by sponsoring Rian’s time and expenses.

@Aminul will work on the migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. of the current handbook to a new Github repo accessibility-team-handbook on github.com/wordpress. Only the Accessibility Team related info will stay into that handbook.

@joedolson and @1fixdotio work on the remaining issues in wpaccessibility.org itself.

#accessibility, #make-wordpress-org-updates, #wp-a11y-docs

Krupa Nanda 12:28 pm on September 9, 2025
Tags: accessibility ( 109 ), meeting notes ( 117 ), wp-a11y-docs

Accessibility Team Meeting Notes: September 03, 2025

On Wednesday, September 03, 2025 at 15:00 UTC, team meeting started in #accessibility facilitated by @krupajnanda. You can read the full transcript or see the meeting agenda.

New Team Reps

@krupajnanda and @thisisyeasin are selected as 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) Team Reps, and @muddassirnasim joined the team to contribute and gain experience in the role.

Accessibility Team Meeting Schedule

The team discussed finding the best meeting time that works across different groups, with @joedolson and the other team reps working to propose options for a vote. The new meeting time is to be announced soon!

Updates from working groups

Design

@joedolson shared that the design working group’s main focus is the admin redesign, which is a large and complex project that’s difficult to track. He emphasised the importance of reviewing new interfaces for accessibility since current work is mostly limited to design proposals. He also pointed out that specific areas, such as BlockBlock Block 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. Commenting, need more design attention and shared a related GitHub issue for reference.

Documentation

@rianrietveld and @joedolson are working on new Accessibility documentation, which can be followed on the make/accessibility blog with the hashtag #wp-a11y-docs. They are getting more contributors to help with this effort.

General

@joedolson reported on progress with coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. tickets, noting that 28 tickets were assigned to the 6.9 milestone, 7 were punted due to inactivity, and 18 have been committed. He also introduced a large patch on #40428 ticket related to hiding CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site.-generated content from assistive technologies and requested testing support.
Joe shared that he audited the WordPress admin for CSS-generated content issues, made changes to ensure dashicons selectors use generated empty alternatives, and emphasised the need to verify there are no visual differences in updated code. @krupajnanda suggested a potential “call for testing” post and requested instructions on how to test, to which Joe confirmed he would prepare guidance.

Gutenberg Team

@joedolson shared that the GutenbergGutenberg The 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/ items and the implementation of the Lightbox in Galleries are the most relevant things that need testing.

Media

@joedolson mentioned he had a discussion point but preferred to defer it to the next meeting due to time constraints. He requested adding “Discuss integration of media metadata sourced alt text” to the next meeting’s agenda.

Update project WP A11y Docs August 2025

How’s the work going on the documentation for WordPress about 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) (WP A11yAccessibility 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) Docs).

This update informs you about:

the brainstorm session about the content;
new contributors that joined in;
the work planned for September 2025;
how you can help.

Note: The new website for the Knowledge Base is stil in its set up phase: content needs to be added, accessibility issues need to be fixed. So we will not publish the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org here yet, but if you want to see the progress, please visit the GitHub repo wp-a11y-docs and follow the link mentioned there.

Brainstorm session about the content

Paul van Buuren, Annelies Verhelst, Wendie Huis in't Veld , Savi Sinnema, Caitlin de Rooij, Johan Huijkman and Rian Rietveld proudly standing before a wall of post-its.

In our previous update we shared the plans for the setup of the Knowledge Base. In Phase 1 we are going to gather all information about accessibility for people that use or build for WordPress and add that to website.

But how to organise that the best way? With a group of seven people, involved in WordPress and/or accessibility, we brainstormed about this for an afternoon. Resulting in a wall full of Post-its.

Thank you Paul van Buuren (@paulvanbuuren), Annelies Verhelst (@anneliesjenl), Wendie Huis in’t Veld (@dolgelukkig), Savi Sinnema, Caitlin de Rooij and Johan Huijkman!

The main conclusions where:

There needs to be a section about how to start, where to begin if you are new to accessibility and have no clue where to start.
To help users get to the knowledge they need, a reading guide is necessary. Per target group about what they need to read and where to find it. Content must be published once, but the way to get there can differ.
How to test was the most requested topic in the survey “Which WP accessibility documentation do you need”. There must be dedicated menu item with how to and checklists.
Each of the “Topics” with a “Standards and best practice” menu item will also have a “how to test” section.
The point of this Knowledge base is not to rewrite all the content there is out there but to write down what’s important in this context and link to reliable resources.

You can find the full report of the brainstorm session in the Google Doc: Brainstorm session WP A11y Docs.

New contributors join in

Kudos to Yoren Chang (@yoren) for making it possible to preview pull requests for the website in GitHubGitHub GitHub 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 be the repository owner. https://github.com/ pages. Annelies Verhelst is helping with content reviews. Gary Jones (@garyj) set up the rights for the wp-a11y-docs repo and helps with pull requests. The NL Design System gave permission to translate Dutch content into English and publish it on the Knowledge Base.

Work planned for September 2025

Copy all accessibility information from the current handbook to the new website.
Move the info that needs to stay in the current handbook to a repo on the WordPress account and publish the handbook from there.
Work on extending the content in the Knowledge Base.
Fix the accessibility issues on the website.

You can follow the work in our GitHub Project board.

How you can help

There are several ways you can help this project:

Pick an issue from the Todo column and work on it. Please comment with the issue that you want to do this work.
Review a pull request from the PRs in review column . With the description of the pull request there is always a link to a preview, so you don’t have to dig into the code. Add your review as a comment with the pull request.
Sponsor Rian’s time and expenses, at the moment 25% of her time is sponsored.
Read through the content that is already published and let us know what you think.
Follow the accessibility-docs SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel on wordpress.slack.com.

#accessibility, #make-wordpress-org-updates, #wp-a11y-docs

Rian Rietveld 11:05 am on August 8, 2025
Tags: accessibility ( 109 ), make.wordpress.org/updates ( 22 ), wp-a11y-docs

Update project WP A11y Docs July 2025

In June, Joe Dolson (@joedolson) and Rian Rietveld (@rianrietveld) started the project to update and extend documentation for WordPress about 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). We now abbreviate the project as “WP A11yAccessibility 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) Docs”.

This update informs you about:

how the documentation will be set up;
the work we did up to now;
what we are going to do next;
how you can help.

Setup of the documentation

The last month we talked with many people in and outside the WP community about the best way to share a11y (accessibility) knowledge in a sustainable way. We came to the following setup.

Phase 1

In a dedicated website WP Accessibility Knowledge Base we gather all information about accessibility for people that use or build for WordPress. In this site we add content and figure out what the best way is to provide the WP community with the best a11y info.

The current Accessibility Handbook will be renamed Accessibility Team Handbook.
And will contain only information about the team itself, how to contribute and when the meetings are (etc). The information about accessibility itself moves to the WP Accessibility Knowledge Base.

Phase 2

On developers.wordpress.orgWordPress.org The 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/ a new section will be created, the Accessibility Handbook where the info for developers and designers will be added, taken from WP Accessibility Knowledge Base. This section will live as a repo on the WordPress GitHubGitHub GitHub 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 be the repository owner. https://github.com/ account.

The setup of using first a dedicated website to write and to find out the best way to organise content and later add relevant content to the developers handbook, is discussed in the Documentation Team Slack channel. Thank you Jon (@kenshino) and Milana (@milana_cap) for your feedback.

Work in July and August ’25

We created a website for the WP Accessibility Knowledge Base. The website is build in Jekyll using GitHub pages which makes it easy for contributors to add content in markdown as open sourceOpen Source Open 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. project.

The related Github repo is wp-a11y-docs.

Note: at the moment the content contains only placeholder text, from August 11 on we are going to fill that site with real content.

What’s next?

On August 20, Rian will host a brainstorm afternoon about which content we need to provide for the WP Accessibility Knowledge Base and which content is useful for developers.wordpress.org. And also about how to organise the content in a way people can easily find what they need. This will be with people from the Dutch WordPress community and Accessibility community.

After that session Rian will create issues on GitHub for everyone that wants to help to pick up.

How you can help?

Pick an issue from the wp-a11y-docs/issues! After August 21 there wil be many to choose from.

#accessibility, #make-wordpress-org-updates, #wp-a11y-docs

Rian Rietveld 12:56 pm on June 26, 2025
Tags: a11y ( 10 ), wp-a11y-docs

Results survey “Which WP accessibility documentation do you need”

In 2 weeks 57 people filled out our survey. Thank you all. 14 of the responders are from The Netherlands and Belgium. Which shows the loving commitment of the Dutch speaking WordPress community.

The survey is closed now.

The results per question

Question: I am a (multiple answers are possible)

Responses:

Website owner: 54%
Frontend developer: 45%
Content manager: 27%
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) specialist: 27%
Full stack developer: 27 %
Backend developer: 25%
Project manager: 23%
UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. specialist: 18%
Writer: 13%
Graphic designer: 13%
SEO specialist: 11%
Marketing specialist: 7%
QA specialist: 5%
Other: Engineering editor, Translation editor: each 1 response (2%)

Lessons learned

Also accessibility specialists need info about the accessibility of WordPress.

People wear many hats, most people checked multiple options.

One group I forgot: self employed creators of websites, that use available themes or theme builders or the Full Site Editor, with plugins to create a site. They have far less control over the accessibility of a site than developers or web agencies. They need options to create accessibility work. They also need to convince their clients.

Question: The country I work from is

Responses:

Belgium and The Netherlands: 14
USA: 7
UK: 4
India: 3
Germany: 3
France: 3
Spain: 2
Italy: 2
Greece: 2
EU: 2
1 response each from Denmark, Uganda, Austria, Nepal, Romania, Portugal, Ecuador and Australia

Lessons learned

Information about web accessibility is a global need.

Question: The projects I’m working on must be accessible

The responses:

Yes: 25
Most: 13
Some: 11
No: 2
I don’t know: 5

Lessons learned

If you add up the “yes”, “most” and “some” answers: 88% of the responders needed to at least know how to create accessible work.

Question: These topics I want to find in the WordPress Accessibility Handbook (multiple answers are possible)

The responses:

How to test my work for accessibility: 72%
What is important for an accessible theme: 63%
Accessibility and Full Site Editing (FSE): 60%
How to add content in an accessible way: 56%
Code patterns: 54%
What is important for an accessible pluginPlugin A 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: 49%
What is an accessibility statement and when do I need one: 49%
Reliable resources: 42%
How to get the accessibility-ready tag for my theme: 39%
How to convince my boss/coworkers why accessibility is important: 39%
Links to WCAGWCAG WCAG 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/. in plain language; 37%
The accessibility of the Admin: 35%
How to write documentation for my plugin/users about accessibility: 32%
Legislation for my country: 32%

Lessons learned

Most of all: we need to provide much more info on how to test for accessibility. People need help to create accessible work, also while using FSE.

Question: My thoughts and ideas

The responses:

How to use screen readers, and other easy ways to demonstrate inaccessibility.

Suffering from information overload and still too often very confused on what to do and how to keep things as realistic as possible, both in content as front end code (pattern libraries, coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks a11yAccessibility 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) by default etc). Want to help others and myself to do the right thing by default as much as possible, still (!) often not certain where to start — might want an a11y helper plugin for different roles; combining helper snippets (like auto-adding “add an alt tag if this image contains relevant information” in the editor via css whenever one is missing within content). In core basic checks in site health (if that would even be possible at all). Both referring to where in the handbook additional explanations can be found (even when info might be different for coders and writers)

I answered no to the requirement to be accessible because my last project didn’t have a front end as such, it was headless and I worked on the api. I’m not sure if there’s accessibility concerns with that! It must be making sure the front end can consume it and make an accessible web page?

Code patterns are especially handy, and linking to reliable off-site resources is just as valid as having them maintained in the WP a11y Handbook.

Don’t use plugins which are
1. More than 5 years not updated which are not secure enough.
2. Plugins who have no accessibility on the roadmap.

What I would need most is tools in place that check certain things when content is added so possible inaccessible content is flagged.
I think every topic you addressed is something that needs to be in the documentation. I checked the most important ones for me.

I want to have detailed knowledge about the accessibility required to submit a theme in wp.org without an accessibility tag.

Nothing in particular, just a source about accessibility that is accessibility written in itself would be very helpful.

I’m only getting started into my accessibility deep-dive, so I don’t have many thoughts or ideas to share yet.

Most important would be to simplify for CXOs why they should invest on accessibility for their websites.

What are the low hanging fruits making Twenty Twenty-Four /-Five more #a11y.

I am new and I want to contribute more to accessibility.

Concrete examples for small entrepreneurs or SMEs who do not have their own developer.

Tips for recognizing inaccessible blocks in the blockBlock Block 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. editor / FSE.

What you should do as a minimum if you are not a developer, but do want to work accessible.

Quick scan checklist for content creators and self-employed people.

Standard text for a simple accessibility statement.

So simple with videos that work on every theme.

Lessons learned

This is all such good feedback, thank you!

My first impression is: People get lost in the documentation and all the information there is on the web about web accessibility. Most of the info they need is already there, somewhere, but hard to find or incomplete.

What stands out as most needed:

Order and clarity in the chaos of information about accessibility.
Information about how to test for accessibility (tools).
Information about the accessibility of WordPress itself: using blocks, Full Site Editing, the Admin.
What is important for creating accessible themes and plugins, provide (code) examples.
Accessibility warnings for content managers.

People need help to create accessible work.

Where do we go from here?

The results of the survey make clear that the accessibility team’s handbook contains too much information, making it hard to find the right information.

The combination of our team’s information with overall accessibility knowledge makes both harder to discover. This is logical when you consider how the WordPress core team handles documentation, separating general “developer” documentation (on developer.wordpress.org) from core contribution documentation (on make.wordpress.org/core/).

To move forward, we should split the information in the current handbook:

Information about the accessibility team including how to get involved, contribution areas, and team processes, remains in the current handbook.
Broader WordPress accessibility information moves to a new, dedicated location, making it easier to discover.

This approach ensures accessibility information is in one central place, helping site owners, developers, and content creators discover the documentation they need to make their sites accessible.

The easiest and quickest way to move forward is to spin up a new website as we experiment on the best structure and format for accessibility information and quickly iterate. We’ll start by researching and rethinking the information architecture, which will inform the technical architecture that best supports our vision.

As with everything we create, the site will be open sourceOpen Source Open 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., with code and documentation ready for feedback and contributions.

We’ll be spinning up the WP Accessibility Knowledge Base soon, restructuring the current accessibility handbook, and migrating content to the new knowledge base.

Ultimately, our goal as a team remains: make WordPress accessible and ensure site owners, developers, and content creators everywhere can easily find documentation to make their sites accessible.

#wp-a11y-docs

Rian Rietveld 1:14 pm on June 11, 2025
Tags: accessibility ( 109 ), make.wordpress.org/updates ( 22 ), wp-a11y-docs

Start project “Accessibility documentation” on WordCamp Europe 2025.

At the contributor dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. of WordCampWordCamp WordCamps 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. Europe in Basel @rianrietveld and @joedolson started the work to update and extend the documentation about 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) for WordPress. This is what we agreed:

Scope

The current documentation in our Accessibility Handbook needs to be improved on.

We are going to work on up to date and well maintained information for WordPress, about what is needed to deliver accessible work and how to properly test for accessibility.

With clear do’s and don’ts, practical examples, and easy-to-follow documentation.

Setup

We update and add content in the in the current Accessibility Handbook. On developers.wordpress.orgWordPress.org The 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/ a section will be created for accessibility specific code examples, for reference in the Handbook.

The content will be moved from the current WordPress pages to markdown files in GitHubGitHub GitHub 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 be the repository owner. https://github.com/.

We want to set this up as an open sourceOpen Source Open 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. project, everyone with accessibility knowledge can contribute to the documentation. The accessibility team will project manage and safeguard the quality of the content.

Work

The current content in the Handbook will be copied to a GitHub repo on the WPAccessibility GitHub account. We work from there to create the content in markdown.
We will conduct a survey in the WordPress community on which documentation they need.
The structure of the Handbook will be reorganised to fit the users need better.
Once the set up and the main content is ready to go, that repo will be transferred back to the WordPress account and mantained from there.
On the WPAccessibility Github account Rian will create and manage a GitHub project with all the work that needs to be done. Such as the content that needs to be rewritten and created. That way it’s easy for more people to contribute and work on different content.
There will be a process of reviewing in place, to make sure the content is up to WordPress and accessibility standards.
Code examples and other technical documentation will be published in an accessibility section of developers.wordpress.org or will be included in with current developers content, depending on the topic.
The updated documentation and requirements for the accessibility-ready tag will be added to a logical place on the themes handbook.

Rian will set up and project manage this work. She will report every two weeks in this blog about the progress.

Roadmap

June – August 2025

Set up the GitHub project
Set up the GitHub repo on WPAccessibility
Transfer the current content of the handbook
Send out the survey

September – October 2025

Rewrite and restructure the current content
Set up a system of reviewing and merge rights
Decide on new content and where to add that and create GitHub issues for them

From November 2025 on

Maintain the current info and keep thinking about info to add or update
Review and if ok merge pull requests from people who contribute
Invite more people to work on the content mentioned in the GitHub issues

With many thanks to Milana Cap, Gary Jones and Virginia Ciambriello for the useful discussions during WordCamp Europe.

#accessibility, #make-wordpress-org-updates, #wp-a11y-docs

About Us

How you can help

Learn More

Accessibility information for web forms

Accessibility of wpaccessibility.org

Making noise

How can you help?

Plans for november 2025

Knowledge Base is ready to contribute

GitHub issues with what needs to be written or reviewed

How can you help?

Plans for October

New Team Reps

Accessibility Team Meeting Schedule

Updates from working groups

Brainstorm session about the content

New contributors join in

Work planned for September 2025

How you can help

Setup of the documentation

Phase 1

Phase 2

Work in July and August ’25

What’s next?

How you can help?

The results per question

Question: I am a (multiple answers are possible)

Lessons learned

Question: The country I work from is

Lessons learned

Question: The projects I’m working on must be accessible

Lessons learned

Question: These topics I want to find in the WordPress Accessibility Handbook (multiple answers are possible)

Lessons learned

Question: My thoughts and ideas

Lessons learned

Where do we go from here?

Scope

Setup

Work

Roadmap

Site resources