Check for basic usability with screen reader

[gnprice]

We should try out the app with iOS's VoiceOver and/or Android's TalkBack, and make sure it's possible to do the essentials to be able to use the app at all:

• log in
• get between the different top-level pages (Inbox, All messages, Subscribed streams, Direct messages)
• use each of those to get to a relevant message list
• read the messages
• send a message

If there's anything that doesn't work, we should file and triage an issue for that so we can fix it. Use the a-a11y label so that it's easy to find the list of them.

Generally the fixes will involve Flutter's Semantics widget and related parts of the Flutter API, to provide the appropriate semantic information for screen readers (like VoiceOver and TalkBack) and other assistive technology to use.

How to approach this issue

See my discussion in zulip/zulip-mobile#4394 about how to start learning to use these systems and to evaluate the app with them.

Not in scope

This issue is milestoned "Launch". Out of scope for this issue is to do any more comprehensive review of the rest of the app's features: reactions, less-common message content features, action sheets, lightbox, compose typeaheads, etc., etc. Those features are also important, and are covered by the companion issue #537, which has the "Post-launch" milestone.

The current state in zulip-mobile — the last I looked, which I see was three years ago — is described in zulip/zulip-mobile#4394: the app basically works, but there are a long list of glitches. We did fix the two issues highlighted as most important (in zulip/zulip-mobile#4232) by an organization with some people who actually use screen readers regularly; but we don't really know how usable the app is for such users.

[MINEGHOST007]

I would like to work on this issue I'll be able to provide screenshots and recordings for Android TalkBack .

[gnprice]

Sure, please go ahead.

Recordings will be a helpful bonus, but please also include transcriptions, along with those screenshots for context. The transcriptions will help make it easy for others to review your findings.

For detailed discussion, please start a chat thread on chat.zulip.org in #mobile-dev-help. (Zulip makes a better medium for discussion than GitHub does.) Then after we have some concrete findings we're confident in, we can post those here on this issue thread, keeping this thread easy to read.

[AshutoshKhadse23]

Hello @gnprice ,
Is someone working on it already if not then I would like to work on it ?
I seen the comment but unable to find the updates on that CZO and here.

[gnprice]

To find chat threads related to a particular issue or PR, I recommend searching for the issue or PR's name as recognized by the chat.zulip.org linkifiers: so for this issue, "F535". That finds this thread: #mobile-team > #F535 Android TalkBack Testing @ 💬

I think this is an issue that would benefit from multiple people working on it independently, though. So @AshutoshKhadse23 please go ahead with your own investigation. If you're able to test the behavior on iOS with VoiceOver, that would be especially helpful (because @MINEGHOST007's testing was on Android with TalkBack); but if not, a second independent test on Android is also useful.

[PIG208]

This is a more boiled-down version of #537 (comment) containing things that I found more relevant for early post-launch:

• The home page bottom tabs do not have labels. The caption for each of them is just: "button, double tap to activate".
• The "----OR-----" separator on the login page might need a caption that elaborates on what it means. Without a visual cue, it is a bit abrupt as a single word. (Note, by navigating the third-party sign-in sites, we can compare those pages' accessibility with ours quite conveniently.) Trying it on GitHub, there is an invisible element right after the "sign in" button! It reads "password log-in alternatives", and the option after it is "sign in with a passkey".
• The loading screen/loading indicator cannot get focused. There should at least be some way to tell if the page is loading.
• Message content navigation appears out of order when the message contains links.
• Headers should be marked as such. This includes recipient headers in the message list and the collapsible channel headings on the inbox page. This is probably quite important for the inbox page, since there can be difficulty telling channel and topic items apart.
• Navigating backwards (to older messages) does not work smoothly. Sometimes the focus can get moved to the sticky header instead of the previous message; sometimes the focus moves off-screen or behind the sticky header, instead of automatically scrolled. For reference on the correct behavior, see what happens when you are about to navigate to a channel item on the channels page off-screen.
• Autocomplete options not disappearing after the keyboard is collapsed might obstruct the message list, and the user might not be aware of that. This is Autocomplete results persist after hiding keyboard, on Android #1098.