Bug 1783172 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

The everyday scenario of keyboard-navigating from AB search input to results list in vertical layout now takes 6 or more tab stops as we're passing through each and every column header (we have 10 columns available and more to come) - that's way too many, and needs way too much focus (pun intended).

Accessibility is good. Too many tab stops for basic scenarios isn't.
Rule of thumb: Multiple adjacent elements of the same type should only have a single tab stop, reach the rest with arrow navigation. Which is good ARIA practice, too!

STR

1. `Address book > List display options > Switch to horizontal layout` 
2. Click in search field, do a random search
3. Press `Tab` as often as required to focus the first contact item in the results list

Actual result
- 6 or more `tab` keypresses needed: each column header is a tab stop
- navigation to the result list extremely inconvenient, plus the number of tabs may change depending on number of columns, so it needs more attention and it's hard to develop muscle memory

Expected
- Single tab stop at the column header which the table is currently sorted by (e.g. Name)
- Column header tab stop should come *after* the results list, not before (to reduce the number of keystrokes from search field to results list)
- Then any other column headers can be focused using arrow-right/left

Windows Explorer certainly had a good reason for this design, try it there!
The everyday scenario of keyboard-navigating from AB search input to results list in vertical layout now takes 6 or more tab stops as we're passing through each and every column header (we have 10 columns available and more to come) - that's way too many, and needs way too much focus (pun intended).

Accessibility is good. Too many tab stops for basic scenarios isn't.
Rule of thumb: Multiple adjacent elements of the same type should only have a single tab stop, reach the rest with arrow navigation. Which is good ARIA practice, too!

STR

1. `Address book > List display options > Switch to horizontal layout` 
2. Click in search field, do a random search
3. Press `Tab` as often as required to focus the first contact item in the results list

Actual result
- 6 or more `tab` keypresses needed: each column header is a tab stop
- navigation to the result list extremely inconvenient, plus the number of tabs may change depending on number of columns, so it needs more attention and it's hard to develop muscle memory

Expected
- Single tab stop at the column header which the table is currently sorted by (e.g. Name)
- Column header tab stop should come *after* the results list, not before (to reduce the number of keystrokes from search field to results list)
- Then any other column headers can be focused using `arrow-right/left`

Windows Explorer certainly had a good reason for this design, try it there!
The everyday scenario of keyboard-navigating from AB search input to results list in vertical layout now takes 6 or more tab stops as we're passing through each and every column header (we have 10 columns available and more to come) - that's way too many, and needs way too much focus (pun intended).

Accessibility is good. Too many tab stops for basic scenarios isn't.
Rule of thumb: Multiple adjacent elements of the same type should only have a single tab stop, reach the rest with arrow navigation. Which is good ARIA practice, too!

STR

1. `Address book > List display options > Switch to horizontal layout` 
2. Click in search field, do a random search
3. Press `Tab` as often as required to focus the first contact item in the results list

Actual result
- 6 or more `tab` keypresses needed: each column header is a tab stop
- navigation to the result list extremely inconvenient, plus the number of tabs may change depending on number of columns, so it needs more attention and it's hard to develop muscle memory

Expected
- Single tab stop at the column header which the table is currently sorted by (e.g. Name)
- ~Column header tab stop should come *after* the results list, not before (to reduce the number of keystrokes from search field to results list)~
- Then any other column headers can be focused using `arrow-right/left`

Windows Explorer certainly had a good reason for this design, try it there!

Back to Bug 1783172 Comment 0