Re: Combobox and Freedom Scientific

Rich Schwerdtfeger




> On Apr 12, 2016, at 7:24 PM, Matt King <a11ythinker@gmail.com> wrote:
> 
> Rich,
>  
> You wrote:
> >They {Freedom Scientific} feel the same way that I did that the Dialog box MUST be modal.  <>
> >The reason for this is because unlike the other controls a user is tabbing through the dialog box >and magically they are outside the dialog box. 
> >They want the user to be able either complete the dialog box 
> >or use escape key to get the user back to the combobox control with the result of the selection. 
>  
> I agree 100% with the above statements about the keyboard experience.  
>  
> To be more specific, I completely agree that if focus is inside a combobox text field and pressing down arrow opens a dialog, authors should:
> 1.     Ensure that the dialog contains the tab ring;
> 2.     Ensure that focus returns to the text field if the user cancels the action by pressing escape or by activating a close element within the dialog.
> 3.     Ensure focus returns to the text field if the user activates an element that sets the text field value.
>  
> The above 3 points are all consistent with our authoring guidance for dialogs. Containing the tab ring is best practice for ALL dialogs. Both modal and some non-modal dialogs are designed to close either when elements they contain activate a command or when a focusable close button is invoked either by activation or via the escape shortcut key. 
>  
> The types of activations that could close or move focus out of a NON-modal dialog do, of course, depend on design requirements for a given implementation. Some NON-modals are effectively modal for keyboard users because there is no advantage to be gained by providing keyboard access to functions outside the dialog while the dialog is open. The dialogs used for the IBM mega menus are a good example of that. Another example is the notifications dialog that opens from the masthead of your Facebook home page.
>  
> Here is the ONE question I have about what you wrote that I would like you to stop and think about. Please give this serious consideration.
>  
> What would be the purpose or advantage of requiring that the content outside a combobox popup be inert?
>  

Because you should not be able to get to it until you leave the dialog box. The problem with linking a dialog box to a combobox is then when you open it you should be in the process of completing what you are doing with the combobox and not jumping out into the netherworld. Let the user stick to the task at hand. Additionally, non-modal does NOT mean that you have to adhere to a dialog tab ring.  

We disagree on this point. 

> Possibly the most important feature of modal elements is that they have an inert background. It is important enough that we specifically mentioned in the description of aria-modal. And in many definitions of modal elements, an inert background is named as the primary defining feature. 
>  

Matt, if you want to get to the background content then hit escape and that will put you back on the textfield. Then you can jump around the background content to your delight. I know for a fact that on GUIs for Windows you cannot get at the content behind a dialog box anyway so you have this big hole in it. 

> It does not seem to me that obscuring the background for a dialog that opened from a combobox textfield would typically be a good idea, especially since the text field itself is part of that background. If the combobox opens a list, tree, or grid, the background would not be obscured. So, it seems a bit arbitrary to add that requirement if the element that pops up has ARIA dialog markup underneath.
>  
> That said, if you do not have the goal of requiring the background to be inert, then I do not believe it is appropriate to use the word “modal” in the context of the combobox description.
>  
I would not want the author mucking with the content behind it if the dialog is up from within the combobox. Escape out of the dialog box and have at it. Also, why would yo want to operate the content behind the dialog box (what if it is floating?).

> If we do not use the word “modal”, then there is still the question of what kind of and how much authoring guidance should be included in the specification. Are we going to start adding detailed keyboard implementation guidance to roles? As I previously stated in feedback on aria-keyshortcuts, I believe the bar for direction to authors in the spec should be set high. Basically, it should be limited to how a role, state, or property is allowed to be used. Based on this, I propose that guidance like the 3 above keyboard implementation practices should be part of the APG – not part of the spec.
>  

I want to use the word modal for the dialog. 

> Another way to look at this is to consider all the other ways authors can creat absolutely horrible experiences that are not mentioned in the spec. I do not think we want to turn the spec into a catalog of the most obvious practices authors should adopt in order to avoid disaster. 
>  

I think by not making it modal you are making an awful experience for the end user and I cannot believe you would even suggest such a thing. 

> My proposal for the combobox role description is to lean on the definitions of listbox, tree, grid, and dialog to address the issues specific to those roles and to rely on the APG to demonstrate how to best implement the combobox role given the requirements and restrictions specified in the spec. I believe this approach will very effectively address your concerns.
>  

OK. The dialog box must be modal. You can handle the keyboard navigation in the APG accordingly. 


> Matt
>  
> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
> Sent: Monday, April 11, 2016 12:52 PM
> To: Matt King <mck@fb.com>
> Cc: ARIA <public-aria@w3.org>
> Subject: Combobox and Freedom Scientific
>  
> Matt,
>  
> I had a meeting with Glen Gordon and Brett Lewis at Freedom Scientific. Among other things we discussed, we discussed the use of dialog box in a combobox and the need for it to be modal. They did not agree with your statement from the last ARIA Working Group meeting:
> https://www.w3.org/2016/04/07-aria-minutes.html <https://www.w3.org/2016/04/07-aria-minutes.html>
>  
> From the minutes:
> "rs: Freedom Scientific raised this issue: it needs to be a modal dialog box
> 
> mk: glenn backed away. let's talk about it later"
> 
> They feel the same way that I did that the Dialog box MUST be modal. The reason for this is because unlike the other controls a user is tabbing through the dialog box and magically they are outside the dialog box. They want the user to be able either complete the dialog box or use escape key to get the user back to the combobox control with the result of the selection. To quote Glenn, otherwise it would be a "horrible experience." 
>  
> What Glen also did say and you agreed to was that there needed to be a way to get back to the dialog box (to the owner) which is the combobox. 
>  
> This was my position and I am going to want the spec. to say that if the author is going to launch a dialog box from within the combobox (includes aria-owns) that it MUST be a modal dialog box. 
>  
> I was not crazy about dialog boxes being launched from a combobox in the first place and I think this is an acceptable compromise and one that would help ensure usability. 
>  
> Please correct your proposal for the combobox role to reflect this and ensure this guidance is provided for in the authoring practices. 
>  
> Rich
>  
>  
>  
> Rich Schwerdtfeger