Re: Technology-specific checks: XML, HTML, SMIL, CSS

aloha, wendy!

what follows is an extremely rough pass at adding XHTML
checkpoints to the draft located at
<http//www.w3.org/WAI/GL/2000/05/wcag-techs.html>

note that the following are
a) far from comprehensive
b) far from complete
c) an attempt to illustrate how to preserve accessibility
(and its sister, validity) from both a backwards and
forwards compatibility perspective
d) an attempt to ascertain if i am on the right track

--- begin proposed XHTML Techniques for
<http//www.w3.org/WAI/GL/2000/05/wcag-techs.html>

Guideline 1. Provide equivalent alternatives to auditory and
visual content.

Checkpoint 1.1 Provide a text equivalent for every non-text
element.

XHTML
1. "alt" is a required attribute of the img element.
Authors are also encouraged to use the "longdesc" attribute
to provide a rich description of the image when appropriate
(i.e. when an understanding of the contents of the image is
indispensable to an understanding of the document as a
whole).

2. While XHTML 1.0 provides an "alt" attribute for the
applet element, since XHTML doesn't allow "empty" elements
(that is, elements without terminating tags), authors are
strongly encouraged to include rich equivalents for applets
by using the applet element as a containing tag, as in the
following example, which illustrates how one might provide
an equivalent alternative for an applet that generates a
"roll-over" graphic which lists the site's sponsor:

<applet codebase="URI" width="%Legnth" height="%Legnth" ...>
<dl>
<dt>A list of our sponsors:</dt>
<dd>Acme Novelty Corporation of America</dd>
<dd>Acme Africa</dd>
<dd>Acme Europa</dd>
</dl>
</applet>

3. Use the XHTML modules for the object and map elements

4. For frames:
4A. Use the noframes element to provide an functional
equivalent for the frameset. Authors are encouraged to
replicate the content of the navigation frame within the
noframes container, so as to provide a user employing a
frames-incapable user agent or who has configured the UA not
to render frames with access to the content of the frameset.
4B. Use the "longdesc" attribute to provide equivalent
access to the content of each frame.
4C. Do not use the frame element to point directly to a
rasterized image or any other binary multi-media file.

5. For inline sub-windows (the iframe element)
5A. Replicate the content contained within the body element
of the document referred to by the "src" attribute between
the start and end tags for the iframe to provide inline
alternative content
5B. Use the "longdesc" attribute to provide equivalent
access to the content of each inline frame.
5C. Do not use the iframe element to point directly to a
rasterized image or any other binary multi-media file.

Guideline 3. Use markup and style sheets and do so properly

Checkpoint 3.1 - Use semantics and structure in accordance
with the markup language being used
Note that this is the proposed generalized checkpoint as
discussed DRAFT of Generalized WCAG

Checkpoints.

XHTML
1. All elements must have closing tags. "Empty" (non-
container) elements, such as IMG or HR, inherited from
HTML4, must either have an end tag (i.e. <br></br> or
<hr></hr>) or the element declaration must end with />
(forward slash greater-than), as in the following examples

<img src="dduck36.png" alt="Donald Duck, as he appeared in 1936." />
<hr title="Section Separator" />

2. All elements must nest properly.  This means that if you
declare an element, you must also close it--using either the
end tag defined for the element or by using the /> (forward-
slash greater-than) to terminate the "empty" element--before
closing any parent elements.

3. All HTML element and attribute names used in an XHTML
document must be in lower case.  This is particularly
important, as XML is case-sensitive, meaning that <LI>
(capitalized) and <li> (lowercase) are two different tags.

4. Attribute values must always be enclosed in quotes.

5. While it is possible to use both the "lang" and "xml:lang"
attributes when specifying a natural language change, the
value of the "xml:lang" attribute takes precedence. Authors
are, therefore, encouraged to use both the "lang" and
"xml:lang" attributes to ensure maximal backwards
compatibility.

6. Use the "id" attribute to identify fragment identifiers.
(Note While HTML 4 defined the "name" attribute for the
elements a, applet, form, frame, iframe, img, and map to
ensure backwards compatibility,  HTML 4 also introduced the
"id" attribute. While both attributes are designed to be
used as fragment identifiers in HTML, in XHTML 1.0, the name
attribute of these elements is formally deprecated, and will
be removed in subsequent versions of XHTML. The reason for
this change is that in XML, URIs that end with fragment
identifiers of the form "#foo" do not refer to elements with
an attribute name="foo"; rather, they refer to elements with
an attribute defined to be of type ID--that is, the id
attribute in HTML 4.)  XHTML documents, therefore, must use
the "id" attribute when defining fragment identifiers, even
on elements that historically have also had a "name"
attribute. .Since many existing HTML user agents don't
support the use of ID-type attributes in this way, identical
values should be supplied for both of these attributes to
ensure maximum forward and backward compatibility--for
example

      <a id="toc" name="toc">Table of Contents</a>

Authors should also be aware that, since the set of legal
values for attributes of type ID is much smaller than for
those defined for "name" in HTML (which is defined as type
CDATA in HTML but redefined as a new type, NMTOKEN, in
XHTML), care must be taken when converting existing HTML
documents into XHTML. The values of these attributes must be
unique within the document, valid, and any references to
these fragment identifiers (both internal and external) must
be updated should the values be changed during conversion.

7. Since XML parsers are permitted to silently remove the
contents of comments, the historical practice of hiding
scripts and style sheets within comments to make the
documents backward compatible is highly unlikely to work as
expected in XML-based implementations.

For maximum backwards compatibility, use external style
sheets,  especially if your style sheet uses any of the
following characters

      < (less-than)
      & (ampersand)
      ]]> (double-right bracket greater-than)
      -- (double-dash)

Likewise, authors are strongly encourage to use external
scripts, and may find it necessary to do so if the script
contains any of the following characters

      < (less-than)
      & (ampersand)
      ]]> (double-right bracket greater-than)
      -- (double-dash)

8. Respect XHTML's "element prohibitions}, as defined at
<http//www.w3.org/TR/xhtml1/#prohibitions> and in Section
4.9 of the XHTML 1.0 Recommendation
<http//www.w3.org/TR/xhtml1/#h-4.9>

The following elements have prohibitions on which elements
they can contain--this prohibition applies to all depths of
nesting, i.e. it contains all the descendant elements.

a -- cannot contain other a elements.
pre -- cannot contain the img, object, big, small, sub, or
sup elements.
button -- cannot contain the input, select, textarea, label,
button, form, fieldset, iframe or isindex elements.
label -- cannot contain other label elements.
form -- cannot contain other form elements.

--- end proposed XHTML Techniques for
<http//www.w3.org/WAI/GL/2000/05/wcag-techs.html>
-------------------------------------------------------------------
ACCOUNTABILITY, n.  The mother of caution.
                         -- Ambrose Bierce, _The Devil's Dictionary_
-------------------------------------------------------------------
Gregory J. Rosmaita      <unagi69@concentric.net>
Camera Obscura           <http://www.hicom.net/~oedipus/index.html>
VICUG NYC                <http://www.hicom.net/~oedipus/vicug/>
Read 'Em & Speak         <http://www.hicom.net/~oedipus/books/>
-------------------------------------------------------------------

Received on Thursday, 1 June 2000 16:52:13 UTC