Closed
Bug 387838
Opened 18 years ago
Closed 14 years ago
No focus events for labels in Thunderbird message header
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jdiggs, Assigned: evan.yan)
References
(Blocks 1 open bug)
Details
(Keywords: access, Whiteboard: orca:high)
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
MarcoZ
:
review-
dmosedale
:
superreview+
|
Details | Diff | Splinter Review |
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•18 years ago
|
Assignee: aaronleventhal → david.bolter
Updated•17 years ago
|
Blocks: tbird3access
Reporter | ||
Updated•17 years ago
|
Flags: blocking1.9?
Updated•17 years ago
|
Whiteboard: orca:major → orca:high
Comment 2•17 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?
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•17 years ago
|
||
David Bolter is on leave for the birth of his new daughter.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•17 years ago
|
Assignee: david.bolter → Evan.Yan
Status: REOPENED → NEW
Reporter | ||
Comment 5•16 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.)
Attachment #339418 -
Flags: review?(bienvenu)
Comment 7•16 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•16 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)
(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•16 years ago
|
Flags: wanted1.9.1?
Comment 10•16 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•15 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)
Comment 12•15 years ago
|
||
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•15 years ago
|
Attachment #398502 -
Flags: superreview?(dmose)
Attachment #398502 -
Flags: superreview+
Attachment #398502 -
Flags: review?(mzehe)
Attachment #398502 -
Flags: review?(dmose)
Comment 13•15 years ago
|
||
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 14•15 years ago
|
||
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 15•15 years ago
|
||
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 16•15 years ago
|
||
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-
Comment 17•14 years ago
|
||
Closing WONTFIX because the better fix is in bug 449560, see also Comment #16.
Status: NEW → RESOLVED
Closed: 17 years ago → 14 years ago
Resolution: --- → WONTFIX
Comment 18•6 years ago
|
||
Keywords: sec508
You need to log in
before you can comment on or make changes to this bug.
Description
•