Open Bug 370437 Opened 16 years ago Updated 6 months ago
TB: Selecting and reordering columns to display (in message list pane) is not keyboard accessible (need alternative UI or XUL core to make <tree> column picker & headers accessible, like Windows Grid
The little button thing on the far right of the message list column headers which allows toggling of displayed columns must be invokable via keyboard or there must be alternate UI which is keyboard accessible.
Summary: Button popup for selecting columns to display (in msgDBView) must be keyboard accessible → Button popup for selecting columns to display (in message pane) must be keyboard accessible
Summary: Button popup for selecting columns to display (in message pane) must be keyboard accessible → Button popup for selecting columns to display (in message list pane) must be keyboard accessible
OS: Linux → All
Hardware: PC → All
Since the other column headers are all replicated by View | Sort By, perhaps there could be a View | Columns submenu.
That seems reasonable to me. It is a bit more to "keep track of" down the road as one of them changes we'd want to make sure the other was updated too. Shall we go ahead with a View | Sory By solution?
I mean, shall we go ahead with a View | Columns submenu?
We also need a way of reordering the columns via the keyboard.
I concur that we need to be able to reorder, not just toggle on and off. Right now, I can simply click and drag where I want the headers to be. But a person who is blind, and who does not use the mouse, doesn't have a good way to get the columns moved around. I'm envisioning a dialog with a list box showing all available headers. Each header would have a check box which would control the header's are visibility. Then, an up button and a down button could be used to move the selected item in the list box up and down, thereby reordering the headers.
This dialog is from Windows Live Mail/Outlook Express, and conveys the idea of an accessible method of reordering/managing list view column headers mentioned in comment #5.
I agree with Aaron that an UI would be the best solution. I was thinking of also mimiking the Vista Explorer window where one can actually tab to the Column Headers, but that is the part of the message list that is already accessible. Note that this is a section 508 issue too, since the functions to reorder the columns and show/hide columns is not keyboard accessible at all right now. Setting keyword accordingly.
Requesting blocking on this one since there is no way to get to the column picker with the keyboard right now.
With our stricter definition of blocker, I don't think this qualifies, but a solution would be good anyway.
Assignee: mscott → nobody
Unlikely as such a solution seems, it would still be nice if this bug at least "depended" on a core bug on making the tree widget itself accessible, even if we hack around the problem here without fixing the dependency. Even though Firefox has done pretty well at burying trees, Page Info's Media tab is rather unlikely to get a menu workaround to let you show, say, the "Alternate Text" column, which seems like it might be useful in accessibility terms :)
Implementing the customization UI dialogue is certainly the best and only solution in the long run, but until we get there (who knows if ever), just having the View > Columns submenu as per comment #3 would be a low-hanging fruit to fix the biggest part of this accessibility problem. We could just reuse the menu from column picker.
Version: unspecified → Trunk
I actually don't think you need a customisation UI dialog. You could do it as follows: 1. Make the column headers focusable via the keyboard. 1.1. This could be done by pressing upArrow at the top of the message list; or 1.2. using a shortcut in the message list; e.g. control+upArrow. 1.3. In Windows Vista and later, the column headers in ListView controls are included in the tab order directly after the list items (so the list consumes two tab stops). However, this clutters up the tab order. 2. When the column headers are focused: 2.1. left and right arrows would move between the headers without moving them; and 2.2. control+leftArrow and control+rightArrow would move the focused header to the left or right, respectively. 3. Pressing right arrow on the rightmost column would focus the "Click to select columns to display" button. 3.1. Pressing space on this button would activate the context menu to choose columns. 4. Provide a way to move focus back to the message list using the keyboard. This depends on the approach chosen for (1).
Btw, there is precedent for using control+left/rightArrow to reorder items: 1. The tab bar in Firefox. 2. I just noticed that the headers for ListView controls in Windows Vista and later also allow this. For some reason, I never tried this before today. :) In addition, pressing enter/space on column headers would "click" that column header.
(In reply to James Teh [:Jamie] from comment #12) > 1.2. using a shortcut in the message list; e.g. control+upArrow. Control+upArrow is a bad idea, as it's used to move to the previous message without affecting selection. If we want a specific shortcut in the message list, maybe alt+upArrow? There's no really standard/common way to do this.
I'd like to clarify a few things here. 1) The column picker forms part of the XUL UI element <tree> (1), and TB is using that element. So bugs inside that element cannot be fixed by TB, they need to be fixed in core XUL (see comment 10). As long as the XUL element bugs aren't fixed, TB can only provide workarounds, or push for the XUL core bugs to be fixed. 2) The current bug that column picker and re-ordering of columns is not accessible directly from within the XUL element <tree> is originally by design (intended), as outlined in XUL's accessibility guidelines (2): > Trees > *Provide alternative functionality for inaccessible operations*. The column > picker and column headers in XUL trees are not keyboard accessible, consistent > with the standard tree behavior on most contemporary operating systems. It is > therefore necessary to provide a keyboard accessible alternative for accessing > this functionality. 3) XUL's main reason (see 2 above) for *not* offering intra-element accessability for <tree> is no longer valid, because the largest contemporary operating system has made its <tree> element fully accessible from within, as mentioned in comment 7: Windows Vista and Windows 7 allow tabbing into the column headers (press tab from treelist to move focus on first column header). From there (tested for Win 7): - Cursor right/left to move focus between column headers - Enter on column header to sort by the column; Enter on current sort column to toggle sort order ascending vs. descending (and after each Enter, Focus is returned to the treelist) - Cursor down on column header makes group by and filter functionality for that column available (advanced stuff! try the date column) - Ctrl+Cursor right/left to move selected column (reorder columns) - Ctrl+Shift+Cursor right/left to adjust column width of selected column - Context Menu key (or Shift+F10) on focused column header will show context menu: - auto-adjust column width for current or all columns (best width) - pick / toggle columns for display So on Windows, every aspect of the tree is now directly accessible *from within* the UI element, at the cost of a single tab stop (only!). *In addition*, /all/ aspects of the tree are still accessible via the Windows Explorer menus: View > Sort by (pick sort column, toggle ascending vs. descending, and "more..." to get to details) View > Choose details (toggle columns for display, reorder columns, adjust column width) Furthermore, the same aspects are also accessible via some more traditional mouse methods and context menus from the list. 4) It follows from Windows Explorer behaviour described ini 3) that current XUL design in 2) is now a bug that should be fixed in XUL core. However, that's not a Thunderbird bug, so it's not this bug! 5) For TB, we cannot and should not wait until 4) happens (if ever). We need to implement alternate UI to work around the current major accessibility problem of tree element, as prescribed in current XUL guidelines (2): > *Provide alternative functionality for inaccessible operations*! 6) Given 5), this bug should focus on what can be done as the route of least resistance to provide alternative UI to make TB's trees accessible. (In reply to Thomas D. from comment #11) > Implementing the customization UI dialogue is certainly the best and only > solution in the long run, Things have changed, the above part of my comment 11 no longer fully applies. > but until we get there (who knows if ever), just > [6a] having the View > Columns submenu as per comment #3 would be a low-hanging > fruit to fix the biggest part of this accessibility problem. We could just > reuse the menu from column picker. 6a) I'd still maintain that this would be the easiest starting point to do something about this bug. 6b) Then, or alternatively, a richer "Choose Details..." dialogue a la Windows Explorer, as proposed in attachment 268974 [details]. 6c) Finally, wait for XUL core to fix their part of the problem. 7) (In reply to James Teh [:Jamie] from comment #12) In view of 4) and more above, comment 12 is good but it cannot be implemented by TB, only in XUL core. So it doesn't help for this bug (and some of the details are unlikely, if only because of 3), like a separate keyboard shortcut for customizing the tree). (1) https://developer.mozilla.org/en/XUL/tree (2) https://developer.mozilla.org/en/XUL_accessibility_guidelines#Trees
Summary: Button popup for selecting columns to display (in message list pane) must be keyboard accessible → TB: Selecting and reordering columns to display (in message list pane) is not keyboard accessible (need alternate UI or XUL core to make Column picker & headers accessible, like Windows)
Summary: TB: Selecting and reordering columns to display (in message list pane) is not keyboard accessible (need alternate UI or XUL core to make Column picker & headers accessible, like Windows) → TB: Selecting and reordering columns to display (in message list pane) is not keyboard accessible (need alternative UI or XUL core to make <tree> column picker & headers accessible, like Windows GridView)
I am wondering if it is simpler to work around this bug and https://bugzilla.mozilla.org/show_bug.cgi?id=722265 by adding a View menu option, so that we have View->Columns and then can choose columns based on that. Otherwise this might need changes in Core as well as in TB which may be harder to coordinate and to pin down in the code...
Any solution (interim or otherwise) needs to be able to reorder as well as choose (show/hide) columns.
I'm trying to work on an extension that allows to reorder columns without the mouse, just via keyboard and I've a technical question: is there some bad side effect if I manipulate the attribute "ordinal" of the columns at startup? I've found out that by changing this attribute in the right way at startup, I can reorder the columns according to a preference value and it seems to work flawlessy. But I'm not expert enough to know if this could break some functionality or have even worse effect. Could you give me an opinion about this? Thank you!
(In reply to James Teh [:Jamie] from comment #17) > Any solution (interim or otherwise) needs to be able to reorder as well as > choose (show/hide) columns. Indeed. Having to locate the column headers non-visually via screen reader review command and then synthesize a mouse click via the screen reader in order to get a pop-up menu in which one can choose a column (but only one) to show/hide is the poster child for inaccessibility. :( Unless I missed a more efficient way, it would be extremely helpful for this to be solved.
Hello, I'm not a developper but a end-user. Since no solution has been found so far to reorder columns using the keyboard, I was wondering if we could do it manually by editing a pref file in the notepad for example. When I was using TB 3.X, we were able to modify the columns order by editing a file called localstore.rdf. But it appears to be deprecated in actual TB versions. It could be a workaround while waiting for a viable solution. Thank you Sof
How important is reordering here actually? It would be pretty easy to show/hide columns via the keyboard, but reordering would be a lot more work.
Component: Mail Window Front End → Folder and Message Lists
Unfortunately, reordering really is quite important for screen reader users, as it affects the order in which information for each message item is read. That can dramatically affect efficiency for the user.
Then I don't see myself having the time to resolve this anytime soon, sadly. I probably have enough free time to add the ability to show/hide via keyboard, but not anything more.
Comment 26 is private: false
You need to log in before you can comment on or make changes to this bug.