Next step for engineers: make a list of elements they can easily fix

@Mazevedo here's some thoughts on what tackle for these initial PRs for VoiceOver support. The ordering is a bit arbitrary but I tried to at least keep Part 1 simple.

Part 1 - Accessible toolbar buttons

1. Make sure notifications bell icon in badged and unbadged state on the Explore feed and Settings (when Explore is turned off via Settings > Explore feed > Explore tab toggle at bottom) has a descriptive accessibilityLabel (particularly something that indicates to the user that there are new notifications if it is in a badged state).
2. Make sure the bottom toolbar filter button and inbox buttons have good accessibilityLabels. Make sure VoiceOver indicates that they are engaged/actively filtering things if they are in their selected state (I'm not sure on the best phrasing of this, but we should say something more than just "Filters, selected").

Part 2 - Accessible cells and modals

3. T296779 would probably good to look into at this point. Currently VoiceOver highlights four different areas, when really it should only highlight the 2 big button areas with descriptive labels for "Mark as Read/Unread" and "More".
4. I think the image icons in the Notifications Cells should be exposed as accessibility elements, with descriptive labels indicating what notification type they are.
5. The project label / icon should have a good accessibility label. For example, it should read "From English Wikipedia" instead of just "EN". Make sure the other Wikimedia project icons (like a Wikidata or Commons notification) have good descriptive labels too.
6. Go through the Filters modal and navigate. Be sure each filter option reading makes sense, and that the selected / unselected state is reflected in what VoiceOver reads. Do the same for the Inbox modal screen.

Part 3 - Edit mode

7. When the screen is in edit mode, we'll want to make sure that when they navigate through each cell, indicate to the user if it's selected or not. Also indicate to the user that they need to double-tap to select. I'm guessing a bit here, it would probably be good to explore how VoiceOver reads out multiple cell selection in Mail or something similar.
8. Picking up again on T296779. You'll want to hide the swipe action elements entirely from VoiceOver if the screen is in Edit mode (isAccessibilityElement = false might help you here).
9. Be sure VoiceOver users can navigate through the Mark and Mark all as read button flows

Part 4 - Fleeting states

10. Be sure VoiceOver can properly read out the screen when the empty state appears. Sometimes when the view dramatically changes a VoiceOver screen refresh notification needs to be posted, otherwise it will read old screen data.
11. We might want to consider broadcasting some announcements. One I can think of is "Notification successfully marked as read/unread". You can post this NSNotification to make announcements. Another one to consider is "Checking for notifications." which appears in the bottom toolbar whenever the data layer is refreshing notifications.

Part 5 - Bonus stuff

12. Consider using custom actions for swipe actions
13. Consider collapsing all cell data into one contentView's accessibilityLabel for speedier navigating. Bonus Bonus would be using the more content rotor (iOS14+).

Tiny PR with part 1 https://github.com/wikimedia/wikipedia-ios/pull/4136

Update from engineering sync: I was thinking let's break off Part 2 item #6 (accessible Filters modal and Inbox modal). Those modals aren't in too bad of shape currently and should be tackled separately. We'll prioritize it after the other (non-optional) Beta must-haves.

Also partially addressed here https://github.com/wikimedia/wikipedia-ios/pull/4151

@cmadeo @OTichonova @JMinor I kicked off an experimental build (Black icon, TestFlight build 1823) with our latest work on this (making toolbar buttons and cells accessible), just in case y'all wanted an early look before waiting on our PR reviews. Note that we have not looked over the filter and inbox modals yet. Some test steps are mentioned in the PR descriptions here and here.

If you have any feedback on copy or the way this is working so far, please let us know. Thanks!

For the beta, we addressed parts 1, 2, and 3 - considering part 2 there's still a need to go over the modals to make sure they are completely accessible.

The PRs referring to this first sweep:
https://github.com/wikimedia/wikipedia-ios/pull/4136
https://github.com/wikimedia/wikipedia-ios/pull/4151

The second PR also addresses T296779

In T288776#7730862, @Tsevener wrote:

@Mazevedo here's some thoughts on what tackle for these initial PRs for VoiceOver support. The ordering is a bit arbitrary but I tried to at least keep Part 1 simple.

Part 1 - Accessible toolbar buttons

1. Make sure notifications bell icon in badged and unbadged state on the Explore feed and Settings (when Explore is turned off via Settings > Explore feed > Explore tab toggle at bottom) has a descriptive accessibilityLabel (particularly something that indicates to the user that there are new notifications if it is in a badged state).
2. Make sure the bottom toolbar filter button and inbox buttons have good accessibilityLabels. Make sure VoiceOver indicates that they are engaged/actively filtering things if they are in their selected state (I'm not sure on the best phrasing of this, but we should say something more than just "Filters, selected").

Part 2 - Accessible cells and modals

3. T296779 would probably good to look into at this point. Currently VoiceOver highlights four different areas, when really it should only highlight the 2 big button areas with descriptive labels for "Mark as Read/Unread" and "More".
4. I think the image icons in the Notifications Cells should be exposed as accessibility elements, with descriptive labels indicating what notification type they are.
5. The project label / icon should have a good accessibility label. For example, it should read "From English Wikipedia" instead of just "EN". Make sure the other Wikimedia project icons (like a Wikidata or Commons notification) have good descriptive labels too.
6. Go through the Filters modal and navigate. Be sure each filter option reading makes sense, and that the selected / unselected state is reflected in what VoiceOver reads. Do the same for the Inbox modal screen.

Part 3 - Edit mode

7. When the screen is in edit mode, we'll want to make sure that when they navigate through each cell, indicate to the user if it's selected or not. Also indicate to the user that they need to double-tap to select. I'm guessing a bit here, it would probably be good to explore how VoiceOver reads out multiple cell selection in Mail or something similar.
8. Picking up again on T296779. You'll want to hide the swipe action elements entirely from VoiceOver if the screen is in Edit mode (isAccessibilityElement = false might help you here).
9. Be sure VoiceOver users can navigate through the Mark and Mark all as read button flows

Part 4 - Fleeting states

10. Be sure VoiceOver can properly read out the screen when the empty state appears. Sometimes when the view dramatically changes a VoiceOver screen refresh notification needs to be posted, otherwise it will read old screen data.
11. We might want to consider broadcasting some announcements. One I can think of is "Notification successfully marked as read/unread". You can post this NSNotification to make announcements. Another one to consider is "Checking for notifications." which appears in the bottom toolbar whenever the data layer is refreshing notifications.

Part 5 - Bonus stuff

12. Consider using custom actions for swipe actions
13. Consider collapsing all cell data into one contentView's accessibilityLabel for speedier navigating. Bonus Bonus would be using the more content rotor (iOS14+).

Seems to be working well for me on 6.9.0 (1910)