-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
NUX: Make tips collapsed by default #11281
Conversation
Thanks for this. I do agree that having the pulsing is much better. Unfortunately in testing though there are a few issue that to me mean we have to iterate: Ideally we would I think only have in a walkthrough as the Tips are today, one showing at a time. This multiple pulsing being the first experience is too much. Whilst this goes when we only have one by one, having one Tip open is a weird experience right now. For now having it just become one by one works. Pulsing one opens to show Tip and then when you close a new one pulses. As illustrated above, having multiple Tips open is easy with them all showing. This isn't a great experience so let's step back to just 1 by 1 in a flow. That all said, I do think the pulsing itself is much better. My issue is with the number :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per my comment, let's have only one at a time for now.
6cae594
to
cd3c530
Compare
@karmatosed: I've made it so that only the first tip is collapsed! Give me a 🙂 or a 🙁 before I start work on making the tests pass so that we can merge this. |
Thanks, that's a lot better! |
cd3c530
to
9a0de00
Compare
Thanks @karmatosed! ❤️ I've made the tests pass, updated the PR description, and tagged some folks for a code review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like quite an aggressive change to be making well after a UI freeze and so close to the 5.0 release.
There are probably accessibility concerns with closing these by default. What's the intended UX for screenreaders, for instance? Do we want the tips to need to be "activated" by screenreader users (I don't think that's ideal/good UX) or should they be active by default in the DOM/screenreader UX and just visually hidden (I think that's better)?
I'll need to do a fair amount of testing on this, later in the day.
@tofumatt having multiple tips and having them open by default also has accessible issues. The goal here is to make it more usable. What can be done with it closed to pass a11y? |
If there will be multiple tips present in the UI with only a visual indicator of its relation to the UI, a screenreader won't be able to contextualise it. So each tip should have a label/short descriptor/intro to what the tip is about so a screenreader user can choose to expand it. That would be a similar UX for a screenreader and allow the tip to be hidden by default (and also allow a few on-screen at the same time without confusion). If we can't do that timing-wise... it should probably be the case that screenreader users don't have to "Open" the tips as that's a visual UX—the tip is visually hidden to reduce visual clutter, but for a screenreader it can't relate the tip to the visual UI. Best to just read it out. Does that make sense? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm missing something, but how are these tooltips announced to users of assistive technology? I don't see them being announced and I can't see how to access them with the keyboard when they're hidden. Additionally: when I clicked on one the screenreader didn't read out the contents.
These seem like an accessibility regression, which is a real shame because these tips would be useful for explaining things like keyboard shortcuts to users.
When I open a page with tips on master
, the tips are read out once I tab at least... it's not great but it works. On this branch I can't tab to the tips obviously and they're basically lost on a keyboard/screenreader user.
I would think that the best way forward would be to have tips use wp.a11y.speak( $short_tip_description )
to announce themselves to screenreader users and provide an obvious way to access them with a keyboard. Maybe include a keyboard shortcut to open them in the short description.
@tofumatt can they announce and be closed? Just want to work out boundaries here. |
Right now when there are “closed”, pulsing tips on screen there is no indication to a screenreader user.
If tips are on-screen, even closed, we should tell the user:
1. There are tips
2. How to open them
3. How to dismiss them (optional but nice)
So they can start closed, but we need a way to announce their presence if not their contents, and a way for keyboard users to access them and open them.
|
This seems like it needs a bit more work to cover all the cases. |
Picking this back up. It's something that I think we should do as part of 5.0.1, which means that there's some time to iterate on a good solution here. The button which opens a collapsed tip appears in the DOM like any other button. When I enable VoiceOver, check this branch out, and then tab through the toolbar, I can hear VoiceOver read:
Would changing the label of the Open tip button to something more explanatory suffice? e.g. I get your point about it not being immediately obvious to users of screen readers that there are tips visible on the screen. I'll need your guidance here as I'm not familiar with Stepping back, I'm not clear on how best to make the NUX guide useful to users of screen readers since much of it is premised on visually pointing to UI elements. I could use your guidance there, too. |
I agree @noisysocks. I do think it's not great they are how they are right now but it is something that can be iterated. |
works for me. 👍 Announcing there are tips available on page load might not be great actually after thinking on it because |
9a0de00
to
3206fa8
Compare
I've updated this to use a more descriptive label for screen readers. |
Thanks! 👍 (Feel free to flag me for another review once you'd like me to have another look—even if things aren't finished yet.) |
I think this is ready to go in. Just needs a code review. No rush though since it's targeted for 5.0.1 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue with this is there still isn't an announcement of the fact that there are tips anymore with them hidden. There's no awareness that a tip exists (or how to activate it) for a screenreader user.
In master
the tip, in its entirely, is read aloud to the user. Here's NVDA's speech log with it in action:
In this branch there's nothing like it so there's just no context for a tip existing.
What we need is for there to be HTML in the DOM that is read out by a screenreader instructing the user that there is a tip available and how to access it. The old tip's content were read out by the screenreader... if that didn't work then wherever the code that checks if tips should be displayed should probably use speak()
to say something like speak( 'Tips on new features are available; press $KEYBOARD_SHORTCUT to open them.' )
or something like that.
<DotTip | ||
tipId="core/editor.inserter" | ||
isCollapsible | ||
label={ ( isOpen ) => isOpen ? __( 'Close tip for ‘Add block’' ) : __( 'Open tip for ‘Add block’' ) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we use US English as our default language we should use double-quotes here, not single. Single-quotes are a British English thing 😅
I see only the first tip is a button. All the other ones are divs, so their popover can't be closed and have the pulsing tip still active. At that point, users have either to go through all the tips or dismiss them permanently. Basically this proposed change collapses only the first tip. Not sure what the added value is other than saving a few clicks. Seems to me this change tries to solve a discoverability problem by means of a more complicated and less intuitive interaction with the tips. That said, re: the first tip (the button one): while it has an For normal buttons, at least we have tooltips (which are already a big trade-off): Pre-existing issues:
|
- Adds `isCollapsible` to `DotTip` so as to support collapsible tips. These are tips that only show the indicator dot. When the indicator dot is clicked, the tip opens like normal. - Make the NUX guide less overwhelming by collapsing the first tip in the guide.
4b065a1
to
5fa8316
Compare
Thanks for the feedback everyone!
I've had a first pass at doing this in 1874e0e. Let me know what you think and we can iterate on the approach 🙂
cc. @karmatosed who can explain the motivation here. My understanding is that we want to make a user's first impression of the new editor less overwhelming by not having the first tip appear so intrusively on the screen.
Good catch—I've added a tooltip in e06f982.
Are there issues for these? They sound like bugs that we should fix regardless of whether this PR lands. |
Attempts to improve the accessibility of tips by: - Allowing `DotTip` to be expanded or collapsed using a keyboard shortcut configured with the `shortcut` prop. - Having collapsed tips that have a shortcut configured `speak()` when mounted so that screen reader users are aware of their presense.
4caa979
to
e06f982
Compare
I understand the goal of this PR 🙂 I'm just saying that it makes things more complicated, interaction becomes unexpected, at the point I wonder if tips still honor the reason they were implemented for. The original goal was: on first load you see a message that encourages you to discover more about the new experience. Now instead we want to hide them ¯_(ツ)_/¯ |
After speaking with @karmatosed, we're shelving this PR for now. In the future we would like to revisit the UX of tips more whole holistically. |
Closes #9242. Fixes #12358.
Makes the NUX guide less overwhelming by collapsing the first tip in the guide.
What's changed:
DotTip
has a newisCollapsible
prop which marks it as being a collapsible tipisCollapsible
How to test