Experience popups are not accessible to screen readers (WCAG/ADA compliance gap) #670

Summary

On-site Experience popups render without the semantics assistive technology needs. A screen-reader user cannot perceive that a popup has opened, cannot read its heading or message, and in most popup styles cannot operate it by keyboard. This affects every customer using web Experiences, and it is a legal-compliance concern, not only a UX one.

What's wrong

• Only the modal and gate layouts expose dialog semantics (dialog role, accessible name, description). The slideout, bar, and inline layouts expose none of it.
• Keyboard support is limited to modal: focus containment exists only for modal/gate, Escape-to-close exists only for modal, and focus is never returned to the page when a popup closes.
• Net effect in the affected layouts: the only announceable content is the "Close" button. No title, no body, no indication a popup appeared.

Customer impact (ZD 22915 — Clorox)

• Clorox's live experience on clorox.com is a slideout. Their own developer inspected the rendered page and confirmed no dialog semantics are present; a screen reader announces only "Close, button."
• Clorox raised this directly as an accessibility defect and cited the W3C dialog pattern. They are a major public-facing consumer brand and treat accessibility as a compliance requirement.
• The popup library is a single shared script loaded by all customers, so the same gap is present on every customer site running Experiences.

Legal / compliance exposure

• In the US, web accessibility is enforced under the ADA (Title III), with WCAG 2.1/2.2 Level AA as the de facto conformance standard, and Section 508 where federal contexts apply. ADA web-accessibility demand letters and lawsuits are high-volume and rising.
• The EU European Accessibility Act (in force June 2025) extends comparable obligations for products and services offered in the EU, relevant for global brands.
• Unnamed dialogs and missing keyboard operability are commonly cited WCAG failures (name/role/value, keyboard operability, focus management). Because these popups are injected into the customer's page, the inaccessible markup becomes part of the customer's own compliance surface — exposure for the customer and contractual/reputational risk for Lytics.

References

• Zendesk 22915 (Clorox)
• PR Fix aria-labelledby typo on dialog widget containers #669 — corrects an invalid label attribute on the modal/gate dialog containers. Necessary, but does not address the layouts above.