Accessibility review for logged-in state

[boonebgorges]

Previously: #108

We should do a WAVE review while logged in.

Special attention should be paid to dynamic areas, which will probably need aria-live labels. I'm not sure WAVE is smart enough to catch this.

[boonebgorges]

I've made a pass through the logged-in states and made a number of improvements.

• I've added aria-live and related regions to the dynamic parts of the application (aria-busy, aria-atomic). I did some light testing using VoiceOver and this appears to be working as expected.
• The aXe scanner does a better job of scanning for form labels in JS-powered form elements, like our select boxes, than the WAVE tool did in my initial scans. It identified a number of places where we either needed aria-label attributes, or aria-labelledby that point to the regular HTML label element corresponding to the original form element.
• Fixed a number of duplicate element IDs.
• Added navigation, banner, application, and complementary landmarks. This covers about 90% of the elements on the page.
• Added an h1 for screen-readers to the theme.

The aXe scanner is showing a couple of remaining items that cannot be easily fixed at the moment. A summary: a. The sidebar filters ("Select Course" etc) have an invalid aria-owns attribute; they're empty, when they ought to be excluded. This is a problem with the upstream library, and is being tracked by them. https://github.com/JedWatson/react-select/issues/1667 I think we should not touch this for the time being.

b. It's reporting that the question-course-data element contrast is insufficient. See screenshot. It just barely misses the contrast ratio - @jennaspevack maybe you could have a look and provide a quick bit of guidance on a new color for this.

c. There are some best-practices failures in the sitewide footer (lack of ARIA role, etc). This is low-priority - not a violation, but a best-practice thing - and should be addressed at the OpenLab level.

d. The tool is reporting a couple issues with the WordPress toolbar (tabindex on the 'Skip to toolbar' link, some minor contrast issues). We should not address this, as it's minor and it's a WP issue.

Once we have addressed (b), I think we can pass things along to Bree and/or EA for some review (in conjunction with the changes in #114).

[jennaspevack]

@boonebgorges I think 555555 would be good for question-course-data and for .ww-subtitle section, which seems to pass WAVE checker, but not the actual contrast ratio. Maybe that has to do with the font size.

Also noticing that the link color on the Help and About pages is still light green, which doesn't pass. That should be the same blue 0044af as the home page.

[boonebgorges]

Thanks, @jennaspevack - I've made the #555 changes, and also changed the selectors so that the link color should be consistent throughout.

[jennaspevack]

Thanks, @boonebgorges - looks like we need to change the hover state for consistency too. It's just black.

[boonebgorges]

@jennaspevack Could you please clarify which element you mean? I'm looking around and I see a couple of things that are black on hover, but I'm not sure which of them needs to be changed, and what they need to be changed to. Maybe a class name so that I could look into it?

[jennaspevack]

Sorry, @boonebgorges I was referring to the links on About and Help. You had changed the link color from light green to 0044af blue above, but the hover associated with those links is still teal. I believe the color is 1abc9c. It should be changed to black.

[boonebgorges]

Ah yes, thank you!! Fixed.

[moui72]

I'm getting 0 contrast errors now.

There are mark-up errors associated with images imported from webwork not having alt-text. See e.g., http://openlabdev.org/webwork-playground/#:problemId=local/CoordinatePlaneTrig/identify-quadrant.pg:questionId=11900

<img src="http://openlabdev.org/wp-content/uploads/2018/05/b3bcce7f-f929-3580-8529-dde333f50a25___df0de1a3-83f3-3909-9471-a462a70e44ce.png" style="outline: red dashed 2px;">

Could we perhaps add an alt tag that reads something like "Image for [problem]" where [problem] is replaced with something like the title of the view at the given URL "Problem: CoordinatePlaneTrig"?

I am not seeing any other accessibility issues at this point

[boonebgorges]

Could we perhaps add an alt tag that reads something like "Image for [problem]" where [problem] is replaced with something like the title of the view at the given URL "Problem: CoordinatePlaneTrig"?

We've leaned against doing this elsewhere on the OpenLab because, while it might fool the WAVE scanner, it doesn't actually provide any accessibility benefits. Any text that we can build programatically is likely to contain no info that would be useful to someone using a screen reader. @bree-z and @jennaspevack Does that sound correct?

[bree-z]

Yes, that's how I remember these discussions. @jennaspevack does that make sense to you? Thanks!

[jennaspevack]

Yep, that's correct.

[boonebgorges]

Awesome - I think we are ready to close this one, then. (alt should be less of an issue moving forward, thanks to #118)

[jennaspevack]

sorry @boonebgorges Just found this: Looks like the mobile > hamburger dropdown link color is blue. I think it should be white, like the main nav. (And the nav hover color doesn't seem to have any styling, but maybe we'll leave that for now unless there is something simple that makes sense to you? Perhaps just an underline?)

[boonebgorges]

Thanks, @jennaspevack. I've made two changes:

• on mobile (hamburger), links are #fff
• on non-mobile, menu links are underlined on hover

I'll leave the ticket closed, but please reopen or report elsewhere if things need more adjustment.