!doctype statementMANUAL (depends on author)
This is a VERY IMPORTANT issue. Formalization of WCAG can be easier if some restrictions are included in a DTD or XML Schema. Otherwise, that's when I use XPath and XQuery expressions. Grammar validation implies a lot of possible automation (even more than any other technique). For example, alt attributes are REQUIRED in XHTML DTDs. I have written the rule //img[not(@alt)] because I still want to provide a rule for non XHTML compliant pages, but I don't really use that sin I have it automated on validation. Elements like applet, embed, b or i are now deprecated. For this reason, I don't have rules like //b or //i should be forbidden
. I leave that for validation.
It is preferable to validate to grammars that have been designed with accessibility in mind.
Have you considered how accessibility has been considered in the design of XHTML grammars? My experience has led me to conclude that the following XHTML "dialects" are ordered in an increasing degree of accessibility, as expressed at my table for accessibility comparison of XHTML dialects.
The accessibility order is as follows: XHTML 1.0 Transitional < XHTML 1.0 Strict < XHTML 1.1 < XHTML Basic 1.0 < XHTML 2.0.
For backwards compatibility, I prefer authoring my Web pages in XHTML Basic 1.0. However, some important semantic tags are missing on XHTML Basic 1.0, so I then choose XHTML 1.1 (stricter than any XHTML 1.0). XHTML Basic 1.0 lacks tags like: fieldset, legend, sup, sub and hr, but Steven Pemberton told me that they will published a revised edition.
title elementPlease, note that the first XPath expression forces a title to be present, while the second addresses the barriers, i.e., all head elements (mandatory in XHTML documents), having no title element. Addressing barriers is a topic for accessibility evaluators. The condition "there should be a title" could be rewritten as the result of the second expression being the empty set.
//meta[@http-equiv="refresh"]
//meta[@http-equiv="refresh"]
Same as 2.1 Meta redirect! Why not to unify?
Similar for h5 and h6. The purpose of these XPath and XQuery expressions is to rewrite the sentence:
Since some users skim through a document by navigating its headings, it is important to use them appropriately to convey document structure. Users should order heading elements properly. For example, in HTML,
h2elements should followh1elements,h3elements should followh2elements, etc. Content developers should not "skip" levels (e.g.,h1directly toh3).
//html[not(@xml:lang) and not(@lang)]
//i | //b
However, I prefer using XHTML validation, using a grammar where those elements are deprecated.
By the way, in the following example, is the expected abbreviation to be heard as "es-es-number"? Probably it looks like a nice visualization abbreviation, but not a very proper hearing abbreviation.
This example shows how to use the abbr attribute in a table heading.
<table>
<tr>
<th>First name</th>
<th abbr="SS#">Social Security Number</th>
</tr>
...
</table>
(//abbr | //acronym)[let $a:=self::node() return
count((//abbr | //acronym)[text() = $a/text()]) != 1]
It is a manual task to detect whether all abbreviations and acronyms are marked, but we still can provide an automatable rule for uniqueness, thus avoiding ambiguity as in the following example. All abbreviations and acronyms having the same text should have the same definition. Otherwise, the may lead to ambiguity.
This example shows that non unique definitions are ambiguous.
<acronym title="United Nations">UN</acronym> <acronym title="Unified Notation">UN</acronym>
//blink
However, I prefer using XHTML validation, using a grammar where those elements are deprecated.
//marquee
However, I prefer using XHTML validation, using a grammar where those elements are deprecated.
title attributeI can't get to issue 654 nor issue 229, but I figure that those against title attribute in images don't really know the difference between alternative text (alt) and complementary text (title). The right tooltip for those images when the mouse is over is the title attribute, not the alt attribute. This was an error in the WCAG 1.0 curriculum! Both attributes have different purposes.
Use the
spanelement with thetitleattribute to provide generic meaning cues.
Why not dfn or any other tag with more semantics (if possible)?
However, I prefer using XHTML validation, using a grammar where those elements are deprecated.
Why applet and other deprecated tags are not here?
I also disagree with forbidding big and small unless someone can tell me of a CSS rule for making font sizes bigger or smaller (relativelly to the font size of the current element) without providing a concrete percentage or absolute size. Is it possible in CSS? How? Otherwise, it could be a suggestion for CSS WG. I know you can make fonts 110% bigger or 90% smaller with CSS, but some authors would prefer to leave that percentage free so that this is solved by device dependant capabilities.
Now you allow big and small? This contradicts 5.11!!
caption element (optional)XHTML Basic does not allow to have nested tables. Tables for layout are forbidden. In XHTML Basic, the subjective function islayout() returns false, when applied to tables.
//table[not(islayout(.))][not(caption)]
//table[not(islayout(.))][not(@summary)]
//table[islayout(.)]
//table[islayout(.)][th | tbody | caption | colgroup | tfoot | thead]
//table[islayout(.)][@summary]
(//a|//area)[let $a:=self::node() return (//a|//area)[@title=$a/@title and text()=$a/text() and @href!=$a/@href] != ()]
Among other things, links must not be ambiguous. Semantic value is left for manual evaluation, but uniqueness can be expressed with a XQuery expression.
title attributeWe're not sure how the title attribute should relate to the link text.
The title attribute should provide extended information about what you are expected to find if you follow the link. For example:
This example (extracted from my home page) shows how to use the title attribute in links. As you can see, it would not be nice to provide this extra information in the text contents of an address element, but it is nice to say what you might get if you follow such links.
<address> <a href="http://www.uc3m.es/" title="Home UC3M">Universidad Carlos III de Madrid</a>. <a href="http://www.uc3m.es/uc3m/gral/IG/CA/situaleg.html" title="Situation & maps of the campus">Avda de la Universidad, 30</a> <br /> E-28911 <a href="http://www.leganes.org/" title="City's Official Web">Leganés</a> (<a href="http://www.madrid.org/" title="Region's Official Web">Madrid</a>), Spain </address>
When an image is used as the content of a link, specify a text alternative for the image. The text alternative should describe the function of the link.
I completely disagree!!!. As I said in my previous example link's title is for that purpose. The image's alt is just for providing an alternative to the image, not for describing the function of the link.
This example shows the difference between img/@alt and a/@title.
<a href="http://validator.w3.org/check/referer" title="Validate this page"> <img class="logow3c" src="http://validator.w3.org/images/vxhtml-basic10.gif" alt="This pages is valid XHTML Basic 1.0" /></a>
tabindex to skip link groups (future)//*[@tabindex][let $n := self::node()/@tabindex return not(isnumber($n)) or count(//*[@tabindex=$n]) != 1 or number($n) < 1 or number($n) > count(//*[@tabindex])]
Do not hide the skip link using the display property; either display:none or display:hidden. Screen readers will not speak text with display:none and sometimes will not speak text with display:hidden.
Why not the following solution to your example?
This example applies the display:none CSS rule only for screen media
@media screen {
.skip {display: none}
}
//*[@accesskey][let $c := self::node()/@accesskey return not(ischar($c)) or count(//*[@accesskey=$c]) != 1]
//*[@target="_blank" or @target="_new"]
imgelements ("alt-text")object elements (future)Why short? They should have no upper limit as long as it is a real alternative. Even more, it does not need to be just a text alternative. Rule 10.7 is OK, but 10.4 should be removed.
//area[let $href:= self::area/@href return count(//a[@href = $href]) = 0]
//area[not(@alt)]
//frame[not(@title)]
//frameset[not(noframes)]
However, the initial expression is not always achievable (so I added the second one), as explained in the following example:
This example shows a label inside a link. We have a form with several of these form fields. Since we have so many, we don't really want to replicate the same text for both the link and the label. We would like them to share the text by nesting the link within the label or the label within the link. The problem is that, since both links and labels are focusable elements, they must not nest (XHTML Basic validation shows an error on the following HTML code. How this could be solved? I found that I have had to lose the label tag in favour of the link! It was impossible for me have both (link and label). Some browsers (Explorer) can't follow the link. When the mouse clicks on the text, only the label works, but not the link. I had to provide a title attribute for the input element because I had to lose the label tag.
<input type="checkbox" id="B01" name="B01" /> <a href="bookingsB01.html" title="B01 lab's bookings"> <label for="B01">Lab. B01</label></a>
(sadly) had to be translated into:
<input type="checkbox" id="B01" name="B01" title="Check if you want to book Lab. B01" /> <a href="bookingsB01.html" title="B01 lab's bookings"> Lab. B01</a>
//label[let $l:=self::label return count((//select|//input|//textarea)[@id=$l/@for]) != 1]
Please, don't deprecate this! A label for each form field and a form field for each label. Orphan labels and orphan form fields are not desirable.
//select[toomany_options(option)][not(optgroup)]
(//a|//area)[starts-with(@href,"javascript:")]
I don't think this should be deprecated.