RE: Combobox and Freedom Scientific

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?

 

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. 

 

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.

 

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.

 

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. 

 

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.

 

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

 

>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