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.

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

Add hyperlink to Column and Group blocks #45959

Open
stellarwebworks opened this issue Nov 22, 2022 · 13 comments
Open

Add hyperlink to Column and Group blocks #45959

stellarwebworks opened this issue Nov 22, 2022 · 13 comments
Labels
[Block] Columns Affects the Columns Block [Block] Group Affects the Group Block [Type] Enhancement A suggestion for improvement. [Type] Feature New feature to highlight in changelogs.

Comments

@stellarwebworks
Copy link

stellarwebworks commented Nov 22, 2022

What problem does this address?

There is currently no way to wrap a link around a group of elements. This is a very common requirement, e.g. a 'card' that could contain paragraphs, headings, images but the whole card needs to be linked to something, not just the internal elements.

What is your proposed solution?

Add a link button on Group and Column blocks so that the whole group or column can be wrapped in a a hyperlink. I guess the priority would be adding this to groups first because a linked group could be placed into a column to achieve the outcome, but it makes sense to have columns linkable too.

@mrfoxtalbot mrfoxtalbot added [Type] Enhancement A suggestion for improvement. [Block] Group Affects the Group Block [Block] Columns Affects the Columns Block labels Nov 22, 2022
@mrfoxtalbot
Copy link

I love the idea, thank you @stellarwebworks!

@mrfoxtalbot mrfoxtalbot added the [Type] Feature New feature to highlight in changelogs. label Nov 22, 2022
@cbirdsong
Copy link

This seems like a difficult thing to add, since doing it properly requires a lot of thought about the overall contents and composition of the block link.

It would be easy if we could simply add a URL field to the containing block and wrap it in an <a>, but that is not accessible and can result in invalid HTML. The only correct way to do this is using the "stretched link" pattern attached to a link within the block, but that requires:

  • a toggle to set any link within the containing block as the stretched link, but only allowing it to be enabled on a single link at a time
  • the containing block being aware that it contains a stretched link to add position: relative; to contain the link, as well as hover and focus states that can be customized
  • ensuring that any other links or interactive elements inside the containing block are usable without accidentally activating the block's stretched link
  • making sure the stretched link does not get broken by creating a new containment context in CSS, which is something the editor cannot easily communicate to the user

It's deceptively complicated. Adrian Roselli's article about accessible cards is a generally good overview of the potential pitfalls of this pattern and what solutions are workable, along with supporting links to other resources.

@stellarwebworks
Copy link
Author

Check out how it's implemented in the EditorsKit plugin. It's implemented as a stretched link. Once you have an active stretched link, no other elements in the column/group can be interacted with, but that is the expected behaviour - the whole container becomes a hyperlink anchor. This looks like a good implementation to me.

I think much of the accessibility issues addressed in Adrian Roselli's article would be up to the end user to implement, Gutenberg just provides the capability of creating a 'block link' or 'card' but is not responsible for how accessible the user makes it, much of which is dependent on the inner contents of the block/card and css used.

@chthonic-ds
Copy link
Contributor

Once you have an active stretched link, no other elements in the column/group can be interacted with, but that is the expected behaviour

This behaviour isn't always safe to assume. If a card design specifies an additional link—for example, a link to a category or tag archive the card belongs to—the stretched link approach can still be used. See this demo using the stretched link approach with a secondary "author" link: https://heydon.github.io/Inclusive-Components/cards-pseudo-content-author-link/.

Gutenberg already supports linking a title, structurally enough to use the stretched link approach. Not supporting links around a container-type element seems to me like a good trade-off to avoid the potential here for inaccessible content being published.

@stellarwebworks
Copy link
Author

@chthonic-ds I really like that example of card (I'll be borrowing that idea myself). However it's probably not easy to implement in Gutenberg as a linkable column or group since it is dependant on what blocks are inside those containing blocks. But I still think that a stretched link like that implemented in the EditorsKit plugin would be a great addition and serve a lot of use cases even with the limitation that it blocks any other links contained within the block. I realise that one can implement 'cards' with currently available native blocks, but it requires technical know how. For non-technical users, having a linkable column or group will allow them to create these type of cards easily and intuitively and I think that the limitation with the link taking over the whole block is acceptable. For accessibility purposes, one could add an optional field to contain text for the link which can be visually hidden but available to screen readers.

@cbirdsong
Copy link

Looking at EditorsKit, the way it implements this is by adding an empty <a href="/whatever/"></a> to the end of the container to stretch out. This is an instant WCAG failure, since the link has no text and would not be comprehensible to a screen reader.

For accessibility purposes, one could add an optional field to contain text for the link which can be visually hidden but available to screen readers.

I don't think implementing it via a separate "accessible text" field is a good idea, since the link's text should almost always already be present on the page, and a separate field would make it very easy for content editors to forget to update the accessible text, especially if the field is optional.

@mrfoxtalbot
Copy link

Just to add more context, there is parallel conversation going in the case of the cover block here #45702

@lefty55104
Copy link

Wouldn’t it be MORE accessible since it would remove the repetitive links?

@bissy
Copy link

bissy commented Jul 7, 2023

https://heydon.github.io/Inclusive-Components/cards-pseudo-content-author-link/

We can not select text in this Cards.
Some people use selecting to read text, and some people copy text to memo.

@mateitudor
Copy link

it's been 84 years

@uniquesolution
Copy link

wp community Its really a very important need of the day and here I am suggesting my approach for a solution that will be accessible too.

  1. in group block allow <a> tag as selection option for HTML element under Advanced option, this will make group tag as a tag. See screenshot to understand what I am talking about https://prnt.sc/OElvxMhMy9KB
  2. Also provide URL, aria-label and title option in the group additional field dynamically if someone have chosen <a> as HTML element for the group. this way we can make that anchor accessible even if inner blocks not have any content that represent link.
  3. Now for the Link field I would suggest that it provide option to choose custom link or post title link (helpful in case when using inside query loop for designing ). Also consider about open in new tab option for the link
  4. Now as the whole group is a link we can put any image, text, other blocks and the whole design will work as clickable link.
  5. Now if someone going to use any link inside that group a warning message should show that group is already using a link, and though the internally provided button or any other link will not work, accept you not change the tag of the parent group. This way we can avoid any overriding a tag inside the group that is already an a tag.

Let's keep this discussion going and suggest the issue of still implementing this in a group.

@cthollaway
Copy link

+1 to this idea. Would love to be able to make cards of different styles clickable in any area, not just on the buttons or text.

@carolinan
Copy link
Contributor

Also provide URL, aria-label and title option in the group additional field dynamically if someone have chosen as HTML element for the group. this way we can make that anchor accessible even if inner blocks not have any content that represent link.

Now if someone going to use any link inside that group a warning message should show that group is already using a link,

These steps are not enough to make the card accessible.
Both group, column and cover can have other interactive elements placed inside of them, not only links.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Columns Affects the Columns Block [Block] Group Affects the Group Block [Type] Enhancement A suggestion for improvement. [Type] Feature New feature to highlight in changelogs.
Projects
None yet
Development

No branches or pull requests

10 participants