Wordpress-android: Accessiblity : Reader Improvements - Main Issue

[jd-alexander]

The following is a list of opportunities to improve the accessibility of Reader. Will be breaking these down into smaller issues once the discussions are had so they can be addressed using smaller PRs.

Settings (Tags & Sites)

Main Settings Container For Tabs

Accessibility Scanner Audit

• Followed Sites Tab - Text contrast

  The item's text contrast ratio is 2.04. This ratio is based on an estimated foreground color of #3895BA and an estimated background color of #006088. Consider increasing this item's text contrast ratio to 3.00 or greater.

• Sites You May Like Tab - Text contrast

  The item's text contrast ratio is 2.04. This ratio is based on an estimated foreground color of #3895BA and an estimated background color of #006088. Consider increasing this item's text contrast ratio to 3.00 or greater.

• Remove Button org.wordpress.android:id/btn_remove - Touch target

  This item's size is 32dp x 32dp. Consider making this touch target 48dp wide and 48dp high or larger.

• Add URL or Tag EditText org.wordpress.android:id/edit_add - Touch target

  This item's height is 38dp. Consider making the height of this touch target 48dp or larger.

• Add Button org.wordpress.android:id/btn_add - Touch target

  This item's size is 32dp x 32dp. Consider making this touch target 48dp wide and 48dp high or larger.

• Add URL or Tag EditText org.wordpress.android:id/edit_add - Text contrast

  The item's text contrast ratio is 4.20. This ratio is based on an estimated foreground color of #787C82 and an estimated background color of #FFFFFF. Consider using a contrast ratio greater than 4.50 for small text, or 3.00 for large text.

Contains tabs:

Followed Sites Tab

Talkback Audit

• Search
  

• Search input doesn't tell when no results have been returned. Return results after waiting for at least 4 - 5 seconds to ensure query was properly entered.

• When search returns results the user won't know if results are actually present. The app should announce that two items actually exist. (It actually announces this the first time the user selects an item in the list.)

Sites You May Like Tab

• No issues noticed.

Search: Can search sites or posts. Shows list of posts and sites.

Talkback Audit

• Search
  
  
  
  • When the search has begun the app doesn't announce this. Also when the search has ended it doesn't announce this either. The app should express the state of the search results. There's a subtle sound.Is the sound after the list has been propagated enough context for the sure?
  
  

Filters: Discover, Followed Sites, My Likes, Saved posts: Lists posts

Accessibility Scanner Aduit

• Filter org.wordpress.android:id/filter_spinner - Touch target

  This item's height is 47dp. Consider making the height of this touch target 48dp or larger.

• Follow Button org.wordpress.android:id/follow_button - Touch target

  This item's height is 30dp. Consider making the height of this touch target 48dp or larger.

• Nav Bar Icons org.wordpress.android:id/nav_icon (navbar_post_item) - Image contrast

  The image's contrast ratio is 2.33. This ratio is based on an estimated foreground color of #FFFFFF and an estimated background color of #A7AAAD. Consider increasing this ratio to 3.00 or greater.

• Discover's Domain - org.wordpress.android:id/text_domain - Text contrast

  The item's text contrast ratio is 4.20. This ratio is based on an estimated foreground color of #787C82 and an estimated background color of #FFFFFF. Consider using a contrast ratio greater than 4.50 for small text, or 3.00 for large text.

• Follow Count org.wordpress.android:id/text_blog_follow_count - Text contrast

  The item's text contrast ratio is 3.91. This ratio is based on an estimated foreground color of #787C82 and an estimated background color of #F6F7F7. Consider using a contrast ratio greater than 4.50 for small text, or 3.00 for large text.

• Discover Text org.wordpress.android:id/text_discover - Text contrast

  The item's text contrast ratio is 3.16. This ratio is based on an estimated foreground color of #8E9196 and an estimated background color of #FFFFFF. Consider using a contrast ratio greater than 4.50 for small text, or 3.00 for large text.

• Discover List Item's Visit Layout - org.wordpress.android:id/layout_discover - Touch target

  This item's height is 32dp. Consider making the height of this touch target 48dp or larger. A parent container may be handling touch events for this item. If selecting the larger container performs the same action as selecting this item, consider defining this item as not clickable. If a different action is performed, consider increasing the size of this item.

• Visit Button org.wordpress.android:id/visit- Touch target

  This item's height is 36dp. Consider making the height of this touch target 48dp or larger. A parent container may be handling touch events for this item. If selecting the larger container performs the same action as selecting this item, consider defining this item as not clickable. If a different action is performed, consider increasing the size of this item.

• More Button org.wordpress.android:id/image_more - Touch target

  This item's size is 36dp x 36dp. Consider making this touch target 48dp wide and 48dp high or larger. A parent container may be handling touch events for this item. If selecting the larger container performs the same action as selecting this item, consider defining this item as not clickable. If a different action is performed, consider increasing the size of this item.

Talkback Audit

• The words "site icon" are being read out loud when the user however over the header of a post in the Reader view.The post title and other pertinent information can be made available but it's okay to disregard the author's profile image since their name is being announced.

• Should empty states be read out loud? Currently the user has to hover each item before it's read.

• For Filters, I have realized that the Pull To Refresh functionality exists. Should a refresh button be placed in the menu for accessibility reasons since doing a refresh with swipes might be difficult?

• Saved posts :
  

Should the empty state image/background be announced automatically?

Tap to save post to your list. Should this icon even be read out since the user won't know what the icon means?

• Discover :
  

Summary of discovery read out and then the number of followers read in the same line. There should be some form of break in this.

• Preview : no issues noticed.
• Post View :
  

• Currently the user has to however over each part within the post view to hear the content. Shouldn't this be read out loud?

I thought about this a lot more and it makes sense for the user to however as they are able to only hear specific sections and access links so its probably okay for the existing functionality to remain for this.

[jd-alexander]

hey @osullivanchris for the Accessibly Scanner Audits the main areas of focus are touch targets and text contrasts. I was thinking it would be good to address these but wanted to know if you have any thoughts or guides I could utilize.

Touch Targets

For the items that don't have proper touch targets, I would use this approach of https://material.io/design/layout/spacing-methods.html#touch-targets of increasing it. Meaning in code I would let the app accept touches in a larger area so just wanted to verify if that should be the approach for all cases because there could be two outcomes based on my analysis.

1) Increase touch target area with code ( no visual changes )
2) Increase the padding, that would cause a visual change.

Text Contrasts

For items that have low contrasts whats the recommended course of action here? Do I just change to a colour with a better contrast meaning, if wordpress_blue_50 then change to wordpress_blue_30? Let me know your thoughts. Thanks :)

N.B A cool contrast resource I stumbled on while doing research https://webaim.org/resources/contrastchecker/ :)

[shiki]

Search

Take a look at Site Creation. On the steps where you enter something and there is a list of suggestions, the app announces “Suggestions updated”. I think this is what we want. As for empty lists, I think we also want to announce those. Please be wary of announcing too much as well.

[shiki]

Should empty states be read out loud? Currently the user has to hover each item before it's read.

I think so! In addition, it's not clear that the user has to press _Enter_ to start the search.

Should the empty state image/background be announced automatically?

That sounds like a good idea.

For Filters, I have realized that the Pull To Refresh functionality exists. Should a refresh button be placed in the menu for accessibility reasons since doing a refresh with swipes might be difficult?

Good question! I think this requires some more discussion and research. I wonder how other apps do this. 🤔

The words "site icon" are being read out loud when the user however over the header of a post in the Reader view.The post title and other pertinent information can be made available but it's okay to disregard the author's profile image since their name is being announced.

Yes. I don't think it provides any value to dictate the site icons.

When the search has begun the app doesn't announce this

Yeah, that should probably be announced.

---

Please let me know if I missed anything, @jd-alexander.

[jd-alexander]

Thanks for the detailed responses @shiki 😄

Take a look at Site Creation. On the steps where you enter something and there is a list of suggestions, the app announces “Suggestions updated”. I think this is what we want. As for empty lists, I think we also want to announce those. Please be wary of announcing too much as well.

Thanks, I will definitely have a look there and your point about making too many announcements is duly noted. A lot is being said by the screen reader when the user hovers/selects different views so the less that can be said the better 😃

Good question! I think this requires some more discussion and research. I wonder how other apps do this. 🤔

So the Buffer team had a similar issue where they had a swipe interaction that would be difficult for users who are using accessibility features so what they did was they created a different UI/UX for that interaction and in their case, this was a bottom sheet that's triggered once an AccessibilityService is enabled I think.
So in our case, adding a refresh button would be along the lines of this behaviour.

I made an issue and moved this comment to it. https://github.com/wordpress-mobile/WordPress-Android/issues/10733

[osullivanchris]

For the items that don't have proper touch targets, I would use this approach of https://material.io/design/layout/spacing-methods.html#touch-targets of increasing it. Meaning in code I would let the app accept touches in a larger area so just wanted to verify if that should be the approach for all cases because there could be two outcomes based on my analysis.

Hey I agree with this approach and its something I have seen work before. I think especially if there is not other interactive items next to the target, increasing it as much as is reasonable is a good course of actions. Where there are two targets close to each other (e.g. enter a tag to follow, and the icon) we should also make sure there is 8dp between them. In an example like that, I would reduce the width of the touch target for the wider one, as the text is towards the left anyway). If this doesn't make sense I can sketch it!

If you have any cases where there is not enough space to make all of the touch targets large enough, I would suggest creating a task to get design input to reconsider the layout (e.g. adding more padding)

For items that have low contrasts whats the recommended course of action here? Do I just change to a colour with a better contrast meaning, if wordpress_blue_50 then change to wordpress_blue_30? Let me know your thoughts. Thanks :)

this one is a little less straight forward. I think we should make these changes as part of the system rather than place by place. We are also doing an overall color update across the apps to adhere to new system colors and to enable dark mode. So I think accessibility could be a consideration within that work. Ping @mattmiklic who has been doing a lot of work on updating colors. See for example pauD4L-r0-p2.

How I would see this solved in the long run is that we should have semantic colors e.g. grey 2, and know that grey 2 has enough contrast on grey 5 or whatever it is. And then when we do accessibility tests and find out that we're using the wrong grey in the wrong place, we just move one up/down as required (with a quick design check). For now this is probably slightly awkward timing to solve this issue as it would require you hard-coding lots of stuff, where we should have accessible, semantic colors defined at a system level.

Should the empty state image/background be announced automatically?

Tap to save post to your list. Should this icon even be read out since the user won't know what the icon means?

I have only skimmed the rest of the original task. But one I spotted here. I think it should be read out. To say something like 'Tap the bookmark icon to save a post to your list'. And then when the user encounters the icon it would also be read out as 'bookmark_icon' or whatever the relevant string is. This is a problem even for users without impairment - to recall which icon does which thing. Naming it consistently in both the place where you do it and the place where it lives could make this saving and retrieval easier for users with screen readers.

[shiki]

For Filters, I have realized that the Pull To Refresh functionality exists

@jd-alexander Going back to this. I just learned that you can use two-fingers to swipe-to-refresh. So I don't think we need to add a Refresh button.

I learned this from _Tip: Use two-finger gestures_ in here.

[mattmiklic]

We are also doing an overall color update across the apps to adhere to new system colors and to enable dark mode. So I think accessibility could be a consideration within that work. Ping @mattmiklic who has been doing a lot of work on updating colors

I believe that the contrast issues in the tabs and on the bottom nav will be fixed as part of the Material color theme I've been working on with @khaykov. Once that work is a bit further along (with a build I can test in light mode) I'll check to make sure that what we're getting from the Material theme has a sufficient contrast ratio.

For items that have low contrasts whats the recommended course of action here? Do I just change to a colour with a better contrast meaning

I think a lot of the text contrast issues listed above are places where we're using Gray 30 or 40 on a white background -- the easiest solution to those would be to change them to Gray 50, which will be sufficient. The https://color-studio.blog site should be a handy resource here as it shows you the contrast ratios for all our colors on both white and black backgrounds. For most colors, anything 50 or higher passes on a white background; anything 40 or lower passes on a black background.

[jd-alexander]

Thanks for the feedback @osullivanchris 😄

Hey I agree with this approach and its something I have seen work before. I think especially if there is not other interactive items next to the target, increasing it as much as is reasonable is a good course of actions. Where there are two targets close to each other (e.g. enter a tag to follow, and the icon) we should also make sure there is 8dp between them. In an example like that, I would reduce the width of the touch target for the wider one, as the text is towards the left anyway). If this doesn't make sense I can sketch it!

Thanks for the clear explanation. I will look into getting this done.

If you have any cases where there is not enough space to make all of the touch targets large enough, I would suggest creating a task to get design input to reconsider the layout (e.g. adding more padding)

Understood 👍

I have only skimmed the rest of the original task. But one I spotted here. I think it should be read out. To say something like 'Tap the bookmark icon to save a post to your list'. And then when the user encounters the icon it would also be read out as 'bookmark_icon' or whatever the relevant string is. This is a problem even for users without impairment - to recall which icon does which thing. Naming it consistently in both the place where you do it and the place where it lives could make this saving and retrieval easier for users with screen readers.

This is a good idea. Will definitely put this in place for sure.

[jd-alexander]

I believe that the contrast issues in the tabs and on the bottom nav will be fixed as part of the Material color theme I've been working on with @khaykov. Once that work is a bit further along (with a build I can test in light mode) I'll check to make sure that what we're getting from the Material theme has a sufficient contrast ratio.

Okay, great!

I think a lot of the text contrast issues listed above are places where we're using Gray 30 or 40 on a white background -- the easiest solution to those would be to change them to Gray 50, which will be sufficient. The https://color-studio.blog site should be a handy resource here as it shows you the contrast ratios for all our colors on both white and black backgrounds. For most colors, anything 50 or higher passes on a white background; anything 40 or lower passes on a black background.

Okay! Good stuff! So I will use this approach with all issues that are not apart of anything that's part of the main controls for navigation and such forth. Got it 👍

Thanks for chiming in @mattmiklic will share my updates with you. When I make the first PR I will send a ping to you so you can have a glance to let me know if I am going in the right direction 🙌