search

wordpress-mobile / WordPress-Android

WordPress for Android
http://android.wordpress.org
GNU General Public License v2.0
2.97k stars 1.31k forks source link

Accessiblity : Reader Improvements - Main Issue #10718

Closed jd-alexander closed 4 years ago

jd-alexander commented 4 years ago

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
settings

Contains tabs:

Followed Sites Tab

Talkback Audit

Sites You May Like Tab

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

Talkback Audit

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

Accessibility Scanner Aduit
Screenshot_20191030-231348
Talkback Audit
Screenshot_20191030-224532

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?

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.

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 🙌