Interesting, when a modal dialog (nested within a `<main>` element or some sectioning content) opens in Chrome it seems to disregard its context, so elements like `<header>` and `<footer>` will have `banner` and `contentinfo` roles as if they were scoped to `<body>`. When opened non-modally, they have `sectionheader` and `sectionfooter` (new ARIA roles + mapping) which means that it is computing the roles based on the dialog’s context.
Safari and Firefox keep the context is both scenarios (i.e. modal and non-modal). I have no idea what is correct. Need to read more.
Anyway, here’s a playground for the bug: knowler.dev/demos/MR4JmQW
“main+header+footer nested in a dialog nested in main with adjacent header+footer” demo by Nathan Knowler
Demonstrates a browser inconsistency for the computed ARIA roles of header + footer within a modal dialog.knowler.dev
Peter Vágner reshared this.
Jamie Teh
in reply to Nathan Knowler • • •data:text/html,<body><main role="none"><header>hi
So it seems Chrome is using the accessibility tree for the context restriction here, not the DOM tree. That means role="none" and any other way of removing content from the accessibility tree, including modal dialogs, change the context. In contrast, Firefox uses the DOM tree in this case.
Normally, the accessibility tree is what you want to use for context because of generics, role="none", etc. However, in this particular case, it seems more appropriate to do this based on the DOM. Hmm.
Jamie Teh
in reply to Jamie Teh • • •