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.
Related
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.
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.
Shouldn't both be removed? Or does it mean we should use <small>? Why is <big> removed but <small> is not? What is the problem with <big> which does not apply to <small>?
http://www.w3schools.com/html5/html5_reference.asp
Remember, the tags are meant to be semantic, not presentational. There is such a thing in English as "fine print". This is what the small tag represents. There is no analogous concept of "big print" except for a header, which is already covered by seven other tags.
<small> is used more frequently, for footnotes and such...with <h1>, <h2> and <h3> there just wasn't a use for <big>, hence why it's removed.
The same logic that applies to small (as "fine print") is also just as true for big (as "warning"). Public postings, mostly, but also manuals or even contracts often have things written in bigger fonts that signify [so... semantics!] a warning.
It's not the same as emphasis, which has a meaning in context, but rather "whatever you skip in this text, this part you should read because it's not the usual blah blah but something with immediate and important consequences"
That's why I think big and small should both be out or both in.
Some purely presentational tags managed to slip through into the spec before but the 2 standards bodies have finally reached a concesus to remove all purely presentational tags in favour of using CSS. If something has no semantic value and is purely for visual apearance - it does NOT belong in the markup - it belongs in a stylesheet.
True or not: We should always use proper capitalization and never put whole sentences in all-uppercase. If we must do so, we should use CSS for this task."
Should we use the CSS property text-transform for other cases if we need them?
(Note that I'm not talking about HTML tags, I’m talking about text content)
Links to read:
http://blog.mauveweb.co.uk/2009/01/14/dont-use-uppercase-in-html/
http://www.webaim.org/techniques/fonts/#caps
Huh? For normal text? That sounds like a ridiculous idea to me. Every language has its rules about what's lowercase and what's uppercase. Why would one want to divert from that?
Update: Sorry Jitendra, I didn't read your update closely. Now this
I head Screen reader spell letter by letter if we use UPPERCASE.
could well be - say, for USA to be spelled like U S A. I could imagine some screen readers do this. But this would only mean not to put words in ALL CAPS - which is a rule you would want to follow anyway.
Having all text in lowercase and uppercasing the right words through text-transform, you would have to put a CSS class on every word that needs to be capitalized - extremely cumbersome, would result in horribleHTML soup, and wouldn't make sense. Just use normal capitalization, and don't use all caps.
You should write content of a page with proper grammar, spelling, and capitalization just as you would in an essay. Navigation and logos should start with an Uppercase (or if it's a name, the proper spelling for the name, e.g. iPhone, not Iphone or IPhone.) Only use CSS capitalization for stylization. So, if you want your site's name to be in all caps (MY WEBSITE) use CSS to make it all caps, but in the HTML make sure it's proper (My Website).
Hope this helps!
It's generally a good idea to concentrate on what's easy for people to read. Almost always, for almost all sorts of information presentation, conventional typographic rules for the language of the site are appropriate, and you should not do anything different without having a really good reason.
The W3C states that all XHTML elements and attribute names should be in lowercase:
XHTML documents must use lower case
for all HTML element and attribute
names. This difference is necessary
because XML is case-sensitive e.g.
<li> and <LI> are different tags.
As for web page content in between tags, of course it is not necessary.
Jaws does not spell out words if they are recognized as English words. FOR EXAMPLE "THIS IS PRONOUNCED NORMALLY." sounds the same as "This is pronounces normally." When dealing with abbreviations capitalization matters. For example "usa" is pronounced phonetically as one syllable. “USA” is pronounced as “u s a” Made up words tend to be pronounced the same regardless of capitalization, for example “FDIOSUF” is pronounced the same as “Fdiosuf”
I'm not talking about HTML TAG i'm talking about text content? I head Screen reader spell letter by letter if we use UPPERCASE.
my question was "Should we always use lowercase text in web page's content?" and use css text-transform for other cases if we need.
Just use natural text, as you did in your SO question. Screen readers will generally read ALL UPPERCASE as individual letters, as such text is generally an acronym (it'll likely vary from reader to reader - some handle things more intelligently than others, and may be able to figure out that a whole sentence isn't likely to be an acronym).
You don't have to lowercase every letter, though - a screen reader shouldn't have any problem with "This Is A Sentence."
UPPERCASE text that isn't an acronym should be done with CSS's text-transform: uppercase;.
It has nothing to do with screen readers. For actual content, you should use normal capitalization. For element names and attributes, you must use lower case if you're using XHTML, because it's case-sensitive and the spec says the tag names and attribute names are lower case. These are two completely different things (content vs.markup).
Edit Re your edited question: You should avoid incorrect use of ALL UPPER CASE TEXT (that would be an example of incorrect use), because screen readers may well spell that out on the theory that it's an acronym like HTML or W3C. But not doing ALL CAPS is not the same as doing all lower case. Use initial capitals at the beginnings of sentences, etc. Don't use ALL CAPS for emphasis, use <em> (or <strong>, depending on the type of emphasis). Doing so marks up your text semantically, which actually helps the screen reader do its job (by allowing it to put emphasis where it should be put).
yes you should, if you would like to modify the text letters use the css property text-transform http://www.quackit.com/css/properties/css_text-transform.cfm
See list here:
http://www.w3schools.com/html5/html5_reference.asp
like <b> , <i>, <br>, <hr>, <small>?
Is it means no cons to use these? But what about content and presentation seperation?
Two reasons come to mind:
Because some people (not me, here is a primer about this opinion and here are the WHATWG FAQ about this) don't think of them as presentational. They argue, that <b> has semantics of its own, for example, where <strong> is not right and the text should be bold anyways (IMHO therefore we have <span>)
Because HTML5 has a pragmatic and backwards compatible approach: What worked in HTML4 should work too in HTML5. They argue, that this is why XHTML2 died.
First have a look what WHATWG says about it (this is also mentioned in the answer to the related question cited above).
It is said (as I thought, too) that <strong> and <em> provide an emphasis when using a screen reader, but according to this article by Harry Roberts, it turns out that in practice screen readers don't accentuate text marked this way.
And last, read the spec about <b> (it's already mentioned in the FAQ in the first link, above):
The b element represents a span of
text to be stylistically offset from
the normal prose without conveying any
extra importance, such as key words in
a document abstract, product names in
a review, or other spans of text whose
typical typographic presentation is
boldened.
and <i>:
The i element represents a span of
text in an alternate voice or mood, or
otherwise offset from the normal
prose, such as a taxonomic
designation, a technical term, an
idiomatic phrase from another
language, a thought, a ship name, or
some other prose whose typical
typographic presentation is
italicized.
Likewise, have a look at <small>, <hr> and <br> (there are examples there, too.)
They have also redefined the meaning and semantics of several of these elements. They realized the need for an element that does something like <b> and there was already an element, so they kept it, and preserved backwards compatibility, instead of introducing something new.