Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessibility considerations for the Composer and Autocomplete #11075

Closed
t3chguy opened this issue Oct 7, 2019 · 5 comments
Closed

Accessibility considerations for the Composer and Autocomplete #11075

t3chguy opened this issue Oct 7, 2019 · 5 comments
Labels

Comments

@t3chguy
Copy link
Member

t3chguy commented Oct 7, 2019

Prior to recent changes the autocomplete has not been whatsoever screen-reader accessible, whilst it is now a lot better, keyboard accessibility of the composer remains a big problem and it seems to compete with its choice of function.

The composer locks the focus to itself, there is no way, using TAB, to get out of it.
There used to a be a feature where TAB on composer without any autocomplete suggestions would complete the latest user having spoken (#4770), but this means that TAB is always hijacked and it is no longer possible to leave the composer. Now that the composer gets automatically focused on any unhandled text input anywhere on the app I think this should be scrapped, and instead @TAB result in mentioning the latest user.

Using TAB for navigation of the autocomplete is still different to competitors such as Slack, where TAB selects the completion but this should not ruin accessibility entirely like disallowing TAB when there are no possible completions.

@t3chguy
Copy link
Member Author

t3chguy commented Oct 8, 2019

Further, learning from Slack, they do not put the completion into the composer until it is confirmed, which means that as soon as the completion pane comes up, the first one can be selected and thusly read out by the screen reader as a notion of showing the autocomplete has shown up (#11011)

@lampholder
Copy link
Member

We discussed this in the product sync, and decided that an easy, noncontroversial decision was that tabbing in an empty composer should escape you from the composer to navigate around the rest of the app.

Otherwise, people use typing-the-first-three-characters-of-somebody's-name-then-pressing-tab-to-autocomplete-them, which would be very annoying to tab out of the composer if the autocomplete happened not to match a room member, so we weren't able to make a decision to make more invasive changes to composer/autocomplete at this stage.

How does that osund?

@t3chguy
Copy link
Member Author

t3chguy commented Oct 8, 2019

Tabbing in an empty composer is a step forward for sure, but what about someone mid-way through a message who wants to send an image before their message or to refer back to a message in the timeline

@t3chguy
Copy link
Member Author

t3chguy commented Oct 22, 2019

Well, Riot is the only one with an autocomplete that works like this, and it irritates me each time I use it and have to remember to use Space, where all other autocompletes I know (Pinafore, Twitter, Slack, IRCCloud, Gmail, and others) use tab to autocomplete. 😉 And I think, this mirrors most mainstream, non-Riot-dev, user expectations.

- Marco Zehe

@t3chguy
Copy link
Member Author

t3chguy commented Nov 1, 2019

Closing in favour of #11071

@t3chguy t3chguy closed this as completed Nov 1, 2019
@jryans jryans added A11y and removed I18n labels Mar 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants