Open jessynd opened 2 years ago
@gziolo and @Mamaduka I'ld love to hear your thoughts about introducing something like what I have done in #38012 as a new default behavior. I initially took the approach of adding it as a new opt in only option but given that he current default isn't following accessibility standards the best solution would be making it the default behavior. Thanks in advance for your insights :)
See: https://github.com/WordPress/gutenberg/pull/38012#issuecomment-1013979790
I just realized that Query Loop block's items are not clickable in all modalities.
I'm looking for an alternative until this is fixed.
Update: I had to remove Query Loop Block 🙁 and insert it again; fixed it. I lost whatever settings I had from previous Query Loop Block.
Nevermind here's the template of the Query Loop Block that is not clickable. It's the last option called offset.
I've noted that if I go with blank template I don't have options to further customize the layout once I go with presets. And items are not clickable.
Hi, I'd echo the need for some kind of containing link for the contents of the Query Loop block, for me this would mean that the heading, excerpt and featured image (and another other post elements, author etc) would be wrapped in a containing a
link. I recently had to make a custom inner block to be able to implement this, so it would be great to be able to use the standard post elements.
@rickcurran Could you clarify your work around and what that custom inner block looks like? I'm not sure I understand how the custom block would actually get the url for the post to put in the a
tag.
@dagoss Basically I made a dynamic block which uses the usesContext
property in "block.json" to access the postId
block context provided by the parent Query Loop / Post template blocks (this is used by the regular "Post Title", "Post Content" inner blocks).
"usesContext": [ "postId", "postType", "queryId" ],
In the Edit section of the block you can specify the context, e.g:
export default function Edit( { context: { postId, postType, queryId }, }) {
The dynamic PHP render.php
file can access the $block->context[ 'postId' ]
attribute to select the custom post markup with title, excerpt and thumbnail image wrapped with the permalink. Here's a rough / simplified version of what this render.php
file looks like:
if ( isset( $block->context[ 'postId' ] ) ) { $postid = $block->context[ 'postId' ]; $markup .= ' <a href="' . get_the_permalink( $postid ) . '">'; $markup .= '<h3>' . get_the_title( $postid ) . '</h3>'; $markup .= '<p>' . get_the_excerpt( $postid ) . '</p>'; $markup .= '</a>'; echo $markup; }
Hope that helps!
@rickcurran Thanks, that got me in the right direction. I was able to keep it generic enough by using <InnerBlocks />
in the edit
method, and then rendering the $content
in the render_callback
on the server side. (I got tripped up by register_block_type
vs register_block_type_from_metadata
on the server side. I was using a block.json for the component and didn't realize the function name differed between client and server.)
@rickcurran I'm trying to understand how to make certain posts in the query loop linkable, but certain other not linkable, so just having an h2.
@vito-dipinto I'm not sure how you'd make the linking conditional, I guess you'd need some kind of custom content block to go in the query loop still but then have some way to control whether the link gets added or not, you could add a checkbox control to the custom content block and enable / disable links with that.
What problem does this address?
When using the query loop in the block editor, each individual post's single view is linked to a number of times in the post template via the post-title, the post-image, post-date and the post-excerpt. What results is a redundancy of links for people that view the website with a screen reader. This is problematic:
It fails WCAG accessibility standard 2.4.4. This standard requires the purpose of a link to be clear. When the heading, post image, excerpt and date are all linked to the same article but the text of the anchor is different for each, it creates confusion and the link purpose is no longer clear. Especially when it comes to the post-date because if more than one article in the list is published on the same date, as is the case for the demo here., the same text will be linked to totally different articles, on the same page.
The redundancy of links clutters the rotor view of links and makes it confusing to the user, especially when considering that the post date links all look the same but they go to different places.
This is the rotor view of the TT2 theme demo site's query loop output:
This change is important for the experience to be better for people that use screen readers, but also to make accessibility compliance possible, especially in FSE themes. I work with clients that need to comply with WCAG AA standards and the query loop is not possible to use as it is right now because of this issue.
What is your proposed solution?