pinafore
pinafore copied to clipboard
nolanlawson
Move keyboard focus to the text area when composing via the dedicated Compose dialog
Steps to reproduce:
- When the main timeline is in focus, hit c, or m.
Result
Keyboard focus moves to the dialog's close button.
Expected result
Keyboard focus should move to the composer text area.
In terms of usability, this makes sense to me. In terms of accessibility, it's a bit tricky, as typically the pattern is to focus the first focusable element inside of the modal when the modal is opened.
However, reading the WAI guidelines, they do say:
In all circumstances, focus moves to an element contained in the dialog.
Unless a condition where doing otherwise is advisable, focus is initially set on the first focusable element.
I'm not sure if this qualifies as "doing otherwise is advisable," but it feels reasonable to me.
From an accessibility standpoint, I think that the focus should be on the first meaningful element. In this case, we can safely assume that the user opened the modal dialog to compose a toot, rather than to close it.
I use Pinafore via a screen reader and the keyboard, and I can confirm that in 99.99% of the use cases the close button is rarely, if at all, used, especially since there exists a hotkey to achieve the same.
On mobile devices, such as iOS and Android, windows work similarly, i.e. rather than focusing the back button at the top left, when a window opens, the first control/heading element gets focus.
The specs, as you mentioned, are unfortunately quite vague on this, as a condition where doing otherwise is advisable can be interpreted in different ways. I think the initial specs did not look into the ever-changing visual practices of control functionality, that is to say, how the first control took on the role of the universal cancel/close/back function, which I believe should be an exception.
What it comes down to in the end is convenience, of course, as users would be able to compose toots faster.
On 2020. Aug 26., at 1:02, Nolan Lawson [email protected] wrote:
In terms of usability, this makes sense to me. In terms of accessibility, it's a bit tricky, as typically the pattern is to focus the first focusable element inside of the modal when the modal is opened.
However, reading the WAI guidelines https://www.w3.org/TR/wai-aria-practices/#dialog_modal, they do say:
In all circumstances, focus moves to an element contained in the dialog.
Unless a condition where doing otherwise is advisable, focus is initially set on the first focusable element.
I'm not sure if this qualifies as "doing otherwise is advisable," but it feels reasonable to me.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nolanlawson/pinafore/issues/1839#issuecomment-680310610, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLD4CAWVNBNPHYK22BVFDSCQ7G7ANCNFSM4QDKE63Q.
Going to go ahead and bump this issue, as I was just about to request it myself. One of the main reasons this is annoying is because I often times forget where focus lands, type something, and if I hit space to go to the next word, the dialog dies. Same with back space, if I need to try and delete.
