System messages need identifying icons (WCAG 2.0)

I could swear that yoroy already made icons for these messages in some issue somewhere. I even thought they were already committed. Hrm...

Yup, and I even think we had a design already that was near commitable, just never happened as far as I know.

webchick, bojhan, do you mean #218674: Update watchdog-*.png status icons ?

[edit] There is another proposal for a consistent core icon set in #735656: Iconize most important Items, #720528: Softfacade icons, rework some of them into protocons? and #606490: Drupal GPL icons - a softfacade initiative.

Mine are here: http://drupal.org/project/protocons

Sub.

@yoroy - I like your icons & would love to see them used more and more consistently in D7

Cliff: I did consider the octagon shape but in the end decided to follow convention (do a google image search on "error icon") and go for the circle.

Oh man, I wish this would go in core (as in system core) and not just Seven - save me loads of fecking about with my starter themes trying to decide on decent message styles and icons etc. I'm trying to chase Seven with the style changes right now so I can be consistent with the default admin theme - be splendid if I didn't have to ;)

Check this out.

• Each message gets styled individually, instead of the whole group.
• Border around faint box to stop more death to eyeballs.
• Icons to the right.
• Form validation error colour updated to match message error.

I would say, move them to the left (it clearly has to be left aligned from a design perspective, it makes no sense to have them on the right) - to achieve this remove the color left-bar.

I would avoid using core its icons here, we kinda already know those look bad. I would suggest to try out:

#606490: Drupal GPL icons - a softfacade initiative and http://drupal.org/project/protocons

+1 for icons on the left
+1 to remove left thick border
+1 for colours saturation (almost none background, i.e. "calm" one)
+1 for 1px border (imo, it's impossible to keep UI "calm" with calm colour fills and without this border)
Actually, only 3 icons are required: [ x ], [ ! ], [ v ].

Btw, that individual separation of messages looks not bad at all, imo. It ephasizes "multipleness" of a problem/issue..

Any screenshots?

Something like that.
(Sorry for icons gray background, it shouldn't be of course).

Remarking this as a bug. Although this is not a critical bug, accessibility problems are bugs and not tasks.

The title is currently a task - you need to rewrite it.

@jbrown
Perfect.
Just for a long message (with more than 1 line) icon should be aligned to top.

Okay - I've implemented it for all themes.

Hopefully I haven't cocked anything up!

I'm really not a big fan of the 1px border. We should probably change those icons too, but this can be done in another issue.

But the lack a border around the faint boxes surrounded by white is the work of Satan!!

Maybe, but it looks better :)

Yeah, I don't think the borders are going to pass design team review. Didn't know the design team members were agents of The Dark Prince, now it all makes sense. :D

(kidding ;))

yoroy/bojhan, could we get a definitive mockup/spec here, so we don't eat up a lot of time trying different solutions?

Ia iak sakkakh ia sakkakth shaxul. Ia kingu ia chtulu azbul ia azabua.

1. Border does look too contrasting. Should be softer. But still should be present. Taking into account such a pale background its absence is doubtful.

2. Icons shouldn't be "sexy". There's no sex in computer icons. They should be as generic as possible. Current D7 core watchdog icons are quite sufficient (but have PNG alpha channel transparency incompatible with some browsers and should be redone). But let's try the other icons suggested in this issue.
They are: http://drupal.org/node/606490 and http://drupal.org/project/protocons
They are almost identical (for 3 principal icons discussed here: error, warning, ok). Still softfacade's look more harmonic, imo (for instance, protocons error "X" is too big, and ok "v" is awkward).
But anyway both of the sets are inappropriate here cause they use complex shading and multiple 24 bit colours. For colourblind people they will look more ugly than generic ones. Although there is still an option to convert their colour depth to 4 bit. Also, they are not proportional.

3. Colours should be equal in terms of brightness. Once again, for some people there is no colours at all. There is only brightness for them (aka shades of gray).
Red (rgb 255,0,0) and Green (rgb 255,0,0) are not equal in brightness. You can clearly see that while printing colour documents with a standard black&white laser printer.
To be exact,
Red rgb 255,0,0 is equal to rgb 77,77,77 in grayscale palette,
Yellow rgb 255,0,0 is equal to rgb 227,227,227 in grayscale palette,
and Green rgb 255,0,0 is equal to rgb 150,150,150 in grayscale palette.
So colourblind people wil see almost black silver and gray accordingly (see attached Image 1).

First of all it is necessary to decide what will be the brightness without colours - in grayscale only.
I'll consider rgb 240,240,240 as a background, rgb 230,230,230 as a border (to make it less contrasting), and rgb 128,128,128 as icon filling colour (see attached Image 2).

Then it is necessary to convert this brightness to rgb colour mode.
It results to:
Red background - rgb 255,233,233
Yellow background - rgb 255,255,128 - (note: this will be unbearable for normal people, so we have to make it rgb 255,255,218; colourblind people will see almost a white background, and that's another reason for a border here)
Green background - rgb 218,255,218
Red border - rgb 255,216,216
Yellow border - rgb 240,240,218 (the same problem as in background, so we need to reduce yellow intensity from max 255 to 240)
Green border - rgb 194,255,194
But, it might be a good idea not to have colour borders at all. They can be light-gray for any type of message.

4. Text colour should be default. No colour for message text. Firstly, there are already enough colours and contrasts. Secondly, due to the above-mentioned grayscale brightness.

All that combination is in the attached Image 3 (with light-gray borders) and Image 4.

@mertskeli Do you happen to have a patch? I am trying to try this out, ie getting a feeling for it by browsing to a bunch of errors/ warnings and success messages :) I do already favor number four, but I feel its not "quite there yet" for example ! its shape is a little bit too rounded and ! isn't standing out enough.

I don't think we have to worry too much about accessibility here, as the icons themselves are far better affordance then colors.

Sorry, I do not know what is "patch" or how to have/make them :) I know most of the html/css tags but not a single php code. I have taken screenshots from my current D7 localhost test site, making manual changes to css.

For icons I absolutely agree - they are not perfect, neither in shape nor in colours. I just took softfacade icons to make screenshots, for general positioning and colour matching.
There is also an interesting article here: http://msdn.microsoft.com/en-us/library/aa511277.aspx

A patch http://drupal.org/patch is basically a standard way of sharing code modifications with other core devs so we can see what you see. :) It takes a little bit of wrangling to get set up to make them, but once you are, you can do anything! :D

But, failing that, a manual "I changed XXX to YYY in file ZZZ" would cut the mustard, and allow someone else who's set up for it to make a patch.

I highly encourage you to learn how to make and apply patches, though, since it'll make code sharing with other devs a lot easier. You can always come on IRC in #drupal-contribute to ask for a hand.

Lots of us can write the patch, can someome summarize what needs to be done design wise.

I think changing the icons that come with core can be discussed elsewhere.

I made some improvements to my patch:

• curved corners
• darker text - (also helps colour-blind people)
• border for error is lighter

Re: #33, corners should not be rounded in Seven, and borders, if they are indeed kept, should be lighter than the screenshots you provided.

Sorry, although long titles are great - they suck for attracting people, it makes em feel heavy and honestly there is no need to sacrifice scan ability (of mine and many others their issue queue) here either.

@jbrown Can you try to make http://drupal.org/files/issues/Image%204_3.png your patch?

The colours in #27 are not pleasant (screenshots attached).

No one like the curves in #33?

@webchick - Thank you for your help. Maybe I'll try. Sometimes I do feel myself handicapped here.

@jbrown - The colours in #27 are not pleasant - Too pale?

@Cliff
I agree, in terms of icon colours there are no problems so far.
But still the graphics itself can be modified. D7 warning icon is just bigger than the other two icons (although that's not so critical).
As for background+border colours, we need to decide it.

@Jeff Burnz
1. We need 3 icons: watchdog-error.png, watchdog-ok.png, watchdog-warning.png. All 16x16 px (right?), 4-bit colour depth (4-8 colours in each palette).
2. We need 3 exact colour sets (background + border) for every type of the mentioned 3 message types. In RGB and HEX.
3. Finalize CSS values (padding, etc.)
4. Make a patch.

OK, well I don't want to comment on design issues here or get involved with building icons etc, and if someone supplies the icons and can't write a patch I'm more than happy to.

I updated the colours from #33 and removed the curved corners (although I do prefer them).

There is now a consistent hue for each message type:

status - 90
warning - 53
error - 16

So, for each message type, color, border-color and background-color have the same hue.

@Cliff - the reason the backgrounds are so pale is #639368: Contrast between error and link colour causes death to eyeballs

It also looks nice bold...

Another screenshot.

Its a shame to get rid the padding on the left IMO - that with the icons on the right did look really distinctive IMO.

Like in #11? I totally hate that now.

I think it is best with the 2px border and curved corners, but not the bold text.

Attached is the patch and example screenshots.

The patch also puts the icons in messages for Garland and Bartik.

@41 - Looks good. i'd vote for this as the final version. Still I believe the best option is to use silver border for all messages. And default font (not coloured).
@42 - Imo, overemphasized. Colour + border + icon is more than enough to attract.
@47 - The majority says the border is not necessary at all. But seems that the same majority agrees for it if it is not too contrasting.
As for 2 px, imo there's no necessity in it. 1px will do.
For rounded corners, well it is not bad. But I believe it depends on theme design. If it is in concordance with the theme's design it can be used. And contrary, if a theme is "angular", system messages shouldn't be styled differently.

+1 #41, I dont think seven should have rounded corners on messages and the fat 2px border looks a bit heavy for this theme. Good work!

@#39.1

Sorry, forgot to replace blue for transparent.

Icon colours:
ok = green / rgb 0,128,0 / hex 008000
error = red / rgb 255,0,0 / hex ff0000
warning = yellow / rgb 255,255,0 / hex ffff00
border = gray / rgb 128,128,128 / hex 808080
checkmark, cross = white / rgb 255,255,255 / hex ffffff
exclamation mark = black / rgb 0,0,0 / hex 000000

Looking at this fresh, I don't think 2px borders and curved corners is right.

I'm most happy with #41.

I think the the changing the icons discussion should be a separate issue. There are already several.

Let's temporary change the issue title.
Seems there is no decision whether we need such icons.

Question: Do we need icons in system messages?
Answer options:
1. Yes
2. No
3. Other

---

Count:
1 - 0
2 - 0
3 - 1

There is no discussion: we need icons or text here to satisfy accessibility rules of WCAG. Given that nobody is suggesting adding text here, we need to go with icons.

The screen shots in #47 look great.

I'm not sure why there would be resistance to adding these icons.

This is a bug.

I just returned from a week's holiday and I'm a bit worried that this issue is moving in several directions at the same time. Summarizing, the following topics are being discussed:

1. Should messages have icons?
Answer: yes, see #57

2. Which icon set do we use?
Opinion: I like Yoroy's Protocons.

3. Should messages have a different background color?
Answer: In any case we need to use accessible colors. The current colors were carefully selected for accessibility in #639368-88: Contrast between error and link colour causes death to eyeballs.

4. Is this topic about the Seven theme only, or about Drupal core in general?
Opinion: We need both good styling in core (so the default is accessible and looks OK) and overridden css Seven (to match the design even better). If this topic fixes both at the same time, that's fine by me.

5. Should messages have borders?
Opinion: I think they should in the core default, but not in the Seven theme because of Mark Boulton's comment in #639368-43: Contrast between error and link colour causes death to eyeballs. For Seven, I prefer the styling that came out of that issue, provided that it can be combined with icons.

6. Should message borders have rounded corners?
Opinion: No, and definitely not as default. Themes can add their own rounded corners when appropriate. Rounded corners make no sense as default styling and they look terrible in Seven, Bartik and Garland.

Is this everything, or am I missing something?

I don't think we should discuss changing the icons in this issue. When a patch from this issue gets committed, then the current icons will be seen and people will be motivated to change them in a new issue.

I just tried HEAD without my patch and it caused death to my eyeballs. The background colour is so faint that the boundary of the edge of the box is not clear. This makes it extremely unpleasant to look at. Borderless boxes are fine, but they don't work when they are this faint. The borders are essential.

I have updated my patch in #41 to work with file upload errors and tabledrag warnings.

When a patch from this issue gets committed, then the current icons will be seen and people will be motivated to change them in a new issue.

We don't have time for "in a new issue". We need to get Drupal 7 out the door. Fix them once, here, or not at all IMO.

And I believe Dries expressed interest in Protocons in the other thread, so let's just use those.

*** I hate issues like this ***

So here is my try to get it done.
Working fine except the block table drag messages, those ones have no styling.
I added new icons to misc folder.

Resized them to be as big as the previous ones.

Screenshots attached.

Forgot the images.

*** Why don't we support rar??? ***

Ok I repared block.js.
So everything is working now.
I rly like this and I don't like a new discussion :)

I grepped for the div that was causing problems.
Only block.js had it.

I applied it to my sandbox http://drupal7.dev.openconcept.ca/

It looks good to me. I've attached screenshots for core themes.

forgot this one. anything else need to be done before it's marked rtbc?

Maybe someone can tweak the paddings for garland and bartik a bit.
It's not so nice to have the icon and the text not being aligned.

Sorry but the icons are beside poorly implemented (in terms of shape I do not see them similar to yoroy's library) also I think in terms of value #606490: Drupal GPL icons - a softfacade initiative brings a lot more, why?

1. The gradient in those bring the icon more towards the front.
2. The outline enhances this effect, creating depth in the icon.
3. There is more space around the !, V or X, allowing it to breathe more and therefor look better.

I mean I love yoroy's work, but at the end of the day holding my quality stick up being transparent - I have to side for softfacade ones.

So setting this back to needs work. In #28 I expressed that softfacade has some small issues, but I feel we can fix that easily - depending on how well it matches with the current proposed background. So, I am sorry to change the direction of this issue here but I feel it got somewhat derailed on #36 not implementing #35 and some people having a from a design perspective not argumented preference for protocons, this includes Dries :P.

Regarding my preference for Protocons:
- IMO, the softfacade icons are too glossy. It reminds me of the Joomla dashboard.
- Sure the softfacade icons bring a lot more, but I'm not sure we need all of it. I'm a bit worried that some module developers cannot resist the abundance of available icons, so we'll see them popping up all over the place (possibly out of context).

Couple of things:

1. This issue is about adding icons to messages, not about changing the output to a list. Why are we doing this? The original issue appears to have been interpreted as requiring an icon for every message - really? Why is not sufficient to have one icon to denote the entire group? A visual border of sufficient contrast can contain the group. I've been doing this in contrib and professionally for years and never had this raised as an issue by a single client - including government and international .orgs with accessibility very high on their agendas.

I raise this now because in reading through this issue I cannot see where this has even been discussed, at all. It just got stuck in there and stayed, but this represents a quite major change in the markup and display of messages - both for sighted and unsighted users.

I much prefer the old markup - multiple messages of the same type grouped within a DIV, in a list, with a heading, and add a single "type icon" to the top left corner to denote that these are "warnings" etc. I do not think this list markup approach is an improvement, if anything it simply ads yet more lists to Drupal core output, not such a good thing for many screen reader users who now are forced to listen to ...

"Heading level two", "Status message", "List item containing one item", "List item one", "The update has been performed."

As opposed to:

"Heading level two", "Status message", "The update has been performed."

2. system-messages.css is missing a proper doc block and the standard CVS tag for css files /* $Id$ */

3. protocons-[type].png - why the "protocons" namespace - its meaningless in Drupal core and pertains only to something that exists in contrib - if anything it should probably be message-error.png etc.

4. If this list markup concept were to stay there's no need to repeat the type class on every list item, it can be set once:

    $output .= "<ul class=\"messages $type\">\n";
    foreach ($messages as $message) {
      $output .= " <li>$message</li>\n";
    }

@Cliff Look, I am all for keeping it simple but also all for keeping it "beautiful" all your arguments are about accessibility, not the visual values. This is not a critical issue so won't hold up the release.

So you are saying softfacade are hard to see, or could be? I don't see how the gradient would effect low vision, since the gradients are very subtle (and could be more if needed). Your implying a lot of things, which to me don't seem inherent to to this icon set as opposed to yoroy's. Can you do the testing required, and simply see what parts don't evaluate well - and we can fix them?

@marcvangend I understand your point, I think part of it is changing the gradient only a little bit, the shapes are good. Lets not worry to much about what developers might and might not do :) - we can't be in that guessing game for this one, as there are no real clues as to what they will do.

Nice overview mertskeli!

softfacade++

It seems softfacade as a whole has been delayed to D8 for some reason: #606490: Drupal GPL icons - a softfacade initiative

Perhaps we can just steal these three icons and put them in a single image file.

I agree with #73.1 - its not in the scope of this issue. I think for Drupal 8 we should do this. The form system should group its own errors into one message, but thats a different story.

A good example of where it makes sense to not group messages is http://drupal.org/files/issues/Multiline%20Error%20-%20Seven.png

Based on #77, I agree with Cliff and would my vote would go to Protocons because they are more contrasted and as a consequence easier to see.

@Cliff Sorry, but I feel its as much of a usability as an accessibility argument. I can invest my own time sure, just not an expert on it so excuse me for asking the one with the expertise.

When it comes to different themes, I am somewhat on the fence why its not the same case with other icons - the gradient doesn't necessarily lessen the saturation? I mean, I tested it with a few themes now for D7 and I didn't find any occurances where the contrast was very low, then again thats not a WCAG compliance.

@Cliff I am very sorry you feel that way, but I find it somewhat weird to say I am blocking issues? (Also find it a bit unfair :( given how much time I spend working on finding a good solution in those) I mean at the end of the day I am as passionate about making Drupal beautiful and unusable as you are about making it accessible. Whenever those roads cross we should consider each others arguments and find a solution, not trow them away as being subjective or not objective? I mean my arguments really aren't unfounded, I clearly stated 3 arguments why I found softfacade better - to now those arguments haven't been discussed at all.

http://drupal.org/node/874370#comment-3351052 Although right, is indeed somewhat misleading as they are not all the size.

Ok, so lets round this up again and get some scope into this patch:

Icons: Looks like the majority including webchick like the Protocons. Lets go with the Protocons - simple, clean, accessible, beautiful.

Changing to a list: Not workable, some situations where this breaks down. Lets drop this from the patch.

Core/Seven (scope): Seven should, ideally, simply inherit cores styles, which means the styles and icons go into core e.g. system-messages.css and misc etc, with styles removed from Seven.

watchdog message & icon usage: In some tables icons are added using img element - one thinks we need to update these to use the Protocons (and kill the old watchdog icons). Also some colors conflict with standard message colors, such as the 404 watchdog error being green, when it should be the warning color (it has a warning icon) - the green is actually the same as the OK tr background color in the Status report table - not good.

Update Status table: Issue here with color I believe, while you can read through the table, its not at-a-glance information. Needs the icons like normal messages (but smaller icons, like the watchdog size icons).

Webchick said earlier to just fix all the issues now, here - these are all issues pertaining to core messaging. The earlier bikeshedding over color and icons is just soaking up time and space when there are simply so many other horror stories surrounding icon usage and color issues in messages, table messages, status reports and so on - for example most of the styles for status reports in admin.css look totally redundant (need confirmation before removing, could be another issue?).

Like I've said earlier, I dont really care that much about the style, although I do prefer the protocons, but I havent followed the colors debate that closely, all I am interested in is seeing the styles and icons are consistent and the CSS is less not more - and switching to core pushing out something accessible that looks good (nothing wrong with this for messages - these are key to accessibility). Personally I think its stupid to have core doing one thing only be overridden by every core theme except for stark. Seems like needless duplication for something that can be consistent - like toolbar.

What this patch does is pull all this together into one scope crept big patch - to unify Drupal core message colors and icons. This is probably needing work - its a big patch and I have included many screenshots to show what this does. I have not accounted for Bartik nor Garland here, they might need some work - right now just focusing on core (system, admin, dblog etc) and Seven (mostly removing styles).

Ok, lets see if this bird can fly. Give me hell ;)

Ok, here by my unsubscription from this issue. With yoroy away, the nice words of cliff, I am the only maintainer and I am totally getting sidetracked on all decisions here including from our commiters who provide no design argument. The whole community in this issue is avoiding to have a design discussion and rather goes, ohh I like this - patch.

Nobody working on the patches seem to care about the style and that makes for a mediocre core in terms of visuals.

Oops

Bojhan, patches are our way of discussing things in "code". I think you miss the point of the patch - to show the rather messy situation that is Drupal core messaging - some places uses img element for icons, some use CSS background image, some use core images, others have none, the same color used to denote two different message types, the CSS is all spread out in multiple modules and stylesheets with inheritance issues and difficulties, some elements have classes missing and it goes on, and on.

I back the protocons -I think they look clean and simple and suit the Seven theme very well. Cliff has outlined several times why the softfacade icons could be problematic, webchick has made strong indication we should use the protocons. I have to use something in the patch so I make a well reasoned and thought out design decision.

cross post with bot.

Leave out simpletest changes see if this can pass. Use the protocon image pack in #83

Bojhan, I really respect the work you're doing to make Drupal more usable and beautiful, but I think you're putting way to much emphasis on design arguments. Suppose that 7 out of 10 people would say they prefer Van Gogh over Matisse, without giving design arguments - would that be meaningless to you? Not to me anyway. I honestly believe that the choosing happens before you put the arguments into words, and often arguments are made up after the fact because we don't dare to trust our intuition. I agree that arguments can add value to an opinion, but don't dismiss opinions without them.

Ok, I want to see the patches here, but not sure what I'm supposed to see here. In Seven it looks all pretty bleak. I tested it in Bartik too.

Where did all of the theming, colors, icons go?

cleared cache?

I disagree with Bojhan pretty often, but I'm absolutely sure he has that inborn feeling for what "looks good".
In maintainers.txt one can see yoroy and Bojhan listed as user experience and usability topic coordinators. It is no way accidental. Let's accept it and respect it. Otherwise, everything will turn into chaos.
Sometimes I completely disagree on this or that issue. In such cases I tell myself: "I don't care. I'm always free to do it MY way in MY website."

@Bojhan
No, you can not quit. Seems yoroy doesn't care about this issue. So you are the only one to blame, and this issue should be assigned to you.
Sometimes we are a bit rude. It's ok, it's a normal clash of male ambitions, a normal defense of one's point of view. There are no girls here.

I agree that we spent too much time discussing such a simple issue. It's time to make a decision. So, please, announce the verdict :)

1. What icons will be used?
a). Current D7 core
b). Current D7 core modified
c). Softfacade
d). Softfacade modified
e). Protocons
f). Protocons modified
g). Brand new
("brand new" means "other" and can be taken from other sources or can be done from scratch)

For now we have such votes:
Softfacade = 3 votes (Bojhan, jbrown, mertskeli)
Protocons = 9 votes (yoroy, Dries, webchick, mgifford, marcvangend, aspilicious, Cliff, Damien Tournoud, Jeff Burnz)
To modify = 3 votes (Bojhan, Cliff, mertskeli) - I call them perfectionists :)
So, Protocons would be a good solution (even without modification), which I'd gladly support.

2. What will be the border color and thickness? Please provide exact hex values for all 3 types of messages.
3. What will be the background color? Please provide hex values for all 3 types of messages.

So, you have all the arguements, ideas, samples, screenshots, etc. Please make the final decision.

@92 - mgifford, those messages should not be in a list - so either the patch did not apply cleanly or somethings up etc. That big patch I posted does not change theme_status_messages() like the previous patches.

It might help to break that patch up and start some new issues - there are more issues in that than we have originally been discussion (obviously), but I stuck them in because we've gotten bogged down in a design argument and need to move forward with identifying the broader issues that need fixing also (eg other places where color is used to convey meaning and need icons also).

It was likely a conflict with other patches I'm testing. I'll nix most of my sandbox & try again. The images go into misc?

@aspilicious - ya, I tried clearing the cache & changing browsers. But if you got it working then it doesn't sound like there was a problem with how it was rolled.

I'm experiencing the same problems today...
Going to try a fresh install.

I ran an update from head and was able to apply the patch in #90.

The misc-protocon-pack.zip (in #83) when extracted will contain a folder with 8 images (ok, error, warning, info in two sizes each - 16px and 24px), copy/paste those images into /misc root.

Did a re-reroll adding support for Garland and Bartik, both of which override the colors (did not touch those for normal messages), just adjustments to padding. Fixed up a small issue in the dblog reports table for Bartik (made it more consistant with Bartiks table styles).

Ok, this is looking good to me know. Must have been some wierd conflict of previous patches.

I'm attaching lots of screenshots for the other two core themes.

I didn't post a link to the admin/modules as warning messages seem to be eliminated from Garland. This seems like a strange inconsistency, but one that is beyond this issue.

Looks good to me Jeff!

Screen shot showing garland warning and OK.

Anyone on this issue @ Copenhagen?

jbrown - are you in Copenhagen, I can meet you tomorrow or any day if you want to discuss and get some work done on it.

I'll be there. We could meet in the chx coders lounge (http://cph2010.drupal.org/chx-coders-lounge) monday afternoon?

OK, chx coders lounge it is - I probably be dropping by most evenings in any case.

subscribe

I don't think the last set of icons is as helpful for usability as it could be. If I ignore color and just pay attention to the icons, the triangular one stands out as being "more warningish" than the others, which are all round. But the one with the "X" in the middle is supposed to stand out more, since it's a more severe warning. If only one icon is going to be non-round then it out to be the red one. Really though if shape is going to be used for differentiating one of the icons then it should be used on all of them.

As a reader I find icon shape by far the easiest/fastest way to notice the more important messages. When an icon is the same shape as another, it takes me an extra moment to "read" its contents. But when things are different shapes it's more recognition that reading, which is a good goal to work toward when you're designing a system of symbols.

FWIW when I think "error" I think red hexagon with a white cross, some variations here http://www.iconfinder.com/search/?q=error

@#108 - Not a bad idea. Like road signs. Different by colour and different by shape.

@#109 - Cliff, probably you could provide best hex values for icons + border + background ? (for all 3 types of messages)

And a couple of things.
1. Regarding WCAG. It's not only about colourblindness. Many of us spend a lot of time in front of monitors. LCD screens have gamma distortion, poor contrast, bla bla. Sooner or later we start to decrease the monitor brightness, and colour balance becomes more and more shifted, and those faint backgrounds become almost invisible. So I assume icons would be useful not only to colourblind but to all active computer users.
2. There are no Softfacade or Protocon icons so far. We only have the scaled-down images with all the consequences of anti-aliasing. Who will draw the final icons?

re #109 - great post Cliff, just want to clarify that Contrast-A is not a Mac only ap, its an Adobe Air ap: http://bit.ly/gpkdb

re #110 - discussed with Cliff and Bojhan last night regarding the icons - what I think we're all after here is something that has the nice looks and shape of the softfacade icons but with the clarity and inherent accessibility of the protocons.

A safe color palette is a good idea, very good, while this will be somewhat restrictive and cannot account for all possibilities it would at least give designers some direction here and save time - this is a critical hard in core at the moment and would dearly love to get this fixed before beta rolls.

So yes we need a set of icons as neither set is ideal at the moment.

Good news.

Questions:
1. What size? 16x16, 18x18 ?
2. Error & ok - round, warning - triangle, right?

@jensimmons thinks a darker background colour is good.

I've tweaked the colours and ported to protocons. The icons set from #83 are required. watchdog is also updated.

We shouldn't be interfering with the status report page.

@webchick has mentioned that we should not change the colours, so I will update my patch to the current colours and post some screenshots in my next comment.

I think it is good if each icon is a different shape.

Here's my patch with the current HEAD colours as @webchick requested - looks good!!

> We shouldn't be interfering with the status report page.

OK, we can attack it later, it has the same issue though, color used to convey meaning.

> I think it is good if each icon is a different shape.

Yes, I think very standard is:
warning - triangle
error - hexagon
ok - round

I've been updating the protocons following some of the feedback and I'll have a go at the octagon shape for the error icon. There's a bit of a white glow added to all the icons for added fancypantsness. Will have a look at which web safe colors to use for the main hues.

Yes, jeffs hexagon = octagon, so I mean octagon ;) Sheesh, sorry guys...

Problem is, at small sizes it's quite hard to discern an octagon from a circle:

@yoroy is that really a problem? Better to have an octagon at non-tiny sizes and a circle when tiny than a circle all the time, right?

Is the plain X icon a possibility, or is it set in stone as meaning "delete"?

I'm not sure we want to add 32px sizes here. But thank you very much for that color analysis, the best scoring ones look perfectly usable to me, I'll incorporate this in my next iteration. Thanks again.

+1 for getting this into D7. Great work, y'all. You've done a lot on this in just a few weeks.

I've been playing around with solid colour blocks, no borders, white text and blue warnings.

Can we all agree that #114 + protocons is the way to go?

Yes, 114 + the new protocons yoroy is working on.

Just piping in to ask if someone in this issue could take #109 and please please PLEASE put it in the handbook somewhere, so that we can refer to it more easily for others new to accessibility patches? Great post!!

I've updated my patch. It now does the following to messages:

• Seven has solid coloured boxes as proposed by Mark Boulton: http://drupal.org/node/639368#comment-3058056 .
• Seven text is now white, with bold for links.
• New simple white icons for Seven.
• Seven background colours now have maximum saturation so the white text is clear. Warnings are now blue.
• Seven required * colour and form error colour is the same as the error message colour.
• Seven is WCAG AA compliant.
• Bartik uses 24px protocons.
• Garland uses 16px protocons.
• Database logging uses 16px protocons
• All icons are CSS sprites
• Old watchdog-*.png icons are no longer required.

status-16x16.png and status-24x24.png go in misc.
message-icons.png goes in themes/seven/images.

#131, I don't think we can really go back to highly saturated boxes in Seven after the lengthy discussion it took to get rid of them in #639368: Contrast between error and link colour causes death to eyeballs. Let's stick with #114.

For a warning there is a blue message in the admin section, but in the front-end its yellow? That's asking a lot from the user (this could be the same message even...).

Also I think the blue warning message could easily be misconstrued as information - visitor information signage and icons are frequently blue. The international warning sign is a yellow triangle so I think we're really disregarding convention to use blue for a warning.

I hear what Mark Boulton is saying, but in reality its very hard to make it work.

Still backing #127 (which is #114).

Thanks Jonathan, I like the direction this is going. I didn't test the patch myself but I do have some remarks based on the screenshots.

Nice job in the new colors and icons for Seven, I think they fit that theme very well. That said, I agree with the others saying that blue may not be the right color for warnings. (I do expect to hear some usability experts saying that the saturated colors draw too much attention, especially because some messages tend to repeat themselves. IMHO, that is something the should not be solved in the message styling, but in the module code producing the message.)

In 'Seven 2.png' and 'Seven 4.png' I see that the icons are vertically centered. I think that the icon should be in the top left corner, because it looks better when the message box gets higher.

Maybe we should also have screenshots how this looks in the Stark theme, so we can see if that base styling is usable and accessible as well.

Just adding a note that I do not think that bold is a sufficient indicator that something is a link - is it important or a link? Please don't make me think.

I updated my patch from #131 to put the icons at the top, links are underlined and tweaked the green a bit.

I don't think it matters if different themes have different colours for messages. The type of message is communicated by the icon.

I couldn't make the yellow work in Seven - I like the blue.

Srry I don't like this. Just had to say this...

jbrown, if you really think that the type of message is communicated by the icon, then why use color at all? Seriously, the icon is there because we cannot rely on color alone, but color is a very strong communicator and we shouldn't confuse people. Think of traffic lights and road signs; red = stop, yellow/orange = warning, green = OK, blue = information.

An X does not indicate an error - a white cross within a red octagon does. This is the combination of shape and color that triggers the brain to respond. An X on its own may just as well entice the user to click it to close the message.

Same goes for warning - an exclamation mark inside a yellow triangle - this is a warning. We all know this. Yellow = warning.

Blue for warning - no, this just doesn't work. Anytime you mess with convention you better have much better reasons other than "I want to use saturated colors" or "I like it better".

The saturated colors have been tried and ultimately removed. Its very easy to see, on a balance of pros and cons, that the better option is light backgrounds with a border and icon. They are clean, simple, effective and accessible.

I've further improved my patch. It now has rounded corners and the icons are centred vertically again. The X did look a bit like a close message button when it was in the corner.

When people first experience a warning message in Seven they will take a moment to understand that what it is (based on the icon). From then on they will know the convention. I think this will be the same regardless of whether it is blue or yellow.

I've finally found a solution that I am happy with. If this doesn't get in I will probably use it anyway for my own projects.

Something based on #113 / #114 would be fine, but those advocating that will need to put in the work to make it happen. Just about anything would be better than what is currently in HEAD.

Obviously, community consensus will determine what happens.

FWIW the bare X doesn't bother me; it doesn't look clickable. An X inside of a circle or square is what makes me think "close button."

This issue is primarily about accessibility and adding icons to improve accessibility. Patches and discussion proposing a complete redesign (saturated colors for example) are totally out of scope and require a separate issue entirely.

Webchick has already made two strong recommendations - use the existing colors (already approved) and the protocons. This issue has to be about the icons and nothing more.

So far very little has been analyzed with regards to the protocons. I have analyzed the protocons using Color Contrast Analyzer and VisCheck.

This first screenshot is of the patch in #114 which uses the protocons in #83. On the left are the results for the lightest part of the gradient (near the top of the symbol) and on the right for the darkest part of the gradient (near the bottom of the symbol).

Color Contrast Analyzer expects a 5:1 ratio to pass - however WCAG AA only expects 4.5:1*, so where CCA states a "fail" I believe this is not actually the case. Furthermore 4.5:1 is for small text, whereas for large text the requirement is just 3:1. There is no indication in WGAG AA (afaik) what the ratio must be for block colors such as images or icons. We can use CCA to at least get the ratios as a starting point for analysis.

Error - a single, very close fail on the top, passes on the bottom - pretty good. Passes 3:1 no problem.
Warning - passes all - excellent.
OK - fails top and close fails on the bottom at 4.5:1, mostly 3:1 passes but may need work.
Info - passes 4.5:1 on top, passes bottom - good.

*See SC 1.4.6.

In this next screenshot we analyze the patch in #114 using Vischeck color analyzer. As you can see - despite the apparent fails indicated by CCA the icons are still clearly discernible for each color blindness condition. The message background and font colors are also OK. Even in grey scale they're fine. The screenshots were taken in Stark.

Looking at these findings IMO the patch in 114 colors and icons are very good - possibly even commitable. I think the fails according to CCA are overstated and the checks using Vischeck clearly show the icons are discernible for the 3 most common forms of color blindness. I would think a fair assessment is to use 3:1 ratio as a benchmark.

It would be good to get some verification from Cliff and to hear what the status on the new protocons from yoroy (I believe the error will be an octogon and the backgrounds fully pass 4.5:1).

Note the image I attached for the vischeck was the wrong one, but this has been corrected and this post now shows the right screenshot (as uploaded in 144). I also found this guide to websafe colors that pass the required contrast ratios: http://trace.wisc.edu/contrast-ratio-examples/ColorSets_6x6x6_OnWhite.htm

corrected screenshot for 143

Wow, great review. Thank for that.

- 'ok' has indeed the weakest contrast in the set – I deepened the green
- 'error' is now an octagon shape. I added a white border here, mirroring real world usage. Experimental tweak, probably not prettier, but might be effective. it's an error after all.
- 'warning', black and yellow are about as contrasty as it gets, so no wonder this one passes best. I actually toned down the black of the '!' here to a dark gray.

Attaching the 16px updated versions here. Committed (including other sizes) against protocons as well.

This is a re-roll of #114 with a few updates for RTL and gives the core themes consistent message styles. The zip (in #147) contains the new protocons (the go in /misc root).

The new protocons...

Ops, except I forgot the dblog stuff...

This time with dblog messages as per 114 (changed from img element to background images with CSS).

Needs the new protocon pack from #147

Jeff, this is a great improvement. I've applied this in my sandbox (with the new icons).

The icons certainly make it look more professional. Looks fine in Seven Bartik & Garland. It looks fine in RTL too.

I'm assuming that yoroy is approving this and has given a usability stamp of approval to this addition. I don't think that Bojhan would need to give a second opinion on that (but it's always welcome).

I'm going to mark this RTBC as I think it's ready for core.

This does not add images to the Status report page - admin/reports/status

Awesome. Great work, these look wonderful now. Committed to HEAD.

I guess we need one final accessibility follow-up issue to add these icons to admin/reports/status, where we're still only using colour to indicate status. Could someone take care of that quickly so we can finally put all this message futzing behind us? :)

That's great news. I've set up this as the followup issue for the Status report - #906738: Status report need identifying icons (WCAG 2.0)

Thanks for the great work here, folks! They look great.

The addition of these icons helped me notice another bug present in errors that are returned via AJAX during a batch operation: #906922: Error message icon is tiled for when the message appears on a batch page in place of a progress bar

One of the original issue also dealt with adding icons to error messages: #193482: Styling status messages in system.css.

Awesome. Thank you everyone for all the efforts put to fix this issue.

Good to see this issue fixed.
Still I failed to find any reasonable explanation why the text and the borders are coloured.

I hate re-opening issues, but these images weren't smushed before being committed. I ran these through ImageOptim. I'll do a separate issue if desired.

./misc:
message-16-error.png
message-16-warning.png
message-24-ok.png
message-16-help.png
message-24-error.png
message-24-warning.png
message-16-info.png
message-24-help.png
message-16-ok.png
message-24-info.png

We might also want to create 1 or two sprites for these icons to save on the amount of connexions.

@xmacinfo - that would be possible if we set the icon as a background on the H2 heading, i.e. instead of hiding the entire heading we just hide the text inside it, then we could use a sprite for these messages.

As for using the H2 element-invisible might be a good idea. We may also consider adding a div to clip the icon properly. My guess is that we should create a new issue and probably tag it performance.

Images in #158 are OK. We indeed save more than a few bytes. Let's commit those.

Committed #158 to HEAD. Smuuuush!

Marking as fixed. see #2125263: Issue status not taken from last comment during D7 migration