While it is recommended to use the title attribute on the <abbr /> element, this has no effect on screen readers (at least not on chromevox).
<abbr title="as soon as possible">ASAP</abbr>
The thing that works is of course aria-label e.g:
<abbr aria-label="as soon as possible">ASAP</abbr>
So in order to be both semantically corrent and screen reader compatible I need to mark both:
<abbr aria-label="as soon as possible" title="as soon as possible">ASAP</abbr>
which seems a bit of a hack. why doesn't chromevox just read the title attribute instead?
In short : Despite one of the WCAG recommendations, abbr is not a perfect solution to explain the signification of an abbreviation to everyone, aria-label should be used when you want to announce the pronunciation of the abbreviation.
Screen readers are not supposed to read the title attribute as it is not intended to replace the aria-label. See also W3 warning:
http://www.w3.org/TR/html/dom.html#attr-title
Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g. requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).
I never encourage the use of the abbr tag for two reasons:
it's not a focusable element so you can't navigate through it using the keyboard to see the meaning of the abbreviation. If you intend to provide a pronounceable alternative then aria-label is definitely what you need.
For instance, when abbreviation is part of the language, you do need to explain it, but you can give a speech alternative :
Director: <span aria-label="Mister">Mr</span> Smith
Blind people do understand abbreviations just like most of us do,
For instance, the following sentence is something blind people can understand perfectly:
John Smith of the NATO was arrested by the FBI.
And the following one is far less understandable
John Smith of the North Atlantic Treaty Organization was arrested by the Federal Bureau of Investigation.
As abbr is used for acronyms and abbreviations you should use the CSS property speak:spell-out to announce that an element must be spelled-out. You can use abbr tag to semantically indicate that it's an abbreviation or an acronym, but it won't have any effect on the global accessibility.
If you do consider that the abbreviation needs an explanation (intended for everyone and not only for blind people) then you should give this explanation in full words without requiring the user to mouseover the abbreviation to see a small tooltip.
Bad example, when abbreviation doesn't help the readability:
<abbr title="Doctor">Dr.</abbr> Smith is located on Lincoln <abbr title="Drive">Dr.</abbr>
Good example (simple is better):
Doctor Smith is located on Lincoln Drive
WCAG promote many other methods than using abbr tag:
Providing the expansion or explanation of an abbreviation
Providing the first use of an abbreviation immediately before or after the expanded form
Linking to definitions
I'm sorry to add another totally different answer but I think both answers should not be merged:
As ChromeVox is opensource, I have a second and now technical answer to your question.
http://src.chromium.org/svn/trunk/src/chrome/browser/resources/chromeos/chromevox/common/dom_util.js
For any element (and there is no exception for abbreviations) ChromeVox fallbacks to the title attribute if there is no text content in the node (node.textContent.length==0)
Here is the order of precedence defined in the code:
Text content if it's a text node.
aria-labelledby
aria-label
alt (for an image)
title (only if there is no text content)
label (for a control)
placeholder (for an input element)
recursive calls to children
Now, it's kind of a buggy situation
This example, in my opinion, correctly reads "BBC":
<abbr title="British Broadcasting Corporation">BBC</abbr>
This one announces "British Broadcasting Corporation": which is a correct fallback to an invalid markup
<abbr title="British Broadcasting Corporation"></abbr>
But this one doesn't read anything, because the node text length is not null
<abbr title="British Broadcasting Corporation"> </abbr>
If we except the last bug, it is not a perfect but quite consistent implementation of Text Alternative Computation
[F. Otherwise, look in the subtree]
G. Otherwise, if the current node is a Text node, return its textual contents.
H. Otherwise, if the current node has a tooltip attribute, return its value.
Note that according to the document referenced in one comment above, the title attribute, if present, should now be used by accessibility api instead of the text content: (http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#text-level-elements-not-listed-elsewhere). I'm not sure it's a good thing as the title attribute was previously and is still defined as the following by the W3.
The title attribute represents advisory information for the element, such as would be appropriate for a tooltip
Related
I have following layout in my web application:
To make it accessibility compliant, is there a need to relate "Al Allbrook" with "Requester" label? If so, how we can achieve that?
"Al Allbrook" is a link to user profile.
If they are not related, how come srceen reader will know "Al Allbrook" is a requester? Same in case of "Site".
In additon to what #andy said, you could also use a table. The first column could have a "requestor" table heading (<th scope="col">). The heading itself could be visually hidden if you don't want it to "clutter" the display but still be available to screen reader (SR) users. The second column would be something like "contact info" and the last column is "site". This allows a SR user to navigate across the row of the table and they'll hear the column heading before the data cell.
Of course, you can do a combination of these techniques. Have a table and have extra information on the links. I would recommend aria-labelledby instead of aria-describedby. While both attributes will cause the extra information to be read by a SR (*), only the aria-labelledby attribute will be displayed in the list of links.
(*) Some SRs announce the aria-describedby attribute directly but other SRs will just tell you that there is a description associated with the link and you have to hit a different shortcut key to hear the description.
The nice thing about both attributes is that the element can refer to itself as part of the label. Kind of a recursive labeling but the "Accessible Name and Description Computation" rules handle the recursion.
if computing a name, and the current node has an aria-labelledby attribute that contains at least one valid IDREF, and the current node is not already part of an aria-labelledby traversal, process its IDREFs in the order they occur
It's probably easier to see an example of this.
<span id="comma" style="display:none">,</span>
...
<span id="requestor">Requestor</span>
Al Allbrook
Several things to note.
First is that the link is referring to itself in the aria-labelledby attribute (the 'myself' id).
Second is that I'm using a trick with screen readers by adding a comma in the label, "Al Allbrook, Requestor" so that the SR has a slight pause when reading the label, "Al Allbrook <pause> Requestor", rather than hearing it as if the guy's name was "Al Allbrook Requestor". Note that the comma itself has display:none so it's not visible, but since the comma element's ID is listed in aria-labelledby, it'll still be used. (See rule 2A in the Accessible Name url above)
Lastly, my example used a <span> for "Requestor" but you might want it to be a heading (<h3> or <h4> or whatever level is appropriate) instead.
For example:
<span id="comma" style="display:none">,</span>
...
<h3 id="requestor">Requestor</h3>
Al Allbrook
And then all this code could be in a <td> if you're using a table.
There is different ways to navigate through a site with a screenreader, so it depends on the navigation mode the user is using at the moment.
In DOM order
In this case, if your "Requester" is before the link in DOM, it will be read before the person's name. Also, the text right before and after a link can be read by means of certain shortcuts.
By accessing a list of links
There is different lists screen reader users can request, f.e. list of all headers, or a list of all links on the page.
If it's important to you to have the "requester" read when navigating to the link directly, you can link the two elements by means of aria-describedby or aria-labelledby.
Alternatively, you could add the text again to the link itself, hidden visually. Like "Al Allbrook, Requester".
I'm creating a content heavy page that is broken up into several small chunks of content. I want this content to be structured in a way that is accessibility friendly.
I originally planned on using the label tag for each piece of content but from what I understand, they are for form elements only. I'm using a series of header (h2, h3, h4...) tags for the main structure of the content but I'm a bit confused as to what I should use for the frequent chunks of short content that needs to be labeled i.e.: Work phone, Home phone, Membership type.
What element should I use to label one-liner pieces of content?
My main concern is how screen readers will digest the content.
I'm laughing to myself at how much effort I'm putting into something as simple as HTML.
Often natural language already conveys what you want to say, without needing any special element:
My work phone: 000
For other cases (or if you want to make cases like the above one explicit), especially if you have a set of name-value groups, and you don’t want to phrase natural sentences, you could use the dl element:
<dl>
<dt>Work</dt> <dd>000</dd>
<dt>Home</dt> <dd>111</dd>
</dl>
The shortest answer to your question is: use microdata.
However, "microdata" has evolved quite a lot over the 10 years - various markup standards have emerged - earlier microformats like hCard, hCalendar & hRecipe and later, more sophisticated initiatives like RDFa, schema.org, JSON-LD - and all have continued to grow and change.
The answer below addresses 2 specific considerations:
How to make telephone numbers immediately apparent to user-agents like browsers and screen-readers.
How to (begin to) establish semantic differentiation between different telephone numbers on the same web-page.
1. Adding Interactivity to Telephone Numbers in mark-up
To assist screenreaders, you can mark up telephone numbers in HTML5, using a syntax similar to the mailto: email address syntax:
Email: me#example.com
Tel: 429-566-3674
N.B. The number stated in the tel: link must begin with a +, immediately followed by the international dialling code.
The HTML above will also add interactivity to your marked-up telephone number.
eg. It will enable smartphones to start calling the number when you click on it in a mobile browser. It will also enable (some) permitted VOIP programmes to start calling the number, when you click on it in a desktop or laptop browser.
=====
2. Distinguishing Home Phone numbers and Work Phone numbers in mark-up
The HTML above will not explicitly distinguish between Work Phone numbers and Home Phone Numbers.
You can start to build such a distinction by employing a microdata vocabulary like that found at http://schema.org/:
<div itemscope itemtype="http://schema.org/Person">
<h2 itemprop="name">Alice</h2>
<dl itemprop="contactPoint" itemscope itemtype="http://schema.org/ContactPoint/">
<dt itemprop="contactType">Home:</dt>
<dd itemprop="telephone">429-677-4785</dd>
<dt itemprop="contactType">Work:</dt>
<dd itemprop="telephone">429-566-3674</dd>
</dl>
</div>
Since HTML5 does not support Microsoft's <acronym> tag, we're left with using the abbreviation element:
<abbr title="Microsoft">MS</abbr>
When it comes to capitalization, cases like that are obvious: it needs to be capitalized.
However, what about other contexts where the word itself isn't usually capitalized in context?
For example:
<p>What is a <abbr title="chief technical officer">CTO</abbr>?</p>
That seems to be fine if one were to switch the title and actual text around.
But when hovering the mouse, it looks a bit odd:
The same goes for:
<p><abbr title="Chief technical officers">CTOs</abbr> are usually skilled technically.</p>
It makes sense if the abbreviation and actual text were switched around, but hovering also looks a bit "weird":
Now, what if we capitalize abbreviations as if they were titles?
For example:
<p>Wouldn't capitalizing <abbr title="Away From Keyboard">AFK</abbr> look weird?</p>
It would if the the title was substituted for the abbreviation, but on mouse-over it seems to look "better":
But what is right semantically?
The replacement text should reflect what the real text would be if it were substituted. Acronyms are generally not constructed from proper nouns, therefore the replacement text should be in all lower-case.
You'd never actually type "Chief Technical Officers" (unless you mistakenly thought they were proper nouns).
From the Chicago Manual of Style
Civil, military, religious, and professional titles are capitalized when they immediately precede a personal name and are thus used as part of the name (typically replacing the title holder’s first name). In formal prose and other generic text (as opposed to promotional or ceremonial contexts or a heading), titles are normally lowercased when following a name or used in place of a name
So it seems clear that you shouldn't capitalise CTO's (unless you mean the Central Treaty Organization).
I don't share your concern - the uncapitalised versions look fine to me. If it is for tooltip-style popups you could mandate all lowercase as house style.
and Away From Keyboard really does look weird...
(forgive my mixed spelling, uk-english quoting us-english...)
If you had to properly choose one HTML tag to represent a price, a money amount or an account balance, (e.g. 3/9/2012 - Income: 1.200,00 € or item #314159 - price: $ 31,99) then
which tag would you choose for the amount and why?
should the currency also be wrapped in its own tag or not?
I'd really like to avoid a generic inline element like <span class="income">1.200,00 €</span> or <span class="price">$ 31,99</span> but so far I've found no references about it.
The HTML spec for var states:
The var element represents a variable. This could be an actual
variable in a mathematical expression or programming context, an
identifier representing a constant, a function parameter, or just be a
term used as a placeholder in prose.
For me this means that <var> is not suitable for the prices in your examples. It depends on what you are trying to accomplish, but it seems your options are:
Use microdata (ref), for example Schema.org’s offer vocabulary for a product’s price
Use <b> if you’d like to draw attention to the price without indicating it’s more important (ref)
Use <strong> if the price is important, such as the total price of an itemised receipt
Use <span> with a class if you need an element to style the price differently, but <b> and <strong> are not appropriate
If nothing above is suitable and you don’t want to style the price, don’t do anything
From the examples you’ve given there doesn’t seem to be any need to mark up prices. If the examples are from a table to display financial information, make sure they’re in a column headed by <th scope="col">Income</th> or <th scope="col">Price</th> respectively for accessibility.
Hope that helps!
Looking at the HTML5 specs, it's rather clear that a price is not considered to be a semantic entity. And I agree. Think about it this way:
If there were semantic elements, this would be the result
<p>
I have 4 apples, 2 oranges and <money>5 <currency>dollars</currency></money>.
</p>
What is it that makes 5 dollars different from 2 oranges? Should we add a <fruit> tag too?
which tag would you choose for the amount and why?
A span with a class, if you want to add some CSS.
Because nobody really cares too much about semantics. Nice to have, but in reality all that matters is styling.
The currency should be also wrapped in its own tag or not?
Definitely not.
I'd really like to avoid a generic inline element
Why?
You may decide to use <i> if you want to express the "special nature of money".
The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, ...
http://dev.w3.org/html5/spec/the-i-element.html
What about <data>?
<p>The price is <data class="money" value="100.00">$100</data>.</p>
According to the HTML5 spec:
The data element represents its contents, along with a machine-readable form of those contents in the value attribute.
When combined with microformats or microdata, the element serves to provide both a machine-readable value for the purposes of data processors, and a human-readable value for the purposes of rendering in a Web browser. In this case, the format to be used in the value attribute is determined by the microformats or microdata vocabulary in use.
In this case you could also use microdata to add additional information about the kind of currency, etc.
I would use a definition list here.
The HTML element (or HTML Description List Element) encloses a
list of pairs of terms and descriptions. Common uses for this element
are to implement a glossary or to display metadata (a list of
key-value pairs).
<dl>
<dt>Income:</dt>
<dd>1.200,00 €</dd>
<dt>Price:</dt>
<dd>$31,99</dd>
</dl>
I can't see anything more semantic than var either:
<var>1.200,00 <abbr title="EUR">€</abbr></var>
Use the var tag. Is described as: "Variable or user defined text"
<var> </var>
Semantically speaking, is there an appropriate place in today's websites (late 2008+) where using the bold <b> and italic <i> tags are more useful than the more widely used <strong> and <em> tags?
While in general I would stay away from non-semantic tags like b and i, strong and em are not direct replacements for b and i.
I would use b or i when it's only presentation you're going for, and what you're marking up has no semantic meaning. For example, a logo like stackoverflow could be marked up with stack<b>overflow</b>. The "overflow" portion has no semantic meaning over "stack", yet stack<span class="overflow-logo">overflow</span> doesn't offer anything either.
Hope this helps.
Not sure how to comment (edit: need moar karma!), but this is in reply to Erik's comment.
Please read the HTML5 working draft. It gives a good explanation on when to use b.
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.
"overflow" does not have emphasis over "stack" in the logo, therefore wrapping "overflow" with em is semantically incorrect.
Never. They are removed in XHTML 2.0 as they are presentational tags. CSS should be used to bold/italicise content.
edit: If you're looking for a purely presentational tag, that's what the SPAN tag with a class and a little CSS is for.
According to the HTML 5 spec, <b> and <i> should be used when appropriate.
On the i:
[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.
On the b:
[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.
Generally speaking, "when appropriate" is deemed to be as a last resort, when all other semantic options have been exhausted. "Presentational" though they may be, it would certainly be a disservice to their semantic cousins <em> and <strong> to consider them always italic or bolded, respectively.
On http://www.webmasterworld.com/forum21/7095-1-15.htm there's a good comment:
"If page readers really read every
<strong> tag in a strong voice, or
really emphasize every <em> section on
a page, then the poor user gets a page
shouting at her or him on a regular
basis.
I think this issue is really a
no-brainer. If I am setting a bold or
italic font for purposes of typography
only, then I use <b> and <i>. If
there's a word or phrase that I want
to emphasize as I would in speaking,
then - and only then - do I use
<strong> or <em>."
For markup generated by a WYSIWYG editor.
The <b> and <i> tags don't have semantic meaning, whereas <strong> and <em> do. If a reader read the block of text aloud it would react to the <strong> and <em> tags, whereas the <i> and <b> tags would be ignored, and treated and purely visual elements. I tend to regard <i> and <b> as deprecated.
Whenever you want to do things incorrectly ... just kidding.
The real answer is never, these tags have been deprecated by the W3C
Neither <b> nor <i> are semantic tags, so purists would say they should not be used. Where I've seen their use justified are in things like putting online content in print where text was bolded or italicized as a matter of convention, but not as a manner of strengthening or emphasizing content.
The easy example is if you're putting online a magazine article that references a book by its title: you may want to put the book title in italics, but the italics are not for emphasis, so the <em> tag would be inappropriate. You could use <i> here, but the semantic thing to do would be to use something like <span class="booktitle"> and then use CSS to make booktitles italics. You are referencing a title, not putting emphasis, and you wouldn't want a screen reader to put verbal emphasis on the title.
My personal opinion is to not use either <b> or <i> today, but using <strong> or <em> as their substitutes when you aren't really looking to do anything besides bold or italicize the text is equally incorrect.
I think when you're trying to make your markup meaningful, these are rarely useful.
There are, however, new tags that produce some of the same results, but which provide even more semantic value. I like to use the <cite> tag when I'm referring to the name of a book, for example, as it still gets italicised, but the HTML now carries meaning about why.
There are a variety of other semantic tags that can also affect formatting listed here:
http://www.w3.org/TR/xhtml2/mod-text.html
I've been using <b> for years to indicate key words on my web site. I wrote a small utility that crawls the site looking for <b> tags and adds them to an index. I use <strong> when I want to bold a word without adding it to the index. I have used this convention for years -- too late to quit now.
It could be argued that there is still a use for the <i> tag: when expressing the scientific name (aka the Latin name) of a species. The scientific name of a species is, by convention, usually presented in italics. Example. It is semantically incorrect to use <em> in this situation because one is not trying to emphasise the name but rather merely distinguish it visually. It may be more appropriate to use something like <span class="sci-name">, but when one considers that most scientific names are composed of words of the italic languages, mainly Latin, the <i> tag becomes a rather sematically rich and convenient solution.
There are technical rules, but here are my two rules of thumb:
1) If you are writing something where, if spoken, you would emphasize a word, < strong > and < em > are appropriate. (E.g., "You have got to be sh*tting me, Pyle!")
2) If you are emphasizing a word for a technical reason, but would not emphasize the word in spoken conversation, < b > and < i > are appropriate. (E.g., "He boarded the RMS Titanic and sailed away, never to be seen again.")
Don't leave out other tags like < cite >, though!
Officially, <i /> and <b /> are "presentational" and shouldn't be used. While many developers think that <em /> and <strong /> are presentational, they are not. They are generally italicized and bolded resopectively, but the CSS can (and should, when appropriate) change how the emphasis and strongness could be displayed.
Similar things could be done with css on a <span /> tag, and many consider that the preferred method, but it isn't substantiatable with the specification.
Some years have passed …
In HTML5 (W3C Recommendation), none of these four elements are deprecated/obsolete.
The (non-normative!) usage summary lists their purposes:
strong: importance
b: keywords
em: stress emphasis
i: alternative voice
Of course, if you want to use them, always refer to their normative definitions (which you can find by clicking on the element names) and verify that they are appropriate for your case.
Examples
The b element could be used for keywords in a text, where the other three elements would not be appropriate: such keywords are not stressed (em), nor are they offset (i), and there is also no need for distinguishing them from boilerplate etc. (strong).
The i element could be used for scientific names in Latin, where strong and em are not appropriate. While b seems to be appropriate, too, its definition explicitly excludes the cases handled by i.
There can of course be cases where you’d use several of these elements. For example, a scientific name could also be a keyword in a document (<b><i>…</i></b>).
When writing websites for mobile devices. They don't always support the 'latest and greatest' standards, are depreciated but not deleted from all modern browsers, and simply take up less space and bandwidth (though in theory the streams are compressed by either the websites or the wireless browser, it can't be counted on).
-Adam