Keyboard-navigating recipient area with tab key becomes a challenge with more recipients, which is easy to address with a reduced focus ring where the details are navigated with cursor keys. STR 1. For new messages with 20+ To recipients (worse for 50+, 100+, you name it), try to add a CC-recipient using keyboard only. Current result - one tab stop on each To-recipient, need to tab 20+, 50+, or 100+ times to add CC-recipient using keyboard - number of recipients = number of tabstops (potentially unlimited) - prevents effective and predictable keyboard navigation Expected result - efficient focus ring keyboard navigation regardless of the number of recipients Proposed solution - only *one* tab stop per recipient field type (To, CC, BCC etc.) - focus first recipient in the field (no initial selection pls for error-prevention; cf. Win Explorer) - individual recipients can be efficiently and intuitively navigated with cursor keys (list-style), which will then focus and select each *subsequent* recipient (e.g. for easy copy/cut) For comparison - TB attachments list (one tab stop, then navigate many attachments with cursor keys) - Win Explorer (one tab stop in files list, then cursor for unlimited files) - FF bookmark dialog, tags list (one tab stop in the dialog, then cursor for unlimited tags) - in general, unlimited lists of items are unfit for tab key navigation
Bug 1602372 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.
After bug 440377 (recipient pills grouped by recipient type), keyboard-navigating recipient area with tab key becomes a challenge with more recipients, which is easy to address with a reduced focus ring where the details are navigated with cursor keys. STR 1. For new messages with 20+ To recipients (worse for 50+, 100+, you name it), try to add a CC-recipient using keyboard only. Current result (2019-12-06) - one tab stop on each To-recipient, need to tab 20+, 50+, or 100+ times to add CC-recipient using keyboard - number of recipients = number of tabstops (potentially unlimited) - prevents effective and predictable keyboard navigation Expected result - efficient focus ring keyboard navigation regardless of the number of recipients Proposed solution - only *one* tab stop per recipient field type (To, CC, BCC etc.) - focus first recipient in the field (no initial selection pls for error-prevention; cf. Win Explorer) - individual recipients can be efficiently and intuitively navigated with cursor keys (list-style), which will then focus and select each *subsequent* recipient (e.g. for easy copy/cut) For comparison - TB attachments list (one tab stop, then navigate many attachments with cursor keys) - Win Explorer (one tab stop in files list, then cursor for unlimited files) - FF bookmark dialog, tags list (one tab stop in the dialog, then cursor for unlimited tags) - in general, unlimited lists of items are unfit for tab key navigation
After bug 440377 (recipient pills grouped by recipient type), keyboard-navigating recipient area with tab key becomes a challenge with more recipients, which is easy to address with a reduced focus ring where the details are navigated with cursor keys. STR 1. For new messages with 20+ To recipients (worse for 50+, 100+, you name it), try to add a CC-recipient using keyboard only. Current result (2019-12-06) - one tab stop on each To-recipient, need to tab 20+, 50+, or 100+ times to add CC-recipient using keyboard - number of recipients = number of tabstops (potentially unlimited) - prevents effective and predictable keyboard navigation Expected result - efficient focus ring keyboard navigation regardless of the number of recipients Proposed solution - only *one* tab stop per recipient field type (To, CC, BCC etc.) - ~~focus first recipient in the field~~ (no initial selection pls for error-prevention; cf. Win Explorer) - text cursor focus after the last recipient (ensure it's in view), makes adding recipients easy & show the focus on field border - individual recipients can be efficiently and intuitively navigated with cursor keys (list-style), which will then focus and select each *subsequent* recipient (e.g. for easy copy/cut) For comparison - TB attachments list (one tab stop, then navigate many attachments with cursor keys) - Win Explorer (one tab stop in files list, then cursor for unlimited files) - FF bookmark dialog, tags list (one tab stop in the dialog, then cursor for unlimited tags) - in general, unlimited lists of items are unfit for tab key navigation
After bug 440377 (recipient pills grouped by recipient type), keyboard-navigating recipient area with tab key becomes a challenge with more recipients, which is easy to address with a reduced focus ring where the details are navigated with cursor keys. STR 1. For new messages with 20+ To recipients (worse for 50+, 100+, you name it), try to add a CC-recipient using keyboard only. Current result (2019-12-06) - one tab stop on each To-recipient, need to tab 20+, 50+, or 100+ times to add CC-recipient using keyboard - number of recipients = number of tabstops (potentially unlimited) - prevents effective and predictable keyboard navigation Expected result - efficient focus ring keyboard navigation regardless of the number of recipients Proposed solution - only *one* tab stop per recipient field type (To, CC, BCC etc.) - focus first recipient in the field (no initial selection pls for error-prevention; cf. Win Explorer) - OR text cursor focus after the last recipient (ensure it's in view), makes adding recipients easy & show the focus on field border - individual recipients can be efficiently and intuitively navigated with cursor keys (list-style), which will then focus and select each *subsequent* recipient (e.g. for easy copy/cut) For comparison - TB attachments list (one tab stop, then navigate many attachments with cursor keys) - Win Explorer (one tab stop in files list, then cursor for unlimited files) - FF bookmark dialog, tags list (one tab stop in the dialog, then cursor for unlimited tags) - in general, unlimited lists of items are unfit for tab key navigation