Accessibility Questions - (using Anki if you need to use Assistive Technology like screen readers)

Hi. I love this app and recently used it to pass a citizenship test! Thanks!

I have some blind friends I was telling about Anki (and the mobile App) and they wanted to use it.

I tried helping them to use my copy on iPhone using Apple VoiceOver and the support is not at the level I would like it to be to recommend they buy it.

There are parts of the app that you can’t navigate into and out of at all, and using the core study function of reading the front, reading the back and rating the answer is not a smooth experience at all.

Are there some guides or resources for using Anki if you are blind, on any platform?

Would you want me to file issues here for issues that make using Anki app difficult when using assistive technologies such as Voiceover?

I am unaware of such resources, although I have found an old thread about this same topic. The conclusion was that indeed Anki Mobile and Anki Desktop were not fully accessible to blind people, although @DoctorToBeIn23 seemed positive it is possible to make it accessible (talking about Anki Mobile).

That was also the conclusion of the main Anki developer, in that thread.

I think it would be a great idea to put all the required modifications to enhance Anki’s accessibility in one place, and since I have the impression this has been done nowhere else, this is a good place to start!

Issue: iOS 15.4 / iPhone 12 / Anki 20.83
Location: Review Screen

Pressing the Gear Icon shows a modal.

This modal has multiple interaction problems:

  1. Two finger Scrub (aka Back) does NOT close the modal. In fact, it’s not possible to exit the modal at all in VoiceOver mode. Probably this sheet should capture the sheet Cancel action and respond to it. (I’m not familiar with this API)
  2. Two finger scrub (aka Back) is sent to the view Underneath the modal. This is a common problem and means the modal sheet view should be marked with accessibilityViewIsModal or equivalent.

References:

Dismiss an alert or return to the previous screen
Two-finger scrub (move two fingers back and forth three times quickly, making a “z”)

var accessibilityViewIsModal: Bool { get set }
The default value for this property is false . When the value of this property is true , VoiceOver ignores the accessibility elements within the sibling views of the receiving view.
For example, in a window that contains sibling views A and B, setting accessibilityViewIsModal to true on view B causes VoiceOver to ignore the accessibility elements in view A. However, if view B contains a child view C and you set accessibilityViewIsModal to true on view C, VoiceOver does not ignore the accessibility elements in view A.

1 Like

Suggestion: iOS 15.4 / iPhone 12 / Anki 20.83
Location: Review Screen

In review mode, on the front side of the card, the whole reading surface is effectively a hidden but un-named button for voiceover.

This is not a familiar paradigm for blind users. While this behavior can be learned, it might be good to have the option to add an explicit named button “reveal answer” or similar in the bottom bar, like on the desktop app.

This would be easy and familiar for a blind person to find on iOS in voiceover mode by sliding a finger along the bottom of the screen, and be more clear than the “hidden” and un-named interaction that’s everywhere.

This would also be good because it would help orient the user who can learn to understand that they are on the front side vs the back (vs the deck screen) by the set of buttons available.

1 Like

Issue: iOS 15.4 / iPhone 12 / Anki 20.83
Location: Review Screen

The front side and back side screens are not labeled as such and might be hard to distinguish for the blind user.

The sighted user can quickly scan the card to look for familiar cues but that’s harder for the blind user to do easily.

I suggest adding an accessibility title “front side” and “back side” to these cards.

This need not be visible on-screen.

The new element should be the first thing focused (accessibility focus) when a new card is revealed.

1 Like

Suggestion: iOS 15.4 / iPhone 12 / Anki 20.83
Location: Review Screen

I saw you support gamepads. That’s an amazing accessibility feature just by itself

I strongly suggest you also support rotors!

What’s a rotor? A rotor is a quick way to access a menu of common actions for the page or currently selected items. It’s like right click for voiceover. When a specific rotor is selected, swiping up and down moves through the rotors commands and double tap activates it.

By adding an action rotor that just contains the most important elements for each side and card you could drastically improve accessibility usability.

Eg: back of card: again, hard, good, easy, show front
Eg: front of card; reveal, undo, bury

The implementation would be basically the same as for gamepad and gestures that already exist in your app

Note: while gestures sound like they would be good for voiceover accessibility users, they are typically not available because voiceover takes over screen taps and swipes for its own interactions!

Here’s a video explaining how to add them:

Here’s an article about rotors

I suggest adding a new rotor called actions or anki that contains actions that make sense on this side of the card, such as

Reveal, go back, bury.

Additional rotors for less frequently used actions eg edits could be added also

Thanks for the detailed feedback Alex, I’ll look into this further when I get a chance.

1 Like

Suggestion: iPhone 12, iOS 15.4, Anki 20.83

Use accessibility default focus to prioritize content

Initial Focus should be on the content

Currently, when a new front or back of card is revealed, the first thing the blind user hears is:

“Button” and the focus is on the gear icon near the bottom of the oage

OR

“Decks, button” and the focus is in the top toolbar

This is hard to understand, and does not deliver the most relevant content, which would ideally be the question or the answer (and a label to say which of front/question or back/answer it is, as stated elsewhere)

expected:, I suggest that accessibility focus should begin in the card content area, on the first bit of text. It should first read a label describing the context, and then immediately read the first line of the content area.

For a good example, see how mail messages are read: after opening a message in apples mail app, voiceover reads:

Mail” // only if I’m switching into mail app RN
Message content” // describes where we are in the view and what the content is of
Hey alex” // starts reading the content-it has skipped the from, to, cc and subject: they can be accessed as desired later. I know I can swipe right to hear the next bit of content
Actions available” // I know I can swipe up and down and double tap to find and execute actions like reply, flag, activate

Screenshot of mail app showing message interface with first content highlighted with voiceover cursor and subtitles showing what voiceover is speaking:

screenshot of Anki app showing front of card interface with first toolbar button highlighted with voiceover cursor and subtitles showing what voiceover is speaking

Thank you Dae for your wonderful app.

I look forward to any improvements you have time to make.

Do you mainly code the app in swift, objective-c or web technologies?

I know accessibility techniques and APIs vary across these platforms, and if I need to add notes on preferred APIs for voiceover it would be helpful to know.

The UI is a combination of Swift and webviews. The main review area is a webview - does iOS provide a way for webviews to indicate the initial focus?

The tts function works very well if coded in the card template. However not sure about navigating the application.

1 Like

I spent some time the other day digging into this without success unfortunately. accessibilityViewIsModal did not help with leaving the tools screen, though we shouldn’t be guiding the user there in the first place. I didn’t have any luck trying to get iOS to focus on the card content by default either, and VoiceOver seems to skip over card content when the content is updated on card transition. I tried various things to get the focus away from the tools button, but did not have any luck there either. It remains on the todo list to take another stab at when I have a chance, but even with some quality of life fixes, the app is probably going to require someone to assist with initial setup.

1 Like