IBM Comments on November 19, 2004 Public Draft of HTML Techniques

Here are IBM's comments to the November 19, 2004 Public Draft of the HTML 
Techniques.


2.1 Meta Redirect
Agree with last editorial comment that an example is needed.  If server 
side redirect is recommended, should provide an example.

2.3 Site Map
Agree with the idea of having summaries in the outline. Always helps to 
add a little more info. 

2.4 Collection information
Good idea, but how will the user know that the current document is part of 
an overall document collection? I understand that there will be an 
indication of start, next, etc, but which collection do these documents 
belong to? Maybe requiring that a contents link is provided on each 
document could remedy this. Gives a common point to return to.

3.1 Section headings
Mixed responses concerning making the first heading on each page an H1. It 
does help for consistency but some web authors may prefer NOT to restyle 
the H1 and thus begin the use of headings with a heading whose default 
size (via the browser default) is smaller to start (thus not beginning 
with H1).
Need to clarify the section about user's not wanting to use headers 
because of the default styles. Make it clear that the solution is to style 
THE HEADER tags and not use CSS to create an alternative to the header 
tags. 

5.5 Marquee
Agree with the editorial Note about providing an example, whether 
scripting based or not.

5.11 CSS instead of presentational markup
Agree with the comment in the editorial note to provide a list of HTML 
elements and equivalent CSS representations. This section could use a bit 
more detail.  Should explain why this is an accessibility issue.

5.14 Color
This technique links back to the guideline (1.4) that requires sufficient 
color contrast. The Guideline contains a placeholder for methods to 
determine correct contrast.  There should be a link to the methods to 
determine correct contrast directly in the technique as well (or for now a 
link to a placeholder).

5.15 Relative size
Why does it help me to size things relatively? Should indicate what 
problems this can create for the end user.

7.4 Identifying groups of rows (optional)
Agree that this needs more explanation as to why it is useful. 

9.4 Image and text links side by side
Would not deprecate the second example

9.6 tabindex to skip link groups (future)
Editorial notes says that there are user agent issues and that the 
technique should say "don't do this". Why is this a future technique if it 
is just going to say "don't do this"?  Needs a better explanation / 
justification.

12.1 Markup and style sheets rather than images: the example of math
is about markup, style sheets, and images - it does not belong in a 
section on "programmatic objects and applets"

12.2, 12.3, 12.4, 12.5, 12.7,  all require a text alternative for objects 
and applets. 
Text alternative is defined as having the same function as the non-text 
content. Assuming that the baseline assumption proves to be valid, this 
will not be required at level 1. 

14 Frames intro
Recommend changing "visually enabled" to "sighted"

14.3 Describing Frame Relationships
It is confusing to present deprecated techniques this way. The styling of 
the task draws your eye to it. But the task says to use longdesc. So it is 
easy to miss the recommendation that it not be used. Why is this one done 
this way when 15.2, also a deprecated technique, is done in the opposite, 
more understandable way? i.e. in 15.2, the task says "don't do something".

14.4 Writing for browsers that do not support frame
Associating the noframes technique with level 1 SC implies that noframes 
is required at level 1. noframes should not be required at level 1. In 
fact, frames are not necessarily even non-text content.

14.5 Frame sources
HTML is not the only thing that works. For example, NSF (Lotus 
Notes/Domino) files work fine as well as JSP and ASP.

14.7 Alternative content for iframe
again, this is associated with level 1 SC but it should not be required at 
level 1

14.8 Longdesc for iframe 
 if providing longdesc doesn't hurt accessibility, I recommend omitting 
this technique. We should bother telling people not to do something if it 
doesn't matter.

15.2 Implicit labels for form controls (deprecated)
 if user agents don't support something that meets the HTML spec, it's a 
user agent issue, not a content issue. We should not prohibit this in our 
techniques document. It could go in the "gap" document Gregg is talking 
about where we describe what to do to make up for lack of user agent 
support.

16.1 Text alternatives for scripts 
A text alternative should not be required. The requirement is to make 
scripts accessible. If they can't be made accessible, then an alternative 
must be provided. Our view is that the alternative should not be provided 
via noscript because then the user who is using a UA that supports 
scripts, has to go turn off scripts to get the accessible alternative. 
Noscript should only be required at level 3 (per guideline 4.2).

16.2 JavaScript URLs
Oppose the restriction on using JavaScript URLs.  How does support for 
JavaScript affect accessibility?  It will affect ALL users that have 
JavaScript turned off but this doesn't make it an accessibility issue. The 
page author should be able to decide if the site requires JavaScript or 
not.  Some pages, especially those in web applications, require 
significant additional coding to make work without the use of JavaScript 
URLs.  As long as the JavaScript works with AT it should be allowed.

16.3 Scripted form submission
Scripts to validate forms are very useful and improve the usability of 
sites for most users. Is there some way to code this so that if scripts 
are supported, it runs the script, and if scripts aren't supported, it 
just submits the form and the error processing has to occur on the server?

16.5 Device dependent event handlers
needs some work. Onclick is device independent in some cases but not all 
cases.

16.5 and 16.6 seem to be in conflict with each other. Perhaps they should 
be combined into one technique.

16.7 Auto submit combo boxes
I think these do work with the keyboard. It's just that most users don't 
know the correct keyboard operation. So I think the requirement is that 
either you don't use them or you inform the user how to navigate them with 
the keyboard. And I'm not sure title is the right way to do this as most 
user agents will not read a title except when the user requests it via 
some key combination. This technique would only work for screen readers 
anyway. Sighted keyboard users would be left confused about how to operate 
the control.