Re: Kynn's Reply: Textual Images vs. Styled Text

Kynn,
Thanks for the binary answers.

But I don't think you're addressing exactly what I was asking.


>>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.

Your argument says why we shouldn't have this guideline.  But that's not 
the question here.  The only question is what is says, which is:

quote

1 When an appropriate markup language exists, use markup rather than images 
to convey information. [Priority 2] For example, use MathML to mark up 
mathematical equations, and style sheets to format text and control layout. 
Also, avoid using images to represent text -- use text and style sheets 
instead.

unquote

It plainly says to avoid using images to represent text.  Now, you might 
say that "avoid" falls short of mandatory. But if we weaken "avoid" that 
way, it makes 7.1 to "avoid" flicker (Priority 1) optional, and if we truly 
want no flicker we'll have to make that an errata,  and examine at all the 
other uses of "avoid".  You might also say that the statement falls within 
the "For example" clause and claim that anything within a "for example" is 
optional, as long as you do it some other way.  But if that's what "for 
example" means, then we're not even requiring ALT text, since ALT text 
falls inside a "for example".  So we'll have to make that an errata also, 
and examine all the other places that use "For example" (which is 
practically every guideline).

Well, since "avoid" and "for example" aren't defined, I suppose those are 
escapes, but if we use them to escape we have to admit that every other 
part of the guidelines that use "for example" or "avoid" have to be 
re-considered.  Is that your position?



>>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.

But again, that's not the question I was asking.  I was asking if _these 
particular sites_ would be in violation; by which I mean of course these 
particular sites as they exist right now.  Right now, they have no other 
means to provide scalability.  So even if we all we did was impose a high 
level requirement of scalability they would still be in violation.

As for your analysis of Lisa's wording, you're right, "And will work" does 
provide an out.  But just from the discussion so far it's clear that 
there's disagreement about what we want to say.  We'll need to agree on 
what we want to say before we decide how to say it.

Note that the first two questions addresses the narrow issue of whether 
certain current sites are, in their current form P2 compliant.  That's my 
current,  real world concern--e.g. what I'll be  telling an auditorium full 
of webmasters next week.  If the sites aren't compliant, one way to fix 
them is with CSS.  You raise the question of what other methods we should 
allow.  A fair question.  But first, I'd really like to see if we can just 
agree on whether sites as they exist today are compliant.

What are your answers to the more narrow question?   Are the sites as they 
exist now P2 compliant?

Len


>>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/
>

--
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP and Dept. of Electrical Engineering at Temple 
University
(215) 204-2247 (voice)                 (800) 750-7428 (TTY)
http://astro.temple.edu/~kasday         mailto:kasday@acm.org

Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
http://www.w3.org/WAI/ER/IG/

The WAVE web page accessibility evaluation assistant: 
http://www.temple.edu/inst_disabilities/piat/wave/