445062 - Please expose Thunderbird header field names as object attributes

Status: NEW

(Core :: Disability Access APIs, enhancement)

Description

[Joanmarie Diggs]

An Orca user has requested that we implement hot keys for quickly accessing the headers displayed for an open message in Thunderbird.  I did a quick proof-of-concept patch where Orca+F1 presented the first header, whatever it happened to be, Orca+F2 presented the second header, whatever it happened to be and so on.  The user's feedback was that he would like there to be consistency between the keybinding and the field (so Orca+F3 is always the To field, for example).

The problem is that the headers are message dependent and I don't see any way to heuristically identify which fields are present and absent. Looking at strings is brittle because we cannot guarantee that the GNOME translators have taken the time to ensure that what they translate in Orca matches what the Mozilla translators have done in Thunderbird.  So.... 

Here is what I'm thinking: You are already exposing object attributes for the accessibles in the header (e.g. class and tag).  If you were to add an attribute which contained the non-localized field name, we could look for those and provide this user with the consistency he is requesting.

I'm opened to other suggestions, though. I just need something reliable. :-)

Thanks in advance!

Comment 1

[Aaron Leventhal]

I would think they have the "id" object attribute. Nearly every important element in the XUL UI's have an id so that extension authors can hook in.

Comment 2

[Joanmarie Diggs]

(In reply to comment #1)
> I would think they have the "id" object attribute. Nearly every important
> element in the XUL UI's have an id so that extension authors can hook in.
> 

Looking at them with Accerciser, I'm seeing class and tag, but no id.  Having an "id" object attribute which identifies the field would be helpful.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to comment #2)
> (In reply to comment #1)
> > I would think they have the "id" object attribute. Nearly every important
> > element in the XUL UI's have an id so that extension authors can hook in.
> > 
> 
> Looking at them with Accerciser, I'm seeing class and tag, but no id.  Having
> an "id" object attribute which identifies the field would be helpful.
> 

in DOMi I see id attribute on every columnheader accessible object.

tree  - "threadTree" id attribute
  list - "treeCols" id attribute
    columnheader - "threadCol" id attribute + tag + class attributes
    and etc

You don't see this in Accerciser, right?

Comment 4

[Joanmarie Diggs]

I'm not sure if we're looking at the same thing or not Alexander. :-)

I see something similar to that if I look at the column header in the message list.  That's not where I'm looking.  (And re-reading my original report, I'm totally responsible for being unclear.  I'm really sorry! I need to sleep more than I do).  So:

Steps to reproduce:

1. Locate a message in your list of messages

2. Press Return to open that message in a new window.

3. Press Shift + Tab to move focus to one of the headers (To, Date, Sender, etc.)

4. Examine the focused object and its label.

I see class (e.g. headerName, headerValue plain), and tag (e.g. xul:label, xul:textbox). In the case of textboxes, I also see line-number. But I do not see id.

Comment 5

[alexander :surkov (:asurkov)]

Thank you for clarification.

We could add new accessible object with 'id' attribute into hierarchy that will hold both label and control. If it doesn't look as good approach then would it be ok to add 'id' attribute on control itself?

Comment 6

[Joanmarie Diggs]

Alexander, as far as I'm concerned, if you can get add an attribute in a logical and predictable place that I can use to provide the desired access, it's all good. :-) Thanks!!

Comment 7

[Marco Zehe (:MarcoZ)]

Please hold off on this. My goal is to convert these labels to read-only textboxes, if possible, and provide real labels for them that correspond to the actual header field they're representing. That's the better solution than the hacky approach to stuff everything into attributes. These items are tabbable anyway, and so far nobody could explain to me why they have to be labels.

Comment 8

[Marco Zehe (:MarcoZ)]

Well turns out converting those to textboxes wasn't doable, but bug 449560 will make the accessible names for each header field contain both the actual name/address and the type ("from:" etc.). Does that help?

Comment 9

[Joanmarie Diggs]

(In reply to comment #8)
> Well turns out converting those to textboxes wasn't doable, but bug 449560 will
> make the accessible names for each header field contain both the actual
> name/address and the type ("from:" etc.). Does that help?

Accessible names are, as I understand it, localized (or potentially localizable), so I'm afraid it does not.

I do see that objects of ROLE_LABEL now expose an object attribute called label which contains both the accessible name for the header field and the address. e.g.:

     to : [e-mail]

Question/concern #1: What is in the object attribute called label coincides with the accessible name of that label. Is that attribute's value independent of the label name or is it taken from the label name? In other words, in a localized version of Thunderbird, is the label object attribute in danger of being localized, or can I count on things like "To", "From", etc. being present regardless of what the accessible name becomes?

Question #2: This is present for the labels which contain the addresses. I am not seeing any object attributes for fields whose contents is presented in objects of ROLE_ENTRY. (e.g. subject and date)

Comment 10

[Wayne Mery (:wsmwk)]

a duplicate of one of these https://mzl.la/29p8ITC ?

Comment 11

[David Weir (satdav)]

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #10)
> a duplicate of one of these https://mzl.la/29p8ITC ?

I am thinking so but the accessibility team is on this bug so they will mark it as a duplicate if they think its a duplicate

Comment 12

[Marco Zehe (:MarcoZ)]

No this is not a duplicate of the others. It's a separate issue. Joanie, is this still relevant at all?