RE: Javascript alternatives not necessary?

Hi Michael,
Be aware about flash accessibility.
Flash player make fla h content accessible only in MS IE under MS Windows, due that Flash refer to MSAA.
So, at now, flash accessibility don't exist.

----- Messaggio originale -----
    Da: "Michael Cooper"<michaelc@watchfire.com>
    Inviato: 20/07/04 21.08.00
    A: "w3c-wai-gl@w3.org"<w3c-wai-gl@w3.org>
    Oggetto: RE: Javascript alternatives not necessary?
    
    
    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. 
    
    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.
    
    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.
    
    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.
    
    I support going in the direction Robert saw us going, but I raise these
    issues to make sure we've thought the whole thing through.
    
    Michael
    
    > -----Original Message-----
    > From: Fentress, Robert [mailto:rfentres@vt.edu]
    > Sent: Monday, July 19, 2004 11:05 AM
    > To: w3c-wai-gl@w3.org
    > Subject: Javascript alternatives not necessary?
    > 
    > 
    > 
    > I just noticed there is no 2.0 equivalent to the WCAG 1.0 guideline:
    > 
    > 6.3 Ensure that pages are usable when scripts, applets, or 
    > other programmatic objects are turned off or not supported. 
    > If this is not possible, provide equivalent information on an 
    > alternative accessible page. [Priority 1]
    > 
    > Is this intentional?  If so, it is wonderful.  6.3 always 
    > struck me as quite unreasonable in that it made conforming to 
    > other standards such as SCORM, which uses javascript as part 
    > of its specification, impossible.  The important thing is 
    > that the scripts are made accessible, particularly by 
    > allowing keyboard access to all the functionality, not that 
    > all functionality be available when javascript is not 
    > supported.  That makes many kinds of web applications impractical.
    > 
    > Sorry if this is ground that has already been covered, but I 
    > am new to the list and wanted to make sure I am understanding 
    > the standard correctly.
    > 
    > Rob
    > 
    > 
    
    
    

[Messaggio troncato. Toccare Modifica->Segna per il download per recuperare la restante parte.]

Received on Tuesday, 20 July 2004 15:19:20 UTC