STR: 0. Open Inspect.exe 1. Open tools > options 2. Open the "Applications" pane 3. Select the headers ("Content Type" and "Action") in inspect.exe ER: The header element has two kids whose names reflect the labels of the treecol elements AR: The header element has no kids and no accessible name I'm pretty sure this is a bug in our XUL a11y stuff, rather than in the markup here, which I'd expect to just work. Surkov, is that right?

This also means that they are not represented with the correct roles and the sort state is not exposed through a11y

it appears there's something wrong with markup, listheader is misused (I guess listhead was supposed to be there, see http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/listbox.xml). Also not sure if treecol is valid there too (I guess listheader should be used instead).

(In reply to alexander :surkov from comment #2) > it appears there's something wrong with markup, listheader is misused (I > guess listhead was supposed to be there, see > http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/ > listbox.xml). Also not sure if treecol is valid there too (I guess > listheader should be used instead). Delightful. While I'm sure that this is the case for <listbox>, it seems that when someone made <richlistbox>, they changed their mind: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/richlistbox.xml#12 which just includes <listheader> above the listbox, not listhead. Which of course means that if we use the semantically correct: <listhead> <listheader ... > <listheader ... > </listhead> It gets lobbed into the entire list (so it scrolls out of view visually when you scroll down in the list), which isn't what we want here. The short-term workaround would be specifying role attributes as per listhead/listheader, which I'm sure would fix things for now. The long-term workaround would be changing the XBL bindings, and the CSS we have for these cases (because as best I've been able to tell we've been doing this 'wrong' everywhere) and the JS where applicable. I'm honestly not sure, although I vaguely suspect that updating the XBL is probably relatively cheap (in that it involves adding another item to the "includes" list at the point I linked to), and then we can start doing it 'right' in future? Perhaps starting with the in-content prefs? Note also that it seems that <listhead> shows up in inspect.exe as another label-less list. It seems like for the windows explorer view, it shows the header as a Header, and then the items in the header as split buttons, which I don't personally think makes sense either. :-\ That said, we can probably make listhead have whatever role we want by adding the right role attribute in the XBL binding for it (which is mostly empty right now) and ensure we're happy with it. Matt and/or David, do you have opinions on the short-term workaround vs. long-term fix here?

Redirecting per IRC feedback. :-)

(In reply to :Gijs Kruitbosch from comment #3) > It gets lobbed into the entire list (so it scrolls out of view visually when > you scroll down in the list), which isn't what we want here. > > The short-term workaround would be specifying role attributes as per > listhead/listheader, which I'm sure would fix things for now. might be not, we check xul:something values of @role attribute specified on xbl:content, so we won't use proper accessible class if you use @role attribute outside XBL binding. > The long-term workaround would be changing the XBL bindings, and the CSS we > have for these cases (because as best I've been able to tell we've been > doing this 'wrong' everywhere) and the JS where applicable. I wish we had less confusing tag names > Matt and/or David, do you have opinions on the short-term workaround vs. > long-term fix here? I think I prefer the long-term fix

Sorry for the delay but I know almost nothing about many of the pieces (listhead/listheader/Inspect.exe) of this bug so I've been trying to find time to look into it more. I would like to defer to someone else who knows this stuff more (maybe dao when he's back?) or we can discuss in realtime over video to speed up the information flow. From what I do currently understand at the high-level (without digging into the current usage of these bindings in the tree), my gut says the long term solution is better.