Tweak language around modal dialogs

[patrickhlauke]

Closes #4185

Note that this only softens/expands some of the example language in the understanding documents. The original issue #4185 seems to conflate non-normative examples in a non-normative document with requirements of how modal dialogs should be implemented ... they are not. They provide examples of appropriate focus order and absence of keyboard traps. They are not the only ways in which focus order or absence of keyboard traps can be achieved. Examples are non-exhaustive, and there is no need - in my view - to expand these further to specifically address variations that result from different behaviours related to <dialog>

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	a08d776
🔍 Latest deploy log	https://app.netlify.com/projects/wcag2/deploys/68921e2350543c00088a3789
😎 Deploy Preview	https://deploy-preview-4381--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[mbgower]

someone misconstruing an example with a normative edict shouldn't necessarily lead us to made the examples less clear or confusing (which I personally find these to be). I'd prefer to leave as is, or lessen the change.

@mbgower As I understand it, the extension of the text is meant to prevent people from failing modal dialogs where the focus ring includes the browser chrome (e.g. the URL field) which does not seem problematic. Is that the only point where you feel it gets confusing?

[adampage]

Heya, @patrickhlauke / @mbgower, how about these tweaks?

[fstrr]

In the Focus Order update, I would prefer the text about being able to cycle through the user agent controls be reinstated, alongside the edit, so that it's clear that that behavior is okay.

[patrickhlauke]

@fstrr should we split the difference and maybe add a parenthetical somehow that reintroduces this? a la

all web page content outside the dialog becomes inert and cannot receive focus
(though, depending on implementation, the focus cycle might still include user agent controls)

[patrickhlauke]

@fstrr should we split the difference and maybe add a parenthetical somehow that reintroduces this? a la

all web page content outside the dialog becomes inert and cannot receive focus
(though, depending on implementation, the focus cycle might still include user agent controls)

as discussed in today's WCAG 2.x backlog call, I've made that change @fstrr

[iadawn]

Does this section say something slightly different to the APG modal dialogs pattern keyboard interaction section?

My personal view is that the APG needs to be changed to avoid focus being locked into the modal.

[patrickhlauke]

APG is only a best practice suggestion, one way to implement a modal, and generally what the keyboard behaviour would be. it's not binding, and the revised wording here takes account of the fact that there are other valid implementations - like a <dialog> element - where browser UI will also still be within the focus order.

otherwise, this may suggest that native <dialog> fails WCAG

[adampage]

I’ve heard anecdotally that one of the reasons the WHATWG chose not to trap focus in the <dialog> element is because that behavior has been used maliciously to extract sensitive information from vulnerable users.

Because of that, I’ve been tempted to submit a PR to APG updating its ARIA dialog implementation to follow suit. There’s an open (but 3 years stale) discussion about this here: w3c/aria-practices#1772. I’ve looked around for a paper trail on that WHATWG decision but haven’t been able to find anything.

[iadawn]

Same issue as above

[mbgower]

@adampage please take this up with the APG #4381 (comment)