Inline proposals needs accessibility love

[hediet]

Feedback from @isidorn:

Here are some suggestion on how to improve the accessibility of the inline propsals:

1. Once you are on an inline proposal pressing Ctrl + K, Ctrl + I, triggers the hover and moves focus into it -> very cool. However it would be nice if the left and right keybindings would move focus inside the hover on the actions. So that keyboard users can easily trigger the hover and use left and right to move the suggestion.
2. Bonus on top of that when Ctrl + K, Ctrl + I is triggered we should remember the previously focused element so it is focused again
3. Once an inline suggestion is shown we should probably use an aria alert to notify the user. Something like: suggestion: CONTENT. This is not the best experience but I think might be a good start. We do a similar things for parameter hints

Once we polish this a bit and there is a public way to try this out we should definitely share it with our a11y community to get better feedback.

[hediet]

I'm moving this to next milestone.

Accessibility is important to me, but the actions are already focusable if "Tab Moves Focus" and "Screen Reader Optimized" are enabled.
I have to admit though, that tabbing through all the actions every time is inconvenient.

However, all those actions already have their own shortcut (which can be triggered even if the hover is not shown). So once you tab through them and the shortcut is read, there is already a more convenient way to access those actions than using the arrow keys.

What do you think, @isidorn?

[isidorn]

All good points. And of course doing this in the next milestone is perfectly fine.

I think users will have to learn those shortcuts and when they do they will no longer need to focus on the inline proposals hover.
However in order to learn them they should still be able to nicely focus on the hover initially.

So from my above I think that 1. would still be great to have!
3. we need either way in order for the proposals to be read out.

So bottom line while I agree with you, I think your points do not contradict the original suggestion.
Though I agree that 2. is less important (since users will probably remember shortcut and not refocus the hover that often)

[hediet]

For 1., there is #130562 as a general feature request for all hovers.

Regarding 2, I think the focus should not be restored to the element that had focus the last time - otherwise, screenreaders might not catch up relevant text at the beginning of the hover.

For 3, see #130565.
A pull approach has been implemented as fix for #129677.