User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082618 Minefield/3.0a8pre Build Identifier: version 3.0a1pre (2007082604) When tabbing through the Account Settings dialog, grouping information is no longer exposed correctly to screen readers. Instead, the grouping names are either empty, or contain urls such as chrome://messenger/content/am-main.xul. Reproducible: Always Steps to Reproduce: 1. Start Thunderbird and a screen reader. 2. Click Tools (or Edit) -> Account Settings... 3. Tab through the page that appears, and listen to what the screen reader tels you. Actual Results: At the Account Name textbox, a grouping name of chrome://messenger/content/am-main.xul is spoken. At the Your Name, e-mail address etc., no grouping information is spoken at all, and at the Manage Identities... button, one again hears the chrome URL from above. Expected Results: Real grouping information should be spoken, as is the case in Thunderbird 2.0. When looking at the Account Settings window using Accessibility Explorer tools, the groupings/panels are indeed either unnamed or have a name of a chrome: url. The first child is always a text element that corresponds to the name of the grouping. If the grouping also has more explanatory text, such as the one for the Identity, the grouping contains a second child of type text right after the grouping title that contains this text. Screen readers, however, do not pick these up by default, but instead rely on the grouping/panel actually being labelled properly.

Does this affect Firefox as well?

(In reply to comment #1) > Does this affect Firefox as well? No, this is a bug specific to the Thunderbird Account Preferences dialog and the way it is marked up in XUL.

If you look at the accessible value for the root object in the window, it will tell you the name of the XUL file which defines this. You can then search for that file on lxr.mozilla.org, and then you can use the "Log" and "Blame" links to investigate who did this and then CC them.

Though since the only changes in either am-main.xul or AccountManager.xul is the removal of the help button that didn't work in Thunderbird, you're unlikely to find a smoking gun there, and are more likely to need to search for when it regressed by trying builds from http://archive.mozilla.org/pub/thunderbird/nightly/ (1.8 branched in August 2005, so a 2006-09-01-trunk build will cut it in half, then if that still works a 2007-03-01 build will cut the remainder in half...).

First part of this bug, the announcement of chrome://... as the group box name before the "Account Name:" prompt, was introduced on May 8, 2007 trunk build. At this point, the "Default identity" groupbox name for the Name, E-Mail Address etc. fields are still spoken properly. The checkins for the period in question are here: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-05-07+00%3A00&maxdate=2007-05-08+09%3A00&cvsroot=%2Fcvsroot

Part 2 got broken on July 1, 2007 builds. The checkins are: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-06-30+00%3A00&maxdate=2007-07-01+09%3A00&cvsroot=%2Fcvsroot. Aaron, one particular checkin stands out at me, the fix is titled "Fieldset children and relations incorrect", but no bug number is given.

Update: It appears that, as soon as bug 388185 is fixed, part 2 of this bug will be fixed as well. The only part that remains is the part about some groupboxes receiving a chrome:// url as the label/caption (see comment #5). Should I set this bug to be depending on bug 388185, or should this bug be redefined to only deal with the chrome:// part?

Getting back to this one, I found that the chrome URLs are actually the accessible names for the xul:page elements. I think I can solve this with some help from ARIA.

Hmm nope, would mean to change something in the XBL binding for xul:dialogheader. Am trying a different approach. The bug was introduced with bug 379755, which makes al xul:tabbox elements to announce themselves as groupboxes. If everything else fails, give it the name of the URL.

More info: It can be fixed by giving the xul:page element a title attribute. As far as JAWS Cursor tells me, this does not have any visual impact, but it fixes the annoying chrome:// urls that screen readers read.

Once bug 432046 gets fixed, which has other accessibility XUL fixes as well as giving the account manager files titles on their xul:page elements, this bug will be fixed as well.

Bug 432046 was fixed today, so this one is also fixed. The only thing we need to be aware of is that xul:page elements should always get a title attribute.