Hello!
When checking the artifacts generated in our build by WCAG validation, I came upon one violation quite often and the solution is not straightforward:
Links must be distinguishable without relying on color.
Example of such a violation:
See this ticket for more details on this example.
This issue does not happen if the Enable Extra Accessibility Features are toggled ON in the user profile. The Extra Accessibility Features are a user related setting that toggles the use of the accessibility.css style sheet. For reference, here is the ticket where the accessibility stylesheet has been created: XWIKI-5543. This style sheet has a few rules, one of which is to make anchors always underlined. You can see the difference between Extra Accessibility Features ON (left) and OFF (right) here under:
There is a few possible ways to solve the above ticket:
- (1) consider a disabled user always has the accessibility features ON: when running functional tests, the test user should have accessibility features ON.
- Any user should be able to differentiate the inline links: change the default link display.
- (4) Change the link color so that it has enough contrast with the regular text color. This can be very tricky because of the conjoined need to keep the contrast high between the link and the background. The margin (if any at all) is very slim. Here is an example: with a white background (most favorable case, on the color theme Iceberg the background is usually very-light gray or light gray), the lightest color weâre allowed for links would be #3d79b8 (lavish blue) with a contrast of 4.5 (WCAG background contrast requirement). The lightest possible color for regular text to keep a contrast of 3 (WCAG link contrast requirement if only color change) in this case would be #2d2d2d (dark gray, lightness 18%). Considering the links are used in a large variety of elements in the interface, we canât really count on one link color satisfying all situations. I think using multiple link colors depending on the context would be terribly difficult and ugly in the interface.
Regarding the second bullet point above, I think accessibility on XWiki should not be hidden behind a user setting because:
- (2) All users can benefit from accessibility fixes, as they can improve readability of the content for anyone.
- (3) A disabled user as of now cannot know easily about this feature of XWiki, and the setting is OFF by default so any user needs to toggle ON this setting by navigating through an âunaccessibleâ XWiki at least once.
Considering (2), I think we have two possible solutions:
- (2.1) Just remove the accessibility parameter and use the changes for all users. This might change the interface too much and annoy some users: making the font size bigger allows less content on the same space, and links everywhere might make some navigation regions look janky compared to the usual (see the settings category selection panel where all the links are underlined, it feels more cluttered and harder to read than non-underlined).
- (2.2) Keep the accessibility parameter but add a default style to solve the accessibility violation we have for any user. To do so, we need to find out what are and are not inline links. Here under is a graphic showing which links Iâd consider inline (light green) and out of a line (orange). With (2.2), the light green blocks would be changed to always display with an underline, while the orange ones would only show an underline when the accessibility features are ON.
We could fix (3) by adding a keyboard shortcut to turn accessibility features ON (or OFF). This shortcut, in order to be useful, would need to be easily known by any user. A good way to do this is to add a stable help element in the UI redirecting to the help page, which itself contains information about the shortcut, or redirects to a page that does. Note that thereâs already a help page, but itâs not always available since the link for it is in the Applications panel. This panel does not appear on edit pages for example.
At last, similarly to (1), we could trigger the accessibility features ON in the functional tests.
Here is a summary of the different ways I found so far to tackle this issue:
- (1) The default functional test user activates its Extra Accessibility Features.
- (2.1) The accessibility setting is removed and everyone uses these changes.
- (2.2) Some of the behavior of the accessibility setting is used for everyone.
- (3) We implement a shortcut to trigger accessibility settings and then (1).
- (4) We change the color of the links to enable enough contrast with the text around it and the background.
My order of preference is (4) < (1) < (2.1) < (3) < (2.2).
So +1 for (2.2) and (3), +0 for (2.1) and -1 for (4) and (1).
What do you think of these solutions? Which one do you think would be appropriate to solve this accessibility issue and make XWiki more accessible?
Thank you in advance for your feedback and have a good day,
Lucas