Accessibility improvements on fun mooc and richie

[manuhabitela]

Here a few things I noted that we can still do on fun-mooc/richie:

Links (fun-mooc)

Content links are, for now, only differentiated by color. Accessibility-wise, this is OK as long as:

• the contrast ratio between the link color and the body text next to it is high enough (3:1 ratio)
• on link hover/focus, the link visual changes (example: it becomes underlined)

For now the contrast ratio is not high enough (2.86:1 between the red links and the black body text around them).

My advice would be to have the links be underlined by default. This allows us to keep the brand color on them.

Navigation menu (fun-mooc)

On fun-mooc's homepage, a few menu items have color issues because of the background. One solution would be to add a white background on menu items.

Course detail block (fun-mooc and richie)

• There is a small color contrast ratio issue in the course detail block, when on a course detail page (see "Aucune session ouverte" in the screenshot below).
• In addition to that, the social network sharing links in this part can be improved. One way to fix is to set an aria-label attribute on each <a> that is the same as its title attribute. We must do this because the title attribute is not necessarily announced by screen readers.

Tarteaucitron (fun-mooc)

A couple things should be improved in the tarteaucitron dialog:

• the cross icon in the top right corner that closes the dialog doesn't have any focus styling. We don't know where we are when we tab on it. There should be focus styles defined.
• the "Allow", "Deny", "Allow all cookies", "Deny all cookies" buttons are almost invisible even when not disabled. When the buttons are enabled, they should follow the usual color contrast ratio rules. Note that a visual difference between "toggled on" and "toggled off" button should still be there. One idea would be to have "outline" buttons when toggled off and "plain" buttons when toggled on. Or we could set an additional border when active. One thing to note is the "toggled on/off" difference shouldn't be set only via color. A different shape is required.

Accesskeys (richie)

Two anchors have an accesskey attribute. This seems like a good idea at first but it's not really recommended to use them. A few reasons to that: there can be conflicts with browser shortcuts, screen reader shortcuts, they are not configurable by the user.

So here the fix would be to simply remove the accesskey attributes.

Cleaning a few content plugins (richie)

While I thought I went through all the available plugins on the website, I was wrong…

There are still a few problems here and there with some plugins. We can note the quote plugin, the license plugin…

Refer to the accessibility docs to check for issues. Most of issues related to plugins already fixed were:

• wrong heading hierarchy (going from h2 to h4, for example)
• big <a> wrapping rich content
• decorative images having alternative text
• using too much headings (no need for a heading to just show something as big and bold)

Obsolete HTML tags generated by the CMS

The CMS generates some presentation-only HTML tags that should be avoided, mainly the <big> tag. They generate errors in the W3C validator, making the RGAA criterion 8.2 fail, and since they are presentation-only tags, they make the RGAA criterion 10.1 fail. In terms of actual real accessibility issues, we could argue this has no real impact, really… so that's a bit of annoying things to do to make WCAG happy.

Item lists (optional) (richie)

In a lot of pages, we list different kind of resources: subjects, collections, organizations, courses, persons… For now most of those lists are packs of div.

We can argue the better thing to do would be to wrap those lists in <ul> and <li> tags, as they are actual lists of items. Doing so would help a tiny bit screen reader users by giving them an alternative way to navigate through these items (via list-related keyboard shortcuts) and get more context.

This is not a deal-breaker though. Content is accessible, and screen reader users can navigate from item to item by using headings-specific shortcuts.

[manuhabitela]

ping @sampaccoud @jbpenrath

[jbpenrath]

About tarteaucitron, we talked about orejime. Do you think this library addresses all issues you mentionned about tarteaucitron ?

[manuhabitela]

Those specific issues are indeed fixed with orejime. But I feel like switching the whole consent manager is kinda overkill here, after looking at the code, tarteaucitron is pretty great a11y-wise, those couple issues are easily fixed with small CSS changes.