I suggest that the default tag for an embedded-entity should not be <article>.

<article> should be reserved for:

The element represents an independent item section of content.

  • forum post
  • magazine article
  • newspaper article
  • blog entry [Example A]
  • user-submitted comment

https://www.w3.org/wiki/HTML/Elements/article

In most scenarios when an entity is embedded it is already inside an <article> tag. People often use this module to embed a photo entity or a video entity. I submit that we should not assume that all embedded Entities are stand alone pieces of content.

There are scenarios where an embedded Entity could be embedded in another embedded entity causing deeply nested article tags.

I would like to change the entity-embed-container.html.twig template to use <div> wrapper instead of <article>.

To be fair, it is valid to nest <article> tags inside <article> tags if the content stands on its own. But I submit that a photo by itself is not an <article>.

We all know that anyone can override the template to do whatever they see fit. Which scenario is the edge case? What should we assume to be the best default tag. Does anyone else have an opinion on this?

Release notes snippet

Note that for improved accessibility, embedded entities are no longer wrapped in <article> tags, but in <div> tags. This may require some CSS changes.

Comments

joelhsmith created an issue. See original summary.

mgifford’s picture

Issue tags: +Accessibility

Articles like sections are both regions that should have an associated heading.
https://thepaciellogroup.github.io/AT-browser-tests/test-files/article.html
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article
http://html5doctor.com/the-article-element/

Seems to me that entities are are too generic. They could be articles, but we shouldn't assume that they are.

Any reason to not just make the <article> a <div>?

Edit: Adding a thanks to Dennis Lembrée for pointing out the issue from Twitter & pointing me to good direction on this too.

wim leers’s picture

Title: Accessibility suggestion » Wrapping embedded entities in <article> is bad for accessibility, use <div> instead
Component: CKEditor integration » Code
Category: Feature request » Bug report
Priority: Normal » Critical
Related issues: +#2712111: Embed specific attributes are cached along with the entity

This was introduced in #2712111: Embed specific attributes are cached along with the entity. @Dave Reid also questioned this in #2712111-28: Embed specific attributes are cached along with the entity, but @slashrsm said he thought it was better in #2712111-30: Embed specific attributes are cached along with the entity. Accessibility wasn't mentioned at all in that issue.

wim leers’s picture

johnflower’s picture

Thanks Wim for looking into this.

phenaproxima’s picture

Status: Active » Needs review
StatusFileSize
new373 bytes

Quick patch, let's see how many tests break (which aren't already broken in HEAD).

Status: Needs review » Needs work

The last submitted patch, 6: 2881745-6.patch, failed testing. View results

phenaproxima’s picture

Status: Needs work » Needs review
StatusFileSize
new5.76 KB
new5.31 KB

Okay, this should fix the non-HEAD failure.

Status: Needs review » Needs work

The last submitted patch, 8: 2881745-8.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

phenaproxima’s picture

Status: Needs work » Needs review
Issue tags: +Needs accessibility review

Those failures are expected. This is squarely in a reviewable state.

marcoscano’s picture

+++ b/templates/entity-embed-container.html.twig
@@ -12,4 +12,4 @@
-<article{{ attributes }}>{{ children }}</article>
+<div{{ attributes }}>{{ children }}</div>

Without entering into the discussion about what tag is more appropriate, changing it here would introduce a BC break for existing sites (it can actually break existing sites' theming). I would then suggest we either consider adding this to a new branch, or create a configurable setting (which may or may not be exposed on the UI), where: on new sites the setting is configured to use a <div> tag, and on existing sites it will keep using <article>. Thoughts?

wim leers’s picture

would introduce a BC break for existing sites

Hm … interesting remark!

Three thoughts:

  1. It's our duty to fix the accessibility of existing sites too.
  2. Any CSS targeting this wrapper tag ought to be targeting it using classes already anyway.
  3. This module is only in beta, not in RC or stable, so it's not frozen.

So IMHO disruption should be minimal, and people know the consequences of using beta-stability modules.

edmonkey’s picture

I agree that these should be generic divs, overuse of the articles isn't semantically correct and could be frustrating for assistive tech users.

Theres been a core issue similar which had been fixed (I found it when looking for this issue), so following that appraoch makes sense.
https://www.drupal.org/project/drupal/issues/2878115

+1 for making this change.

wim leers’s picture

joelhsmith’s picture

Thank you everyone for your hard work on my little request. It warms the heart of us Accessibility people everywhere to see how much the Drupal community cares for people with a variety of abilities.

wim leers’s picture

@joelhsmith Awww! ❤️❤️❤️

wim leers’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs accessibility review

#10: per #2, #13 (which refers to #2878115: Make the HTML wrapper tag for media items more semantically correct, which basically made the same change in core) and #15 (who also opened this issue), I think it's fair to say we've actually already had the necessary accessibility review.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 8: 2881745-8.patch, failed testing. View results

marcoscano’s picture

#12:

So IMHO disruption should be minimal, and people know the consequences of using beta-stability modules.

Can we at least add a specific warning at the notes of the release where this will be included, so this change stands out to people reading that before updating?

Thanks!

wim leers’s picture

#2328659: Convert all existing entity_embed tests from WebTestBase to BrowserTestBase improved the tests, which means this patch no longer applies.

wim leers’s picture

Issue summary: View changes

Can we at least add a specific warning at the notes of the release where this will be included, so this change stands out to people reading that before updating?

+1. Done: added release notes snippet to IS.

phenaproxima’s picture

Status: Needs work » Reviewed & tested by the community
Issue tags: -Needs reroll
StatusFileSize
new5.8 KB

Rerolled!

wim leers’s picture

Status: Reviewed & tested by the community » Fixed

🎉

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

andrewmacpherson’s picture

Priority: Critical » Normal

If this issue was marked critical on the basis of accessibility, that's WAY off the mark, I think.

Articles like sections are both regions that should have an associated heading.

#2 is misleading in my view. I've given an explanation on an active core issue: #3029740-7: Media content is wrapped with an article wrapper if stable or classy theme is used or extended