449544 - The Thunderbird address book import wizard's 'Import everything' radio button is a child of the wrong (or a misnamed) panel.

Status: NEW

(MailNews Core :: Import, defect)

Description

[Ye Guo]

1. Launch orca and enable speech. 
2. Launch thunderbird. Click 'Address Book' button.
3. In Addrees Book window, select menu Tools->Import to invoke import wizard window.
 
In the import wizard window, orca spoke 'or select the type of material to import', and then spoke the 'import everything' radio button. But it should speak the later one firstly.

Comment 1

[Joanmarie Diggs]

Orca is doing that because the 'Import everything' radio button is a child of a panel whose name is 'or select the type of material to import:". This is the accessible hierarchy we're seeing:

- or select the type of material to import: (panel)
   - Import everything (radio button)
   - (label whose accessible text is 'or select the type of
      material to import:')
   - Address Books (radio button)
   - Mail (radio button)
   - Setting (radio button)
   - Filters (radio button)

The 'Import everything' radio button should either not be a child of that panel, or that panel should have a different name. (The LABEL_FOR/LABELLED_BY relationship pair is set between that panel and the label inside it.)

Thanks!

Comment 2

[Phil Ringnalda (:philor)]

While we can certainly rewrite that page (for the worse, since "Select the type of material to import: (.) Import everything" is both awkward and pushier than the current scheme), that strikes me as a bug in the a11y backend: betting that a label which appears after the first radio item will be an appropriate label for the entire radiogroup, rather than only for those radio items which come after it, strikes me as a very bad bet. Offhand, I can't imagine a situation where that ordering would be used for anything other than what it's used for here, Self-Labeling Item One, Label which only applies to items two through five, Item Two, Item Three...

Comment 3

[Willie Walker]

(In reply to comment #2)
> While we can certainly rewrite that page (for the worse, since "Select the type
> of material to import: (.) Import everything" is both awkward and pushier than
> the current scheme)

Having a disjoint radio button group as is currently done is rather strange.  Furthermore, having an accessible hierarchy where the label for the panel is visually nested somewhere within the children is bizarre.  This is the first I've ever come across this situation.  

> that strikes me as a bug in the a11y backend: betting that
> a label which appears after the first radio item will be an appropriate label
> for the entire radiogroup

The bet being made is this: since the panel contains the entire radio button group and the label is for the entire panel, the label is for the entire radio button group.  It's not such a bad bet.  Except this very strange and bizarre case, the label for the panel is the label for all the components in the panel.

Comment 4

[Willie Walker]

(In reply to comment #3)
> button group.  It's not such a bad bet.  Except this very strange and bizarre
> case, the label for the panel is the label for all the components in the panel.

Sorry.  "Except for this very strange and bizarre case, the label for the panel is always the label for all the components in the panel."

Comment 5

[:aceman]

I agree the radiogroup layout is quite hacky, even without the accessibility aspect. There is no label before the radiogroup, only the one inside it. Also some of the radio items are indented.
I'll see if this can be improved.