-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Improve the link preview accessibility and labels. #60908
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,7 +6,7 @@ import clsx from 'clsx'; | |
| /** | ||
| * WordPress dependencies | ||
| */ | ||
| import { __, sprintf } from '@wordpress/i18n'; | ||
| import { __ } from '@wordpress/i18n'; | ||
| import { | ||
| Button, | ||
| ExternalLink, | ||
|
|
@@ -96,7 +96,8 @@ export default function LinkPreview( { | |
|
|
||
| return ( | ||
| <div | ||
| aria-label={ __( 'Currently selected' ) } | ||
| role="group" | ||
| aria-label={ __( 'Manage link' ) } | ||
|
Comment on lines
+99
to
+100
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The |
||
| className={ clsx( 'block-editor-link-control__search-item', { | ||
| 'is-current': true, | ||
| 'is-rich': hasRichData, | ||
|
|
@@ -107,7 +108,14 @@ export default function LinkPreview( { | |
| } ) } | ||
| > | ||
| <div className="block-editor-link-control__search-item-top"> | ||
| <span className="block-editor-link-control__search-item-header"> | ||
| <span | ||
| className="block-editor-link-control__search-item-header" | ||
| role="figure" | ||
| aria-label={ | ||
| /* translators: Accessibility text for the link preview when editing a link. */ | ||
| __( 'Link information' ) | ||
| } | ||
|
Comment on lines
+114
to
+117
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This seems like a good option 👍 |
||
| > | ||
| <span | ||
| className={ clsx( | ||
| 'block-editor-link-control__search-item-icon', | ||
|
|
@@ -149,26 +157,25 @@ export default function LinkPreview( { | |
| label={ __( 'Edit link' ) } | ||
| onClick={ onEditClick } | ||
| size="compact" | ||
| showTooltip={ ! showIconLabels } | ||
| /> | ||
| { hasUnlinkControl && ( | ||
| <Button | ||
| icon={ linkOff } | ||
| label={ __( 'Remove link' ) } | ||
| onClick={ onRemove } | ||
| size="compact" | ||
| showTooltip={ ! showIconLabels } | ||
| /> | ||
| ) } | ||
| <Button | ||
| icon={ copySmall } | ||
| label={ sprintf( | ||
| // Translators: %s is a placeholder for the link URL and an optional colon, (if a Link URL is present). | ||
| __( 'Copy link%s' ), // Ends up looking like "Copy link: https://example.com". | ||
| isEmptyURL || showIconLabels ? '' : ': ' + value.url | ||
|
Comment on lines
-165
to
-166
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This was added because users specifically wanted a way to view the full URL without having to edit it. For sighted users the URL is clipped when it overflows and thus users requested a way to see the full URL, even if that requires them hovering over a button. What's the rationale for removing this? Perhaps it's this:
Which seems true until you realise that the full URL is visually clipped. We don't want to undo that visual clipping (it's been iterated on several times) and so this was a good way to retain UX for sighted users.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not only a visual thing. You are missing the point that before being the tooltip, this is the aria-label of the button. This is basically the equivalent of the button text, would you ever provide users with a HTML button like the following one? If we want to provide users the ability to see the full URL, then the tooltip is not the right place for that. I also want to mention that these are simple, basic, accessibility principles we've been repeating sinc eyears in this project but it seems designers still don't get the point.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What I've tried to do is provide you with context you are missing regarding a UX requirement of being able to perceive the entire link. If that context doesn't currently marry with best practices then it would be nice if we could work together collaboratively and constructively to devise a more suitable solution for the benefit of users. Do you have any suggestions for how we could achieve this?
I appreciate your frustration regarding accessibility principles. I looked at the component docs and noted the lack of documentation around this component and how it should be used: https://wordpress.github.io/gutenberg/?path=/docs/components-tooltip--docs Given that this something you find yourself repeating, I think we could work together to improve the documentation and add specific notes on accessibility linking out to resources where appropriate. I'll hold my hand up and accept that I could be more informed about the specifics of a11y regarding tooltips, but I strongly believe that if we want consumers (especially 3rd party, non-Core team developers) to follow best practices we should be looking at providing documentation alongside the component. That requires a collaborative effort and I'd be more than happy to work alongside you on that if you are open to it. If not then I will do it myself.
I'm not a designer but I think it's disingenuous to paint designers in this light. Mistakes happen, it's the will to correct and improve both the code and one's own knowledge that is key. Providing documentation is also a great way to share the knowledge of individual contributors and make it more readily available to others.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For avoidance of confusion here's an example of where being able to see the entire URL is needed. Is this linking to the correct PDF? How do I know?
Again, I'm not advocating we continue to use a pattern that provides a poor experience for users of assistive tech but I feel we owe it to our users to find a solution that accounts for this requirement before we remove it from the UI.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd like to reiterate my concerns above regarding the tooltip providing important UX for sighted users. I've re-read the thread and acknowledhge that That said whilst fixing this for one set of users, we should avoid introducing a regression for another set. Therefore I wonder if it's possible to have a tooltip attached to the button which isn't used as the
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see you are exploring in #61158. I'll check that too.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've re-tested the implementation on this PR and I've changed my opinion. Having a very long URL in a tooltip doesn't offer a huge amount of value. It is also detrimental to the UX for a large number of users. With the advancements to the Link UI in WordPress 6.5 it's now much easier to just click "Edit" and see the full URL in the form input field. Prior to those changes it was necessary to click several buttons to achieve the same thing. So overall I'd be in favour of this change. |
||
| ) } | ||
| label={ __( 'Copy link' ) } | ||
| ref={ ref } | ||
| accessibleWhenDisabled | ||
| disabled={ isEmptyURL } | ||
| size="compact" | ||
| showTooltip={ ! showIconLabels } | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for spotting this.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is extremely annoying that contributors to this project keep missing this. That also proves there is a lack of manual testing and no one tests the UI with the 'Show button text labels' preference enabled, which is less than ideal.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Again the documentation makes no mention of this. We don't have to make it wordpress specific but mentioning when this property should / shouldn't be applied would help avoid contributors needing to monitor for further reoccurrences. https://wordpress.github.io/gutenberg/?path=/docs/components-button--docs
I don't think it's helpful to draw such conclusions from a single PR review instance. In this case I didn't perform manual testing as it was a first pass review. Happy to do so once the issue of preserving the ability to perceive the full URL from the preview has been addressed.
I find it's usually best to avoid generalisations such as this. Indeed, whilst I won't name them, I can think of many contributors (including designers) who do this on a regular basis.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd recommend we be proactive here and raise another PR to update the documentation for this prop to add some guidance about it's effective usage. We could explain the a11y best practices that surround this and help to guide future contributors. Any other components that make use of this prop could also be covered. I wonder what @ciampo thinks about improving the guidance around relying on icons/tooltips in the component library?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Better documentation is always a win! I should also mention that it was recently agreed (see #65989 and #66021) that The anchor should be self-sufficient when it comes to their accessible label / description — ie. they should either have accessible content, or use the I can look into updating |
||
| /> | ||
| <ViewerSlot fillProps={ value } /> | ||
| </div> | ||
|
|
||



Uh oh!
There was an error while loading. Please reload this page.