I accessibility guidance for my CSS-only tooltip — http://chantastic.github.io/tip.css/
This is how you use it:
<span data-tip-content="this is a tip" data-has-tip>Hover here</span>
The current API
To avoid the browsers default rendering of title, I'm using data-tip-content for tooltip text. By doing that, I'm also losing the accessibility benefits of title (Related SO Question).
My Current Work around
I'd like to add aria-label as a content source, making use look like this:
<span aria-label="this is a tip" data-has-tip>Hover here</span>
My Question
Does aria-label make sense in this case? Is there an accessibility interest that this will not cover?
I am very new to accessibility and would appreciate experience-based feedback. Thank you.
If you think there is a better solution, please consider these constraints:
CSS-only. Many JS-tooltips simply remove and restore the title-attr on mousenter/mouseleave. I'm not interested in a JS solution.
No Additional Markup. This library is intended to be minimal and simple. It uses :after, :before, and content to avoid the requirement for additional markup blocks.
Two-Attribute API. This library only requires the addition of 2 attributes.
The aria-label attribute specifies a label for the element, typically an accessible name for an input element that would otherwise lack an explicit label, because the user is expected to infer its role from the visual context. Although its description refers to the HTML title attribute and tooltips, it’s not really meant to be used for things like CSS tooltips. Rather, it is useful for labelling elements instead of using the title attribute, which has some drawbacks in such use.
However, there is unfortunately no ARIA attribute that would be more suitable. There is odd asymmetry: ARIA has aria-label for direct labeling and aria-labelledby for indirect labeling, i.e. for specifying an element that contains a label for the current element, but for descriptions, there is just the indirect aria-describedby.
So this boils down to using aria-label, given your current approach and markup. In a different approach, where the tooltip text is element content and not an attribute value, you could use aria-describedby.
P.S. The attribute data-has-tip looks redundant here, since you can use, both in CSS and in scripting, just the presence of a data-tip-content attribute instead.
Related
On my page I have few blocks (div) that have the same style regarding background and border (menu panel, info panel, footer panel, ...).
Now I would like to write that style only once and not repeat it for every panel. Yet I don't see any comfortable way of doing that.
One approach I investigated was to introduce a dedicated class (for example panelClass) that would capture the common panel styles. Then in (X)HTML I would just add that class to every element that is supposed to be a panel.
But this doesn't feel right. After all I would be "revealing implementation" in the (X)HTML. I'm no longer able to transparently change things easily because that requires modification of the (X)HTML.
Not to mention that it introduces issues with order of the classes (and thus order in which CSS attributes will be overwritten if needed).
EDIT: (an extended explanation for kolin's answer)
By “revealing implementation” I meant that the (X)HTML (“the content”) is much more strongly connected to the CSS (“the presentation”) than I would like them to be. Maybe I’m pursuing an unreachable ideal (maybe even an unreal or a dummy one!) but I’m trying to keep “the content” separate from “the presentation”.
Thus having a class menu isn’t bad because it describes “contents” not “presentation”. While using instead (what I understood from the cited articles and few others on that site) classes like menu box bordered left_column is bad because it mixes presentation with contents. Once you start adding such classes you might very well add that CSS directly to style attribute. It sure would be much more work and an unmaintainable result but conceptually (when regarding contents-presentation separation) it wouldn’t make a difference.
Now I do realize that in real life for real pages (rich and nice) it is virtually impossible to keep contents entirely separate from presentation. But still you may (should?) at least try to.
Also just look at the “But” in the end of the article The single responsibility principle applied to CSS. In my opinion the island class he used is already presentational because it does not describe contents. It describes how to show it. And that is immediately obvious once you see how widely he used (or might have used) that class on elements having nothing in common as regarding contents.
END EDIT
Another approach was to use selectors grouping. So I would have something like:
#menu, #info, #footer {
background: /* ... */
border: /* ... */
}
This avoids the need to modify (X)HTML. But still causes order issues. And also makes it hard to group styles logically. Especially if they are distributed among many files.
I think that what I really would like to have is to be able to name a group of attributes and just import them somehow in selectors. Something like #include in C++ for example. Is there any way to achieve this? I doubt it but maybe...
If not then is there any other method?
Using classes to define styles is the correct way to do it.
One approach I investigated was to introduce a dedicated class (for example panelClass) that would capture the common panel styles. Then in (X)HTML I would just add that class to every element that is supposed to be a panel.
For me this is exactly the way I would do it.
But this doesn't feel right. After all I would be "revealing implementation" in the (X)HTML.
is there a security problem with revealing implementation?
A few selected posts from Harry Roberts :
http://csswizardry.com/2012/04/my-html-css-coding-style/
http://csswizardry.com/2012/04/the-single-responsibility-principle-applied-to-css/
http://csswizardry.com/2012/05/keep-your-css-selectors-short
I find his style of using CSS eye opening, and it may help you
update
Following on from your update, I agree with you that you should try and seperate structure from presentation, although there will be times where we can't quite manage it. Whether it is fully possible or not, i don't know.
I partially disagree about the island class, the padding property to me kind of hovers over the border of structural and presentational. structural because it alters the layout of whatever element it is applied to, presentational because the padding alters how it looks on the page.
in an ideal world you should never need a class attribute that encompasses menu box bordered left_column, because you would write a couple of classes that seperate out the structure and presentation.
thinking about your case I might create a panel class
.panel{
margin:10px 0;
padding: 10px;
display:block
}
and a panel-display class
.panel-display{
background-color:#1111e4
}
.panel-display > a{
color:#fff
}
in this way I could just play with the presentation without affecting the structure of the site.
(n.b. I'm not sure if this helps you in anyway!, it just seems logical to me)
Should we use
css: input[type='submit']{...}
or set class name for input tag?
html: <input type="submit" class="submit">
css: .submit{...}
You should use the class name instead of attribute selector if you want to support IE6.
This article is interesting:
The Skinny on CSS Attribute Selectors
Yes, As Sarfraz said if you go for browser compatibility you should go for class name, but attribute selector provides a vast range of control over any elements.
IMO, it all depends on exactly what style you're applying - in addition to the general browser support factors that others have already mentioned, of course. For example, if what you're applying is an absolutely core part of your design (e.g. layout), then it's probably safest to stick with a class name.
However, if what you're applying is a 'decorative flourish' and, in particular, if it's CSS that isn't even supported in older versions of IE anyway (think border-radius, for a start) then it's much better to keep your markup clean and make use of the attribute selector.
Under similar circumstances, you may deem it worthwhile to progressively enhance via javascript - i.e. leave the markup nice and clean but add a class or inline style to the element using JS.
Due to mod rights on a site, I can only add css (no js etc...). When users input text in a comment box, it saves it and then displays it as a <p>. is there any way through css i can search for a specific word in the <p> tag and remove/censor it?
Thanks
There is no practical solution for that ( You may be able to select elements based on the value and hide them in CSS3 but it wouldn't be cross-browser friendly, if at all possible ). I'm afraid you'll have to use JS/server-side for a real solution.
On the hacky side of things and for IE only, you may be able to use an expression and display:none elements which contain certain strings in their nodeValue, it wouldn't work for modern browsers.
If parent element in this case input field has class or id you can hide elements inside like this
textarea#mytextarea p
display:none;
}
Once upon a time, there was a pseudo-class :contains() in the wonderful spec of CSS3 selectors ... but it disappeared early and afaik well before any implementation.
A JS solution has one problem: search bots and any user without JS (or displaying the source code) will see the f***ing original text :)
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Is it ok to use <strong> in place of <b> blindly ?
When to use <strong> and when to use <b> or other ways to give look of bold? strong has semantic value ( and useful for screen reader while b is presentation (and even valid in HTML 5).
my question is not what is the difference between strong and b.
The question is when to use semantic tag and when to use just to make text bold
Should I always use <strong> if client's content files (MS word files) has some words bold in content paragraphs?
alt text http://shup.com/Shup/365676/11051764618-My-Desktop.png
How can we know when client want to give emphasis to text and when he just want to make text bold for presentation/aesthetic purpose?
If it's client job to tell us, then how to explain this scenario to client to give us clear info on "when he just want to make text bold for presentation/aesthetic purpose" ?
I've always followed a simple rule of thumb:
<strong> means "strong emphasis", and implies no particular visual style. It has semantic meaning, but could look like anything.
<b> is used to apply a bold visual effect to text, but is a presentational tag like <font> and so should be avoided (where possible) in favour of CSS.
How can we know when client want to
give emphasis to text and when he just
want to make text bold for
presentation/aesthetic purpose?
Read the client's text with understanding.
use <strong> when the context says that the bold text is more important than the other (and it is inline)
use <b> if it just should be bold (even in database, feed reader or without stylesheets). In this case boldness may be used to catch the readers eye.
When in doubt, ask the client what did he meant.
To save you and yourself a hassle, ask the client to use formatting styles in his editor. This is very useful feature, pity that there few people who do know what for this feature is.
Edit:
This is strong and this is bold. Any difference?
All the problems begin here. If the strong were by default colored RED (no red markup on SO), and normal weight, there would be no questions like this.
There's no "right" answer to this (which is probably why semantic markup isn't in a good state).
Depending on the way your client works I'd say your proposal to replace emboldened content in paragraphs with <strong>, and everything else with relevant heading styles, is reasonable. It may be a good idea to sample the documents to establish what practice has been used.
First ask the client "why have you highlighted these words?" and use that to inform your decision. If you can't get a clear answer, I'd use <B> since it's better to not imply that there are semantics to the highlighted words when in fact there are none. Use of <B> can be used as a clear indication that you have unsatifactory presentational markup, and therefore helpful to future maintainers that it can be freely corrected in the light of new information about the reason for the highlighting.
If you're doing a conversion of a word document to HTML, then I think <b> is a better choice, because you're conveying the fact that the text was bold in the word document. Word uses styles to apply semantic meaning, so if it's marked with the "Strong" style, then you use the <strong> tag in the HTML.
Using CSS to define a style other than default bold for a <strong> tag is understandable.
Using CSS the same way on a <b> tag would be more questionable.
I would like to know the best way to markup scientific names in XHTML. This answer says I should use the <i> element, which I'm not too in favour of, unless of course, it is the right element to use.
I could use <span class="scientific">, but seeing as one of the first uses of HTML was to markup scientific documents, I'd imagine there'd be a better semantic hook for this sort of thing.
Also, is there any element to markup the common name of a scientific name?
Note: It looks like Wikipedia, or at lease this article is using <i> for scientific nams.
Edit: Would the <dfn> tag be appropiate?
dfn is for a definition of something.
<p>The prefix cardio- means <dfn>of the heart</dfn>.</p>
As far as I can see in the list of HTML 4 elements nothing specifically fits the bill. This leaves you with a few options:
<span class="scientific">cardio</span>
The semantics are added by the class, and so this is probably the most correct way, technically. However, it does have the downside that without your CSS, it won't appear different in any way to the surrounding text. Another option might be this: /me prepares to duck for cover
<i class="scientific">cardio</i>
Now before I get my head bitten off for using the verboten element, <i>, consider that it is no less descriptive than using <span>, and even if a stylesheet were missing, you'd still get vaguely the correct formatting. Just make sure you add the class attribute.
In (X)HTML5, the i element should be used:
[…] such as a taxonomic designation, a technical term, an idiomatic phrase or short span of transliterated prose from another language, a thought, or a ship name in Western texts.
I guess "taxonomic designation" matches your case.