Re: Please review for this week's call: proposal and process for the "text in images" thread

Wendy A Chisholm wrote:
> 
> Please:
> review this entire message.
> 
> Please:
> Do not respond to this message unless you have new information that has not
> been presented yet.  There has been quite a lot of traffic on this thread
> and I have been very pleased to see people sending considerate, thoughtful
> messages.  I am glad to see how much information has been collected in the
> last couple of weeks.  However, Jason and I believe we are ready to wrap up
> this discussion.
> 
> Therefore, I propose:
> 
> <blockquote> 3.1 Use markup rather than images to convey information.
> [Priority 2]  This checkpoint is strongly tied to checkpoint 11.1.
> Note: Until style and graphic markup languages are more common, minimize
> the use of text in images.  For example, use HTML text styled with CSS.
> Choose common fonts (such as Arial and Times) that can be rendered using
> CSS. You may use text in images for logos and limited accent elements where
> specialized fonts and text treatments are required and cannot be achieved
> with CSS.
> </blockquote>

Hello,

Counter-proposal: Delete checkpoint 3.1. 

Rationale:

Reading from the 5 May 1999 version of WCAG 1.0, I understand
two requirements in 3.1, one related to layout and one related to
text in images.

1) "Don't use images for layout, use style sheets instead" is
   covered at the same P2 level by checkpoint 3.3 
   ("Use style sheets to control layout and presentation.")

2) The reason not to encode text in images is that you want
   people to use text markup since it is more likely to 
   be available as speech and braille. 
   If people encode text in images, then checkpoint 1.1 requires
   a text equivalent. Is there a difference between using
   the IMG element and alt plus longdesc, using OBJECT plus
   a rich text equivalent, or using SVG with an embedded
   text equivalent? These are all solutions to ensuring
   that content is available in three modes (visual, aural, 
   tactile). 

   The fact that SVG is a text format for images does not mean
   that the data used to construct the image will be usable by
   people as speech output. A text equivalent is
   required for the image data, even if both are included in the
   same SVG file. Therefore, the definition of "non-text element"
   as used in checkpoint 1.1 needs to make clear that a
   "non-text element" may be composed of (text) characters. The
   same goes for ascii art. (I refer you to the definition of
   non-text element in the last call draft of the UAAG 1.0 [1]).

3) We should encourage authors to use structured markup 
   to achieve the previous two goals when that markup is supported.
   Invoke checkpoint 11.1 here. The question of "when do we know
   that X is supported?" is pushed to checkpoint 3.3 (style
   sheets).
   
 - Ian

[1] http://www.w3.org/TR/2000/WD-UAAG10-20001023/#def-non-text-element

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Wednesday, 25 October 2000 16:00:17 UTC