![\"Black](\"https:\/\/html5accessibility.com\/stuff\/wp-content\/uploads\/2025\/06\/IMG_4417-Copy-1.jpg\")
<\/p>\n<\/p>\n
Note:<\/strong> I tried to find the orginal of this photo so I could attribute it to its creator, but came up with nothing, maybe Jonny knows…<\/p>\n Back in 2014 I did some testing on Some stuff that doesn\u2019t work between the DOM and Shadow DOM<\/a> I was recently asked by my friend\/colleague Demelza Feltham<\/a> about use of What I found back then was that I don’t plan to go into the details of why it doesn’t work yet here, but I can assure it’s not for lack of trying on the part of Standardista’s<\/em> and and Browser engineers. If you want to read more about the reasons why and why it still has not been resolved, the following are illuminating:<\/p>\n The attributes potentially affected by this issue are:<\/p>\n Relationship attributes<\/a>:<\/p>\n Some relationship attributes<\/p>\n You could use standard HTML controls<\/a> without all that stinking<\/em> DOM darkness and encapsulation fandango<\/em> fucking up your relationships.<\/p>\n Defy the JavaScript industrial complex<\/em> by any means necessary<\/strong><\/p>\n If this is not an option, then there are some ways you can work around these issues in some<\/em> cases. A relatively simple example is provided:<\/p>\n Example with an See the Pen Old gold<\/h2>\n
aria-labelledby<\/code> that referenced an element in the Shadow DOM<\/p>\naria<\/code> relationship attributes didn’t work when an element being referenced was outside the shadow DOM and the element referencing it was inside the shadow DOM, ditto for the opposite. It was same story for native HTML relationships as well. Fast forward to 11 years later, as in now! 2025<\/strong>, and the situation remains the same<\/strong>.<\/p>\n\n
ARIA<\/h2>\n
\n
aria-activedescendant<\/code><\/a><\/li>\naria-colcount<\/code><\/a><\/li>\naria-colindex<\/code><\/a><\/li>\naria-colspan<\/code><\/a><\/li>\naria-controls<\/code><\/a><\/li>\naria-describedby<\/code><\/a><\/li>\naria-details<\/code><\/a><\/li>\naria-errormessage<\/code><\/a><\/li>\naria-flowto<\/code><\/a><\/li>\naria-labelledby<\/code><\/a><\/li>\naria-owns<\/code><\/a><\/li>\naria-posinset<\/code><\/a><\/li>\naria-rowcount<\/code><\/a><\/li>\naria-rowindex<\/code><\/a><\/li>\naria-rowspan<\/code><\/a><\/li>\naria-setsize<\/code><\/a><\/li>\n<\/ul>\nHTML<\/h2>\n
\n
for<\/code> attribute on label<\/code><\/a> element<\/li>\nfor<\/code> attribute on output<\/code><\/a>\u00a0\u00a0element<\/li>\nheaders<\/code> attribute on th<\/code><\/a> element<\/li>\n<a href=\"#IDinShadows\"><\/code><\/li>\n<\/ul>\nWhat you can do?<\/h2>\n
output<\/code> element outside the Shadow DOM and an input type=\"range\"<\/code> element inside, the output<\/code> updates with the current range<\/code> value:<\/p>\n\n
range input<\/code>, an input event<\/code> is triggered.<\/li>\n<output><\/code> element\u2019s .value<\/code> to match the range<\/code> value.<\/li>\n<output for=\"...\"><\/code> (via JavaScript) would have been done automatically if both were in the same DOM context:<\/li>\n<\/ul>\n \/\/ Update output value when range input changes\r\nshadowRange.addEventListener('input', () => {\r\noutput.value = shadowRange.value;\r\n});<\/pre>\n
\nUntitled<\/a> by steve faulkner (@stevef<\/a>)
\non CodePen<\/a>.<\/p>\n