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 Tuesday, 19 April 2005 23:44:26 UTC