ankidroid
TalkBack Accessibility Improvement Umbrella Tracker
This is an umbrella improvement issue to track TalkBack improvements in AnkiDroid.
We would love any help taking specific items from this and implementing them!
To keep things organized the issue itself will be edited as things are defined and tracked
Comments will just be used for discussion not actual tracking.
This was prompted by an email to the support list from Rod Maccoux:
You can turn TalkBack on and off. Talkback can be found under settings/accessibility. While testing, you can suspend and unsuspend TalkBack by holding down the volume up and volume down buttons simultaneously.
Talkback gestures that you will likely use are:
- Double Tap with one finger to simulate tapping on an icon.
- Flick or swipe with one finger to move forward or backward through the screen’s contents.
- Or, you can just explore the screen’s contents by moving your finger around on the screen.
- Use two fingers to scroll.
Following are some ideas to look at in order to improve accessibility with TalkBack.
- Any data element including buttons that a person with vision would like to view, should have the attribute android:focusable="true" so that TalkBack can speak the data contents.
- If a button is a graphic, and not a button with a text label the button should attach the parameter
- android.contentDescription = "button description" (exclude the word button) to the graphic’s attributes. TalkBack will add the word “button” to the button’s description.
- All icons should have textual labels assigned to them.
Hi @david-allison-1, Can you tell me more about the issue? Like, when the user enables TalkBack, then we need to track his/her movements with ankidroid.
It'd be useful to pick one of the 4 issues defined in the original post, break it off into a separate GitHub 'issue' and solve it.
If you haven't used TalkBack before, the first step would be to download both the app (and use the tutorial) and download the TalkBack code samples from Google.
It integrates with AnkiDroid already, we don't need to handle detecting swipes, but we do need to define the UI flows which would make sense while using TalkBack (for example: the order of navigation), especially focusing on the accessibility of the main screen of the app: the Reviewer.
If I pick up the first issue, then if a user is pressing any button and data elements, then TalkBack should speak its contents.
Hi @david-allison-1, Do I need to label charts in the statistic tab? If yes, then what should be on the label?
Preface: I don't know exactly. Haven't found Android-specific guidelines.
We'll likely want to leave this for later as it'll be a large task (and Statistics will be getting changed in AnkiDroid 2.16).
One guideline that I read suggested that it would be best to provide this data in a tabular format for accessibility. This seems like a sensible solution, but is a lot of work.
For non-text content that is not covered by one of the other situations listed below, such as charts, diagrams, audio recordings, pictures, and animations, text alternatives can make the same information available in a form that can be rendered through any modality (for example, visual, auditory or tactile). Short and long text alternatives can be used as needed to convey the information in the non-text content.
A bar chart compares how many widgets were sold in June, July, and August. The short label says, "Figure one - Sales in June, July and August." The longer description identifies the type of chart, provides a high-level summary of the data, trends and implications comparable to those available from the chart. Where possible and practical, the actual data is provided in a table.
https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html
Also food for thought: https://accessibility.psu.edu/images/charts/
Just a note that a blind user asked on the mailing list how to get Talkback working with AnkIDroid and all I could do was point here, where there has not been much progress. I have not personally had time and no one else has either, but I wanted to at least mention that there is interest in this.
@sujjethog-ops I've already assigned an issue to you, best to take one at a time
@david-allison Could I be assigned the issue? It may take me a week or so to find all the buttons and accordingly change them so I'll do it in a single pr by then.
@ShaanNarendran thanks!!!! Go for it, given there's a lot, don't wait to be assigned.
I'd split the work into one commit per screen/file and submit a minimum of one PR per day. Ideally favouring more, but smaller PRs. Especially splitting out controversial/questionable commits into a separate PR.
Anything larger than that would be a nightmare to review, and demotivating for you with the back and forth needed. Incremental improvement is great here.
When you start, list how you're going to be verifying that the changes are representative of what would appear on an actual screen reader
You may also want to keep track of your progress publicly, so others can follow your methodology if you decide to move to other issues
@ShaanNarendran thanks!!!! Go for it, given there's a lot, don't wait to be assigned.
I'd split the work into one commit per screen/file and submit a minimum of one PR per day. Ideally favouring more, but smaller PRs. Especially splitting out controversial/questionable commits into a separate PR.
Anything larger than that would be a nightmare to review, and demotivating for you with the back and forth needed. Incremental improvement is great here.
When you start, list how you're going to be verifying that the changes are representative of what would appear on an actual screen reader
You may also want to keep track of your progress publicly, so others can follow your methodology if you decide to move to other issues
Okk, this is fine by me, I will probably try to do 2 or 3 tomorrow and then 1 a day till friday since I have finals that day. I'll do my best to keep it as easy to review as possible, just one question: "When you start, list how you're going to be verifying that the changes are representative of what would appear on an actual screen reader", how should I go about this?
"When you start, list how you're going to be verifying that the changes are representative of what would appear on an actual screen reader", how should I go about this?
I don't know currently. There'll be a research step involved on your side to do this.
PS: Please focus on your finals. Education was SO important to the path I took in life, and I want to be sure you're making the most of this.
"When you start, list how you're going to be verifying that the changes are representative of what would appear on an actual screen reader", how should I go about this?
I don't know currently. There'll be a research step involved on your side to do this.
PS: Please focus on your finals. Education was SO important to the path I took in life, and I want to be sure you're making the most of this.
I'll definitely do my best to record whatever changes I make, I'd love to make the app more accessible. About the exams, I really appreciate the advice, makes me feel a lot better having guidance like this. Initially, I had thought this was going to be more of a chore but it's become super fun and addicting but I always do my best for exams to keep up grades so yeah. But, anyways I'll keep updating the issue with PRs !