Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Playground block: A11Y: Difference between "Run" and "Activate Live Preview"? #290

Open
alexstine opened this issue Jun 4, 2024 · 12 comments
Open

Playground block: A11Y: Difference between "Run" and "Activate Live Preview"? #290

alexstine opened this issue Jun 4, 2024 · 12 comments
Assignees
@brandonpayton
Labels
Accessibility Bug Something isn't working Playground block

Comments

@alexstine
Copy link

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.
@brandonpayton
Copy link
Member

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?

@alexstine
Copy link
Author

@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.

@brandonpayton
Copy link
Member

brandonpayton commented Jun 7, 2024 •
edited
Loading

@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?

@alexstine
Copy link
Author

@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 brandonpayton added Bug Something isn't working Playground block labels Jun 13, 2024
@brandonpayton brandonpayton mentioned this issue Jun 18, 2024
Merged
brandonpayton added a commit that referenced this issue Jun 18, 2024
@brandonpayton
Playground block: Distinguish better between Run and Activate buttons (…
22b0808 
…#315)

This PR updates the ARIA descriptions for the Run and Activate buttons
to help clarify how they are different.

Related to #290
@adamziel adamziel moved this to Up next in Playground Board Jul 1, 2024
@brandonpayton brandonpayton mentioned this issue Jul 18, 2024
Open
13 tasks
@brandonpayton
Copy link
Member

@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?

@alexstine
Copy link
Author

@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
Copy link
Member

@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?

@alexstine
Copy link
Author

@brandonpayton Correct.

@brandonpayton brandonpayton mentioned this issue Jul 25, 2024
Merged
brandonpayton added a commit that referenced this issue Jul 25, 2024
@brandonpayton
Playground block: a11y: Avoid lost focus due to activation (#338)
80e8797 
## What, why, and how?

Before this PR, clicking the Activate Live Preview button loses the
focus because the button disappears as soon as it is clicked. This is
not good for accessibility. This PR updates the block to move focus to a
meaningful location, the "Beginning of Playground Preview" marker, when
the Activation button is clicked.

Related to #290

## Testing Instructions

Because the Beginning of Playground Preview marker is not actually shown
when focused, I tested via the following dance:

- Open a post with a Playground block that requires activation
- Open the dev tools console
- Run the following in the console: `setTimeout(() =>
console.log(document.querySelector(':focus')), 2000)`
- Click the Activate Live Preview button before the timeout
- Observe that the before-preview marker is logged as having the focus
@brandonpayton
Copy link
Member

Ok, great. I've made that update in #338 which should be included with the next release.

@brandonpayton brandonpayton moved this from Up next to Reviewed in Playground Board Jul 26, 2024
@adamziel
Copy link
Collaborator

@brandonpayton is this one now resolved, since #338 is merged?

@adamziel adamziel moved this from Reviewed to Needs Author's Reply in Playground Board Aug 27, 2024
@joedolson
Copy link

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.

@adamziel adamziel moved this from Needs Author's Reply to Inbox in Playground Board Sep 5, 2024
@brandonpayton brandonpayton moved this from Inbox to Up next in Playground Board Sep 7, 2024
@brandonpayton brandonpayton mentioned this issue Sep 7, 2024
Merged
@brandonpayton
Copy link
Member

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.

@adamwoodnz adamwoodnz mentioned this issue Sep 23, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@brandonpayton brandonpayton

Labels
Accessibility Bug Something isn't working Playground block
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@adamziel @brandonpayton @joedolson @alexstine