See question at T163916#3214766.

I used this feature. Here's some primary evaluation and problem statements

1. The icon for code highlighting is ambiguous/cryptic. code highlighting icon can be derived from "highlighting" or "code" or both. see recommendations below

2. The states for enabled disabled are ambitious. the colors turning rainbow is not super accessible as well. The issue here is disable state shouldn't look disabled because the action isn't a disabled action. the action is "to disable" something. so we need both states to look active but distinct

3. the tooltip. for lack of our own instant tooltips it's okay to fallback to OS level tooltips. the tooltip text should refer to the feature by "syntax highlighting" vs "codemirror" as a proper noun. it will set better expectation. this feature doesn't need to be branded as it's a utility feature with 1 touchpoint.

4. Position: This is odd man out situation. the syntax highlighter is a "view mode" which is related to the "display" of editing content. but it's sitting between "insert content" menus like bold, link, citation, insert media. the same reason it's the only button in that space to have 2 states, active and deactivate. I would recommend moving this button on the right hand side next to the Visual Editor button. both of them can be grouped together as they relate to display and not insert. Toolbar tools should be grouped by their functions.

Recommended design based on above points
https://wikimedia.invisionapp.com/share/25BK644SD#/232026363_disable

1. button moved to right
2. new icon for code highlighting includes, yellow highlight plus {{}} code
3. active state can be used by colorblind individuals. it uses the toolbars 3d nature to show a "pressed" state

Feedback about actual syntax highlighting, fonts, color, and hierarchy choices to come after this.

Details about the icon from Nirzar:

https://zpl.io/Z1rswaj
https://zpl.io/Q7ApN
both icons.

The css for pressed background:

.pressedbackground {
width: 39px;
height: 33px;
background-image: linear-gradient(to top, #ffffff, #edf4fa);
box-shadow: 0 -1px 0 1px rgba(255, 255, 255, 0.5), inset 0 1px 3px 0 rgba(106, 145, 163, 0.45);
}

In T163919#3233162, @Nirzar wrote:

I used this feature. Here's some primary evaluation and problem statements

1. The icon for code highlighting is ambiguous/cryptic. code highlighting icon can be derived from "highlighting" or "code" or both. see recommendations below

While I agree that it is, in a way, code highlighting, but I am pretty sure most users don't see wikitext as "code". I'm afraid the curly braces can be somewhat confusing and might lead people to think they are for switching between VE/wikitext editor (which employs a similar icon [[ ]], although in a dropdown).

@Niharika: Let's move discussion about the icon to T164441.

Some points for Tuesday's design review with Nirzar and Volker:

• Icon and toggle state?
• Gray background behind asterix
• Blue background behind links -- helpful or not?
• Accessibility concerns for grayed-out comments -- too light for people to see?

• Gray background doesn't seem useful to me.
• The “blue” background behind links is a PNG, which need, again, is more than questionable.
• For the low contrast of HTML comments' color coding, currently #aaa. The recommendation here would be #72777d from our color palette, as it is sufficiently lighter than text color and fulfills WCAG 2.0 level AA contrast ratio.

https://wikimedia.invisionapp.com/share/25BK644SD#/232930653_default

^ here's the flow and UI based on the conversation with @kaldari and @DannyH

wait for 1s when you click on the link. a popover with first time user shows up explaining what's the new tool. you can say try it or no thank to set expectation around what the feature does

@Nirzar's mock fulfills the consistency needs from my perspective perfectly. Good to go and forward-thinking in regards to the new Wikitext editor.

@Volker_E: I tested out using #72777d for the comments, but this had the unfortunate affect of not having enough contrast between the regular text and the comment text. See the following screenshots:

#aaa:

#72777d:

I found it much more difficult to distinguish comments while using #72777d. In the first screenshot, I can instantly recognize 3 comments in the paragraph. In the second screenshot I have to scan through the text to find them.

@kaldari There are a few contrast issues with the current color scheme from a short accessibility test:

• Apostrophs
• Bold
• List headers
• Headers
• etc.

It has to be clear to us, that with not conforming to the contrast ratios, people with visual impairments, but also in cases of usage outside in the sunlight, users are running into readability issues or worse, are excluded from the syntax highlighting.
It's clear that the contrast difference between #72777d and text color will be lower than with #aaa, from the screenshots I'm not convinced that it's such a negative impact compared to being exclusive on the feature.

@kaldari I think the #72777d screenshot is pretty easy to parse; I didn't have any trouble with it. There might be a difference between our displays, maybe we can look at it side by side when we're both in the office. :)

@Nirzar The popup makes sense, I really like it. Can I ask why we're using yellow as the highlight color in the popup? We're not using yellow in the actual highlighting.

@kaldari There are a few contrast issues with the current color scheme from a quick accessibility test:

• Apostrophs
• Bold
• List headers
• Headers
• etc.

It has to be clear to us, that with not conforming to the contrast ratios, people with visual impairments, but also other users in certain use cases (ex: outside in the sunlight) are running into readability issues or worse, are excluded from the syntax highlighting. Syntax highlighting might serve as added feature and the normal product target of making it conform to WCAG 2.0 level AA success criterion might not apply here from a product specific perspective.
To add to Danny's point, it's clear that the contrast difference between #72777d and normal text color will be a bit lower than with #aaa. But from the screenshots I'm not convinced about its negative impact compared to being not inclusive on the feature.

The popup makes sense, I really like it. Can I ask why we're using yellow as the highlight color in the popup? We're not using yellow in the actual highlighting.

Highlight associates with florescent yellow color...
just for example https://www.google.com/search?q=highlight&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjFoe_3hebTAhUHqFQKHc_GALgQ_AUICigB&biw=1280&bih=676

It's been used in UI for highlight intent a lot. most ui frameworks like bootstrap use it as well. It's just indicative and not actually representative of real colors. yellow stands out to highlight. in reality, this feature is more like syntax color coding and not highlighting but we use the word due to it's strong recall with programming nomenclature.

In that definition of highlighting, the text is black and the background is yellow. You don't write yellow words on a white background, because it's hard to read. This treatment might make people think it's going to make some of the text less readable.

This treatment might make people think it's going to make some of the text less readable.

I doubt that. we will need to usertest it.

Maybe just the same thing with light blue instead of yellow?

If that doesn't work for you and you're getting frustrated, then we can go with yellow, and it'll be fine.

I updated some tickets based on the above conversation:

T164441: Replace CodeMirror icons with new icons
T165001: Take out gray background behind list bullets in syntax highlighting
T165003: Syntax highlighting popover for first-time user

I don't think we've reached a decision on the gray color for comments. How do we move forward on that?

If the rest of y'all agree that #72777d looks fine for comments, I would be fine with changing it as well.

I would also love to know if @Pastakhov (the main developer of the extension) has any thoughts, concerns, or suggestions about the changes above.

I agree with everything except the color for comments.
#72777d looks very good but it is a problem. It looks too organic, and it does not allow you to easily visually separate the plain text and comment text. Of course this depends on the used fonts, display, light, settings and tastes, but IMO #72777d is too close to having a too low contrast.
Perhaps, as a compromise we could use # 969696.

@Pastakhov The issue with anything higher-brightness than #767676 or our slightly adapted to our color palette #72777d on white background is, that it doesn't provide the success criterion 4.5:1 contrast.
It's a difficile product decision, but in our Wikimedia Foundation web products we generally aim to conform to WCAG 2.0 level AA success criteria.

@Volker_E IMO comments are inherently very close to part of an inactive user interface component (in Incidental) that is excepted from requirement to have a contrast ratio of at least 4.5:1.

We can also use #a2a9b1 (B50 from wmf colors) which is not AA compliant but darker than what we are using right now. this is very similar issue like the placeholder text where we needed low contrast for better functionality and distinction.
Adding this color with font style oblique will create enough contrast between two

@Volker_E this would be compromising our AA standard, if that is a deal breaker then we can just do #72777d + oblique

it looks like this ->

Going lighter than AA compliance means that there's a certain percentage of users who will have a hard time reading comments, especially in sunlight. (I don't know what that percentage is.) Whether we're okay with that depends on whether we think it's important for people to read the comments or not.

I think the #72777d + oblique looks good, the italics set the text apart.

@Pastakhov You're referring to the “Understanding Success Criterion 1.4.3” section:

“Text or images of text that are part of an inactive user interface component, that are pure decoration […] have no contrast requirement”.

From my personal experience in working with affected users and my understanding of the ARIA spec and it's purpose for implementation, this exception for disabled UI elements exists as they should not be needed to finish a user task. If such an element becomes active, it will need to provide sufficient contrast and will therefore turn readable.
A comment on the other hand might be needed to sufficiently understand the content around.

@Volker_E From my point of view, we need several themes T163533 in any case, and the question is which one to use by default. The one that will be more convenient for most editors or one that will be readable by all.
And why aren't we getting input from real Wikipedia editors? I reason more as a software developer, and maybe for Wikipedia editors it's actually more important to read the comments than to easily separate they from the regular text.

@Pastakhov I agree with all of your latest comment. The difficult product decision is how to best-satisfy the 80% without leaving the 20% behind (numbers arbitrarily chosen). Syntax highlighting is already an added feature, you can always go black (dark grey)-on-white without it.
A way to proceed could be having the default theme as high contrast as it's not hurting the syntax highlighting for the majority and having an alternative theme fulfilling level AA contrast ratio.

@Nirzar & @DannyH We've just removed all of oblique/italics in UI element definitions in M101 and OOjs UI as it doesn't play well with Chinese/Japanese/Korean characters.

@Pastakhov I could go and get five users to weigh in, but I don't think their opinion would be much different than the opinions of the five people looking at this right now. This is a situation where we should trust the designers and the standards; that's what they're for.

@Volker_E We already use italics in the feature to show text in italics. Does that make a difference?

There are basically two different use cases for comments in Wikitext:

1. To offer guidance or suggestions. This is a similar use case to placeholder text. Even if it isn't readable, the user can still successfully edit the article.
2. To temporarily remove content from an article. This is similar to an inactive user interface component. The content is disabled and there is no reason the user needs to interact with it. They are free to ignore it and edit the rest of the article.

Thus I think Pastakhov has a point that maybe comments should not be required to meet the contrast requirements. Perhaps it would make more sense to have them match our convention for placeholder text (#a2a9b1). As this is a purely opt-in feature that can be easily turned off anyway, I don't think we need to be as strict as we would for other features.

What about using a background color to distinguish comments instead of the text color?

Suggestions for background color:

• fff0d0 (wikEd)
• fc3 (Visual style guide)
• fef6e7 (from M101 supplementary colors)
• the color for highlighted (under text highlight) in M101

We've just removed all of oblique/italics in UI element definitions in M101 and OOjs UI as it doesn't play well with Chinese/Japanese/Korean characters.

Comments are not UI elements. they are content elements. also i don't think we should be not using ligitimate solution for all becuuse it does not work for some. let's have appropriate solutions to each. we can do oblique for latin, Cyrillic, Indic etc . it's an additional styling element.

What about using a background color to distinguish comments instead of the text color?

We are using background color for other elements such as links, images etc. because they are usually short. not sure how that will work for long comments. but we can try

I'm leaning towards Pastakhov as well. I think color coding text is an optional feature which relies heavily on ability of users to identify colors.