380054 - Differentiate document list from form control list

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

Spun off from https://bugzilla.mozilla.org/show_bug.cgi?id=379678#c16
Summary: it's confusing that the same role for a list is used for an <ol>/<ul> and for a <select size="[>1]"> widget list. Also apparently GTK uses ROLE_MENUITEM for the list items in a list widget, but I need to find a good example.

Joanie wrote:
> Assuming, however, that I must continue to live in an imperfect world..... :-) 
> Functionally speaking, from the end user's -- and, I'd argue, the AT's -- 
> point
> of view, a listbox is merely an expanded combo box.* Both exist to allow the
> user to select the desired option by arrowing to it.  (You, know, like a menu
> :-) ) Both have very similar states.... 
> * With the added possibility of multi-select-ability, of course.

Unfortunately the combo box has a ROLE_LIST child anyway, and this would confuse our implementation. I believe ROLE_LIST was originally added to both MSAA and ATK/AT-SPI for the widget, and that Mozilla started using them for doc structure as well since we had nothing else. In MSAA we could differentiate by marking the ROLE_LIST as READONLY if it's a document structure as opposed to a widget. Since you don't have that state in ATK, and it's not really EDITABLE, and there is no LISTBOX role, what should we do to differentiate these?

Where is an example of a widget listbox in Gnome that I can look at?

Comment 1

[Aaron Leventhal]

Joanie, shouldn't you be able to differentiate by seeing if if the list supports the Selection interface?

Comment 2

[Joanmarie Diggs]

For an example try:
* http://nlscatalog.loc.gov/cgi-bin/Pwebrecon.cgi?DB=local&PAGE=First

Can I differentiate between them? Sure.  Whether or not they have a state of FOCUSABLE is also a good clue.  It's not so much the "can" as it is where all we have to do it.  We'll have to check and do handling in:

* Caret Navigation (since we're implementing our own)
* Form field navigation
* List and list item "structural navigation"
* The speech and braille generators

When the children of listboxes were menu items life was much better. :-)

Comment 3

[Aaron Leventhal]

> When the children of listboxes were menu items life was much better. :-)
I have no problem doing that if it's correct. Will that be enough? Also, do you have a Gnome example I can look at?

Comment 4

[Joanmarie Diggs]

> I have no problem doing that if it's correct. Will that be enough? 

As far as I'm concerned, it certainly *should* be.  :-)  The reason I'm qualifying "should" is that 
I am noticing a change in how combo boxes behave as a result (I assume) of the changes to grabFocus().  I haven't yet had time to work out what the change is or what I'm going to do about it. :-)  But if whatever it is turns out to impact listboxes whose children are menu items....

> Also, do you have a Gnome example I can look at?

Visually spaced out the "Gnome" before.  Sorry! Not sure I follow you, though.  But: If you have gtk-demo installed, the closest thing would be a tree table.  

If I'm still missing the point/question, maybe Will and/or Peter can chime in with the answer??

Comment 5

[parente]

Aaron, there at least three different kinds of combo boxes in gtk. One kind appears in the GNOME character map application. It's the Font combo in the top left of the window. Three additional kinds appear in gtk-demo under "Combo boxes". A little inspection with a poke tool will show you their differences.

Comment 6

[Aaron Leventhal]

I'm not looking for a combo box, but a listbox widget where there is no combo box. Similar to the CC list in a bugzilla page.

Comment 7

[Joanmarie Diggs]

With respect to what I said in comment #4:

> I am noticing a change in how combo boxes behave as a result (I assume) of the
> changes to grabFocus().  I haven't yet had time to work out what the change is
> or what I'm going to do about it. :-)  

Just figured it out:  And it's not a combo-box thing or a grabFocus() thing. Now that we are getting caret-moved events when items don't have focus (i.e. so that we can update our position during a Find), we need to check what the source of the caret-moved event is before we go running off to it. <grin>  Put another way, it's something the AT needs to handle so never mind and thanks for the new events. :-)

Comment 8

[Joanmarie Diggs]

(In reply to comment #6)
> I'm not looking for a combo box, but a listbox widget where there is no combo
> box. Similar to the CC list in a bugzilla page.

Aaron, when I looked in gtk-demo, the "list" on the left (where you get to pick your widgets) seems to me to be most like the list you're after.  It's a tree table. 

Comment 9

[Aaron Leventhal]

I considered that as well. Does tree table seem like the right role for something with one column and no levels? They added the list role for this, not for lists in documents (I think).

Anyway, I suppose it doesn't use MENUITEM or LISTITEM then.

Comment 10

[Joanmarie Diggs]

> I considered that as well. Does tree table seem like the right role for
> something with one column and no levels? They added the list role for this, not
> for lists in documents (I think).
> 
> Anyway, I suppose it doesn't use MENUITEM or LISTITEM then.

The concern I have with switching it to a tree table is similar to the one I have with the children being LISTITEMs:   We'll still have two creatures that are different functionally but sharing the same role:  The children of data/layout tables and the children of listboxes.

My vote's still for the children of listboxes being MENUITEMs. :-)

Comment 11

[Aaron Leventhal]

Okay. I guess they will be SELECTABLE though. And the ROLE_LIST parent may be marked MULTISELECTABLE.

Comment 12

[Aaron Leventhal]

After talking with Joanie we decided WONTFIX.