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.

@itmaybejj I'm sorry to report that heading detection is no longer working in version 2.2.6. Our websites have the setting "Auto-detect any Web components" checked on and Editoria11y no longer detects web component headings skipped nor does it detect straight up HTML headings skipped.

I have attached screenshots for context. Can you please verify that indeed this latest release 2.2.6 is no longer checking headings properly? I'm happy to provide more context or additional testing.

For now, I am recommending that our sites roll back to Editoria11y version 2.2.5 until we get a point of view from y'all. Thank you!

I don't... understand... 2.2.6 and 2.2.5 are identical; same library files, no changes to the module PHP or JS, only some missing strings in the translation file for non English language sites and a change to the dev scripts.

Is it possible there's a race condition here (possibly in my module) or a JS file load order issue, where rolling back is a red herring and it's just that clearing cache as part of the rollback hides the problem? Like, if you clear cache a few times and hard refresh is the problem intermittent in both versions?

@itmaybejj please disregard! In our projects, we had an issue where configuration for "Check content in these containers" wasn't correct. Editoria11y was failing silently due to this bad config. We were able to correct our configuration and everything is now working as desired.

When I rolled back to 2.2.5, the config for "Check content in these containers" was reset, so that is the reason it worked again. It had nothing to do with version. It had everything to do with bad config causing silent failures.

Apologies for the confusion! Silent failures are the hardest to troubleshoot!

Oh good; that's what I was hoping because all other possibilities were going to be "exciting" to try to troubleshoot.