WordPress Playground Demo: Accessibility issues

[jonathanbossenger]

This issue serves to track individual accessibility issues found on the WordPress Playground demo at https://developer.wordpress.org/playground/demo.

These issues were surfaced using the Axe DevTools®: Digital Accessibility Testing Tools, available as an extension for Firefox or Chromium based browsers.

To view the individual issues, install the extension on your browser of choice, browser to the Playground demo site, enable the browser Developer Tools, and switch to the axeDevTools tab.

Then, select the Scan all of my page options.

Issues

• WordPress Playground Demo: The settings button does not have discernable text #613
  • PR Accessibility: Add aria label to settings button wporg-wasm#10
• WordPress Playground Demo: The iframe must have an accessible name #614
• WordPress Playground Demo: There is a form element that does not have a label #615
  • PR Accessibility: Add title to input url bar wporg-wasm#11
• WordPress Playground Demo: The main tag should have a unique role or role/label/title combination #616
• WordPress Playground Demo: The Settings modal form elements must have labels #617
  • PR Accessibility: Add label to plugin checkboxes on settings modal wporg-wasm#12
• WordPress Playground Demo: The Settings modal heading levels should only increase by one #618
  • PR Accessibility: Replace h4 with h2 on settings modal titles wporg-wasm#13
• WordPress Playground Demo: The Settings modal images have alt tag attributes that are duplicated as text #619
  • PR Accessibility: Add the word Theme: to img alts for themes on settings modal wporg-wasm#14
• Accessibility: Font contrast in the URL bar #659
• Accessibility: Give the URL input a title #658
• Accessibility: Accessible iframe names #657

[dmsnell]

@jonathanbossenger I left notes in each individual issue, but it looks like we're trying to fix things that are evident in a third-party site embedding the Playground but which aren't problems in the Playground itself.

Do you know where the developer.wordpress.org/playground code is?
Also at least one of these reported issues appears to come from the twentytwentythree theme, so that issue needs to be taken up there as there's no way to solve it here.

[jonathanbossenger]

@dmsnell aha, interesting. Thanks for reviewing these and pointing this out.

I do not know where the demo code is, but I can only assume it's somewhere in the https://github.com/WordPress/wordpress.org repository. I'll do some digging on Monday, and if needed, log the upstream issues there.

I'll also look into the twentytwentythree related issue at the same time, and either report back, or log the upstream issue.

[jonathanbossenger]

Thanks to @dd32 I found the playground demo code https://github.com/wordpress/wporg-wasm.

[sejas]

I'll be working on some of these issues during contributors day 🙌

[sejas]

I created 5 PRs that solve #613, #615, #617, #618 and #619

• PR Accessibility: Add aria label to settings button wporg-wasm#10
• PR Accessibility: Add title to input url bar wporg-wasm#11
• PR Accessibility: Add label to plugin checkboxes on settings modal wporg-wasm#12
• PR Accessibility: Replace h4 with h2 on settings modal titles wporg-wasm#13
• PR Accessibility: Add the word Theme: to img alts for themes on settings modal wporg-wasm#14

For #614, it seems the iframe comes from content inside the iframe. Probably core or the theme.
For #616 I couldn't reproduce using Axe.

Someone can take a look to the PR's?
I'm happy to help setting up the environment.

[jonathanbossenger]

Thank you so much for this @sejas.

I will try and see if I can find some time to retest #616, maybe it's been fixed with a theme update.

[adamziel]

@jonathanbossenger All the reported issues are now fixed. For a better read we'd need to test using actual assistive technologies like screen readers – what's your opinion on this @jonathanbossenger?

Also, what's the use-case we're solving for here? I'm asking because I noticed you posted a screenshot from https://developer.wordpress.org/playground/demo which is an app built on top of Playground to showcase what's possible. The actual demo where you get all cool features like blueprints or different PHP and WP versions is https://playground.wordpress.net/.

[jonathanbossenger]

For a better read we'd need to test using actual assistive technologies like screen readers – what's your opinion on this @jonathanbossenger?

To be honest, when I was still a developer, I only ever used Axe DevTools, and that was enough for my requirements at the time. So when it was reported to me that the playground demo was not accessible (see below), that's all I had to refer to.

Perhaps we could see if someone from the Accessibility team is available to test this out and provide additional feedback. I will report back to the person who originally flagged this, and see if they can help as well.

Also, what's the use-case we're solving for here?

The original use case was not even the playground demo, but my attempt to have the interactive code block added to Learn WordPress. I you read in the comments, as the playground demo was not accessible, which is the public-facing "product" that folks can use, it's assumed that anything that uses WP Playground is also not accessible.

I noticed you posted a screenshot from https://developer.wordpress.org/playground/demo which is an app built on top of Playground to showcase what's possible. The actual demo where you get all cool features like blueprints or different PHP and WP versions is https://playground.wordpress.net/.

That might also be part of the problem as https://developer.wordpress.org/playground/demo is what is linked to from Learn WordPress, and this is one of the reasons that the button that opens playground on our courses includes a note that "Note that WordPress Playground is currently undergoing accessibility testing" - see example here.

So perhaps we should be using https://playground.wordpress.net/ on Learn WordPress instead?

I would also point out that running AxeDevTools on https://playground.wordpress.net/ also shows accessibility warnings.

[adamziel]

@jonathanbossenger would you post a screenshot of these warnings? Here's what I see:

[jonathanbossenger]

Sure, this is what I see. I have Best Practices On, looks like yours are off.

I don't use a screen reader, so I have no idea how important the best practices are, but I tend to err on the side of caution in these things.

[flexseth]

• Online Yoast Contributor Day - April 18, 2024 #1185

Tagging for visibility if anyone wants to tackle an accessibility challenge!

[adamziel]

For context – we need to check whether Axe DevTools with "Best Practices" on report any issues, and then either:

• Close this issue if there are no more problems
• List those problems here

[flexseth]

Self-assigned.

Didn't realize the contributor day was geared towards documentation, I'll try to close out some of the issues linked to the original post that aren't docs related.

[ironnysh]

I can help with that (testing and opening a PR to fix HTML and CSS issues). -- @flexseth

[flexseth]

I can help with that (testing and opening a PR to fix HTML and CSS issues). -- @flexseth

THANK YOU!! 🤙

[adamziel]

@ironnysh fixed the last accessibility issues in #1246, yay! Let's close this issue and use #1248 to make sure no new issues get merged in the future.