a11y: Print script module live regions HTML in page HTML #65380
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sirreal
added
[Focus] Accessibility (a11y)
|
Size Change: -411 B (-0.02%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
sirreal
commented
Sep 16, 2024
sirreal
commented
Sep 16, 2024
sirreal
force-pushed
the
update/a11ymodule-print-necessary-html
branch
from
8888f39
to
7496f88
Compare
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
sirreal
changed the title
|
Thank you for working on this and for the ping.
I can confirm the live regions need to be in the DOM on page load. For history, in the very first version of
@gziolo I'm afraid I don't know much about ES modules. Is your question related to the CSS part? It can be certainly moved to an inline style. Also, instead of repeating the style for all the 3 elements that need to be visually hidden, maybe the styling could be applied to a container element? Worth reminding this CSS is basically the screen-reader-text CSS rule used in WordPress core. For consistency, it's good to use exactly the same set of CSS declarations even though the A quick note; |
That seems fine technically and would make this less verbose. I'll apply that suggestion 👍
Nice, I'll see about switching to
That's correct, thanks for the suggestion, I'll use Safari in the future. |
sirreal
commented
Sep 17, 2024
sirreal
commented
Sep 17, 2024
sirreal
force-pushed
the
update/a11ymodule-print-necessary-html
branch
from
7496f88
to
6e5f9b4
Compare
sirreal
commented
Sep 17, 2024
|
I've applied the suggestions and:
This is ready for another round of review, testing, and/or feedback. |
|
Excellent, I processed the proposal with a fresh perspective and responses from @afercia and @sirreal. I think it's a perfect trade-off for the use case. It diverges further from how |
gziolo
approved these changes
Sep 17, 2024
|
I created #65409 as a follow-up to remove some redundant styling mentioned in #65380 (comment) from the |
sirreal
added a commit
to sirreal/wordpress-develop
that referenced
this pull request
Sep 20, 2024
This script module requires an additional change that will be landed separately before it can be landed. See WordPress/gutenberg#65380.
sirreal
added a commit
to sirreal/wordpress-develop
that referenced
this pull request
Sep 20, 2024
This script module requires an additional change that will be landed separately before it can be landed. See WordPress/gutenberg#65380.
This was referenced Sep 26, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Fix potential issues where
@wordpress/a11yscript modulespeakmay not be detected and announced by accessibility software, in particular when dynamically loading the module.Why?
While working on #65123, I noticed that the live regions would not be announced on their first update but would on subsequent updates.
This is caused because accessibility software needs to detect the live regions in order to announce them. The
@wordpress/a11yscript module was adding the live regions correctly when the module was loaded, but when loaded on demand (import( '@wordpress/a11y' ).then( { speak } ) => speak( 'announce me.' )) the update would happen before the live region was detected and the announcements were missed.The
wp-a11yscript includes code to prevent it from duplicated the DOM elements that are added on page load so this should not present any conflicts with the a11y script's setup.How?
Update the a11y script module so that it does not register the live regions but expects them to be present on the page.
A function is added to add the HTML for the live regions when the
@wordpress/a11yscript module may be present (is enqueued or is in the import map).This reverts some of the changes from #65101 to pass the localized string through the script module. Now the localized string is simply printed on the page.
Testing Instructions
This can be tested easily with #65123. Screen readers should read (localized) "Page Loaded." the first (and every subsequent time) that the interactivity router navigates.
Screenshots or screencast
demo.mov
(The extra "polite" aria-live region in the screen capture is from the Interactivity API).