- From: Matt King <a11ythinker@gmail.com>
- Date: Wed, 17 Feb 2016 16:50:28 -0800
- To: "'Richard Schwerdtfeger'" <richschwer@gmail.com>
- Cc: "'ARIA Working Group'" <public-aria@w3.org>
- Message-ID: <013201d169e6$5d356530$17a02f90$@Gmail.com>
Matt wrote:
>Specifically, how would you like to see the scope of aria-modal expanded?
Rich wrote:
>I believe we should add aria-modal to landmarks.
>We make a statement that ATs should use this new property to indicate that navigation is limited to within the element
>unless the user intentionally exits the container such as the through of the escape key.
The definition of aria-modal also says that the content outside the modal element should be inert, which is inline with the standard definition of modal.
Matt wrote:
>Earlier parts of this thread imply you would recommend
>setting aria-modal true on DOM nodes even in cases where the non-modal nodes are not inert.
>Is that the case? If yes, I have 2 other questions:
>1) How would screen readers know if they are to allow/support interaction with content outside the modal node?
Rich wrote:
>The screen readers should see that aria-modal=“true” is applied to a container
>and indicate to the user that tab navigation is restricted to the the container
>and to exit the container they must either:
>1. hit escape which will return them to the control that launched it.
>2. successfully complete and submit the results of the dialog box.
If I understand what you are saying, it would be valid to have a landmark that has aria-modal=true and restricts the tab ring to its content on a page where the content outside the modal node is NOT inert. I think this would mean that:
1. The screen reader user could use the reading cursor to explore and activate anything on the page.
2. Tab is stuck inside the region and the user would have to find where it is stuck and do something to figure out why. Remember that pressing a button to expose a disclosure or expand a region does not suggest a switch to forms or application mode. And, we would not want it to do so since a region is a structure, not a widget.
Matt wrote:
>The dialog role provides screen readers with a clear indication that a node manages focus (restricts the tab ring).
Rich wrote:
>Well. unfortunately (and we have seen this)
>authors don’t always play ball here
>and a tab can send you out of the dialog box.
How would aria-modal improve this? Do you think it is reasonable to expect that authors are less likely to allow tabbing out of landmark regions marked modal? If aria-modal does not actually mean modal in the conventional sense, we could confuse authors even more.
I would also venture a guess that novice screen reader users are far more likely to struggle in a situation where they can see all content but tab is stuck in just part of it.
It seems to me that:
1. the dialog role is the most effective way to help screen reader users understand that the tab ring is scoped to a specific node.
2. The aria-modal property is the best way to indicate to screen readers that the content outside the dialog is probably inert.
If you want to make an expandable landmark region either fully modal or quasi-modal, one possibility is to make the control that expands the region dynamically wrap the expanded content in a dialog with a label that refers to the region label and place the focus inside of it. The screen reader user will automatically hear that it is a dialog and expect to find a close or cancel control that is operable with the escape shortcut key. The screen reader will not have to do anything special to help the user understand what is going on.
And, per the current aria-modal specification, the aria-modal property should only be set true on the dialog element if the content outside the region becomes inert.
Do you see a problem with this approach?
Matt
Sent: Wednesday, February 17, 2016 1:00 PM
To: Matt King <a11ythinker@gmail.com>
Cc: ARIA Working Group <public-aria@w3.org>
Subject: Re: Expanding the scope of aria-modal
On Feb 17, 2016, at 1:04 PM, Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> > wrote:
Note: the topic of this thread has changed with this reply.
Rich wrote:
>I am seeing other use cases in IBM where even expandable landmarks are made “modal”.
Matt wrote:
>Rich, I am getting the feeling that by "modal" you mean that the tab ring is dynamically restricted to a specific section or DOM node.
>Is that your intention?
Rich wrote:
>Yes. That is what I mean.
>aria-modal was added to ARIA 1.1 and I believe its scope must be expanded.
Specifically, how would you like to see the scope of aria-modal expanded?
I believe we should add aria-modal to landmarks. We make a statement that ATs should use this new property to indicate that navigation is limited to within the element unless the user intentionally exits the container such as the through of the escape key.
We need to indicate that if a combobox launches a dialog box that it MUST be marked as aria-modal=“true" as you don’t want the situation where the user is tabbing around the dialog box and then falls out.
Earlier parts of this thread imply you would recommend setting aria-modal true on DOM nodes even in cases where the non-modal nodes are not inert. Is that the case? If yes, I have 2 other questions:
1) How would screen readers know if they are to allow/support interaction with content outside the modal node?
The screen readers should see that aria-modal=“true” is applied to a container and indicate to the user that tab navigation is restricted to the the container and to exit the container they must either:
1. hit escape which will return them to the control that launched it.
2. successfully complete and submit the results of the dialog box.
2) Don’t you think that would create mass author confusion if aria-modal was define very differently from how the rest of the UI world uses the term modal?
No. see above. We added the aria-modal property for a reason. This is why.
>If we are going to supply this property, this is an excellent indicator
>that ATs can trigger off of to state this restriction (in a human consumable way) to users (when set to “true”).
The dialog role provides screen readers with a clear indication that a node manages focus (restricts the tab ring).
Well. unfortunately (and we have seen this) authors don’t always play ball here and a tab can send you out of the dialog box.
Additionally, as Freedom Scientific stated the user does not expect a combobox to launch a dialog box. This does not happen on the desktop. So, they want to be able to tell the user that this thing is modal. Normally, as Cynthia stated, the user can tab away from a combbox without choosing anything.
What would be the advantage of marking a node modal without giving it the dialog role? My initial thought is that it could really confuse screen reader users. Wouldn’t the visual equivalent be a modal experience embedded in a page where there is no boarder around the modal experience and all the inert content appears active? Wouldn’t that drive sightees crazy as they click on interactive elements and get no response?
See above.
Matt King
From: Rich Schwerdtfeger [ <mailto:richschwer@gmail.com> mailto:richschwer@gmail.com]
Sent: Wednesday, February 17, 2016 6:50 AM
To: Matt King < <mailto:a11ythinker@gmail.com> a11ythinker@gmail.com>
Cc: ARIA Working Group < <mailto:public-aria@w3.org> public-aria@w3.org>
Subject: Re: ACTION-1490 proposal says good bye to the "inline" notion for combobox
Yes. That is what I mean.
aria-modal was added to ARIA 1.1 and I believe its scope must be expanded. If we are going to supply this property this is an excellent indicator that ATs can trigger off of to state this restriction (in a human consumable way) to users (when set to “true”).
Rich
Rich Schwerdtfeger
On Feb 17, 2016, at 1:03 AM, Matt King < <mailto:a11ythinker@gmail.com> a11ythinker@gmail.com> wrote:
Rich wrote:
I am seeing other use cases in IBM where even expandable landmarks are made “modal”.
Rich, I am getting the feeling that by "modal" you mean that the tab ring is dynamically restricted to a specific section or DOM node.
Is that your intention?
Matt
-----Original Message-----
From: Richard Schwerdtfeger [ <mailto:richschwer@gmail.com> mailto:richschwer@gmail.com]
Sent: Monday, February 15, 2016 12:15 PM
To: Matt King < <mailto:a11ythinker@gmail.com> a11ythinker@gmail.com>
Cc: Joseph Scheuhammer < <mailto:clown@alum.mit.edu> clown@alum.mit.edu>; Bryan Garaventa < <mailto:bryan.garaventa@ssbbartgroup.com> bryan.garaventa@ssbbartgroup.com>; ARIA Working Group < <mailto:public-aria@w3.org> public-aria@w3.org>
Subject: Re: ACTION-1490 proposal says good bye to the "inline" notion for combobox
On Feb 14, 2016, at 11:53 AM, Matt King < <mailto:a11ythinker@gmail.com> a11ythinker@gmail.com> wrote:
Rich wrote:
I am seeing other use cases in IBM where even expandable landmarks are mad “modal”.
Mad modal?
made
Clearly aria-activedescendant will not work in these scenarios (pop up control) as it is not a descendant.
This really is not any different that having a live region controlled by another part of the page.
If it is not owned then the focus must be determined by the modal window or object with in the window/container.
I do not understand where modality becomes part of this discussion.
Maybe an example would help.
Matt, it is extremely important to know that if you are in a region where keyboard navigation is isolated to that modal area unless you escape out of it.
So, one thing we are looking at is to have expandable search areas where you hit a button that expands out a search box with a lot of option within in it.
The new combobox text is not meant to create a new interaction paradigm. It's primary purpose is for ARIA to catch up with what is actually happening on the web.
Matt if you are going to launch a dialog box from a combobox then you have broken what people expect a combobox to do. As Cynthia said, this does not sound like a combobox.
What you are doing is launching a modal dialog box and the user needs to know this as you can put anything in it. They don’t know what to expect. They don’t know what combination of functions you are going to operate on to deliver a value to the combobox and they need to be assure that in the middle of it you don’t tab outside of it when you are half way through operating it.
While there are some comboboxes that open a dialog, most that pop open a listbox or a grid that mimics a list are not changing the conventional interaction model at all. In a conventional combobox, if you open the listbox, down arrow to a particular value, and then press tab, the value that had focus is placed into the combo input and the focus moves to the next element on the page. I am not clear why it would make any difference whether the list is made with a listbox, tree, or grid. The same behavior is equally workable.
So, we can’t deal with most. We need to let people know what to expect. They typically don’t expect you to navigate a grid and then leave the combobox. It is confusing. Knowing whether it is modal or not is very important. However, the fact that you can launch a dialog box should indicate to ATs what guidance to give the user. For example, It would be good, to know that when you opened the combobox that your keyboard navigation is limited to within the (whatever you launched). We need to be consistent and the ATs need to provide guidance to the user as to what quagmire they just walked into.
Another option is to place these things in a dialog box where the combobox launches a dialog box with objects within.
The dialog box MUST be modal.
That is an option that works. And, in that particular case, I agree that it wouldn't make sense to use aria-activedescendant.
ok
Matt
-----Original Message-----
From: Richard Schwerdtfeger [ <mailto:richschwer@gmail.com> mailto:richschwer@gmail.com]
Sent: Thursday, February 11, 2016 9:07 AM
To: Joseph Scheuhammer < <mailto:clown@alum.mit.edu> clown@alum.mit.edu>
Cc: Bryan Garaventa < <mailto:bryan.garaventa@ssbbartgroup.com> bryan.garaventa@ssbbartgroup.com>; Matt King < <mailto:mck@fb.com> mck@fb.com>; ARIA Working Group < <mailto:public-aria@w3.org> public-aria@w3.org>
Subject: Re: ACTION-1490 proposal says good bye to the "inline" notion for combobox
Good point Joseph. One of the things I have been wrestling with is the fact that what is being launched (if it is not a descendant - hence aria-activedescendant) is the fact that what gets launched must indeed be a modal window.
This would get us away from having to apply aria-activedescendant on a combobox in these instances however it needs to be clear that if aria-controls is these are housed in modal windows that are controlled by combobox.
I am seeing other use cases in IBM where even expandable landmarks are mad “modal”. I think we need to discuss modality in this scenario. Clearly aria-activedescendant will not work in these scenarios (pop up control) as it is not a descendant. This really is not any different that having a live region controlled by another part of the page. If it is not owned then the focus must be determined by the modal window or object with in the window/container.
Another option is to place these things in a dialog box where the combobox launches a dialog box with objects within. The dialog box MUST be modal.
Rich
On Feb 11, 2016, at 10:19 AM, Joseph Scheuhammer < <mailto:clown@alum.mit.edu> clown@alum.mit.edu> wrote:
On 2016-02-08 10:42 AM, Bryan Garaventa wrote:
That is not true. This is why we support aria-activedescendant on role=”combobox”. Please test the following implementation that uses this technique.
<http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Simulated,%20Readonly)/demo.htm> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Simulated,%20Readonly)/demo.htm< <http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20%28Simulated,%20Readonly%29/demo.htm> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20%28Simulated,%20Readonly%29/demo.htm>
Warning: sarcasm, ahead.
You have implemented a combobox that uses aria-activedescendant without aria-owns. What is the active descendant a descendant of? Not the combobox, actually.
Does this mean we need to re-write the definition of aria-activedescendant?
:-)
--
;;;;joseph.
'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
- C. Carter -
Received on Thursday, 18 February 2016 00:51:05 UTC