Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.If you add a heading with ARIA attributes, say <h3 role="navigation" aria-label="This is a label">Testing 123</h3> within the body of a node that is limited to Basic HTML it is converted to <p>Testing 123</p> and the attributes are stripped.
This is a conversion process. if you put in <p role="navigation" aria-label="This is a label">Testing 123</p>, there's no problem.
This is an issue for ATAG 2.0 B.1.2.1 Restructuring and Recoding Transformations (WCAG).
Basically good accessibility attributes are being removed as a result of a transition because a tag isn't allowed. The attributes just need to be brought forward.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | Screen Shot 2022-03-11 at 11.30.02 am.png | 27.97 KB | darvanen |
Comments
Comment #1
mgiffordComment #2
dawehnerUh, I thought that bugs are considered as 8.0.x material, especially why they don't break APIs
Comment #3
mgiffordI'm happy dealing with it in 8.0 if we can. I've been trying to trim down the list of #a11y issues that I think we can get to before the release of D8.
Since there was no movement here I bumped it to 8.1. I'll move this back for now though. Thanks for the clarification @dawehner
Comment #14
darvanenThis came up as the daily triage target for the bug smash initiative.
In order to reproduce this I:
<h3>from the allowed tags<p>tagThe result was the removal of the
<h3>tag with no replacement at all:It looks like the disallowed tags are being stripped by the input filter, then replaced with a
<p>tag later, likely by CKEditor interpreting a line break.I'm not sure this can be solved because there is currently no such thing as tag replacement in the backend as far as I can tell, and with good reason. Replacing all disallowed tags with a
<p>tag would cause chaos.I think this one might need to be "won't fix".
Comment #15
longwaveTo me this is works as designed, if someone enters an h3 and that is disallowed by the input format we must strip it, attributes and all. We can't really know what to do with any attributes automatically - there may be nowhere to put the attributes (as in #14), what if the attributes already exist on the next element we try to merge them into, what if there are multiple choices of where to put the attributes, etc.
Reading ATAG 2.0 B.1.2.1, to me it is not about filtering, more about transforming markup permanently in an editor tool. There is no permanent data loss here - the attributes are preserved in the source field, they just happen to be filtered from this particular output - the HTML could be output elsewhere in a different format that preserves the accessibility info.
Comment #16
darvanenYou're right, it still has those tags/attributes in the database. They do get stripped off the next time you go to edit the content.
"works as designed" works for me. I'll wait a little longer and see if there are other opinions before applying it.
Comment #17
jonathanshawI agree this suggests no way of fixing.
Comment #18
darvanenI'm calling it.
If you stumble across this and can think of a way to solve the currently-unsolvable, please feel free to reopen.