IBM comments on the HTML Techniques July 30, 2004, public draft

IBM comments on the July 30, 2004, public draft of the HTML Techniques

General: 
 It would be nice if the samples includes a working code example rather 
than just a code listing.   IBM tries to use this technique on our 
examples pages and users find it helpful to see the code for the technique 
and how it actually works.
Some examples reference HTML 4.01 and others reference XHTML 1.0.  It 
would be nice if the techniques consistently used only one technology or 
at least made it clear which technology was used for each technique. 
Consider putting the details of deprecated techniques in an appendix and 
only including the heading description in the main part of the document. 
>From the Abstract,  "although some techniques contain Cascading Style 
Sheet solution"  Please make clear which techniques use CSS and which use 
only HTML.  It would be even better if the combined CSS and HTML 
techniques were in a separate section.
>From the Abstract,  "cross-references between success criteria and 
techniques are not fully established"  This would make it appear that it 
is left to the reviewers, when in fact there are specific relations in 
each section.   However the relations are not established in any sort of 
heading that are reflected in the table of contents which requires someone 
looking for a how to meet Guideline 4.1 to look through this entire 
document to locate the data needed.  Please  provide a cross-reference 
appendix. 
>From the Introduction - "Techniques in this document are known to contain 
errors" Which ones?  Please fix or mark them before they are put out for 
review again. 
Metadata
1.1 doctype - The doctype is not generally considered meta data 
information and probably shouldn't be included here.
1.2 "All documents, including individual frames in a frameset, should have 
a title element that defines in a simple phrase the purpose of the 
document." Note that the (mandatory) title element, which only appears 
once in a document"  These two statements appear contradictory - it might 
be nice to clarify that a frame source IS a separate document.  An example 
of frame title might help to clarify.
What is the accessibility benefit of the <address> tag?  Should it really 
be included?
1.4 - glossary - An example would be helpful. 
Navigational supports
2.1 "The meta element should be used specify metadata for a document 
including keywords, and information about the author"  Technically this 
sentence is incorrect since not all meta tags specify metadata.  For 
example,  http-equiv meta tags are designed to be used as equivalents to 
HTTP headers.  This should be rewritten for better clarity.  More detail 
and an example of the right way to use meta would be helpful.   A better 
wording of the sentence below the Task box would be, "The Refresh meta 
element" or something similar, not "meta http-equiv of '(timeout; url='".
 2.1 "It is acceptable to use the meta element to create a redirect when 
the time-out is set to zero. However, it is preferable to use server-side 
methods to accomplish this."  Why is an immediate redirect allowed but a 
timed redirect that might provide additional information on why the 
visitor is redirected is not?  More information and justification would be 
helpful. 
2.2 Meta refresh - the technique says do not use meta refresh.  But there 
are some applications that need to do this.  For example, how should long 
running transactions indicate status to users, for example an order 
process that needs to validate information and cannot provide status 
within the HTTP timeout?  Another example are real-time scores, which 
cannot be shown unless content does refresh.  It would be helpful if WCAG 
offered techniques to address these issues.
Language
4.1 Languages -  It would be good to include a link to the language codes. 
  If XHTML is to be supported this technique should be updated  since both 
lang and xml:lang should be used for XHTML documents.
4.2 language example (and possibly others) - The double quotes around 
attributes should be ", not typographic quotes 
Text Markup
5.1 - b and i elements.  The document indicates that the b and i elements 
were deprecated in HTML 4.01 and XHTML because they were used to create a 
specific visual effect.  Though it appears that the elements will be 
deprecated in XHTML 2.0, they are in both the HTML 4.01 and XHTML 
specifications without reference to being deprecated.  There are people 
who have argued against their usage for a long time, but that's not the 
same.  With the addition of CSS support providing the ability to place 
class information on these elements, many of us don't really see a 
difference between em and i or strong and b.  To disallow their usage at 
compliance level 1 will require a considerable amount of effort to modify 
many existing authoring tools from various vendors.
 5.2 Abbreviations "* uncertain whether these elements need to be marked 
up on the first occurrence on the page or for every instance, * unclear on 
the distinction between abbreviations and acronyms, in English and other 
languages, * the HTML Working group has proposed removing the acronym 
element in favor of a single abbreviation element for all cases, * how 
common must a word be before it need not be marked up this way."  I think 
it makes a difference how someone is to use the "document"  if they use it 
for reference, I'd say mark all instances.  If the "document" is generally 
read from top to bottom, novel form then only the first time would seem to 
be necessary.  I'd declare acronyms separate from abbreviations.  All 
abbreviations that are not acronyms should be marked as abbreviations.  I 
would not remove the acronym element.
5.4, 5.5 - blink and marquee;  It shouldn't matter what technique is used 
for blink and marquee they should either be allowed or disallowed.  If 
allowed, then list the pros and cons of the different techniques.
5.9 - title attribute - please clarify what is meant by "where 
appropriate" both here an in the related "clarify link text with the title 
attribute".  Some concrete examples would help here. 
 5.10 - supplemental clues  This one is not very clear, perhaps an example 
would help. 
5.14  Need to be clear what this section is for.  Does this section mean 
these are recommended for accessibility?    Perhaps only list structural 
elements you don't wish to have used.?   Or eliminate this section. 
Lists
6.1 Ordered lists - Under the task is the advice, "For numbered lists, 
compound numbers are more informative than simple numbers." Agree. 
However, it should be noted that there is no current coding technique that 
facilitates creation of compound numbers. The list item attributes 
start="' and value="" were deprecated in HTML 4.01 and there is no 
replacement.
 6.3  - list styles - consider moving this to css techniques document.
Data Tables
 7.1 table caption - Do you want to suggest a preferred location for the 
caption (using the align attribute)?
7.3 - table summary"It is rare to use both the caption element and the 
summary attribute since one or the other should be enough to provide a 
description."  This information would be useful if it was  included in 
7.1. Also, many people don't understand when to use caption element, title 
attribute and summary  for a table.  An example of each would be useful. 
7.9 - axis Please provide an example of the use of axis. 
Tables for Layout
8.0 Tables for Layout is a bit schizophrenic  "information about deciding 
if a table is used for data or layout." "should consider using style 
sheets for layout and positioning" "Do not use the table element for 
layout purposes unless the desired effect absolutely cannot be achieved 
using CSS." "when using tables to create a layout, do not use structural 
markup to create visual formatting"  This section should clearly indicate 
either CSS for layout and no tables or either are ok, and one is 
preferred.  As it is the reader is really not left with a comfortable 
feeling about what they should and should not do. 
8.4 - tables Why was 640x480 selected as the resolution.  It seems like an 
arbitrary choice, some browsers have much smaller sizes (mobile clients), 
the average PC client has a much larger size.
Links
 9.1 supplement link text with title where appropriate - Please add a 
definition of what is meant by "where appropriate".  Some examples could 
help clarify. 
9.2 - text for images used as links.   There are two examples, the one 
with both and image and text link should probably be removed since it is 
covered in the next section, 9.3.   Information about user agent support 
would be helpful.
9.4 grouping links The text only discusses putting links in groups so they 
can be skipped. Skip nav can be accomplished without grouping links etc. 
Please provide more information about the accessible reason to put links 
in groups.
 9.6 skip links - consider  re-titling this to    "skip repetitive 
navigation links"
9,9 and 9.10 - access keys.  For those not familiar with access keys this 
is confusing and needs more details.  Should access keys be used or not?
9.11 anchors and links -  Is this for any link to another window?  I 
suggest that this should be taken care of in the browser, not in the HTML. 
 The links could be read differently when a new page is opened.
9.13 - opening new windows.  The target attribute is no longer allowed in 
XHTML 1.0 strict so this technique needs clarification for HTML version.
Images
10.3 - misuse of alt text.   Is this a case where a negative example is 
needed to clarify?  Many people may not understand the description.
10.4 Image titles - "Do not use the title attribute on images." .  This 
doesn't seem right.  Especially since IE picks up title before alt for its 
mouseover images function, and, at least one draft of XHTML 2.0 was going 
to deprecate ALT and go with title. 
10.9 Describe images without longdesc - An editorial note says "We hope to 
deprecate this technique in the future but right now felt it was useful." 
Please do not let this technique be deprecated.  It is still the best 
alternative for all audiences.  Describing an image, chart, or graph in 
the actual document text makes the information accessible to everyone. 
Additionally, as we have recently discovered, longdesc implementations 
vary between the assistive technologies, making that technique 
unattractive because of the different behaviors. Supplemental note: Use of 
longdesc in Jaws causes a new window to be launched to contain the 
longdesc page.  Use of longdesc in IBM's Home Page Reader causes 
navigation to the longdesc page.  This inconsistent behavior makes it 
difficult to design a longdesc page that satisfies both audiences. For 
example, if a "close window" link is included for the convenience of the 
Jaws user, that same link completely closes the browser for the HPR user.
10.13 Background images - The advice is too limiting, and not well 
described.  It needs to be rewritten to correctly describe the problem and 
proper use. Background images are very useful for visual embellishment, 
and can actually be thought of as enhancing accessibility for those 
audience where visual symbols are more readily understood than text.  The 
difficulty is the same as with any image.  The best practice is: A 
background image should not be used as the only method to convey 
meaningful information.  Since background images do not support ALT text, 
use them only for visual embellishment where they are not the only method 
for conveying information.
Image Maps
11.2 server side image maps - "If you must use a server-side image map, 
please consult the section on server-side image maps "  This link just 
takes you to the top of section 11 (that you are already reading) and thus 
is redundant and not useful. 
Programmatic objects and applets
Chapter 12 - be careful here, this entire chapter describes proprietary 
techniques that never were standards compliant.  Does WCAG making 
recommendations about how to use those techniques now offer the W3C's 
approval of nonstandard elements and attributes? I don't think that is the 
intention.   The problem should be described, and responsibility left with 
techniques owner to create standards compliant methods of using it. For 
example Macromedia should be responsible for creating standards compliant 
methods of including Flash objects.   The W3C should probably not be 
providing techniques for <embed> since it is a proprietary element. 
Frames
There are good reasons for not using frames, but the reasons mentioned 
here do not necessarily still apply: the previous page functionality has 
greatly improved in browsers and is no longer a major concern, referring 
to specific content with a unique URI is generally desirable but not an 
accessibility requirement, and not the case with dynamically 
generated/POSTed content either so this is by no means specific to frames. 
 Opening a frame in a new browser window does not make sense to me (a 
frame by definition is not a separate window, user initiated unframing 
should not disorient the user)
This sentence in the beginning of the Frames section, "Thus, content 
developers should always make the source (src) of a frame an HTML file " 
should say HTML document rather than file. 
14.1, 14.2:  The techniques say that the frame name attribute is not 
presented to the user.  I agree with their comments that the frame title 
attribute is not interchangeable with the name attribute, but AT does read 
the name attribute if title is not provided.  IBM guidelines say you 
should include both because some versions of AT will look at name before 
they look at title.  The newer versions of JAWS, Window-Eyes and HPR look 
at frame title first, but that's not true of earlier releases.  Also, 14.1 
and 14.2 seem to contradict:  14.1 says, "The title attribute is not 
interchangeable with the name attribute. The title labels the frame for 
users; the name labels it for scripting and window targeting. The name is 
not presented to the user, only the title is." which implies that name 
should not be used.  14.2 implies you should have both. 
14.3:  In this version longdesc has now been deprecated for use with frame 
element.   The logic given is that longdesc is not well  supported, so 
shouldn't be used.  This doesn't seem like a valid reason to deprecate the 
function since AT may be adding support in their new releases (or should 
at least be encouraged to do so).  Should this really be deprecated?
14.4:  The frame BODY element is required in the examples.  Is this really 
required?   I've seen conflicting information on other sites about the 
requirement for the BODY element and would appreciate clarification.
14.5:  I agree with the editor comment about the narrow scope of valid 
frame sources.  Clearly, there is a problem with using an image file as a 
source, but there are other valid sources.  This is a major issue for IBM 
since all Domino files are .nsf source and fail this checkpoint and 
current checking tools.  The same problem occurs with .JSP files which are 
also valid.  This should be reworded to give examples of other accessible 
source besides HTML while making it clear (as it does) that image files 
are not accessible.
14.6:  This contradicts 14.3 which says that longdesc has been deprecated. 
 Here it explicitly tells you to use longdesc.
14.7:  The way the techniques for iframe are worded, it makes it sound 
like you MUST have alternative content for any iframe.  This isn't true. 
Use of IFRAME has the same accessibility as FRAME and is well supported. 
The one issue I do see with iframe is that many applications  use IFRAME 
for layout by putting many empty IFRAMES on a page to control the layout. 
They are in the tab/navigation order and have titles.  Having a title such 
as "this frame is empty and used only for layout" is annoying when 
listening with a screen reader.  I think this issue should be addressed by 
WCAG.  Do you just not put a title - it will still be in the navigation 
when you F6.  I haven't found any Web checking tools that currently test 
for the title attribute in IFRAMES.
14.8 longdesc on iframe - editorial comment states, "We just want to say 
that while HTML permits longdesc, it isn't meaningful to provide.". Why 
isn't it considered meaningful?
Forms
15.2 Implicit labels for form controls (deprecated)  - Home Page Reader 
does support implicit form labels.  Shouldn't we be encouraging the other 
user agents to properly support the HTML spec for implicit form labels 
rather than deprecating this technique?
15.3 - title attribute on forms controls:  Is this technique to use the 
title attribute going to be the recommendation for fields with no visible 
labels?  The example needs to be more specific or there should be a 
specific technique to address this.  The big problem today is that ALL the 
Web checking tools look for the LABEL element.  If you use the title 
attribute, you will fail the checker.  Once the checking tools get the 
word that title attribute is acceptable, how do they determine when LABEL 
must be used and title is acceptable?  The acceptable use of title is not 
clear in the example.  The IBM  techniques use either CSS or invisible 
images with LABEL to ensure that the forms pass the checkers.  IBM shows 
the use of the title attribute, but do not recommend as a replacement for 
LABEL because of the problems outlined above.
15.5 - grouping options of select elements:  I agree with the concern 
about OPTGROUP - this is another example of where the AT vendors should be 
encouraged to support the feature. 
15.6 - tab order in forms.  The title says "tab order in forms" but the 
task includes links and objects, which are usually outside of forms. The 
use of tabindex does not help a keyboard user to move more logically 
through a page - it just creates a tab order that is different than the 
normal document tab order, thus creating confusion. Even though the use of 
tabindex is valid HTML, the example only encourages poor use usage of 
tabindex. 
15.8 - place holders in empty controls:  I'm glad to see this is 
deprecated. This affects USABILITY , not accessibility and there is debate 
whether it really makes the form more usable.
script techniques
16.2 device independent event handlers says, Note that there is no 
keyboard equivalent to double-clicking (ondblclick) or mouse movement (
onmousemove) in HTML 4.0. Avoid using these elements."  What is the device 
independent equivalent of onmouseover?  The table shows onfocus but that 
is not equivalent.  Does that mean people shouldn't use onmouseover?




Becky Gibson
Web Accessibility Architect
                                                       
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com