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

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

Andrea Fercia 12:34 pm on September 13, 2023
Tags: a11y, meeting ( 2 )

Accessibility Office Hours

In an effort to improve 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) knowledge in the WordPress project, the accessibility team will hold Office Hours every Wednesday at 14:00 UTC, starting on September 20th.

The purpose of this initiative is to provide a dedicated space and time to discuss accessibility principles and best practices.

When

The first accessibility office hours will be Wednesday, September 20, 2023 at 14:00 UTC in the #accessibility Slack channel.

Why

It’s difficult to find opportunities to discuss general accessibility principles and best practices in depth. Accessibility team meetings mainly focus on issues that emerge during the release cycle and bug scrubs focus on specific TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets or 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/ issues.

The accessibility office hours is not a space to discuss specific issues. Instead, it’s meant to be a learning opportunity for everyone. It’s a space where everyone can help everyone improve their accessibility knowledge.

Though this is a meeting focused on accessibility, everyone is welcome, so please drop in and say hello if you have time! Feel free to contribute discussion points and leave them in the comments on this post.

Office hours as a metaMeta Meta 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. project

In the accessibility team there’s not much prior experience about the best way to hold this kind of meeting. This is an opportunity to get participants involved in setting the best way to structure these sessions. All are welcome to join and propose ways we can organize topics to prioritize them in the most efficient way.

All participants contribution will also be key to discuss whether and how to collect the outcome of the meetings discussions in a series of documented, shared, best practices.

What if I can’t make it?

Wednesdays at 14:00 UTC may not fit with everyone’s spare time or time zone. Depending on the requests and number of participants, the accessibility team is open to running a second office hours session on a different day and at a later time. Please do feel free to let us know what would work for you in the comments.

#a11y, #meeting

Joe Dolson 3:03 pm on July 12, 2019
Tags: a11y

Accessibility Team Meeting Notes for 5 July 2019

Meeting transcript on Slack

Media tickets updates

A few more tickets discussed, but relatively little progress this week.

Success Metrics and framing for 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/ SidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.

@sarahmonster raised the concern that we were looking at options without having done prior work to determine what was considered success and how to evaluate that, so we’ve taken a step back to define that.

Secondarily, we want to move away from discussing this in a private conversation and improve transparency as we brainstorm.

Still in progress at defining the path for opening this discussion; summer plans & WCEU have slowed progress.

WCEU Update

@ryokuhi was at the WP 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) theme auditor table, which was very interesting.

@poena commented that the themes table was in a different room from the theme auditor, so they couldn’t work together.

@ryokuhi Would very much like to see more presence from #a11y team members at major WordCamps and contributor days

Discussed the feasibility of that, given the expense for members & size of the team; considered the possibility of having a remote 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/. focused on accessibility.

Gutenberg Open Forum

@ryokuhi will add some thoughts about Snackbars

Continuing discussion, by mutual agreement, focused on how we might imagine a remote contributor day for accessibility & other teams.

Rian Rietveld 11:58 am on May 7, 2018
Tags: a11y, weekly meetings ( 60 )

This week in WordPress Accessibility, May 4th, 2018

Bug scrub

We discussed issues marked for the Gutenberg merge proposal milestone:

Simplify and streamline keyboard navigation through blocks:
First: what if 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. toolbar had only one tab stop and navigating through its controls would be possible with the arrow keys? Would users be able to get it?
Interaction modal: ARIA toolbar example
Conclusion: we are going to try this and let it test by some advanced keyboard / screen reader / VIM users

Second: the tab order
A good tab order would be for example: insert block, then editable area and then the rest. But should the visual order meet match DOM order? @afercia will try to investigate on the first two things in the next days

Constrain tabbing within popovers and similar components:
Alexander Botteram is working on a modal component that introduces a re-usable “constrain tabbing” feature.

Publishing Flow accessibility:
Nic Bertino did research on this and created a design proposal, that needs following up by the design and develop team.

Weekly meeting

Handbook

We added new pages added about Test for web accessibility to the handbook’s Best Practices chapter. If there are people who want to review what is published, please do.

Sami Keijonen tweeted posts from the handbook in a series on Twitter. Nobody uses Facebook in the team, so we won’t start a Facebook campagne.

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/

Summarised: Minor fixes went in, the bigger issues are still to solve.

We need to write a manual for AT users. We need people who are familiar with Gutenberg to be involved in writing the manual for AT users of Gutenberg. We can start outlining the processes and AT combinations to be documented. Rian will investigate what the best place is to publish this manual. Rian and Sami want to help writing.

We will dedicate our weekly bugscrub now on Gutenberg for now

We need to contact someone from Dragon about issue raised by Eric Wright: Can’t add a post title using speech recognition software.

Open Floor

Nicolas Steenhout has a podcast: A11y Rules. He’d love to speak to people that are NEW to 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), either working full time in it, or developers that are exploring #a11y.

I would love to speak to people that are NEW to accessibility, either working full time in it, or developers that are exploring #a11y. I'm looking at that "fresh to the work" perspective for my 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) Rules Podcast. Please let me know if you're interested. https://t.co/XFrhFN0h9U

— Nicolas Steenhout (@vavroom) May 1, 2018

So, if you think that’s you, please contact him, always nice to hear new voices

Action

Write ATAG statement: Joe Dolson
Write about what 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.1 means for the WordPress project: Rian
Find the best place for the Gutenberg AT handbook: Rian

#weekly-meetings

Joe Dolson 10:06 pm on September 17, 2014
Tags: 4.1, a11y, tickets ( 2 )

WordPress Accessibility Ticket priorities for 4.1 early

WordPress 4.1 development is just started. From an 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) perspective, this means that we know almost nothing about what new features and UIUI UI 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. changes will be taking place, but it gives us a great opportunity to work on resolving older outstanding issues or addressing concerns arising out of version 4.0.

This is a grouping of the tickets currently in the Accessibility Focus report; no new tickets were opened for the purpose of this list.

One general recurring topic in these tickets is the handling of focus in modals. This is something that could stand some global work: all WordPress modals should be initiated and closed in a standardized way: focus should be assigned to the first focusable item in the modal when it’s opened, focus should be restricted to within the modal while it’s open, and the modal should be closable using ‘Esc’. A thorough review of all modals would be valuable.

Group 1:

These tickets have an impact on the front-end use of WordPress. They are very unlikely to be relevant to any new features in development for 4.1, but are longstanding issues and improvements. Because they alter front-end code, they may require more time in trunk to address impact on plugins or themes.

~~#15926~~ Add alt attribute support for Custom HeaderHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. functionality
~~#24148~~ Add aria-labelledby attributes to comment form (fixed)
#21221 Image title and alt attribute content should be texturized.
~~#27402~~ Add aria-describedby to image gallery output (fixed)
JS #27645 MediaElement.js player & playlist not keyboard accessible (see Issue 1262 and Pull 1090 on MediaElement for reference)
~~#16433~~ Extend function to optionally include commenter name in comment_reply_link
#18650 Make archives and categories widgets dropdown ada compliant (depends on #29699)

#18650 is a particularly long-standing issue which has significant challenges due to the way the front-end HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. would need to change to make the feature accessible. Other features should all be able to be addressed without any major front-end impact.

Group 2:

These are areas that received a lot of attention in 4.0, but have outstanding issues. #26167 doesn’t directly relate to the plug-in work done in 4.0, but would be a good area to get resolved. It should be an easy fix.

JS #28892 CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. – Widgets – Feedback for screen reader users when Moving widgets + other actions
JS #28888 Customizer – Widgets – Screen Readers Don’t Announce WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Names
~~#20880~~ Keyboard navigation in Appearance > Header is broken
#26167 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 activation links need to contain plugin name and the “Plugin” column should be marked as row header
JS #29371 Media Library: Focus keeps jumping to URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org field
JS #29455 Plugin Info Modal Close Button Does Not Announce for Screen Readers
JS #29326 Improve accessibility of edit-selection mode

Group 3:

General issues relating to the author experiences, that can impact a user’s ability to author content.

Add Media Experience:

JS #25103 Submit buttons on form fields in the Add Media panel
JS #23562 Using Speech Recognition Software with the Add Media Panel
JS #28864 Cannot access edit menu options with keyboard inside Image Editor

TinyMCE/Editor:

JS #29838 Post editing area: keyboard accessibility, tab order and focus
JS #27642 Keyboard Accessibility for TinyMCE image panel
~~#27553~~ Make WP editor toggle focusable
#21414 Use the “Keyboard Shortcuts” checkbox in the user profile to turn on/off all custom shortcuts
~~#29358~~ Remove the ‘accesskey` attributes from Quicktags buttons

Other:

JS #27555 Make tag post metaMeta Meta 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. box more accessible
#26600 Search installed themes input has no submit button
#26550 Some anchor links should be buttons in media microtemplates

Group 4:

Administrator/Designer experience:

These issues will effect a smaller number of users on fewer occasions because they primarily effect issues related to site set up and configuration. #18801 could really stand some major work; the settings pages in WordPress have a large number of miscellaneous accessibility issues, but I think that the ticket is too all-encompassing as is; we need to open some individual tickets handling specific issues in the settings pages or in the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., so that the issue is more readily addressed.

JS #27592 Screen Reader Users Do Not Know Widgets are Expandable
~~#27593~~ Widgets: Toggle arrows on focus need an indicator beside color alone
#18801 Accessibility Enhancements to Settings API

These are issues that make features more difficult to use, but don’t prevent the usage of the feature.

#26758 Edit Tags form on submission does not stay at the same page and gets redirected
#28873 JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. code for adding bookmarklet Press This is hard to access with keyboard only
#25111 Keyboard focus does not stay within Full Screen Editor modal
#26562 Remove title attributes: class-wp-admin-bar.php
CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site./HTML #26504 Semantic elements for non-link links
JS #26601 Inappropriate content in heading on Themes page
#26551 Remove title attributes: link-template.php
#26560 Remove title attributes: rss.php

Group 5:

These are tickets we recommend for closure.

~~#29475~~ Adding ARIA roles in wp_nav_menu
~~#26553~~ Remove title attributes: comment-template.php

#4-1, #a11y, #tickets

About Us

How you can help

Learn More

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?

When

Why

Office hours as a metaMeta Meta 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. project

What if I can’t make it?

Media tickets updates

WCEU Update

Gutenberg Open Forum

Bug scrub

Weekly meeting

Handbook

Open Floor

Action

Group 1:

Group 2:

Group 3:

Add Media Experience:

TinyMCE/Editor:

Other:

Group 4:

Administrator/Designer experience:

Group 5:

Site resources