-
Notifications
You must be signed in to change notification settings - Fork 269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WordPress Playground Demo: Accessibility issues #612
Comments
@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? |
@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. |
Thanks to @dd32 I found the playground demo code https://github.com/wordpress/wporg-wasm. |
I'll be working on some of these issues during contributors day 🙌 |
I created 5 PRs that solve #613, #615, #617, #618 and #619
For #614, it seems the iframe comes from content inside the iframe. Probably core or the theme. Someone can take a look to the PR's? |
Form elements are required to have a contrast of at least 4.5, and the URL bar has a contrast of 4.2 between the background color and the font color. This commit makes the font lighter to satisfy the requirements. To test, install axeDevtools and confirm the contrast issue is no longer reported. Related: #612
Form elements are required to have a contrast of at least 4.5, and the URL bar has a contrast of 4.2 between the background color and the font color. This commit makes the font lighter to satisfy the requirements. To test, install axeDevtools and confirm the contrast issue is no longer reported. Related: #612
@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/. |
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.
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.
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. |
@jonathanbossenger would you post a screenshot of these warnings? Here's what I see: |
Form elements are required to have a contrast of at least 4.5, and the URL bar has a contrast of 4.2 between the background color and the font color. This commit makes the font lighter to satisfy the requirements. To test, install axeDevtools and confirm the contrast issue is no longer reported. Related: #612
Tagging for visibility if anyone wants to tackle an accessibility challenge! |
For context – we need to check whether Axe DevTools with "Best Practices" on report any issues, and then either:
|
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. |
I can help with that (testing and opening a PR to fix HTML and CSS issues). -- @flexseth |
THANK YOU!! 🤙 |
Fixes two accessibility issues found when scanning https://playground.wordpress.net (i.e., the generic instance) with axe DevTools. See discussion in #612. ## What problem is it solving? Makes Playground more accessible. ## How is the problem addressed? **Testing environment:** Arc/Chromium with the Axe DevTools (axe-core version 4.8.4) extension. The _Best Practice_ option is enabled. ### Findings: - The first test found 22 issues - The second test, with the `wp-admin-bar` hidden using CSS, found 4 issues - The third test, with the `Twentytwentyfour` navigation hidden using CSS, found 2 issues. Only these last two are generated by Playground. **Left:** First scan. **Right:** Third scan: <img width="250" alt="First-scan" src="https://github.com/WordPress/wordpress-playground/assets/63248335/48e29ff5-3a2e-4b29-8461-0b67dd6308b1"> <img width="250" alt="Playground-generated-a11y-issues" src="https://github.com/WordPress/wordpress-playground/assets/63248335/c4a9039a-c50f-4304-b34d-8a86c83c518b"> *** Both issues affect Playground's address bar area: <img width="500" alt="Issues" src="https://github.com/WordPress/wordpress-playground/assets/63248335/12cac34a-58e1-47dc-a9a1-b40d0f74bd81"> ### Solutions: 1. To solve issue number 1, **Form elements should have a visible label**: change the `title` attribute of `<input class="_input_845jo_7" name="url" type="text" title="URL to visit in the WordPress site, like"/wp-admin"" autocomplete="off" value="/">` to `aria-label` (i.e., `aria-label="URL to visit in the WordPress site, like"/wp-admin""`). 2. To solve issue number 2, **All page content should be contained by landmarks**: change `<div class="_toolbar_8xy06_95">...</div>` to `<header aria-label="Playground toolbar" class="_toolbar_8xy06_95">...</header>` See screenshot after applying the changes: <img width="250" alt="After-the-fix" src="https://github.com/WordPress/wordpress-playground/assets/63248335/6b674899-64f9-458b-90a1-2d1bd3896ac3"> ## Testing Instructions Run a scan with axe DevTools (enable the _Best Practice_ option)
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
h4
withh2
on settings modal titles wporg-wasm#13Theme:
to img alts for themes on settings modal wporg-wasm#14The text was updated successfully, but these errors were encountered: