Accessibility user test results

[rianrietveld]

Accessibility usertest: Twenty Sixteen
https://make.wordpress.org/accessibility/2015/09/22/accessibility-usertest-twenty-sixteen/

Summary

The main opinion: This theme tested pretty well!
No drastic errors. Yay!

First: can someone reproduce Jeff’s error?

Missing context for sighted users (maybe also a usability issue): The author, category, and tag links in the post meta simply state just that. That is, “themedemos”. Or “Uncategorized”. Nothing else, no context. For screen reader usres there is extra text to give context.

Landmarks: A lot of the remarks where about landmarks. W3C and VAWE now mark elements with the same role as warnings (not errors). Like: Element nav does not need a role attribute role=nav.

Note Rian: We discussed this in the team chat and decided that the roles should stay for now, for backwards compatibility with old assistive technology.

Navigation: three the same remarks:

• Users should be able to select ‘ESC’ to close a drop-down menu, and then when tabbing or arrowing again they are taken to the next main menu item.
• Screen reader user have to go through all submenu items in order to get to another tab item
• Currently, if you want to navigate to “Page B,” you have to tab through the entire main nav, sub items included.

Note Rian: this is not an accessibility error, but a keyboard user usability issue. Might be worth to find a solution for this.

Featured image: There was confusion about the featured image with the link being skipped. This is on purpose to prevent extr noise for screen readers by adding an aria-hidden=”true” to the link.

Input fields: The color contrast for the border or background colors could be increased.

Focus errors:

• search button should show up on focus
• inconsistent focus for responsive Menu toggle button
• submenu toggle responsive menu should have an outline

Page navigation

• no ARIA indicator current page number for a screen reader
• color is not enough to indicate this is the current page number

[davidakennedy]

Thanks for filing this issue @Rrwd, and for all the test wrangling.

I think it's best to break these up into separate issues so we can discuss each on its own. I'll work on that.

Regarding the page navigation issues: That may be better as a Core ticket. It's using the_posts_pagination, like Twenty Fifteen did. We can certainly fix within the theme, but I'd rather see work put into Core to fix it everywhere.

[davidakennedy]

Missing context for sighted users (maybe also a usability issue): The author, category, and tag links in the post meta simply state just that. That is, “themedemos”. Or “Uncategorized”. Nothing else, no context. For screen reader usres there is extra text to give context.

I'm not seeing this. I see that there is hidden text for each of the post meta items. I see them on archive and single pages. Is there another place where they're missing? Worth noting that the hidden text is not inside the links, but before it. But I think that's fine.

[rianrietveld]

@davidakennedy I think what Jeff means is that by just showing names, it may be unclear for sighted users that they are usernames, categories and tags. It's not really an accessibility issue more a usability issue.

@davidakennedy can you take over from here?

[rianrietveld]

Actually, beside a few minor focus/color issues this theme is absolutely awesome.
Thanks everyone!

[iamtakashi]

Missing context for sighted users (maybe also a usability issue): The author, category, and tag links in the post meta simply state just that.

I think each post meta except category and tag is pretty self-explanatory. How about adding hashtag, # to each tag so that there is clear difference between categories and tags?

[LateButEarly]

@iamtakashi 👍 I like that idea. I feel like users would easily understand that a hashtag is related to a tag.

[brentlogan]

That's something I've done for a while. Simple CSS:

.tags-links a:before {
    content: "#";
}

[iamtakashi]

Yep, it's easy and it would be almost universally recognised as tag. I'll make a PR and let's hear what people think about it.

[joedolson]

I think a hashtag is clear for context, but we should check how it's read by screen readers. I also note that the hashtag will only appear before the first word of a tag, so multi-word tags might look a little strange.

[iamtakashi]

A good point about screen readers. The PR above is first attempt without checking how it's read by screen readers. We do need to test it.

Before:

After:

[afercia]

Tested "on the fly" with screen readers while discussing this on Slack: at least Firefox + NVDA and VoiceOver read the hash as "number", depending on screen reader punctuation settings and way to navigate the content (arrowing or tabbing etc)

[iamtakashi]

Would adding `speak: none" help to make sure it won't be read?

[davidakennedy]

Hey @Rrwd, what do you mean by:

inconsistent focus for responsive Menu toggle button

How does that need to change? Seems solid to me.

[davidakennedy]

I've broken out any a few of these issues into separate issues. The ones I haven't either are not issues, or have already been discussed here. Hopefully, this will make it easier to knock these out.

[rianrietveld]

@davidakennedy What I mean is that the toggle buttons don't get enough visual focus (no outline like the menu-items) and that the menu buttons stayed in "active focus" mode when you enter the menu. I have made a youtube to demonstrate this: https://www.youtube.com/watch?v=hiTEBvBPE1U

[rianrietveld]

Also I think the active page in the Page navigation should get a better focus, not only a colour change form blue to black.

[davidakennedy]

@Rrwd I see, you're talking about the menu toggle's :focus state when it's active, not its initial :focus state. 😄 Thanks for the explanation. That can be fixed.

[davidakennedy]

I tested this, and it does not work. I still hear the CSS generated content in both Safari and Chrome with Voiceover.

My preference would be to leave this as it was originally. It would be ideal to have some visible text in that area that says "Post Info" or something like that. But it's okay not to as well. The way it's grouped also creates a pattern I think users are used to. And screen readers get the bit of extra information they need.

Leaving the CSS Generated content in there will cause more confusion than good, I think. See this blog post.

[rianrietveld]

@davidakennedy +1, we discussed this in Slack and in this case the cure is worse than the issue

[iamtakashi]

I'm closing this thread as the issues reported here are now either fixed, being discussed in separate tickets.