Web component flagged as missing text

Yeah; Editoria11y and Sa11y are running a homebrewed abbreviated version of the accessible name algorithm that roughly matches markup that is possible to create with CKeditor and Gutenberg. Haven't added slot name computation yet.

It won't be hard. I'll look into wrapping it into the next release.

OK I've added the ability to read text in slotted templates and added this case to my automated testing.

I am going to wait until January to tag a release though just in case this breaks something unexpected.

Fixed in 2.2-RC10. I'll backport this next time I refresh 2.1.

Also fixed in 2.1.22.

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

Hi @itmaybejj,

I was testing this new integration and I'm finding the scanner cannot see inside the shadowroot as I expected. I looked in the code and it seems only if the heading tags are found in a slot, which is visible already to the Light DOM, will the scan tool pick them up. If the heading tag is only being output into the Shadow DOM inside a template of a valid HTML web component, the scan tool will not detect the heading tags. Essentially the request should be to add the name of a custom web component, and then the tool attaches Shadow Root when that web component is selected and scans inside the shadow root. Should we open a new issue for Shadow Root scan support?

See:

• https://developer.mozilla.org/en-US/docs/Web/API/Element/shadowRoot
• https://developer.mozilla.org/en-US/docs/Web/API/ShadowRoot

Agree with @matthand on the need to check inside the web component and not only the slot. Unfortunately, this update did not resolve our issue due to the structure of our Heading web component. Editoria11y is not able to check all our Heading web components at the moment.

Attached is a screenshot of our Heading web component structure where the heading tags are outside the slot. We only have text inside the slot, so this is ignored by Editoria11y. You can visit this page on our web site to see the H1 as our Heading web component. https://www.principal.com/finpro/policy-riders-and-endorsements.

Additional screen shots added to provide context on our Heading web component structure.

Oh my goodness; this is the first time I've seen a nested Web component. I think both my element finder and name computation only recurse once and will need to be rewritten. I'll reopen this issue.

I should have a release ready for this in April.

itmaybejj → closed merge request !24

If y'all are up for testing something, I'm hoping MR 25 will take care of this.

I'm flagging this as fixed for now because of testing on a copy of your DOM. Please test 2.2.5 → with the new param "Auto-detect any Web components" turned on under "Web components and custom tests," and reopen if I haven't succeeded.

I have that param off by default for now until I'm confident it both works and doesn't hurt performance. This part of the code usually finishes in less than 1ms so I don't think it's going to hurt performance in any noticeable way.

@itmaybejj I have confirmed this is fixed by testing version 2.2.5.

I first tested with the new param "Auto-detect any Web components" turned on. Success!

Next, I tested with only the "Check inside these specific Web components" with the value "pds-heading". Also success!

Screenshots attached of my local testing as editoria11y-test-1.png, editoria11y-test-2.png, editoria11y-test-3.png

Thank you so much for addressing this issue. Our Content Authors will be very relieved they can rely on this tool once again to catch skipped headings. Our team appreciates you and this module!

🎉
Huzzah!

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