Re: Expanding the scope of aria-modal

> On Feb 17, 2016, at 6:50 PM, Matt King <a11ythinker@gmail.com> wrote:
> 
> 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.
>  
Yes, that is also true. 

> 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.
>  
Well that is true, however a combobox is not supposed to launch a dialog box either. We have authors that want to launch a search region and restrict navigation to that view. Dialog is also not a widget either. Its superclass is a window. 



> 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.
>  
This is quite simple. The fact that something is “modal” would cause the AT to convey the contextual navigation restrictions to the user and how to get out of it. When you launch a search box 

> 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?
>  
Yes I do and btw you asked how we would expand modal earlier in the discussion. When you launch these landmark areas you are not going to have a message or a label. It is good to contextually say you are in this type of landmark region. Also, dialog boxes are designed for you to gather input … more than they are to isolate you to an operation.  So, no, I don’t think dialog box is adequate. I would rather know that I was in a modal search or navigation region.

I actually believe many things could become modal on a web page. Hitting the escape key to get you out should be common practice.

We added aria-modal. we need to teach the ATs to take this information and convey its purpose. Not everything is supposed to be a dialog box. Dialog boxes are used to convey messages and perform input to an operation that launched it. 

I think you are bending the rules for one thing that you want and not the other. If I wanted to be pedantic I would say that a combobox can never launch a dialog box.  

Thinking more on this I would also consider requiring that when you have a combobox that launches a modal anything that we add aria-haspopup on it. … including a combobox that launches a dialog box. 

Rich

> 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 <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>>
>> Cc: ARIA Working Group <public-aria@w3.org <mailto: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 <a11ythinker@gmail.com <mailto: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 <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>>
>>> Cc: Joseph Scheuhammer <clown@alum.mit.edu <mailto:clown@alum.mit.edu>>; Bryan Garaventa <bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com>>; ARIA Working Group <public-aria@w3.org <mailto: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 <a11ythinker@gmail.com <mailto: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 <clown@alum.mit.edu <mailto:clown@alum.mit.edu>>
>>>> Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com>>; Matt King <mck@fb.com <mailto:mck@fb.com>>; ARIA Working Group <public-aria@w3.org <mailto: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 <clown@alum.mit.edu <mailto: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 -
>>>>>