W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2005

RE: UAAG Priority 1 checkpoint analysis summary

From: John M Slatin <john_slatin@austin.utexas.edu>
Date: Tue, 19 Apr 2005 22:50:12 -0500
Message-ID: <6EED8F7006A883459D4818686BCE3B3BFB8117@MAIL01.austin.utexas.edu>
To: "Joe Clark" <joeclark@joeclark.org>, "Loretta Guarino Reid" <lguarino@adobe.com>
Cc: <w3c-wai-gl@w3.org>

Joe wrote:
<blockquote>
I can't think of a context in which [background images] cannot be
identified 
programmatically, either through CSS background { } declarations or
plain 
old HTML.
</blockquote>
Probably true for HTML. Does it hold for other technologies-- e.g., SVG,
Flash, PDF, SMIL? What about the case of an image containing text over a
background and placed on the page by CSS? Or for that matter a single
GIF or JPEG that shows words over a background? 

"Good design is accessible design."

Dr. John M. Slatin, Director 
Accessibility Institute
University of Texas at Austin 
FAC 248C 
1 University Station G9600 
Austin, TX 78712 
ph 512-495-4288, fax 512-495-4524 
email jslatin@mail.utexas.edu 
Web http://www.utexas.edu/research/accessibility 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Joe Clark
Sent: Tuesday, April 19, 2005 6:44 PM
To: Loretta Guarino Reid
Cc: w3c-wai-gl@w3.org
Subject: Re: UAAG Priority 1 checkpoint analysis summary



> 2.1 Render content according to specification
>        WCAG 4.1 requires writing to spec (but at level 3)

...which will probably not exist. Valid code should be a Level 1 
requirement. Won't that light a fire under a few seats?

Then there's the issue of formats that cannot be validated.


> UAAG checkpoints that may need additional coverage in WCAG:
>
> 2.3 Render conditional content
>        Do we need a requirement to expose conditional content
> programmatically?

That issue is still up in the air, isn't it?

But let us not forget that the HTML and CSS specs require certain
content 
and presentations never to be rendered under certain circumstances:

* alt

"For user agents that cannot display images, forms, or applets, this 
attribute specifies alternate text" (emphasis added)

<http://www.w3.org/TR/REC-html40/struct/objects.html#adef-alt>

Hence if you can display the image, you *may not* display the alt. (Then

it's interesting to use CSS :after to display the alt in, say, a 
printout.)


* summary on table

"This attribute provides a summary of the table's purpose and structure 
for user agents rendering to non-visual media"

<http://www.w3.org/TR/REC-html40/struct/tables.html#adef-summary>

Hence summary *may not* be rendered visually.


* display: none and visibility: hidden

The former cannot be manifested in any way; the latter is hidden but
takes 
up space in the layout. See
<http://www.alistapart.com/articles/fir/#css>.


Hence, machines may "easily" determine if certain conditional content 
could or should even be rendered (classic example: alt text).



> 3.1 Toggle background images
>        WCAG 1.4 requires making it easy to distinguish foreground
> information from background information. However, we may need a
requirement 
> that the background image can be identified programmatically

I can't think of a context in which they cannot be identified 
programmatically, either through CSS background { } declarations or
plain 
old HTML.



> 3.3 Toggle animated or blinking text
>        Do we need a requirement to identify animated or blinking text
> programmatically? Does WCAG 2.3 cover this sufficiently?

You can't produce blinking text in valid HTML per se, as <blink> was
never 
valid code, thankfully. In HTML+CSS you can, by using text-decoration: 
blink. See <http://www.w3.org/TR/CSS21/text.html#lining-striking-props>.

(I'm pretty sure that fragment identifer, #lining-striking-props, is a 
secret rugby reference that somebody just loved being able to slip in.)

In those cases, blinking text can always be identified by a machine.

I suppose there are lots of other cases, like Flash and animated GIFs, 
and, God help us, <marquee>.


-- 

     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
       --This.
       --What's wrong with top-posting?
Received on Wednesday, 20 April 2005 03:50:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:36 UTC