Re: Combobox and Freedom Scientific

Matt,

It helps to hear use cases for the author and I see the points you are trying to raise. So, I am not trying to invalidate your perspective. 

Here are my areas of concern. 

1. I am less concerned about pretty. My first concern is that while the screen reader user is in the middle of a non-modal dialog box, that the screen reader user can walk outside the dialog box and operate content (while in the middle of the dialog box and in the middle of operating a combobox). It goes beyond the widget itself. In actual fact the rest of the page is a combination of inert and non-inert content. The inert content sits behind the dialog box which could cover quite a bit of the web page. The inert content is still in the accessibility tree as it is not hidden by the author even though it is obscured and inoperable. There is really no way of telling what is inert unless you activate it. A sighted user can see this differentiation as the sighted user can see what is obscured and what is not. If the dialog box is exposed on a mobile device. As it is users have never been told that a combobox includes something other than a listbox. Throwing all these other paradigm shifts of optionally having a tree or a dialog box in the combobox is going to be even more confusing. As I have said, I really don’t like Dialog boxes in comboboxes at all. This is why I am trying to limit the view of the user while they are operating assistive technologies in this scenario. 

2.  I don’t see the reason to go back and see the contents of the search box while you are in the dialog box. A simple escape key would exit the dialog box and place focus on the combobox’s textfield. You can then also access all of the non-inert screen. Also, presumably, you are in the dialog box to choose a selection that populates the search box.  I believe this is also much more usable for a magnifier user as the suer can zoom back to the input field when escaping the dialog box as focus will follow it. 

3. The browser vendors keep threatening to implement an HTML dialog box (beyond Chrome and Android). Presumably the implementations of these will get much easier. 

So, it seems like we are helping the author while throwing the vision impaired user over the transom. I am particularly concerned about the less experienced sight impaired user. 

Perhaps other impaired users have similar concerns. I know Bryan is not a fan of launching a Dialog box from within a combobox. I have worked on building enough assistive technologies in my day that these issues are giving me cause for concern. Freedom Scientific also raised concerns and asked that the dialog box be modal. 

Rich


Rich Schwerdtfeger




> On Apr 15, 2016, at 5:40 PM, Matt King <a11ythinker@gmail.com> wrote:
> 
> Rich,
>  
> I hear you saying that if a combobox is allowed to open a dialog, you want to use the word modal to describe such a dialog because you want the dialog to manage focus, i.e., contain the tab sequence.  <>And, I totally agree that managing focus would be the desired best practice.
>  
> The definition of aria-modal says:
> “When a modal element is displayed, authors should mark all other contents as inert (such as "inert subtrees" in HTML) if the ability to do so exists in the host language.”
> An inert background is the common understanding of a modal in the web design world. 
>  
> Imagine what that would be like for a combobox. I will assist your imagination just a little with an example. This particular example is not using a dialog, nor is it the kind of situation where you would use a dialog; so you do have to use a little imagination.
>  
> In the first implementation, we have a search input that opens a pop-up containing search suggestions. In the attached image named modal-dialog.png, all the background, including the search field is inert. The only element not obscured by the screen is the pop-up element.
>                                 
> In the second implementation, in the attached image named modal-trigger-and-dialog.png, the search input and search suggestions pop-up are both in front of the screen so you can now see the input but all the rest of the background is inert.
>  
> The first implementation is easy to code and very hard to use. I am told its ugly as sin too.
>  
> The second implementation is a little better from a usability perspective, but so tricky to code that no one will do it. And, it’s not much prettier.
>  
> This is the primary reason I don’t want to hamstring authors by saying the dialog must be modal.
>  
> Matt King
>  
> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
> Sent: Thursday, April 14, 2016 3:25 PM
> To: Matt King <a11ythinker@gmail.com>
> Cc: ARIA <public-aria@w3.org>
> Subject: Re: Combobox and Freedom Scientific
>  
>  
> Rich Schwerdtfeger
>  
>  
> 
>  
>> On Apr 12, 2016, at 7:24 PM, Matt King <a11ythinker@gmail.com <mailto: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 <mailto:richschwer@gmail.com>] 
>> Sent: Monday, April 11, 2016 12:52 PM
>> To: Matt King <mck@fb.com <mailto:mck@fb.com>>
>> Cc: ARIA <public-aria@w3.org <mailto: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
> 
>  
> <modal-dialog.png><modal-trigger-and-dialog.png>