Kynn's Reply: Textual Images vs. Styled Text

At 9:42 PM -0500 11/23/00, Leonard R. Kasday wrote:
>But nonetheless, do these uses of graphical text as navigation 
>elements violate the current wording of 3.1?  I hope we can reduce 
>this to "yes" or "no".
>My opinion:  "yes".

No.

Reason:  There are no technologies which can adequately replace the
use of graphical text, due to lack of support, lack of functionality,
and so forth.  Therefore, an outright ban on graphical text is
inappropriate.

>And should whatever wording we come up with to replace 3.1 still 
>keep these sites in violation?
>My opinion:  "yes".

No.

Reason:  We should not be dictating specific solutions, but instead
identify what the problem is, and how to overcome those problems.  The
problem is that navigation (and indeed, all content) must scale
appropriately and readably if users with visual impairments request
this be done.  Due primarily to poor support of various technologies
by the browser manufacturers, this is not easily done.  A web author
must provide the necessary meta-information (markup) to allow for
this.  One way to do that is to not use graphical navigation.  However,
it's not the _only_ way, and to claim this as an absolute rule is
throwing the baby out with the bathwater.

>Does Lisa's latest wording accomplish this, i.e. keep these sites in 
>violation:
>My opinion: "yes"

This is Lisa's proposal, right?
>>  > Oh all right, I'll try again
>>>
>>  > 3.1 When an appropriate markup language exists AND WILL WORK,
>>>  use markup
>>  > rather than images to convey information TO ALLOW TEXT SCALABILITY.
>>  > [Priority 2]   For example, use SVG for line art, MathML to mark up
>>>  mathematical equations, and CSS for text-oriented special
>>>  effects. You may
>>>  not present relevant textual content
>>>  as an image, unless the text has a primarily graphical
>>>  function, and the
>>>  effect cannot be achieved with markup,
>>>  (as in the case of some for logos and limited accent
>>>  elements) provided that
>>>  you provide a textual equivalent to the content contained in
>>  > the image.

My answer:

No.

The "AND WILL WORK" statement gives a clear "out" for use of graphical
text, and the further explanation grants an exception which can be
used by all the web sites Len listed.  Therefore, this re-definition
does not do what Len wants it to do.

I do like the use of "to allow text scalability" in this guideline
as it makes it clear why the guideline exists.

There are problems with this proposal:

1.  "AND WILL WORK" is undefined and means the same thing as "until
     user agents" -- granted, this is allowed in WCAG 1.0, but it is
     a very problematic construction.

2.  I object in principle to any accessibility guideline which says
     "there is technology which does what you want, but isn't
     accessible, so instead you _must_ use this other technology
     which won't meet your needs, but it is sainted W3C technology."
     I object to any guideline which says "tear down and simply don't
     do that, because we don't consider it important" instead of saying
     "do that, but also do this to make it accessible."

3.  The "for example" section seems to speak authoritatively ("use",
     "you may not", etc) but these are actually techniques and do not
     belong in the guideline itself.

4.  I am very wary about demanding the use of SVG, MathML, or CSS in
     a guideline, something we have typically delegated to the
     techniques (for well-written guidelines/techniques).  I am
     especially uncomfortable about suggesting the use of SVG or
     MathML as use of those _generally unsupported_ languages will
     lead to an overall _decrease_ of access to content by _nearly
     all audiences_ which effect NO OVERALL INCREASE IN ACCESSIBILITY
     because, to the best of my knowledge, no assistive technology
     can parse SVG or MathML effectively.  Therefore, you are throwing
     away a technique which may work for some for a technique which
     works for almost no one, let alone the people whose needs we are
     claiming to champion, based entirely on dogma.  This type of
     dogmatic suggestion should not be a checkpoint but one of a
     number of techniques.

I suggest the following rewrite:

      Provide content (textual or otherwise) in a manner which allows
      the user to scale the presentation size.

The use of "markup" to accomplish this is a red herring; these
guidelines should not be mandating what technologies are used but
rather telling how to use them.  (Guidelines which provide guidance
on which technologies are best to use are fine, but outright mandating
of SVG, MathML, etc is wrong.)

I think that our problems are resulting because the "make sure that
people can scale visual presentation to their liking" guideline has
been place in Guideline 3, which is about "proper use of markup
and styles."  This casts the entire debate in those terms, and therefore
assumes that _the_ way to provide textual scalability is _only_ to
use markup/styles "properly."

This therefore discounts options such as that used for image maps,
where the navigation elements are repeated in text lists on the
bottom of the page.  Those guidelines are presented in Guideline
1, under checkpoints 1.1 and 1.5.

This checkpoint is all about using graphics responsibly and
accessibly, and should not be about forbidding graphics entirely if
markup _could_ be used.  Therefore I propose that a more appropriate
location for this checkpoint is Guideline 1.  Thematically, it fits
much closer with the idea of providing improved access to image map
content and images themselves, than with the idea that valid HTML is
good for you.

--Kynn
-- 
Kynn Bartlett <kynn@idyllmtn.com>
http://www.kynn.com/

Received on Monday, 27 November 2000 15:11:34 UTC