comments on HTML techniques

Hi Michael, Wendy,

some comments on HTML techniques:

1.1
* According to <http://www.w3.org/TR/REC-xml/#NT-doctypedecl> for 
XML-based languages it must be !DOCTYPE (upper-case), which is ok for 
HTML, too. So 'The !DOCTYPE statement' would be better.
* 'Example:
This is an example defining an English-language document as using the 
HTML 4.01 Transitional DTD.'
There's no indication of the document being written in English. The 'EN' 
in the formal public identifier does _not_ specify the language of the 
document.

1.2
* 'All documents, including individual frames in a frameset, ...'
The frames are not documents. Proposal: All documents, including those 
loaded into individual frames in a frameset, ...

2.1
* 'Resources: ... Test suite: Test files for "glossary"'
                                               ^^^^^^^^

4.1
* See <http://www.w3.org/TR/2005/WD-i18n-html-tech-lang-20050224/>

4.1/4.2
* Should there be a sentence about ATs currently not or at least very 
rarely supporting xml:lang?

5.
* 'They refer to "inline" tags that allow control over the presentation 
of specific words and phrases in the document.'
Do they? 5.1, 5.2, 5.3, 5.6, 5.7, 5.9, 5.10, 5.13 are not about 
controlling presentation.

5.1
* b and i elements are _not_ deprecated in HTML or XHTML 1.x.

5.2
* 'If a heading is already abbreviated provide the expansion in abbr.'
Accoring to <http://www.w3.org/TR/html4/struct/tables.html#adef-abbr> 
the abbr attribute contains an abbreviation for a long header, not the 
other way round. The example is correct.

5.10
* contains two references to 'Test suite: Test files for "Supplemental 
meaning cues"'.

5.12
* b and i are not deprecated, too.

6.1
* I think the long format (1.2.4.3) is a user-agent issue. UAs could get 
the nesting level information from the DOM and generate the long format 
by themselves. This should be configurable. -> UAAG

6.2
* 'Editorial Note: We need to provide pointers to alternate ways to 
achieve the desired effect.'
p {
   margin-left: 2em
}

8.4
* 'Tables used to lay out pages where cell text wraps pose problems for 
older screen readers that do not interpret the source HTML or browsers 
that do not allow navigation of individual table cells. These screen 
readers will read across the page, reading sentences on the same row 
from different columns as one sentence.'
This will apply to all sorts of 'columns' (HTML tables or CSS 
float/positioning), no? If this is still an issue, column arrangements 
of content in general has to be forbidden.

9.2
* 'Where appropriate, use the title attribute of the a element to 
clarify links.'
If the link needs another text (in a title attribute) to clarify the 
link text, the link text is not clear -> inappropriate

9.3
* '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.'
This only applies to images, that are the _only_ content of a link, 
right? Not for e.g.
   <a href="...">some text and <img alt="an image" src="..."> and another
     text</a>
* 'If you provide link text, use empty quotes as the alt attribute value 
of the img element. (e.g.: alt="")'
The attribute value is empty, not 'empty quotes'.

9.8
* 'Do not hide the skip link using the display property; either 
display:none or display:hidden'
There's no 'hidden' value for the display property. Do you mean 
'visibility: hidden'?

10.2
* Example
Shouldn't this be marked as a deprecated example?
* 'alt="&amp;nbsp;&amp;nbsp;&amp;nbsp;"'
Shouldn't this be 'alt="&nbsp;&nbsp;&nbsp;"'?

11.1
* 'For all image maps, content developers must supply a text alternative.'
Does this mean
1. for all images, used as image maps, or
2. for all image map choices?
    2.1 area/@alt?
    2.2 redundant text links? (11.3 says, this is deprecated)

12.7/12.8
* Why is the example not marked deprecated, while the one in 12.9 is?

12.10
* 'Also, it is necessary to actively use the accessibility features of 
the plugin to result in accessible content.'
Shouldn't this be '... use the accessibility features of the content to 
be rendered by the plugin ...'?

14
* 'Opening a frame in a new browser window can disorient users.'
This is not specific to frameset documents.

14.1
* 'The name is not presented to the user, only the title is.'
UAs do show the name attribute, some prefer the title attribute if present.

14.3
* 'Editorial Note: Note that if the a frame's contents change, the text 
alternative will no longer apply.'
14.3 is about relations of frames, not about frames' contents.

15.2
* 'In practice this is not supported by user agents'
It is supported at least in current Gecko and Opera browsers.

16.1
* 'It is unclear whether noscript should always be required, even if 
script failure does not present an accessibility problem'
E.g. link that opens the browser's print dialog, inserted with 
javascript. This does not need a noscript, does it?

16.5
* 'Avoid using these elements.'
-> Avoid using these event handler attributes.

16.7
* '[...] because they cannot be used with the keyboard.'
                       ^^^^^^
The second paragraph implies that it is possible.

Appendix

1
* 'We are unsure whether to deprecate this technique, but we believe we 
should.'
Note that with IBM HPR there is still a AT UA that does not 
differentiate between adjacent links. But this is an UAAG issue, right?

4
* 'The label must immediately precede its control on the same line'
With radio buttons and checkboxes, the control usually precedes the label.
-- 
Johannes Koch - Competence Center BIKA
Fraunhofer Institute for Applied Information Technology (FIT.LIFE)
Schloss Birlinghoven, D-53757 Sankt Augustin, Germany
Phone: +49-2241-142628

Received on Friday, 1 July 2005 12:45:32 UTC