Should dialog/alertdialog be modal or non-modal by default?

[scottaohara]

Testing has shown that some browser / screen reader combos will see the dialog role and treat it as modal by default, without the need for aria-modal=true.

In these same pairings, aria-modal=false doesn't appear to do anything to removal the "modalness"... which then effectively means that the attribute doesn't do anything at all... since without it, the dialog is treated as modal... and with it set to false it doesn't undo the modal behavior.

But before I can file bugs, I think it's worth actually specifying whether these roles should be modal by default or not. I always assumed "not" by default....but....maybe there's validity to do that and meet current implementations/heuristics half way?

[JAWS-test]

I think aria-modal=true for alertdialog would be ok, but not for dialog, because it has far-reaching implications:

When a modal element is displayed, assistive technologies SHOULD navigate to the element unless focus has explicitly been set elsewhere. Assistive technologies MAY limit navigation to the modal element's contents

Since the standard so far was aria-modal=false, I would leave it at that for role=dialog. Unless most UA+AT combinations already interpret this differently - can you share your test results for aria-modal?

[scottaohara]

Can't share tests right now.

But aria-modal=false is not exactly the norm... actually an explicitly declared aria-modal=false seems to be typically ignored under default settings.

[carmacleod]

some browser / screen reader combos will see the dialog role and treat it as modal by default

I think that's a bug in the browser and/or screen reader.

Modals should be a very conscious decision by an author. They are disruptive; they interrupt the user's workflow and hijack the keyboard/page/app.

Nonmodals are less offensive; they let users continue with what they were doing; they can be ignored.

I think the missing value default for aria-modal should stay false.
If an author decides to use a modal, they need to do a bunch of things, and one of those is setting aria-modal=true.

I suspect most component libraries (even on desktop) support nonmodal by default, and modal is an extra step, i.e. set a modal flag, or call openModal() or showModal() instead of open() or show().
HTML <dialog> is one such example, with show() and showModal().

@JAWS-test said:

I think aria-modal=true for alertdialog would be ok

Maybe? Right now in the alertdialog spec, it's in the prose as a SHOULD:

Content authors SHOULD make alert dialogs modal by ensuring that, while the alertdialog is shown, keyboard and mouse interactions only operate within the dialog. See aria-modal.

We could make that stronger by saying MUST, and maybe even by having the "Implicit Value for Role" say "Default for aria-modal is true".

The trouble with defaulting to true, though, is that authors might not do the extra work to make it truly modal (tab trapping, etc) and so it might not really be modal, even though the attribute says it is.

[scottaohara]

tests/results: https://scottaohara.github.io/testing/dialog-tests/ column 1 & 2 are marked as "??" because, right now, I do not think the specification is explicitly clear enough on if dialog and alertdialog are considered modal or not by default. And that's really my end goal for this issue, is to definitively state in the alertdialog and dialog role definitions what the default state is.

I think the missing value default for aria-modal should stay false.

Then i think we need to state that in the definitions for dialog, because that doesn't seem to be the way this has gone down with implementation. I could very well see matching reality here and indicate a dialog is modal by default, and authors must set aria-modal=false if they want otherwise. I don't honestly feel strongly one way or the other... but I do think we need consensus.

The trouble with defaulting to true, though, is that authors might not do the extra work to make it truly modal (tab trapping, etc) and so it might not really be modal, even though the attribute says it is.

This is the risk of all of ARIA though. :(

[cookiecrook]

We've seen a lot of authors use aria-hidden accidentally (or more often forget to remove it) and make entire pages inaccessible. And aria-hidden is not the default on anything.

Since the effect of aria-modal is effectively the same for most users (all other contents inert), I'd recommend making false the default value for all roles. Otherwise, authors will inadvertently break things.

[scottaohara]

cc @aleventhal @jcsteh for any additional info here regarding current behavior

[aleventhal]

Here are interesting notes I took on this issue from over year ago:

NVDA and JAWS both make different assumptions about the default value of aria-modal in role="dialog", which makes aria-modal pretty useless. Technically, JAWS is more up-to-spec by assuming a default value of "false". As I understand it, NVDA assumes that dialogs are modal. Mick says that NVDA did not want to change their assumptions, after community discussion. He wrote:

Due to a lot of user feedback on Twitter and Github, we have decided not to make any change to our current behavior for dialogs on the web. If a dialog is in deed modeless, the user can already press NVDA+control+space to jump focus out of the dialog and back into the parent document.
You can see some of the comments on the PR at:
https://www.github.com/nvaccess/nvda/pull/8194

After reading some of the comments in the that PR, I'm thinking, maybe NVDA is doing the right thing. Basically, to keep the user inside the dialog by default, but let the user outside of it if they want. After all, as a sighted user, I can "see" outside of the dialog.

FWIW, here is a GitHub issue to support aria-modal in NVDA, but it doesn't seem particularly clear to me nor tied to the rest of the community discussion: nvaccess/nvda#9122

[sinabahram]

I want to signal that I have concerns about this topic. Note, obviously not with you, Aaron, just with the current state of things. I suggest a dedicated call, because we absolutely will not cover this issue properly on the weekly calls. I’m happy to host with Zoom and make time for this. I can bring a few dozen experiences across clients from small to huge to the table, but more importantly, I think we need a reasoned approach that does not depend on making assumptions or deciding on defaults. Can we just follow the spec? If the spec needs changing, let’s do that, but this is an untenable situation RE screen readers just deciding what they “feel” is the right way to do something, and it causes me a great deal of frustration when advising developers what to do.

[aleventhal]

Of course. Let's look to see if the spec needs updating, or just ATs. Happy to do a separate call but I feel that we need someone to represent NVDA, even if it's one of the community members in that PR thread. Otherwise, we might want to try for Reef, as Mick's time is hard to get.

[scottaohara]

for the deep dive i have updated the testing results on the page I shared. just a few changes, but also added results for what narrator + edge are doing.

https://scottaohara.github.io/testing/dialog-tests/

[scottaohara]

Action items:

• I will update test results to indicate the current browser implementation for aria-modal when unspecified, set to true or false.
• I will create a PR to indicate that role=dialog would be aria-modal=false by default. (PR will be draft until the following action item results are discussed)
• create alertdialog test cases and report on results.