- From: John M Slatin <john_slatin@austin.utexas.edu>
- Date: Tue, 19 Apr 2005 22:50:12 -0500
- 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