SC 2.1.2 Tab looping

[Que-tin]

There is a problem with the following example that leads to major differences between the browser and open source implementations for the dialogs:

When the dialog has been opened, focus is trapped within the dialog; tabbing from the last control in the dialog takes focus to the first control in the dialog. The dialog is dismissed by activating the Cancel button or the OK button.

imo there is too much room for interpretation and clearer guidance is needed that defines a "Best Practice" for this specific scenario. Otherwise it leads to further inconsitency between implementations.

The native <dialog> doesn't support tab looping at all while most open source libraries are on the other extrema and don't provide an option to disable it.

With clearer guidance one or the other would need to be adjusted to fulfil the Level A requirements.

[fstrr]

It looks like this relates to No Keyboard Trap.

You say "The native <dialog> doesn't support tab looping at all", which isn't the case—see this quick demo where, when the dialog is open, it's not possible to navigate to the elements on the underlying page. It does allow the user to navigate to the browser's "chrome", which is fine, and then back into the open modal dialog.

It looks like the example hasn't been updated since the native dialog element became fully supported. It could be updated to clarify that both trapping inside a modal dialog and allowing the user to access the browser's chrome is fine, as long as there's an accessible method to close the modal dialog. Does that work for you?

[tay1orjones]

This was discussed at length over in whatwg/html#8339, particularly whatwg/html#8339 (comment) where @matatk @niklasegger mentioned facilitating updates to APG but it appears that maybe no one followed up on this.

It could be updated to clarify that both trapping inside a modal dialog and allowing the user to access the browser's chrome is fine, as long as there's an accessible method to close the modal dialog. Does that work for you?

@fstrr Yes. Also the 2.4.3 focus order understanding doc needs updated as well. I'd encourage the title of this issue to be updated to include that and mention of <dialog>.

These updates would be really helpful as we're seeing many folks default to assuming the native <dialog> focus behavior doesn't meet the success criterion because of the inclusion of the browser URL bar.

[patrickhlauke]

@fstrr Yes. Also the 2.4.3 focus order understanding doc needs updated as well. I'd encourage the title of this issue to be updated to include that and mention of .

note that the examples in understanding documents are just that ... examples. they're not normative, nor are they comprehensive.

[patrickhlauke]

I've filed #4381 to tweak the language in the focus order and keyboard trap understanding, but note that, as I wrote in the PR description, the issue here seems to conflate non-normative examples in non-normative understanding document with actual hard requirements ... they're not, they're just examples. Examples are non-exhaustive, so if a page/content does something else, as long as it still satisfies the core normative requirement of an SC, they're fine.