Expose slideout widgets as dialogs to assistive technology

[sean-cstk]

Addresses #670 for the slideout layout. Opening as a draft for engineering to approve or redirect — the semantics choice below is a judgment call and I'd rather have it challenged than assumed.

Problem

Slideout templates render no dialog container, so the widget root carried no role and no accessible name. A screen reader landing on a slideout announces only the "Close" button — no headline, no message, no indication a widget opened.

Confirmed against a customer's live site (ZD 22915). Their developer ran:

document.querySelector('.pf-widget').closest('[role="dialog"]')  // -> null

Change

One block in createWidgetHtml, scoped to layout === 'slideout':

• role="dialog" on the widget root
• aria-labelledby / aria-describedby pointed at the headline and message elements
• ids derived from the widget's own config.id, so multiple widgets on a page don't collide

The judgment call (please push back if you disagree)

No aria-modal, and no focus trap. A slideout doesn't block the page or contain focus. Setting aria-modal="true" without a real trap tells assistive-technology users they're confined to a dialog when the rest of the page is still live and reachable — worse than the current silence. So this marks the widget as a dialog and names it, without claiming modality.

If the team would rather slideouts behave as true modals (trap + aria-modal), that's a bigger behavioral change and I'd want that decided here rather than assumed.

Verified

jsdom harness rendering a real slideout config against the built bundle, before and after:

	before	after
role	null	dialog
aria-labelledby	null	clorox-wipes-win-headline
aria-describedby	null	clorox-wipes-win-message
aria-modal	null	null (intended)
closest('[role="dialog"]')	null	found
accessible name	none	"Wipe. Wipe. Win!"

Modal regression check: root role stays null, container keeps role="dialog" + aria-modal="true". Unchanged.

Scope

Slideout only. bar and inline have the same gap but likely want different semantics (region/complementary rather than dialog) — left for follow-up under #670.

Independent of #669 (the aria-labelledby spelling fix on modal/gate). Neither depends on the other.

[cthorn-cs]

CI failure is a test-coupling issue, not a problem with the accessibility change — the slideout semantics are correct.

The three failing A/B specs count rendered widgets with a substring id selector, e.g. $('[id*="ab-widget1"]'), which assumes each widget contributes exactly one id-bearing element. This PR's aria wiring correctly adds two more per slideout (…-headline, …-message, the targets of aria-labelledby/aria-describedby), so the count triples — hence "Expected 3 to be 1" and "Expected 6 to be 2".

Fix is test-only — scope those selectors to the widget root class so the new child ids don't inflate the count:

-    var w = $('[id*="ab-widget1"]');     // line 31
+    var w = $('.pf-widget[id*="ab-widget1"]');
-    var w = $('[id*="ab-widget2"]');     // line 72
+    var w = $('.pf-widget[id*="ab-widget2"]');
-    var w = $('[id*="ab-widget10"]');    // line 236
+    var w = $('.pf-widget[id*="ab-widget10"]');

.pf-widget matches only the root (headline/message are .pf-widget-headline/.pf-widget-message), so the counts go back to 1 and 2. Lines 185–187 don't fail because those widgets are modals (fixed pf-widget-headline id, not config.id-derived), but they could be tightened the same way for consistency. The slideout change itself — including keeping aria-modal off — is unaffected.

[cthorn-cs]

LGTM. Slideout dialog semantics look right, and keeping aria-modal off (no focus trap without real containment) is the correct call. CI's green after the A/B selector fix.