Meeting minutes
scotto: today’s convo is scoped to w3c/
… this is also related to an `aria-hidden` issue I filed
… aria-modal is currently mostly used just for dialogs, alert dialogs, etc.
… with values of true and false, where even if it’s false, there can still be some light virtual cursor trapping by some AT
… related to the work we’ve been doing on popovers — for tooltips, notes, dialogs, menus, listboxes — there seems to be some overlap, where aria-modal behavior might make sense
… in the Open UI WG there’s been a lot of talk about making more robust listboxes
… where people want to add rich descriptions, as an example
… people also want to put interactive elements inside, like links and buttons, etc.
… might it make sense to have some partial trapping to allow for easy navigation to the top and bottom of these elements
… so that’s the high-level
Matt_King: I recently wrote about the language we use and should use when talking about modality and related concepts
Matt_King: in particular, I proposed that there are essentially 3 boundary renderings that happen in all screen readers
… porous, solid, and invisible
… porous: the way we typically render a region or a list
… invisible: like a paragraph, we don’t convey the boundary
… solid: with dialogs or windows, with a normal reading command, you’ll bump into a boundary
scotto: I see potential for two versions of modality: things are fully inert and you shouldn’t be able to get to it, and a second version that allows a “door” to get to the rest of the content
Glen_Gordon: there’s the new Microsoft Outlook online which will likely replace Windows Outlook, and we’re trying to simulate the Windows experience of “trapping” people inside a message
… would be helpful to have a modal “clue” to support this
Matt_King: Yes, ARIA should say something about boundaries
… in that case, couldn’t the message be a non-modal dialog, in ARIA terms?
Glen_Gordon: I don’t want the user to be able to wander out
Matt_King: “solid” can be both modal and non-modal — there’s a “wall” in both cases, but in the non-modal case you can jump over the wall and get to content outside
Roberto_Perez: there are some of these boundaries and modalities which are determined by the AT
… depending on heurisitics
… NVDA will trap the virtual cursor inside a dialog, whether it’s modal or non-modal, for example
… the problem where I’m concerned is authors
… authors might misuse dialogs or explicitly hide content from AT too often / inappropriately
… ATs and users should have the ultimate choice
scotto: dropdowns are an example of light modality — the user is lightly trapped inside its popover list, but they can still tab out of it
Brett: what concerns me about labeling too many things as “dialog” is setting user expectations
… to hear it too often will be confusing
… I do like the idea of being able to extend modality to multiple things, but they shouldn’t all be called “dialog”
<scotto> disagree with a new role. because that would just swap out using "dialog" everywhere inplace of whatever this new role would be.
Matt_King: with aria-modal, we could have values of true, false, and mixed
<scotto> aria-modal=porous ;)
Matt_King: where “mixed” could mean this container has a solid boundary that you can jump over
aaronlev: I surveyed a dozen users, and one thing that users complained about most was getting lost — that web apps don’t act like native apps in that way
… maybe we should consider other names and get away from aria-modal: something like aria-boundary, aria-island
… sometimes you just want to decorate a container to say that the user should be kept inside
scotto: agree with all of that
… I do like the idea of moving away from aria-modal, maybe creating a synonym attribute since it does have some overlap, but it could be a better name to indicate that it’s not just for modals
… re: concerns about misuse, and this is more related to the aria-hidden topic, a lot of the a11y APIs with modals is that the tree isn’t pruned
… in Webkit, it _is_ pruned
… but in Windows, it is marked as hidden, but it still exists in the a11y tree
… which allows for an escape hatch in cases of author misuse
<Zakim> jamesn, you wanted to ask if we have ever had a synonym attribute before and to ask how dialog works on macOS vs Windows
<scotto> implicit boundaries is what i was just thinking. defining those and using 'implicit' as a token / default value
Matt_King: in ARIA, we could just say that the “dialog” role always means it’s modal
… and then add another role, like “panel” or “window”
scotto: I’m hesitant to adding a new role
<Zakim> jamesn, you wanted to ask what are the next steps
Matt_King: I think the main problem can be solved with a new attribute like aria-mixed, but it could still be useful to have an HTML element or role that is implicitly aria-modal=false
scotto: I could work with Matt_King on something like aria-modal=mixed
… maybe some elements could have aria-modal=mixed as implicit
aaronlev: we’re gonna need clearer language than “modal”, especially for ESL authors
Matt_King: I’d like to explore whether it’s even sensible to permit the concept of a non-modal “dialog”
jamesn: let’s not worry about naming for now, but make progress on the underlying concepts
scotto: I can take a crack at extending `aria-modal`, acknowledging that we might change the name later to make it more understandable
<spectranaut_> matt's essay on modal dialogs: https://