Web Content Accessibility Guidelines 2.0 - comments on "HTML Techniques for WCAG 2.0"

 Note: in the following document, a line prefixed with "--" refers to a section
 of text from the WCAG 2.0 WD document as published on the 19th of November 2004,
 while "++" refers to an alternative text suggested by me.


 General
  The document states: " To encourage migration to newer technologies, examples
  for techniques are XHTML unless there is a specific reason to present an HTML
  example." but leaves out the current difficulties involved with using XHTML
  "in the wild". It is estimated that using XHTML on the client-side will not
  become feasible until a new version of the popular Internet Explorer user
  agent is available - something which is not likely to happen during 2005.

  I suggest that the examples be written in HTML 4.01 Strict, and that XHTML
  be left out until such a time that it can be safely used on the WWW. If this
  is not possible - which would amaze us all - then a section on how to use
  server-side transformation of XHTML to HTML based on a UAs Accept header must
  be added.

  This issue is particularly important with regards to the comment made
  under "Future Work": "User agent support information is not included in this
  draft. In future drafts, the WCAG WG intends to provide this information to
  help authors decide which techniques to implement."

  In addition, the document often refer to whether or not a specific
  assistive technologies support a specific method or implementation. This is
  not something the WCAG should concern itself with: the methods used should
  be device independent in order to avoid a repetition of the "Best Viewed
  in Netscape" syndrome: "This site is accessible IF you are using AT such
  and such".

  It is -not- the task of the WCAG to specify which UAs that are, or are not,
  acceptable for use on the WWW, nor what their capabilities should or should
  not be.



 1.1
    -- "Validating to a published formal grammar and declaring that validation
    --  at the beginning of a document lets the user know that the structure of
    --  the document is sound."

  This statement is incorrect. While there is immense value in validating
  to published, formal, grammars, the doctype added to a document does not
  in any way represent a "validation".

  It is worth noting, that it is quite possible to produce a valid document
  with unsound structure. For instance, the body of the document could consist
  of a single <div>, a number of <font size=7> 'headings' and many line
  breaks (<br>).

  We suggest a rewrite:

    ++ "Validating to a published formal grammar lets the user know that the
    ++  syntax of the document is sound, in addition to minimizing the
    ++  possibility of incorrect structure/rendering. This is important in
    ++  order for a User-Agent to correctly handle/present a document. The
    ++  use of a transitional grammar should be avoided whenever possible."


  Following this is:

    -- "It also lets the user agent know where to look for semantics if it needs
    --  to."

  The DOCTYPE declaration in an SGML/XML-based language refers to a specification
  of syntax, and syntax only. There is no grammar specified in a formal
  manner in a DTD. This statement should be removed.

  In addition, the example used is described as

    -- "This is an example defining an English-language document as using
    --  the HTML 4.01 Transitional DTD."

  It isn't. The only language information in the example is the "EN" in the
  Doctype. This describes the language of the comments in the DTD, not
  the language of the document itself. For the document to match the description
  'lang=en' would need to be added to the <html> tag. (On a side note, I think
   we should avoid the use of Transitional DTDs wherever possible).



 2.1
   -- "It is acceptable to use the meta element to create a redirect when the
   --  timeout is set to zero. However, it is preferable to use server-side
   --  methods to accomplish this."

  This method of redirection should not be used. It is illogical to use a
  client-side method when the redirect should be applied immediately, and
  the same method has no well-defined way of specifying which type of
  redirect (see HTTP) should be in effect. This impacts both user-agents and
  cache technologies. Suggested rewrite:

   ++ "Server-side methods, by way of HTTP status codes and Location headers,
   ++  should be used for all redirection purposes. Periodic reloading of a
   ++  resource should be left to the discretion of the User-Agent."


 5.1
   -- "The b and i elements were deprecated in HTML 4.01 and XHTML because
       they were used to create a specific visual effect."

  Neither b nor i have been deprecated.




 3.1
   -- "... how common must a word be before it need not be marked up this way."

  The idea that a "common" word need not be marked up as an abbreviation or
  an acronym is based on the faulty assumption that the a randomly selected
  user X shares the same "common" ground as the author.

  This assumption mean that any user not already sharing a knowledge of the
  topic matter with the author is left without any explanation of the given
  words. It will be important for WCAG 2.0 to clarify these issues; but also
  to remove such myths as the above editorial comment.


 5.4
   -- "Do not create blinking content with the blink element."

  This guideline, which is excellent advise, is marred slightly by the comment
  that CSS can be used instead of the blink element. It is highly unlikely that
  blinking content becomes more accessible when implemented by way of CSS.
  Suggested rewrite:

   ++ "Do not create blinking content"  
  

 5.5
   -- "Do not create scrolling text with the marquee element."

  The same problem exist here as with 5.4. The issue is not which technology
  should be employed to implement a bad idea, but whether the idea is bad or
  not.

  As the checkpoint remarks: scrolling content can provide accessibility
  problems. Suggested rewrite:

   ++ "Do not create scrolling text"


 5.12
   -- "If you must use HTML elements to control font information, use big and
       small, which are not deprecated."

  At this point in time there is no practical reason left to use HTML elements
  to control font information. Suggested rewrite:

   ++ "Do not use HTML elements for any layout or presentational purposes."



 5.13
   -- "How often are these elements used? Are they supported by assistive
       technologies?"

  These questions are clearly out-of-scope for WCAG. Structural and semantic
  markup should be employed regardless of whether one specific user-agent
  support or do not support the markup. Please remove.




 5.14
   -- "Provide a list of HTML color attributes."

  There is preciously little point in providing a list of HTML colour
  attributes when (a) these are clearly listed in the HTML specification, and
  (b) using them is not recommended. Please remove this.




 6.1
   -- "Format ordered lists so their items can be followed logically."

  It would seem clear that an ordered list can be followed logically by
  virtue of being explicitly ordered ... please clarify this point?




 8
   -- "Editorial Note: Furthermore "layout tables" are not defined in the HTML
       specification. This interacts with Technique @@doctype and validating
       code."

  Please clarify this point. A table can validate without difficulty, and
  still be used to implement layout. The term "validation" must be used
  precisely in this document.

  The section marked '8' need a full rewrite, and spell out quite clearly
  that tables are not - under any circumstance - be used for implementation
  of layout.

  The only section to be kept should be 8.4, which is needed both for backward
  compatibility and for linearising agents.



 9.8
   -- "Some designers would prefer not to have the skip link visible to all
       users. There are several techniques used to hide the skip link."

  This suggestion is harmful to accessibility, as it will create a situation
  which keyboard users will, at one point, loose track of the link focus. This
  can be particularly difficult for people with low vision using regular
  browsers, but also impacts "non-disabled" users. A suggested rewrite would
  be:

   ++ "Some designers would prefer not to have the skip link visible to all
       users. This creates accessibility and usability difficulties and
       must be avoided. An alternative style sheet, presented through the
       standard LINK element and not a per-site specific mechanism for
       style sheet switching, which allow the user to hide the link should
       be provided instead."



 9.10
   -- "Do not cause pop-ups or other windows to appear and do not change the
       current window without informing the user."

  At this point in time - late 2004 - it should be make quite clear: do not
  open new windows. The WCAG should be device independent - and an assumption
  that you can warn a user before a "window" is opened is faulty: what will a
  non-GUI user believe when warned that something which cannot happen on his
  system is about to happen? Suggested rewrite:

   ++ "Do not cause pop-ups or other windows to appear, and do not change the
       current window."

  Note that this also impacts on 9.12




 9.14
   -- "Use the link element to refer to accessible alternative documents."

  A comment should be added here that "alternative" documents, i.e. alternative
  versions of the actual content as opposed to alternative rendering, should
  be avoided. The situation here has not changed since WCAG 1.0, and this needs
  pointing out. "Text-only" or "Braille-only" versions of content is a last
  resort at best.

  The principle of "graceful degradation" should be stressed in WCAG 2.0 to
  a much larger extent than in 1.0.



 10.1
   -- "When using the img element, specify a short text alternative with the
       alt attribute."

  Throwing words such as "short" about in a specification does not aid in the
  use of it. Either it must be explicitly defined, or re-written so as to mean
  "as long as is needed to adequately communicate the same message as the image
  was meant to convey".


 10.13
   -- "Do not use background images."

  This needs clarification. Is the WCAG making an explicit stand against
  all forms of background images, or only those implemented by way of the
  deprecated HTML attribute 'background'? This would be better solved by 5.12
  as suggested rewritten in this document.


 12.5
   -- "Provide alternative content inside the applet element."

  The APPLET element is deprecated. That means 12.5 actually violates 1.1. We
  recommend removing this, and adding to 12.4 to ensure that the OBJECT element
  with appropriate alternative content is used instead.


 12.6
  See 12.5


 12.7
   -- "Provide alternative content for embed with noembed."

  Neither the EMBED nor the NOEMBED elements are part of any published
  grammar, and should never be used in production code. It is astonishing
  to see such a suggestion being used in the Web Content Accessibility
  Guidelines.

  The draft must be updated to make it quite clear that all object inclusion
  should be made by way of the OBJECT element. Non-HTML elements should not
  be included as a recommendation in the WCAG 2.0 WD.



 12.8
  See 12.7

 12.9
   -- "Use the embed element within the object element for backward
       compatibility."

  Again, the EMBED element does not exist in HTML, and should not be used at
  all. The OBJECT element, with appropriate alternative content, should be
  used for "backward compatibility".



 14
   -- "For visually enabled users, frames may organize a page into different
   --  zones. For non-visual users, relationships between the content in frames
   --  (e.g., one frame has a table of contents, another the contents themselves)
   --  must be conveyed through other means."

  WCAG 2.0 seek to address some of the issues left over from the first version.
  One such issue is clearly that of frames - it is time for us to move away from
  these, and to make it explicitly clear that the technology should not be used
  at all. Suggested rewrite:

   ++ "For visually enabled users, frames may organise a page into different
   ++  zones. However, frames as implemented by today's browsers create
   ++  a number of difficulties for both 'non-disabled' and disabled users. It
   ++  is therefor our recommendation that frames should not be used under any
   ++  circumstance"

  It should be made clear that no site can conform to WCAG 2.0 if frames are
  in use.


 15.2
   -- "Do not use the label element implicitly."

  This is included based on the argument that no UA today support this
  technique. This is a faulty assumption for two reasons: (a) several UAs
  today -do- support implicit labels, and (b) avoiding a documented technique
  due to possible user agent malfunction is not a future-proof methodology, nor
  does it in any way guarantee backward compatibility.

  Note, also, that the phrase "implicit label" is commonly used in reference
  to labels that can be inferred from their position in the content, and not
  labels that are explicitly encoded. This goes against phrasing in the HTML
  specification, but should nevertheless be changed so as to avoid confusion.


    - Tina Holmboe, Greytower Technologies (UK) Ltd.
    - David Dorward.

Received on Wednesday, 1 December 2004 19:41:33 UTC