370437 - 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)

Status: RESOLVED DUPLICATE of bug 1803272

(Thunderbird :: Folder and Message Lists, defect)

Description

[David Bolter [:davidb] (NeedInfo me for attention)]

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.

Comment 1

[Mike Cowperthwaite]

Since the other column headers are all replicated by View | Sort By, perhaps there could be a View | Columns submenu.

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

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?

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

I mean, shall we go ahead with a View | Columns submenu?

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

We also need a way of reordering the columns via the keyboard.

Comment 5

[Aaron Smith]

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.

Comment 6

[Aaron Smith]

Attachment: Proposed list view header management UI

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.

Comment 7

[Marco Zehe (:MarcoZ)]

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.

Comment 8

[Marco Zehe (:MarcoZ)]

Requesting blocking on this one since there is no way to get to the column picker with the keyboard right now.

Comment 9

[David Ascher (:davida)]

With our stricter definition of blocker, I don't think this qualifies, but a solution would be good anyway.

Comment 10

[Phil Ringnalda (:philor)]

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 :)

Comment 11

[Thomas D. (:thomas8)]

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.

Comment 12

[James Teh [:Jamie] (away returning 28 Jan)]

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).

Comment 13

[James Teh [:Jamie] (away returning 28 Jan)]

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.

Comment 14

[James Teh [:Jamie] (away returning 28 Jan)]

(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.

Comment 15

[Thomas D. (:thomas8)]

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

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

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...

Comment 17

[James Teh [:Jamie] (away returning 28 Jan)]

Any solution (interim or otherwise) needs to be able to reorder as well as choose (show/hide) columns.

Comment 18

[intendentedelleacque]

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!

Comment 19

[Joanmarie Diggs]

(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.

Comment 20

[Sof]

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

Comment 21

[Jim Porter (:squib)]

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.

Comment 22

[James Teh [:Jamie] (away returning 28 Jan)]

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.

Comment 23

[Jim Porter (:squib)]

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 24

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381

Comment 26

[Wayne Mery (:wsmwk)]

xul is on its way out, right?
If so, what is the path forward for a full fix? Is it part of or dependent on bug 213945?
And is it possibly in scope for version 91.
If not, can the temporary, half measure fix be done for 91?

Comment 27

[Ali Savas]

Now that the Thunderbird project has been getting more development work for a while, this bug should be fixed as soon as possible. It is still not possible to sort the columns with a screen reader. It doesn't have to get the highest priority now, because there are more important bugs, but it should be fixed very soon.

Comment 28

[Wayne Mery (:wsmwk)]

ref comment 26, which accidentally got marked private

Comment 29

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #26)

xul is on its way out, right?
If so, what is the path forward for a full fix? Is it part of or dependent on bug 213945?

Well, see mkmelin's Bug 213945 Comment 213 for the prospects of having bug 213945 soon.

And is it possibly in scope for version 91.
If not, can the temporary, half measure fix be done for 91?

Showing and hiding columns via keyboard should be doable as a quick fix (I probably could).

Reordering columns is a lot more involved, regardless of implementation. Maybe we could use Alt+cursor up/down in the colpicker menu to reorder. Maybe that would be easier than the real thing, having Ctrl+cursor right/left to move focused/selected column header (as in Windows Explorer).

Does anyone know why moving the last column (Delete column in my case) one column forwards changes its ordinal from 43 to 23? How do these ordinals work? We don't even have 43 columns... :-/

Comment 30

[Ali Savas]

Personally, I think it would be better if there was a "Arrange Columns" dialog under "View". There should appear a list with the available columns, which can be selected and deselected. With the buttons "Up" or "Down" you could move the columns up or down. This is similar to the way it is done in Microsoft Outlook.

Better this way and right, than a "quick and dirty" solution. For that it may take a little bit longer with the implementation because of me. I would agree, if it can not be implemented until the next stable version, but in the next but one.

I gladly accept the suggestion with the keyboard shortcuts, but this may only be an interim solution until the implementation.

Comment 31

[Alessandro Castellani [:aleca]]

Unfortunately it seems that the XUL tree element will remain at least until the next ESR after 91, so we should definitely find a solid and stable solution for this.

I like the proposal of Ali of implementing an Arrange Columns dialog (maybe even an in-content dialog, or subdialog).
That would give us the space and flexibility to use pure HTML to make everything keyboard accessible.

The XUL tree is a strange beast with many quirks I haven't figure out at all.

Comment 32

[Elizabeth Mitchell]

Fixed in bug 1803272. We made significant changes to the underlying code of the message list.