Help with TITLE text

When a User views a PM, there is a “Star” icon placeholder which can be used to denote if a PM is “Important”.

By default, a PM is “Normal” and so a Grey Star is displayed.

However, by clicking on the “placeholder”, the User can mark the PM as “Important” and a Red Star appears.

(If you have ever used Gmail, then this is a very similar setup!)

On to my question…

So, I am conflicted about what to place in the TITLE attribute for my Star Icon…

Option #1:
I could describe WHAT ACTION the User is supposed to take…

Gray Star would display “Click to mark as Important”
Red Star would display “Click to mark as Normal”

Nice, but it doesn’t tell you the current state.

Option #2:
I could describe the CURRENT STATE of the Private Message…

Gray Star would display “Normal PM”
Red Star would display “Important PM”

But then you might not realize that by clicking on the Star you can switch from “Normal” to “Important” and back again?!

Option #3:
I could go crazy and combine Options #1 and #2!!

Gray Star would display “Normal PM (Click to mark as Important)”
Red Star would display “Important PM (Click to mark as Normal)”

Nice, but maybe TMI…

What do you think?

Sincerely,

Debbie

  • Google-mail is using option #2. They’ll assume the user knows (because of the mouse pointer) that a star is clickable and will toggle the state.
  • Personally, I’m feeling more for option #1, describing the functionality. I assume that the user knows that “click to mark as …” means that the star is the opposite before the click. After a click, the users can see again the invitation “click to …” (the opposite), so feedback is ensured and returning back after an incidentally wrong click is easy.
  • Option #3 is always possible of course, but I think it’s not needed. - Maybe a better place to explain everything is in the “users manual”.

BTW, I don’t know research results about the % visitors who read all tooltips! :wink:
And if the design and functionality of a site is intuitive, nobody will complain about the text in a tooltip.
If you can’t decide after a while, a dice can make the decision: I think it’s not very-very important (a tooltip is only assistance, and shouldn’t be a condition for use).

I think you are missing the bigger point…

Not only do I want a website that is intuitive for regular users, I don’t want to stymie someone who has a disability.

I thought the TITLE attribute was not only used as a “Tool Tip” but also by screen-readers to announce what an Image or Icon is?

Maybe I am mixing TITLE and ALT up again?! :-/

Regardless, what I want is to make sure that my nifty new “PM Stars” are usable if Images are turned off, or someone is visually impaired, or whatever.

Follow me?

Sincerely,

Debbie

Yes, I think you are. Alt(ernative) text is what the browser displays if the image is unavailable, and what a screen reader uses in place of an image. http://webaim.org/techniques/alttext/

A screen reader will also read out title text, so you don’t want to have the same text in both. To quote from another thread:

TechnoBear,

What do you think in response to my OP though?

Sincerely,

Debbie

(If you have ever used Gmail, then this is a very similar setup!)

I’ve never been able to figure out what those dumb stars are, especially since it turns out they can have like 8 colours. Or something.

Never rely on title text: not all screen reader setups will read it out (especially, usually if there is both alt and title, only one is read out unless you’ve changed your settings), but all keyboard and touch users will not have access to title either, due to browsers being dippy-dumb and the W3C members not willing to fix title.

They’re also not willing to fix alt, which is broken visually in many browsers. Chrome will not show alt unless it fits within the dimensions of the image; Opera will show something always but cuts off text that overflows outside image dimensions. So far as I can tell, only Firefox/Gecko does it right (allows image to remain an inline element and alt text is never truncated).

I’d say the alt text needs to state the state/meaning of the star. So, marked as important! Not marked as important! etc.

Since the stars are clickable, you can have the title show mouse users what the thing does: while not foolproof, you can make a general assumption that someone using a mouse can probably see something of the stars, and so then hopefully the state reflected by size, colour, outline, whatever. Remember colour-blind dudes. So the title can show the function, and off-screen text or label could offer the non-title variant.
<text>Change</state><img alt=“not marked as important”>

But as a clickable thingie, HTML-wise they’re probably a button (something that can run a script when cliked) or possibly a “fake” button (something like a span dressed up like a button). We of course prefer the former, so we don’t have to manually add in all the focusable and keyboard and role junk. But anyway you can have a hidden/offscreen label for the star stating the function. A cool idea with this is, like Gmail, you could offer users later the ability to forego icons entirely and use text… meaning you could, with css and a state remembered by javascript and a cookie, swap the text and image.

You might also be able to use a checkbox. These have labels stating what they do/mean, and a state (checked, not checked). There’ve been some working and fairly accessible attempts to disguise checkboxes and radios as images of other things, while the control itself is still completely clickable and useable. That way you could have
Mark as important

[•] Mark as important

Here, the state of being checked or not is part of the control by default. You know that the second one IS marked as important, and you have a pretty good guess what unchecking it means. Here you don’t need text to describe what state you’re in, if there are only two options, only the label text (what the control affects).

So that might be an option, maybe an easier one. The technique for adding stars would use something like this http://csscheckbox.com/ (except make sure focus is visually obvious for keyboarders). I’ve used the CSSninja method (which is very very similar but the image sits on the label) in our ecommerce stuff for “custom” checkboxes and radios. The important thing here is that visually you get what you want, but the browser can take care of allll the other crap for you and it just works like always as a benefit of using a default control (and yeah, these aren’t forms but an interface, but nobody will be too confused by checkboxes outside a form if you’re in an interface).

You’ve said a lot Stomme!

Let me see if I can address your points…

My stars are 2-state: Either Light Gray to denote “Marked as Normal” (i.e. “Marked as NOT Important”) or Red to denote “Marked as Important”.

Okay, so you are saying the ALT tag should define the current state of the Star (“Marked as Important”, “Marked as Normal”), right?

And, are you also saying that all screen-readers should read that ALT text?

You lost me here.

So based on my OP, what are you saying the TITLE attribute should show?

Option #1: What action to take. (“Click to mark as Important”, “Click to mark as Normal”)

Option #2: What the current state of the Star is. (“Marked as Important”, “Marked as Normal”)

(Since I believe you are suggesting Option #1 for the ALT attribute, then using good web design, it would seem that for the TITLE attribute you’d say use Option #2, since you’re not supposed to have the same verbiage for the ALT and TITLE attributes…)

What I did was to simply use a Form Button and put the Star in as a Background Image like this…


<input type='submit' name='submit' id='pmNormal' value='Mark as Important' alt='Click to mark as Important' title='Click to mark as Important' />\
\\r";


#viewPM input#pmNormal{
	width: 22px;
	height: 20px;
	padding: 0;
	margin: -2px 0 0 5px;
	background:url("/images/stars_sprite_85x20.png") no-repeat 0 0;
	text-transform: capitalize;
	text-indent: -999em;	
	overflow: hidden;
	display: inline-block;
	vertical-align: top;
	cursor: pointer;
	border: none;
}

Much simpler than any silliness using JavaScript…

Sincerely,

Debbie

I agree with poes. (I’d be daft not to - she knows more about all this than I do. ;))

The alt text should convey the same information which the image conveys - therefore “marked as important” or “marked as normal”.

I would expect a mouse tooltip (i.e. title) to tell me what something does, so “Click to mark as important”, etc. And as poes is pointing out that not all screen readers will read both alt text and title, and keyboard users also don’t get to see tool tips, then an equivalent label for the buttons should provide them with the same information.

My interpretation of Stomme Poes is just the opposite. :slight_smile:

=======
Other point: a background-image can’t have the Alt-attribute.
If you use a background-image for the star (in order to get the hover-effect), then there is no foreground-image to hang on the alt=“Marked as Important” / alt=“Marked as Normal”.
To get the hook, you can have a transparent image as foreground-image: that can have the Alt.

DEAR FORUMS I AM VERY NOT LIKING THE LOGGING OUT OF MY PERSON WHILE I BUSY TYPING 5000 LOC AND THE ASKING OF THE PAGE REFRESHES FOR GREAT LOSS!!!1
Luckily I copied and pasted this crap into a text editor before Opera lost it all.

I was very unclear… I started typing as ideas came to me, and still prefer the last one I said :stuck_out_tongue:

This is how I deal with graphics-monkeys insisting on special form controls instead of the ones made by the browser (and so in this case, they can be stars):

I have divs or something wrapping the label-input pairs. They need a class.

I also have some Javascript I took from PacielloGroup for detecting if the user is mousing around or not, so that outlines and other crap I add for keyboard don’t show for mousers who click something in browsers who hold the focus state on that element (firefox esp).


<div class="starz">
  <input type="radio" name="important_1" id="important_1">
  <label for="important_1"><span>Mark as important</span></label>
</div>

The span’s there just if you want some more flexibility in showing/hiding/styling the label text without moving the label itself. You can’t move the label here–it’s holding an image covering up the real form control!

This is a lot of crufty code: I blame LESS, which another dev at my work had started using. Since I must in LESS, I’ve gotten lazy and more verbose in my CSS. It does NOT encourage good practice. Bleh.


.starz {
  position: relative;
}
.starz:after {                                                               
  content: '';
  display: block;
  clear: both;
  height: 0;                                                        
}                                                                       
.starz:not(#ie8) input[type=radio] {                                       
  position: absolute;                                             
  left: 0;                                                        
  top: 0;                                                         
  width: 25px;<-- SET TO STAR IMAGE WIDTH!                                                    
  height: 25px;<-- SET TO STAR IMAGE HEIGHT! (and it's best if it's a "square" image)                                                   
  margin: 0;                                                      
  padding: 0;                                                     
  opacity: 0;                                                     
  cursor: pointer;                                                
}
//if you haz disabled stars possible                                                                    
.starz:not(#ie8) input[type=radio]:disabled {                                
  cursor: default;                                                
}

.starz:not(#ie8) input[type=radio]+label {                                         
  min-height: 25px; <-- SET TO IMG HEIGHT-ISH                                                       
  margin: 0; <-- I OFTEN ADJUST WITH MARGINS                                               
  padding: 0 0 0 30px; <-- ASSUMING IMAGE IS TO LEFT OF LABEL. If you're not showing label, make width of image                                                 
  line-height: 25px;<-- LINE IT UP WITH IMAGE IF LABEL VISIBLE 
  background: url(path/to/star/sprite.png) 0 0 no-repeat;  <-- THIS POSITION IS UNCHECKED/UNSELECTED                                                   
 }

.starz:not(#ie8) input:checked+label {
  background-position: SHOW SELECTED STAR PART;
}                                                                            
//if label visible, do something to make it obvious to keyboarders that they're focussed on it                                                                        
.starz:not(#ie8) input:focus+label {                                               
  color: #00f;                                                     
}
//if no label, either have a sprite image part for radio-is-focussed, or draw an outline around it, or something!

If you have disableds, then you’ll add background positions for disabled-unchecked and disabled-checked states.

In addition to this, I have even m0aR code for when mouse is detected like
.mouseDetected .starz:not(#ie8) input:focus+label {
outline or border or whatever we set: 0;
}
This might be a must if there’s no visible label and you’re using a star colour to show that it’s focussed on, because in something like Firefox the checked state won’t show, only the focussed state! So I’d like an outline: 2px solid #somecolour myself.

This right here is pretty close to hitting everyone nicely.

Because the star is an image or image sprite, this doesn’t scale on zoom. SVG and em widths could maybe help this, but I have no good stories about SVG to share yet.
This also fails if the image doesn’t load for some reason. Detection of image loading and removing the styles could help, but I have no good stories of content-negotiation to share yet.

Because the radio button is the usual available control, it’s accessible to everyone as much as regular ones are, because this is a regular radio button.
The label, even if you took the span text and hid it, is available to anyone with scripts off/user stylesheets, screen readers, stuff like Dragon, etc.
The radio button can give its state and whether it’s being focussed on to the browser, who can pass that on to anything asking for it. So a screen reader user for example knows if “Mark as important” is checked or not.

The :not(#ie8) thing is because IE8 doesn’t know the :checked css state. However, if you’re javascripting this stuff, you could add a class of .checked instead and then you don’t need the nots. Me, since I do this for graphics monkeys, I let IE8 just look normal.

Hope this helps.

@Francky: “If you use a background-image for the star (in order to get the hover-effect), then there is no foreground-image to hang on the alt=“Marked as Important” / alt=“Marked as Normal”.
To get the hook, you can have a transparent image as foreground-image: that can have the Alt.”

I do this all the time with graphics-failures insisting on thuper-thpecial submit images:
<input type=“image” src=“path/to/trans.png” width=“bg image width” height=“bg image height” alt=“SEARCH”>
input[type=image] {
bg: teh bg image;
}
input[type=image]:focus, input[type=image]:active {
bg-position: wuzzup;
}
input[type=image]:hover {
bg-position: lawlz;
}

It’s clunky but if it’s already built into your setup it seems to be okay. It does mean 2 requests, but you can reuse the trans anywhere and let the browser stretch it into the needed dimensions.
Back when I was young and stupid, instead of just being stupid, I used to make different-sized trans images. Because, wut.

Long ago I was young and had to serve IE6 as well without the IE png-hack extra’s (to get the grey transparent). Since then instead of a transparent.png I’m using a transparent.gif. Modern browsers don’t explode with it. :wink:

The trick for IE6 (tho a gif for this case was fine) was to make sure the Gimp had set in the palette for the background colour the same colour as the area where the image would be. Not in the image, just the settings in the toolbar at the time of saving.

Gimp would ask, “save background color?” And if you did that, IE6 would, in place of the transparency, show that colour instead. Dunno if this worked in other editors, but prolly did since bgcolor was part of teh image metadata and I guess IE6 was reading that.