[A11y] Add labels for different screens for Talkback reader

[rt4914]

When Talkback is on, whenever we click on any option which leads to new screen the reader will automatically read the label associated with that screen first. If in case label in not present then it will read app name i.e. Oppia.

We need correct labels for following screens:

• Onboarding Flow → Onboarding Flow
• Profile Chooser Screen → Profile selection page
• Admin Add Pin → Authorize to add profiles
• Admin Auth (when clicked on Add Profiles) → Authorize to add profiles
• Admin Auth (when clicked on Admin Controls) → Authorize to access Administrator Controls
• Pin Verification → PIN verification
• Add Profile →Add Profile
• Topic Page → Topic Page
• Story Screen / Chapter List → Chapter List
• Revision Card → Skill Page
• Question Player → Practice Mode
• Concept Card → Concept Card
• Exploration Player → Exploration Player
• Hints & Solution Screen → Hints and Solution
• Profile Progress → Profile
• Topics in Progress → Topics in Progress
• Stories Completed →Stories Completed
• Options Screen → Options
• Reading Text Size →Reading Text Size
• Default App / Audio Language →Default Audio Language / App language
• FAQ List → FAQs (Frequently Asked Questions)
• FAQ Single → FAQs (Frequently Asked Questions)
• Help →Help
• App Version → App Version
• Profile List →Profile List
• Profile Edit Screen → <Profile_name>
• Rename Profile → Rename Profile
• Reset Profile PIN →Reset PIN
• Stories for you or Recently Played Screen → Whatever is shown in toolbar/actionbar Approved (This will need slightly bigger changes to code.)

In general if there is a static/fixed Title for the screen, we use that as label. And if there is dynamic title then we need a static label which will not be shown on screen but will be read by the talkback.

Example

device-2021-02-24-021647.mp4

In this above video as soon as we double-tap Battery, new screen is opened.
The reader first outputs Battery followed by Navigate up, Button and finally Battery again. In this the first Battery output is the label of this new screen which indicates the learner which screen is opened. The second Battery is because we selected the title in the screen and it's just reading that text.
So we need labels for various screens general which matches the title but if the title is dynamic then we need static label.

Note: The above list can change as and when we find more such issues.

[Arjupta]

@rt4914 the links provided in the description point to this same issue

[rt4914]

@Arjupta This issue is not finished yet. I will add more information to this soon.

[rt4914]

@mschanteltc You can directly edit the description to edit and approve things.

[mschanteltc]

I updated the original post and have questions/comments for the following:

• Onboarding Flow: Does this need to have a label even though there is no heading or label that reads "Onboarding Flow"?
• Admin Auth: For these pages, my concern is that if we label them to be "Admin Authorization", it might confuse the users who tapped on it with the intention of creating a new profile. I believe that we should leave the headings as is since the body text describes why a PIN is needed before moving on to creating a new profile. WDYT?
• Topic Page, Story/Chapter List, and Revision Card should be specifically named whatever Topic/Story/Revision it is based on. Would there be any issues with this?
• FAQs should also be read out as 'Frequently Asked Questions' for users who may not understand its abbreviated version

[rt4914]

I updated the original post and have questions/comments for the following:

• Onboarding Flow: Does this need to have a label even though there is no heading or label that reads "Onboarding Flow"?

If we do not introduce any label it will output Oppia by default. We can mention any thing in label like Onboarding process started, etc.

• Admin Auth: For these pages, my concern is that if we label them to be "Admin Authorization", it might confuse the users who tapped on it with the intention of creating a new profile. I believe that we should leave the headings as is since the body text describes why a PIN is needed before moving on to creating a new profile. WDYT?

Same for this too. If we do not add label it will output Oppia by default. Does this make sense: Authorize to add profiles and Authorize to access Administrator Controls ?

• Topic Page, Story/Chapter List, and Revision Card should be specifically named whatever Topic/Story/Revision it is based on. Would there be any issues with this?

Do you mean that we should label it as Matthew Goes to Bakery or Fractions of a Group? It is doable but I will need confirmation about the technical solution from Ben.
Otherwise as per Ben suggestions in one of the PRs: we can also use Topic page, Chapter List and Subtopic page as static labels for these screens. WDYT?

• FAQs should also be read out as 'Frequently Asked Questions' for users who may not understand its abbreviated version

So the output should be FAQs Frequently Asked Questions or just Frequently Asked Questions ?

[mschanteltc]

I updated the original post and have questions/comments for the following:

• Onboarding Flow: Does this need to have a label even though there is no heading or label that reads "Onboarding Flow"?

If we do not introduce any label it will output Oppia by default. We can mention any thing in label like Onboarding process started, etc.

I see, let's stick with "Onboarding Flow" then. I approved this in the original post.

• Admin Auth: For these pages, my concern is that if we label them to be "Admin Authorization", it might confuse the users who tapped on it with the intention of creating a new profile. I believe that we should leave the headings as is since the body text describes why a PIN is needed before moving on to creating a new profile. WDYT?

Same for this too. If we do not add label it will output Oppia by default. Does this make sense: Authorize to add profiles and Authorize to access Administrator Controls ?

Yes those would work better. Would there be any issues since the heading does not match with the Talkback description?

• Topic Page, Story/Chapter List, and Revision Card should be specifically named whatever Topic/Story/Revision it is based on. Would there be any issues with this?

Do you mean that we should label it as Matthew Goes to Bakery or Fractions of a Group? It is doable but I will need confirmation about the technical solution from Ben.
Otherwise as per Ben suggestions in one of the PRs: we can also use Topic page, Chapter List and Subtopic page as static labels for these screens. WDYT?

I'm opened to doing a combination of both. So for example, "Topic page: Decimals". This gives a description on what kind of page it is and specifics on what the page is about.

• FAQs should also be read out as 'Frequently Asked Questions' for users who may not understand its abbreviated version

So the output should be FAQs Frequently Asked Questions or just Frequently Asked Questions ?

Let's do FAQs (Frequently Asked Questions) if possible.

[rt4914]

I updated the original post and have questions/comments for the following:

• Onboarding Flow: Does this need to have a label even though there is no heading or label that reads "Onboarding Flow"?

If we do not introduce any label it will output Oppia by default. We can mention any thing in label like Onboarding process started, etc.

I see, let's stick with "Onboarding Flow" then. I approved this in the original post.

Thanks.

• Admin Auth: For these pages, my concern is that if we label them to be "Admin Authorization", it might confuse the users who tapped on it with the intention of creating a new profile. I believe that we should leave the headings as is since the body text describes why a PIN is needed before moving on to creating a new profile. WDYT?

Same for this too. If we do not add label it will output Oppia by default. Does this make sense: Authorize to add profiles and Authorize to access Administrator Controls ?

Yes those would work better. Would there be any issues since the heading does not match with the Talkback description?

No. Its completely fine to have label and title different.

• Topic Page, Story/Chapter List, and Revision Card should be specifically named whatever Topic/Story/Revision it is based on. Would there be any issues with this?

Do you mean that we should label it as Matthew Goes to Bakery or Fractions of a Group? It is doable but I will need confirmation about the technical solution from Ben.
Otherwise as per Ben suggestions in one of the PRs: we can also use Topic page, Chapter List and Subtopic page as static labels for these screens. WDYT?

I'm opened to doing a combination of both. So for example, "Topic page: Decimals". This gives a description on what kind of page it is and specifics on what the page is about.

Okay. Then in this case I will clarify one thing with Ben.
@BenHenning For dynamic title we need static labels or the labels should be ready in advances because we cannot wait for loading of data. So to do that I have one solution. When learner clicks on Topic Card on home screen we already have topic name available. We can send this topic name to TopicActivity and can set label from their programmatically. There are two issue with this: (a.) AndroidManifest.xml file will not contain label attribute as a result (b.) the Static Check that we were planning to do for labels won't work in such cases. WDYT?

• FAQs should also be read out as 'Frequently Asked Questions' for users who may not understand its abbreviated version

So the output should be FAQs Frequently Asked Questions or just Frequently Asked Questions ?

Let's do FAQs (Frequently Asked Questions) if possible.

Sounds good. Thanks.

[rt4914]

@mschanteltc Can you update the description for 4 pending items Admin Auth (2), Pin Verification and Add Profile ?

[mschanteltc]

@mschanteltc Can you update the description for 4 pending items Admin Auth (2), Pin Verification and Add Profile ?

Updated.

[BenHenning]

@mschanteltc one concern I have around making the topic/story/etc. activities dynamic is we're now introducing redundancy for screenreader users. They will be hearing the topic title twice: once for the activity label, and second when they swipe through the toolbar. What benefit do we gain from having this redundancy? In general, I think we should aim to reduce the amount of information we need to convey so that it's easier to use the UI. WDYT?

Edit: well it seems that this is actually standard (e.g. to have the toolbar title & activity label in-sync). However, I'm still leaning toward having static labels for all activities even if the toolbar is dynamic, especially since dynamic titles are probably longer to read out which means the redundancy is more noticeable in those cases.

[mschanteltc]

@mschanteltc one concern I have around making the topic/story/etc. activities dynamic is we're now introducing redundancy for screenreader users. They will be hearing the topic title twice: once for the activity label, and second when they swipe through the toolbar. What benefit do we gain from having this redundancy? In general, I think we should aim to reduce the amount of information we need to convey so that it's easier to use the UI. WDYT?

Edit: well it seems that this is actually standard (e.g. to have the toolbar title & activity label in-sync). However, I'm still leaning toward having static labels for all activities even if the toolbar is dynamic, especially since dynamic titles are probably longer to read out which means the redundancy is more noticeable in those cases.

Thanks for your input Ben! I think as long as the Topic/Story/Revision names are mentioned at some point, we can use the static labels so we can eliminate the redundancies like you mentioned. Should I go ahead and edit the post to reflect this?

[rt4914]

@mschanteltc one concern I have around making the topic/story/etc. activities dynamic is we're now introducing redundancy for screenreader users. They will be hearing the topic title twice: once for the activity label, and second when they swipe through the toolbar. What benefit do we gain from having this redundancy? In general, I think we should aim to reduce the amount of information we need to convey so that it's easier to use the UI. WDYT?
Edit: well it seems that this is actually standard (e.g. to have the toolbar title & activity label in-sync). However, I'm still leaning toward having static labels for all activities even if the toolbar is dynamic, especially since dynamic titles are probably longer to read out which means the redundancy is more noticeable in those cases.

Thanks for your input Ben! I think as long as the Topic/Story/Revision names are mentioned at some point, we can use the static labels so we can eliminate the redundancies like you mentioned. Should I go ahead and edit the post to reflect this?

@mschanteltc Yes, you can edit the description and add correct labels to reflect correct labels.

[mschanteltc]

Updated. One last thing that is PENDING is the Revision Card which was originally Subtopic Page. However since "Subtopic" is not a term used in the app and is commonly replaced with "Skill", Skill Page is used instead. WDYT?

[rt4914]

Updated. One last thing that is PENDING is the Revision Card which was originally Subtopic Page. However since "Subtopic" is not a term used in the app and is commonly replaced with "Skill", Skill Page is used instead. WDYT?

@mschanteltc Makes sense. I am updating the description.

[rt4914]

Closing this issue as it has been broken down into following issues:
#2804 #2805 #2806 #2807 #2808 #2809 #2810 #2811 #2812 #2813 #2814 #2815 #2816 #2817 #2818 #2819 #2820 #2821 #2822 #2823 #2824 #2825 #2826