Issue with tab: it's already used as a standard editing shortcut. It changes indentation in lists, and moves in tables. This is pretty standardized across editors, so using it would probably break user-expectations. We should maybe look into how other places handle an equivalent movement (e.g. Google docs moving from the document to a comment?).

Considerations:

• For most checks we probably don't want to automatically move focus from the document to the check, as checks can appear instantly as you are typing
• TAB is bound to some other actions depending on context, for example increasing list indentation or navigating through a table
• For this reason we use ctrl+shift+enter to move focus to the context (e.g. the link context shown when you click on a link), although this is only documented in the keyboard shortcuts dialog (ctrl+?)

El T394473#10929040, @DLynch escribió:

Issue with tab: it's already used as a standard editing shortcut. It changes indentation in lists, and moves in tables. This is pretty standardized across editors, so using it would probably break user-expectations. We should maybe look into how other places handle an equivalent movement (e.g. Google docs moving from the document to a comment?).

Google Docs uses the Tab key for tabbing text in the document. However, in our case, the Tab key is not used for tabbing. If the cursor is placed in the text and an Edit Check is displayed, why not use` Tab` to automatically move the focus to the first interactive element in the Check?

If we cannot use the Tab key to shift focus from the text to the Edit Check’s interactive elements, an alternative solution could be to automatically move the focus to the first action (such as the “Revise” button) when the Edit Check appears. This would allow users to immediately interact with the Edit Check to solve/decline it. Once the user solves/declines it, the focus would return to the text area so that they can continue editing. In case the user wants to return to the text while the focus is within the Check, they could use Esc to leave/close that Check.

Wdyt?

In T394473#10931415, @bmartinezcalvo wrote:

El T394473#10929040, @DLynch escribió:

Issue with tab: it's already used as a standard editing shortcut. It changes indentation in lists, and moves in tables. This is pretty standardized across editors, so using it would probably break user-expectations. We should maybe look into how other places handle an equivalent movement (e.g. Google docs moving from the document to a comment?).

Google Docs uses the Tab key for tabbing text in the document. However, in our case, the Tab key is not used for tabbing. If the cursor is placed in the text and an Edit Check is displayed, why not use` Tab` to automatically move the focus to the first interactive element in the Check?

Because "TAB is bound to some other actions depending on context, for example increasing list indentation or navigating through a table" - so when your cursor is in a list or a table, it is unclear what action tab would take.

If we cannot use the Tab key to shift focus from the text to the Edit Check’s interactive elements, an alternative solution could be to automatically move the focus to the first action (such as the “Revise” button) when the Edit Check appears.

We should never steal focus from the surface if the user is just typing text (both on desktop and mobile) and this can be a very frustrating user experience - if they aren't looking at the screen it will start swallowing characters, or they could start taking actions they didn't intend (e.g. pressing space or enter will cause a button to get pressed).

After some conversations about this, it seems that the best solution for now would be to use Command + Shift + Enter to move the focus to the Edit Check, as in the rest of the contextual popups. Should we move forward and implement this solution for now?