WordPress
Playground block: A11Y: Difference between "Run" and "Activate Live Preview"?
Test page: https://learn.wordpress.org/test/wordpress-playground-block-plugin-test-page/
From the button labels alone, I cannot tell the difference between what these buttons will do. Let's start with answering that question and then I can guide on the proper solution. This is in the preview iFrame.
Run sounds like it would load the iFrame from the provided code but I have no idea what Activate Live Preview would mean. From my perspective, they appear to do the same thing.
Hi @alexstine, thanks for bringing this up.
Run sounds like it would load the iFrame from the provided code but I have no idea what Activate Live Preview would mean. From my perspective, they appear to do the same thing.
Before live preview has been activated, both the "Run" and "Activate Live Preview" buttons have different purposes but effectively do the same. The "Run" button serves to run the code editor's content in Playground, but when the live preview is not yet active, "Run" has to activate the preview in order to run the code. The "Activate Live Preview" button serves to communicate that user action is required to load the live preview, and when activating the preview, it run the code from the editor as a side-effect.
After live preview is activated, the "Run" button remains and serves to run the latest contents of the code editor in Playground.
Does that help?
@brandonpayton Any chance you can remove the Activate live preview button? Run will ultimately do the same thing and it will be far less confusing.
@alexstine I feel like the "Activate live preview" button may have value from a visual UX perspective because it is centered on the live preview area while the "Run" button is located separately with the code editor. When using a screen reader, encountering a "Run and Activate" button followed by a separate "Activate and Run" button sounds confusing and like it would cause a person to pause and wonder "What's the point? Am I missing something?"
Is there a good way for the "Activate live preview" button to be excluded from screen reader consideration to avoid this?
@brandonpayton Nope, that's not possible. After selecting activate live preview, it also gets removed from the DOM which is also not a great experience.
@brandonpayton Nope, that's not possible. After selecting activate live preview, it also gets removed from the DOM which is also not a great experience.
@alexstine I do not believe we should remove the "Activate live preview" button because there is also a Playground block mode where there is no code editor and it is the only button that can activate the preview. And it seems good to keep the Preview UI consistent between the code-editor and no-code-editor modes.
To try to help disambiguate the buttons, I made different ARIA descriptions for each.
The run button has:
This button runs the code in the Preview iframe. If the Preview iframe has not yet been activated, this button creates the Preview iframe which contains a full WordPress website and may be a challenge for screen readers.
And the activate button has:
This button creates the Preview iframe containing a full WordPress website which may be a challenge for screen readers.
These descriptions should be in the latest version of the block on the Learn WordPress site. Do they help at all?
In addition, you mentioned that it is not great that the "Activate live preview" button gets removed from the DOM after the Preview is activated. We may be able to hide the activate preview button with CSS without making it invisible to screen readers. In that case, I would like to be sure it cannot be focused or invoked again by keyboard users. Would adding a disabled attribute be OK from an accessibility perspective?
@brandonpayton No, you can't do that either. That will create the same situation where screen readers have a focus loss. Maybe you could focus the beginning of Playground text or something so meaning and operability are maintained?
https://www.w3.org/TR/WCAG21/#focus-order
Thanks.
@brandonpayton No, you can't do that either. That will create the same situation where screen readers have a focus loss. Maybe you could focus the beginning of Playground text or something so meaning and operability are maintained?
https://www.w3.org/TR/WCAG21/#focus-order
Thank you, @alexstine. I think that helps. Do I understand correctly that it is OK for the button to be removed as part of activation as long as the focus is moved to a meaningful target like the beginning of preview marker?
Ok, great. I've made that update in #338 which should be included with the next release.
This is definitely better, but it would be very helpful if the beginning of preview marker contained text indicating the loading status of the preview. Right now, focus is moved to the marker right after pressing 'Activate', but the preview is not yet loaded. There is no notification indicating that loading is still occurring, nor is there a notification when the loading has completed.
I think that when the activation is triggered, the beginning of preview marker text should include a 'Loading' text, then when the loading is finished, there should be an audible message to let the user know that the loading is completed.
Hi @joedolson, thank you for your thoughtful feedback. I attempted to address it with #355 and tagged a new interactive-code-block release containing that change.