RE: Javascript alternatives not necessary?

Michael Cooper writes:
 > 
 > This is, I think, an oversight in the guidelines, not a deliberate position.
 > I agree with Robert's position that if scripts, etc. are supported and
 > accessible, there is no need for text alternatives, but think the guidelines
 > need to address this issue specifically rather than leave it unsaid. 

Not in guideline 1; this issue belongs under guideline 4. I would
rather not complicate any of the other guidelines with qualifications about
which technologies are and are not supported.
 > 
 > There is actually a general issue here that applies clearly to WCAG 1.0
 > Checkpoint 6.3 but also applies to other issues. For me, the question is,
 > for any non-text content, if that content type provides accessibility
 > features, should the guidelines require that a text alternative also be
 > provided? Using some HTML examples, if I have a Flash or SVG plugin in my
 > document, and I use the accessibility features of those technologies, do I
 > still need to provide text alternative content for the <object> element that
 > loads them? If I have client side scripts doing something interesting on the
 > page, but those scripts are accessible (assuming they're supported) do I
 > have to provide text alternatives in a <noscript>? I would interpret that
 > the requirement to provide text alternative for most images would be
 > triggered by the fact that the .gif and .jpeg formats don't support embedded
 > accessibility features - but I would argue that if an image format did, this
 > question would be equally applicable to that case.

The requirement under 1.1 is that a text equivalent be provided for
non-text content. Images, audio and any combination of these count as
non-text content. Scripts are not examples of non-text content, but
any images, sounds etc., they create are.

Thus if an image format supports the inclusion of text equivalents,
and the format is supported per guideline 4.1, then the provision of a
text equivalent by means of the pertinent features of the format
suffices to meet guideline 1.1.

 > 
 > In considering these questions as applied to the guidelines, we also have to
 > keep in mind that we're being technology-independent. So, we shouldn't
 > assume that the non-text content is a "plugin" to an otherwise textual
 > document, as would be the case with HTML loading Flash or something. For
 > instance, an XHTML document could just have SVG appear in the middle of it
 > with no special <object> element needed to load it up - and therefore no
 > hooks for a text alternative besides what is provided by SVG itself. The
 > issue of differential or unpredicatable assistive technology for mixed media
 > like this is one we need to have some kind of statement about but can't make
 > a priori assumptions about.

On the approach I favour, we first apply guideline 4.1 to determine
whether XHTML+SVG is supported. If so, then the descriptions contained
in the SVG itself satisfy guideline 1.1.
 > 
 > The answer I've heard from the group in the past is that non-text content
 > should have a label associated with it (under Guideline 1.1) even if we
 > expect it to be supported and it has accessibility features. I guess it
 > would be up to Techniques then to describe how to provide that label in
 > specific cases. But I'm not sure if that is a future-proofed position, so I
 > think we should consider it some more. And even if that is the group's
 > position, I don't think the Guidelines are clear enough about that, so we
 > need to say something more.
 > 
As appears from my responses I disagree with the position described in
the above. If we do need to say something more on this topic, it must
be under guideline 4.

Received on Sunday, 25 July 2004 04:32:39 UTC