This Wiki page is edited by participants of the HTML Accessibility Task Force. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Task Force participants, WAI, or W3C. It may also have some very useful information.
Spec Review/Landmarks
Under review:
Contents
Léonie Watson
The spec states:
"This specification does not provide a machine-readable way of describing bread-crumb navigation menus. Authors are encouraged to just use a series of links
in a paragraph."
Should the links within a bread crumb navigation be marked up as a list? Links within primary navigation blocks are usually represented as a list, so recommending the same for bread crumb navigation would be more consistent.
Using a list would also provide screen reader users with easier access to information available at a glance to sighted people. Most screen readers announce something to the effect of "list of x items" when they encounter a list. Knowledge of the number of links and/or steps within a bread crumb navigation is often very helpful.
4.13.3 Tag clouds
I'm not at all sure about the recommended technique for producing tag clouds. It relies on the title attribute, which may be problematic (see the footnotes section below. I'm also uncertain about the use of text descriptions to handle the weighting of tags within the cloud, and use of the <a> element.
Lastly, display:none; is used to hide the verbal descriptors. If this information is intended to be available to screen readers (but not visually) this technique won't work. It should use an offscreen approach instead (position:absolute; left:-999em;).
Strongly suggest that someone else take a look at this section. I may be worrying about nothing!
4.13.4 Conversations
The spec states:
"This specification does not define a specific element for marking up conversations, meeting minutes, chat transcripts, dialogues in screenplays, instant message logs, and other situations where different players take turns in discourse.
Instead, authors are encouraged to mark up conversations using p elements and punctuation. Authors who need to mark the speaker for styling purposes are encouraged to use span or b. Paragraphs with their text wrapped in the i
element can be used for marking up stage directions."
My concern is that this offers no way for someone using a screen reader or other AT to understand the purpose of the content. Is there an ARIA solution that could be applied here perhaps?
4.13.5 Footnotes
The spec states:
"For short inline annotations, the
title attribute should be used."
This could represent a problem for screen reader users. Most screen readers do not announce the value of a title attribute by default. Some can be configured to acknowledge title attributes, but not all.
In the example provided in the spec, neither Jaws 12 or NVDA 2011.1 (in either IE8/9 or FF4/5) report the footnote.
The spec then states:
"For longer annotations, the a
element should be used, pointing to an element later in the document. The convention is that the contents of the link be a number in square brackets."
My suggestion would be for this to be the recommended method for providing a footnote. It's consistent with the way footnotes are provided in other environments (such as print or word processed documents), and has the advantage of being well supported by screen readers.
Submit WCAG techniques for these
Léonie Kelly to file bug that the section should be removed since it doesn't spec anything, or examples made better for a11y Bug 13650
Greg Lowney
Can you mark up content that is repeated across pages on the site or subsite? For example, an example given in the HTML5 spec for the <footer> element describes it as showing a "site wide footer", but there is no easy way to distinguish that from a page-specific footer. This is particularly, but not exclusively, an issue for <header>, <footer>, and <nav> elements. This is an issue because assistive technology may often want to hide or skip over things that are repeated on multiple pages, but not skip over equivalents that are unique to the current page. Note that repeated content may still vary somewhat from page to page, as in when items in <nav> are all links except the one representing the current page, or the fact that different pages may have different copyright dates. One mechanism might be to allow an string attribute on these elements that could be compared to elements on other pages of the same site, and if the strings match the user agent can assume that they are equivalent (e.g. <nav sitewide="toplevel">).
Discuss