Page MenuHomePhabricator

Gray used in .autocomment in RC and watchlist is not accessible against background and hinders link discovery
Open, NormalPublic

Description

This was originally brought up at en.WP VP proposals#Darker section titles in page history. A subsequent commenter noted that the text was not even AA compliant against the background (except with 18pt font).

We think we've found an acceptable AAA-compliant color with #585858. My recommendation would be the lightest-gray that achieves AAA compliance, and #585858 just happens to be the color on which we settled.

One of the issues with increasing the autocomment's contrast to the background is with the following .comment text, which is the edit summary-proper. We've been exploring ways of increasing the contrast between these two texts also:

  • Change .autocomment to straight letters
  • Change .comment to straight letters, setting CSS for .autocomment to italics
  • Change .autocomment to use font-weight: lighter (seem to work against desire to increase contrast).

There may be other styles to explore in that regard.

Event Timeline

Izno created this task.Feb 3 2016, 1:34 PM
Izno updated the task description. (Show Details)
Izno raised the priority of this task from to Needs Triage.
Izno added a subscriber: Izno.
Restricted Application added subscribers: Danny_B, StudiesWorld, Aklapper. · View Herald TranscriptFeb 3 2016, 1:34 PM
Izno updated the task description. (Show Details)Feb 3 2016, 1:39 PM
Izno set Security to None.
Izno updated the task description. (Show Details)Feb 3 2016, 3:58 PM
Danny_B moved this task from Unsorted to Colors on the Accessibility board.Feb 4 2016, 3:13 AM
Earwig added a subscriber: Earwig.Feb 7 2016, 6:45 AM
Izno triaged this task as Normal priority.May 5 2016, 11:57 AM
Izno updated the task description. (Show Details)
Izno added a project: good first bug.
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptMay 5 2016, 11:58 AM
Volker_E updated the task description. (Show Details)Jul 14 2016, 6:39 PM

@Izno In our work on finding design answers to users' needs, we sometimes find ourselves with different, in parts diametrically opposing solutions.
While it's completely agreeable that we want to provide users with visual impairments a sufficient interface, we also have to make sure, that majority of users looking at this specific view (Revision history) are able to easy scan this by having priority in information visually set apart.

Our color palette for interface elements was updated a short time ago to ensure the UI elements are aligned to at least WCAG 2.0 level AA compliance.
With compliance to level AAA, it's a different story that is not solved easily without lowering differentiation between more and less important information.
Therefore I'd suggest to go for #72777d from the palette as AA compliant color for the .autocomment parts. This would improve the current status quo and still fulfill the need of visual hierarchy.

Related is another task, where we are discussing about further features and special needs for smaller groups of users as part of accessibility settings.

Izno added a comment.Oct 4 2016, 4:28 PM

I'm just asking questions here to make sure the issue is investigated completely:

@Izno [conflicting requirements background] [...] we want to provide users with visual impairments a sufficient interface

Mmhmm.

majority of users looking at this specific view (Revision history) are able to easy scan this by having priority in information visually set apart.

I made this comment in the VPT discussion, in fact.

ensure the UI elements are aligned to at least WCAG 2.0 level AA compliance.

So the argument you're making for your suggested value is that AA here is consistent with the rest of the palette in our desire to be minimum WCAG AA? Arguments to consistency-alone aren't always the best. :)

With compliance to level AAA, it's a different story that is not solved easily without lowering differentiation between more and less important information.

This is true, if all that's being considered is color. As noted above, we explored some other ways to differentiate the less-important (which is the .autocomment text) from the more-important (which is the edit summary text). Have you reviewed those options, or explored any of the options (including your suggested value) with users?

Volker_E added a subscriber: RHo.Oct 4 2016, 10:42 PM

ensure the UI elements are aligned to at least WCAG 2.0 level AA compliance.

So the argument you're making for your suggested value is that AA here is consistent with the rest of the palette in our desire to be minimum WCAG AA? Arguments to consistency-alone aren't always the best. :)

Yes, in M82 you can see very clearly which color combination complies to which WCAG level (for example white on progressive blue complies to AA, an idea by @RHo btw)

With compliance to level AAA, it's a different story that is not solved easily without lowering differentiation between more and less important information.

This is true, if all that's being considered is color. As noted above, we explored some other ways to differentiate the less-important (which is the .autocomment text) from the more-important (which is the edit summary text). Have you reviewed those options, or explored any of the options (including your suggested value) with users?

I agree, color shouldn't be the only indicator (at best). But another one isn't easy to find. Italics for example doesn't work to users' satisfaction for languages like Chinese, Japanese or Korean as it's not part of the typographic tradition.
For future solutions, the browser support of properties like text-emphasis is luckily inclining.

Izno added a comment.EditedOct 5 2016, 6:20 PM

Yes, in M82 you can see very clearly which color combination complies to which WCAG level

And I see the suggested gray is listed there. That is good to know.

I agree, color shouldn't be the only indicator (at best). But another one isn't easy to find. Italics for example doesn't work to users' satisfaction for languages like Chinese, Japanese or Korean as it's not part of the typographic tradition.

I'm not sure how this is relevant to those specific proposed solutions for this specific task. Presently on en.WP and ja.WP, the line of interest (both autocomment and summary) is already italicized (I didn't check the others, but I expect the same elsewhere).

If those shouldn't be italicized on ja.WP, or there shouldn't be italics at all on the line, that's a separate task.

So actually, in this case, straight letters would almost assuredly be preferred for the summary...

I agree, color shouldn't be the only indicator (at best). But another one isn't easy to find. Italics for example doesn't work to users' satisfaction for languages like Chinese, Japanese or Korean as it's not part of the typographic tradition.

I'm not sure how this is relevant to those specific proposed solutions for this specific task. Presently on en.WP and ja.WP, the line of interest (both autocomment and summary) is already italicized (I didn't check the others, but I expect the same elsewhere).

If those shouldn't be italicized on ja.WP, or there shouldn't be italics at all on the line, that's a separate task.

So actually, in this case, straight letters would almost assuredly be preferred for the summary...

The relevance to add this design problem, is that italics is part of one of the proposed solutions. It's clear to me as well, that the current implementation might be flawed. When we're considering solutions, we should aim for most inclusive improvement possible.

chelsyx added a subscriber: chelsyx.Oct 7 2016, 9:55 PM

Thank you @Volker_E for inviting me to the discussion. I'm happy to help! :)

Italics is not a traditional way to emphasize in Chinese. The difference in Chinese is less obvious to me. From this discussion on Zhihu (Chinese Quora), it seems most designers thinks italicized Chinese is very ugly...

Traditionally people use dot under the characters to emphasize, but very few people use it now. See https://zh.wikipedia.org/zh/%E7%9D%80%E9%87%8D%E5%8F%B7

This discussion and this article suggest using a different font to emphasize a piece of message. For example:

Volker_E moved this task from mediawiki.ui to Color consistency on the UI-Standardization board.

I think we should go #54595d. The contrast is 6.72, enough for AA in small text.

Before:


After:

@Ladsgroup The task is describing further problems besides the text color, why would you go for #54595d over the proposed #72777d, which also fulfills level AA on white background? We have to consider different needs, not only color contrast and increasing contrast might go hand-in-hand with lowering differentiation between higher and lower priority information. Therefore I would be cautious about using #54595d.

Izno closed this task as Invalid.EditedNov 30 2018, 4:27 AM

Invalid with T165189: "→" link to page section on History page can be hard to click, should be larger somehow I think, even if that change gets tweaked based on Anomie's comment. 😃

Restricted Application added a project: Growth-Team. · View Herald TranscriptNov 30 2018, 4:27 AM
Izno reopened this task as Open.Dec 3 2018, 11:41 PM

Since the other task is making everything the same gray again, reopen this one.

In addition to the pre-existing accessibility problem with the specific gray, it's now also a link that isn't super discoverable. Many editors found making the link blue (like normal) excessive, and overwhelming, creating a "sea of blue". The most important argument I was convinced by was:

...The section title autocomment is less important than the actual comment and should be deemphasized, while making it link-blue adds emphasis to the detriment of the actual comment.

So somehow we need to find a style that isn't stronger than the black, but still discoverable as a clickable link. Is that possible? :)

Legoktm renamed this task from Gray used in .autocomment in RC and watchlist is not accessible against background to Gray used in .autocomment in RC and watchlist is not accessible against background and hinders link discovery.Dec 4 2018, 3:14 AM
Dvorapa added a subscriber: Dvorapa.Dec 4 2018, 9:23 AM
Schnark added a subscriber: Schnark.Dec 4 2018, 9:46 AM

I'm going to re-propose this:

An option would be to just change the style beyond the link color. For example, the font size could be smaller, and with different color and or background. It would give a hint that it's something clickable and also visually distinguish from everything else:

@Ciencia_Al_Poder Two issue with such treatement, first in the proposed image it would run into color contrast accessibility issue again. Second, it would over-emphasize a less prioritized link again. Visual treatment should guide the eye for the most important information and de-emphasize the less important. Therefore the grey color was chosen beforehand.

Dvorapa added a comment.EditedDec 4 2018, 11:03 AM

The problem with #54595d and #585858 to me is that they are too similar to the black in a summary text. The link is then even more hidden. A gray colour right in between white and black it should be. Is it such an important part of the line we need to achieve AAA compliance?

Dvorapa added a comment.EditedDec 4 2018, 11:06 AM

The original colour seems ok to me, since it passes at least AA for both black and white, maybe just a slightly darker, like #71767C (right between black and white on WCAG scale) or #70757B (still AA compliant for both black and white).

stjn added a subscriber: stjn.Dec 4 2018, 2:31 PM

In addition to the pre-existing accessibility problem with the specific gray, it's now also a link that isn't super discoverable. Many editors found making the link blue (like normal) excessive, and overwhelming, creating a "sea of blue". The most important argument I was convinced by was:

We could’ve just made a link discoverable by people with original colouring on any active states like was proposed by me originally. Although a selector for this would be pretty bad to implement with something like .autocomment a:not(:hover):not(:focus):not(:active):not(:visited) (maybe someone can propose something shorter).

Agree with @Volker_E about other solution being proposed here.

Updated the screenshot in the task.

TheDJ added a subscriber: TheDJ.EditedDec 5 2018, 9:23 AM

@stjn I just tested .autocomment, .autocomment a:not(:hover):not(:focus):not(:active) and I kind of like that..


Here i am hovering the Documentaries section link.

Isarra added a subscriber: Isarra.Dec 5 2018, 6:53 PM

Just to make sure it wasn't missed, in the other ticket @Jdforrester-WMF raised a concern with using :hover being problematic for people on touch devices in T165189#4790357 but I believe @stjn addressed his concern T165189#4790562 by noting that it's not just hover, it's any active states including :focus and :active.

@stjn I just tested .autocomment, .autocomment a:not(:hover):not(:focus):not(:active) and I kind of like that..

I played with it a bit and like it as well. I can't speak for whether it meets our accessibility needs/standards though.

chelsyx removed a subscriber: chelsyx.Dec 6 2018, 2:01 AM

What about additionally wrapping the arrow or everything else into an extra element, to make the arrow always blue (and thus easily discoverable as link), like before? That way users without ability to hover over the link will still be able to recognize it as link, and combined with the "turn blue on interacting" above will quickly learn that the whole section name is the link.

TheDJ added a comment.Dec 6 2018, 9:31 AM

I just noticed there is a bit of precedent for this styling in the StructuredDiscussions UI, in their history, reply and thank links.

Just to make sure it wasn't missed, in the other ticket @Jdforrester-WMF raised a concern with using :hover being problematic for people on touch devices in T165189#4790357 but I believe @stjn addressed his concern T165189#4790562 by noting that it's not just hover, it's any active states including :focus and :active.

@stjn I just tested .autocomment, .autocomment a:not(:hover):not(:focus):not(:active) and I kind of like that..

I played with it a bit and like it as well. I can't speak for whether it meets our accessibility needs/standards though.

Yes, anything that relies on interaction before revealing itself to be a link is not discoverable for people on touch devices (except for a rare few odd devices which we can disregard). That means that any system that only shows the link via some form of interactive element – be that :hover, :focus, or :active – is insufficient.

Anomie added a comment.Dec 7 2018, 5:58 PM

Yes, anything that relies on interaction before revealing itself to be a link is not discoverable for people on touch devices [...] That means that any system that only shows the link via some form of interactive element – be that :hover, :focus, or :active – is insufficient.

On the other hand, that depends on the extent to which immediate discoverability is necessary. While clicking the link to get to the section is a nice shortcut, it may be that everyone discovering it isn't so needed that it outweighs the concerns over emphasis. As @TheDJ noted, there's precedent for that in Flow's interface.

Yes, anything that relies on interaction before revealing itself to be a link is not discoverable for people on touch devices [...] That means that any system that only shows the link via some form of interactive element – be that :hover, :focus, or :active – is insufficient.

On the other hand, that depends on the extent to which immediate discoverability is necessary.

Given that the near-universal consensus to the change was "wow, that's clickable?!", clearly the answer is "quite".

stjn added a comment.Dec 7 2018, 6:12 PM

Given that the near-universal consensus to the change was "wow, that's clickable?!", clearly the answer is "quite".

We can’t say for sure whether it was because the arrow was so small or because users generally don’t know where to click. Implementing affordance for actions should be theoretically enough to make it discoverable for now, and then it could be revisited.

Absolutely. The two standard design affordances on the Web for "this a thing you can click and it will change the page somehow" are blue coloured text with a hover underline effect, and a graphical representation (to some level of abstraction) of a button. This discussion is proposing doing neither of those things.

Anomie added a comment.Dec 7 2018, 6:34 PM

Given that the near-universal consensus to the change was "wow, that's clickable?!",

Hardly. I did see a number of people with that reaction, but on the other hand I saw a similar number (if not more) criticizing the resulting sea of blue. Some people even did both.

Really, the real near-universal reaction seems to have been to not say anything about it either way. We only see the people who felt strongly enough to comment, whether because they didn't know the arrow was a link before (despite it having been blue!) or because they didn't like the new swaths of blue.