If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

No focus events for labels in Thunderbird message header

RESOLVED WONTFIX

Status

()

Core
Disability Access APIs
RESOLVED WONTFIX
10 years ago
7 years ago

People

(Reporter: Joanmarie Diggs, Assigned: Evan Yan)

Tracking

(Blocks: 2 bugs, {access, sec508})

Trunk
x86
Linux
access, sec508
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.1 ?
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: orca:high)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
Steps to reproduce:

1.  Launch Accerciser and turn on event monitoring
2.  Launch Thunderbird and view/open a message
3.  Press Tab to move among the fields in the header:
    a. Subject (role entry)
    b. From (role label)
    c. Date (role entry)
    d. To (role entry)

Expected results: a focus: event and an object:state-changed:focused event would each be issued for all of the above fields.

Actual results: a focus: event and an object:state-changed:focused event are issued for the entries but not for the labels. (i.e. No events for the From and To fields)

Updated

10 years ago
Assignee: aaronleventhal → david.bolter

Updated

10 years ago
Blocks: 396347
(Reporter)

Updated

10 years ago
Keywords: sec508
Whiteboard: orca:major
(Reporter)

Updated

10 years ago
Flags: blocking1.9?

Updated

10 years ago
Whiteboard: orca:major → orca:high
Not blocking 1.9 for this.
Flags: blocking1.9? → blocking1.9-

Comment 2

10 years ago
Thunderbird has the followin hierarchy:

xul:label@class="headerValue" - label accessible
  xul:mail-emailaddress - focusable but it's not accessible
    xul:label - label accessible

when we catch focus event then it sounds we do not fire ally focus event for xul:label.

1) Why do we need top xul:label element?
2) should we fire focus event when non accessible node get DOM focus event and if we should then which accessible should receive it (top on bottom in this case)?
3) Should be mail-emailaddress accessible?

Comment 3

10 years ago
1) It's the label of the headerName, e.g. label="&fromField.label;", label="&senderField.label;" right?

2) If we want to fire the focus event, I think top is better.

3) I think we should. Because it contains a label and an image.

BTW: I don't get all the children of "expanedHeaderView" in accerciser, is it a known issue?

Comment 4

10 years ago
David Bolter is on leave for the birth of his new daughter.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Updated

10 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

10 years ago
Assignee: david.bolter → Evan.Yan
Status: REOPENED → NEW
(Reporter)

Comment 5

9 years ago
In the good news department, it seems we are now getting focus events for *something*. :-)  Looking at accerciser, the hierarchy seems to be:

- ROLE_LABEL (no name)
  - ROLE_UNKNOWN (name is the displayed email address)
    - ROLE_LABEL (name is the displayed email address)

The focus events we're getting are for the item of ROLE_UNKNOWN.  Because we're getting these events, we are able to speak the address being displayed. However, because it's of ROLE_UNKNOWN, we don't present any role information like we do with header fields that are entries (e.g. date and subject). Could this item be given a different role and/or the focus events be for the 2nd label (i.e. the one with a name) and/or the hierarchy changed (are all three of those things needed?).

Also, unlike the header fields that are entries (date and subject), there is no relationship connecting any of the above three accessible objects with the label associated with it/them (e.g. "To:"). As a result, we present the displayed address but cannot reliably indicate which field it is. (I think it would be a brittle solution were we to guess the label based on the current hierarchy.)
(Assignee)

Comment 6

9 years ago
Created attachment 339418 [details] [diff] [review]
patch
Attachment #339418 - Flags: review?(bienvenu)

Comment 7

9 years ago
Evan, have you checked the latest trunk code? The header display stuff has changed a lot in the last couple days. The code you changed hasn't, but I'm not sure it's all still used.

Comment 8

9 years ago
Comment on attachment 339418 [details] [diff] [review]
patch

Neil might be a better person to review this, since this is shared code.
Attachment #339418 - Flags: superreview?(bienvenu)
Attachment #339418 - Flags: review?(neil)
Attachment #339418 - Flags: review?(bienvenu)
(Assignee)

Comment 9

9 years ago
(In reply to comment #7)
> Evan, have you checked the latest trunk code? The header display stuff has
> changed a lot in the last couple days. The code you changed hasn't, but I'm not
> sure it's all still used.

Thanks for the reminder. It's still used.

Updated

9 years ago
Flags: wanted1.9.1?

Comment 10

9 years ago
Comment on attachment 339418 [details] [diff] [review]
patch

Neil, thoughts on this? I suspect the patch doesn't apply thx to Karsten :-) but before I revive it, what do you think it in general?

Comment 11

8 years ago
Comment on attachment 339418 [details] [diff] [review]
patch

dmose would be a better person to look at this.
Attachment #339418 - Flags: superreview?(bienvenu) → superreview?(dmose)
Created attachment 398502 [details] [diff] [review]
patch for both SeaMonkey and Thunderbird

Sorry that it's taken so long to get this reviewed.  Since that patch was written, there's been some bit rot, and mailWidgets.xml was forked so that Thunderbird now has its own copy.  Here's a version of the patch with bitrot fixed, and with a port to the new Thunderbird copy.  Can someone with a screenreader (Evan?) test this new patch against the current Tb source?

Setting both r? and sr? to myself, as this is a pretty straightforward patch.
Attachment #339418 - Attachment is obsolete: true
Attachment #398502 - Flags: superreview?(dmose)
Attachment #398502 - Flags: review?(dmose)
Attachment #339418 - Flags: superreview?(dmose)
Attachment #339418 - Flags: review?(neil)

Updated

8 years ago
Attachment #398502 - Flags: superreview?(dmose)
Attachment #398502 - Flags: superreview+
Attachment #398502 - Flags: review?(mzehe)
Attachment #398502 - Flags: review?(dmose)
Comment on attachment 398502 [details] [diff] [review]
patch for both SeaMonkey and Thunderbird

I spoke a little too quickly on the review bit: sr=dmose, because in general it seems fine, but I haven't been able to locate any documentation for nsIAccessibleProvider that would allow me to figure out whether .XULPane is the right constant or not.  So I'm going to delegate r= to mzehe.
Comment on attachment 398502 [details] [diff] [review]
patch for both SeaMonkey and Thunderbird

Taking this review off my obsoleted e-mail address (why is this still floating around anyway?). :)
Attachment #398502 - Flags: review?(mzehe) → review?(marco.zehe)
Comment on attachment 398502 [details] [diff] [review]
patch for both SeaMonkey and Thunderbird

>+        <xul:label class="headerName" xbl:inherits="value=label"
>+                   control="emailAddreses"/>

This is a typo, right? Shouldn't this ID be "emailAddresses" like in the one for SeaMonkey below?
Comment on attachment 398502 [details] [diff] [review]
patch for both SeaMonkey and Thunderbird

With this patch applied, screen readers on Windows will double-speak each e-mail address field when tabbing through. This bug was filed long before bug 449560 was fixed, so I wonder if it is still applicable at all. Focus now moves through the different e-mail address fields, so I believe there is actually no need to re-class a xul:description as a PANE accessible any more.
Attachment #398502 - Flags: review?(marco.zehe) → review-
Closing WONTFIX because the better fix is in bug 449560, see also Comment #16.
Status: NEW → RESOLVED
Last Resolved: 10 years ago7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.