Ckeditor5: Add keyboard support for insert table dropdown

[jodator]

While implementing insert table feature:

I've realized that it has no keyboard support defined. But I'd leave it as a followup to focus first on other missing features from MVP.

I also had some minor issues with getting this to work with FocusCycler and using <div tabindex="-1">. Also maybe I'm missing something but with current implementation of above dropdown I'd like to use methods like focus( 10 ) and focus( -10 ) to skip a whole row on arrowup and arrowdown.

[Comandeer]

Probably the slightly better approach would be to make the dimensions, located below the grid, editable. In such case keyboard would focus inputs, avoiding the whole grid. IMO it would be also more readable for screen readers.

[oleq]

Some new ideas (or just confirmation of what we came up with) in this ticket: #6765.

[dpavez14]

It seems that the best approach could be something as Comandeer suggested or just replace the grid by 2 inputs, because this way it would be accessible for other kind of input methods, as voice commands (eg. Voice Control, Voice Access).

[oleq]

or just replace the grid by 2 inputs

That would make the UI nearly useless for anyone using mouse so it's definitely a no-go. The grid is one thing and the inputs are another, and I think what @Comandeer suggested is a very good idea in this case.

[oleq]

Related #7939.

[magda-chrzescian]

_I have done some research on this and summed up the discussion below:_

Context and Problem Statement

• The UI for inserting tables should be accessible for as many input methods as possible.
• Ability to insert tables bigger than 10x10

Decision Drivers

• It is impossible to insert a table using a keyboard.
• It is impossible to insert a table using a device with a touch screen.
• It is impossible to insert a table using voice control.

Considered Options

• Extension of the current interface by adding the keyboard, touch, and voice control support
• ~Replacing the current interface with two inputs for defining the amounts of rows and columns~
• Mix of the two above: Adding the extra inputs and displaying the existing interface only on devices with the pointer support
• Making current labels editable

Decision Outcome

The 'Mix of the two above' option seems to be the most reasonable.

It would cover the need to support multiple input methods with minimal effort thanks to the additional inputs and will also keep the super fast and simple table insertion for desktop users.

Pros and Cons of the Options

Extension of the current interface by adding the keyboard, touch, and voice control support

The detailed description of this one can be found here: #6765
Plus, the touch support should include enlarging the cell size, adding an 'insert table' button for the touch screen, and adding support for at least mouseDown and mouseUp events in the editor.

👍 a pretty consistent interface on various devices,
👍 the current behavior of the interface doesn't change (comfortable for existing users)
👍 one-click table insertion for mouse users,
👍 very simple interface for keyboard users (no navigation between inputs, just ⬇️ ➡️ and enter,

⚪ sufficient support for touch devices,

❔I'm not sure how this solution would work with the screen readers,

❌ probably a huge effort to implement

Adding the extra inputs and displaying the existing interface only on devices with the pointer support

• Tab should be used for navigation between input, arrows/scroll (native) for increasing and decreasing the values.
• '+' and '-' should not be focusable.
• The existing grid should not be focusable.
• The inputs should have extra buttons if we want them to be accessible on the touch devices.
• Table is added to the editor by clicking the grid, clicking the 'insert' button, or pressing enter while one of the inputs or a button is focused.
• The sizes of the elements and hiding the grid on touch devices can be handled with interaction media features.
• For minimizing the size of the interface for most of the users, inputs would be displayed after clicking the 'more' button, or by default, if the interface was opened with the keyboard.
  

👍 relatively simple to implement,
👍 available for screen readers and voice commands,
👍 the current behavior of the interface doesn't change (comfortable for existing users)
👍 one-click table insertion for mouse users,

⚪ sufficient support for keyboard,
⚪ sufficient support for touch devices
⚪ a relatively consistent interface on various devices (differences handled with CSS only)

Making current labels editable and the grid responsive to the touch events

• the grid works with the mouse as in the current implementation,
• but you can also focus the inputs to type the dimensions
  
  
  
  • when any of the fields is focused a button appears nearby (next to or underneath) allowing to accept the dimensions and insert a new table
  
  
  • the grid could reflect/preview the numbers (geometry of the table)
  
  
• the size of the inputs must be enlarged enough to be focusable with the finger (usually ~40px),
• the first input must be auto-focused after a user opens the dropdown, so he can discover that it's editable
• there is an optional feature that can improve this interface on the touch devices - the grid can react to the touchstart and touched events to update the size of the grid instead of using regular inputs.
  

👍 relatively simple to implement,
👍 available for screen readers and voice commands,
👍 the current behavior of the interface doesn't change (comfortable for existing users)
👍 one-click table insertion for mouse users,
👍 small and simple interface,

⚪ sufficient support for keyboard,
⚪ a relatively consistent interface on various devices (differences handled with CSS only),

❌ poor support for touch devices if no touch support added to the grid (the values need to be entered with the keyboard),
❌ the button can be mistaken with the information that entered values are valid

[Reinmar]

Replacing the current interface with two inputs for defining the amounts of rows and columns

For me, the grid is very convenient for mouse users and replacing it with number inputs will be a big step back. So, to the list of cons, I'd add the fact that it would negatively affect the current UX.

[oleq]

Thanks, @magda-chrzescian for the research. 

I agree with Reinmar that the grid must stay for desktop users and for backward (UX) compatibility.

BTW: Have you considered a UX that would roughly look like this in your research?

In this approach:

• the grid works with the mouse as in the current implementation,
• but you can also focus the inputs to type the dimensions
  
  
  
  • when any of the fields is focused a button appears nearby (next to or underneath) allowing to accept the dimensions and insert a new table
  
  
  • the grid could reflect/preview the numbers (geometry of the table)
  
  

[oleq]

Also, I'd add "Ability to insert tables bigger than 10x10" to the Decision Drivers section. Maybe this is not our top priority, but let's keep it in mind.

[magda-chrzescian]

@oleq yes, I considered this option. I rejected it because of the need to support touch devices - it doesn't really look like something that can be edited and the inputs would be too small to focus properly. I proposed the +/- buttons as the extension of this idea, which would be more convenient for touch screen users.

But, after rethinking, I believe that it can be used in UI for touch devices under some conditions:

• the size of the inputs must be enlarged enough to be focusable with the finger (usually ~40px),
• the first input must be auto-focused after a user opens the dropdown, so he can discover that it's editable

And I still see a relevant inconvenience - I'm not sure if it is obvious which input reflects the number of columns and which the number of rows. It's going to be clear only after entering the value and focusing the second input (the grid also must reflect the state of the inputs).

I will summarize our thoughts and add another option to the ADR.

[magda-chrzescian]

I updated the ADR, according to our earlier conversation with @oleq.

• I updated the solution for additional inputs, so the dropdown is smaller in the default state.
• I added the proposed option with editable labels
• Removed the option, where the grid was removed completely (kept it on the list in the case we would like to go back to it)