E-mail List Archives
Thread: Flash and Checkpoint 1.3
Number of posts in this thread: 7 (In chronological order)
From: Steve Vosloo
Date: Wed, Aug 14 2002 11:57PM
Subject: Flash and Checkpoint 1.3
No previous message | Next message →
I'm still trying to get my head around WCAG Priority 1 Checkpoint 1.3:
"1.3. Until user agents can automatically read aloud the text equivalent
of a visual track provide an auditory description of the important
information of the visual track of a multimedia presentation."
Am I correct in saying that there is not one single site out there,
which has a Flash movie on it without an accompanying auditory
description of the movie, that is compliant with W3C level-A?
My initial idea of providing an alternative text-only description is
apparently not sufficient. What's a developer to do? Remove the flash
movie or find the nearest sound recording studio?
Thanks
Steve
Steve Vosloo
Division Manager
Usability J
From: John Foliot - bytown internet
Date: Thu, Aug 15 2002 4:59AM
Subject: RE: Flash and Checkpoint 1.3
← Previous message | Next message →
MessageSteve,
I'm still trying to get my head around WCAG Priority 1 Checkpoint 1.3:
"1.3. Until user agents can automatically read aloud the text equivalent
of a visual track provide an auditory description of the important
information of the visual track of a multimedia presentation."
Am I correct in saying that there is not one single site out there, which
has a Flash movie on it without an accompanying auditory description of the
movie, that is compliant with W3C level-A?
If you subscribe to strict adherence of all WCAG checkpoints (Bobby Fans!),
then, yes, you are essentially correct.
The spirit of the checkpoint (by my interpretation) is that when presenting
a multi-media presentation that the essential information is conveyed for/to
all users. Thus an audio narration requires a text transcript for those who
cannot access the audio content, and a visual presentation must be
"story-boarded" for those who cannot access the visual presentation. Like a
storyboard, not every single motion or action need be documented, but the
key, essential actions must be delivered to the end user ("... description
of the important information..."). The checkpoint states that this
"storyboard" treatment must (should?) be made available as an audio track.
Taking it to the MAX, the description should probably be presented in both
audio and text formats; my personal concern is that it may in fact reach a
point where the content developer is delivering too much information
simultaneously, causing "brain-overload" at the user end. I suppose the
ultimate answer is to provide the media in multiple formats/configurations,
allowing the end user to choose the delivery options which best suits their
particular needs. I further suppose that something of this nature could be
developed using Flash, but it would probably involve a fair bit of
development work.
The National Center for Accessible Media (Media Access Group of WGBH /
Public Televison) has a showcase page with various streaming media examples,
and may be found at:
http://ncam.wgbh.org/richmedia/showcase.html
<opinion>
Many content developers are faced with the daunting task of using the often
vaguely worded concepts outlined in the WCAG guidelines as Standards, even
though they were never written in the language of Standards. The spirit of
this checkpoint is a good one, but the practicality of it poses serious
developmental considerations. Using SMIL (a W3C approved technology -
guideline Priority 2 - 11.1) allows the simultaneous inclusion of text and
audio/video (a.k.a. captioning) but the inclusion of a second (optional)
audio track which runs concurrent with the main presentation is problematic
at best. *Most* users requiring descriptions of visual files (gifs, jpegs,
pngs, streaming video, flash animations, etc.) are probably using a "user
agent" which *IS* reading out loud text (JAWs, IBM HPR, etc.), so providing
a text file which storyboards the actions (or including the action
information as part of the overall script file) would probably suffice, but
the guideline does not address this possibility.
</opinion>
My initial idea of providing an alternative text-only description is
apparently not sufficient. What's a developer to do? Remove the flash movie
or find the nearest sound recording studio?
Mic test... testing one, two, three, check.
Good Luck
JF
Thanks
Steve
Steve Vosloo
From: Andrew Kirkpatrick
Date: Thu, Aug 15 2002 5:19AM
Subject: Re: Flash and Checkpoint 1.3
← Previous message | Next message →
Steve,
Whether you are correct or not depends on what you are calling a Flash
From: Steve Vosloo
Date: Thu, Aug 15 2002 11:22PM
Subject: RE: Flash and Checkpoint 1.3
← Previous message | Next message →
Thanks John.
>*Most* users requiring descriptions of visual files (gifs, jpegs, pngs,
streaming video, flash animations, etc.) are probably using a "user
agent" which *IS* reading out >loud text (JAWs, IBM HPR, etc.), so
providing a text file which storyboards the actions (or including the
action information as part of the overall script file) would >probably
suffice, but the guideline does not address this possibility.
<more opinion>
I totally agree. The guidelines should be divided into "real world" and
"ideal world" suggestions. The site I'm dealing with has thousands of
Flash movies. They're all complimentary to existing information -- it's
a school site. So a user (student) of the site reads the HTML text and
then sees a Flash animation of the theory. If she was reading a book,
she'd see a diagram. The web is interactive so we're able to offer an
animation. But the point is that without the animation the student would
still be supported by the other channels -- text and images. In this
spirit, and acknowledging that providing auditory descriptions of
thousands of Flash movies is prohibitively expensive, I think a text
description is a good 2nd option.
<more opinion>
From: Carol Foster
Date: Tue, May 20 2003 11:16AM
Subject: Adobe Acrobat 6.0
← Previous message | Next message →
Does anyone know anything about the new and improved accessibility
features for Adobe Acrobat 6.0, due out the end of this month, beyond
what is on the Adobe site, mainly at
http://www.adobe.com/products/acrobat/access_overview.html
Thanks,
Carol
--
Carol Foster, Web Developer
Internet Publishing Group, Information Technology Services
University of Massachusetts, President's Office
phone: (413) 587-2130
fax: (413) 587-2148
mailto: = EMAIL ADDRESS REMOVED =
http://www.umass-its.net/ipg
--
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Paul Bohman
Date: Thu, May 29 2003 3:12PM
Subject: RE: Adobe Acrobat 6.0
← Previous message | Next message →
I'm quite impressed with the strides that Adobe is making with their Acrobat
software. They've taken the initiative to push the accessibility of the
Acrobat reader into new areas. I've only recently downloaded and tested the
reader, so this is only my first impression, but so far my first impression
is positive.
One of the major innovations that Adobe implemented in Acrobat 6.0 is a
self-voicing feature. Adobe uses the built-in voice synthesizer of the
operating system (of Mac and Windows computers). These synthesizers are
generally not as sophisticated as the typical screen reader that you can buy
(e.g. JAWS, Window-Eyes), but you have the choice. If you already have a
screen reader installed, you can read Acrobat documents with that screen
reader. If you don't have a screen reader, you can let Acrobat read it to
you, using the operating system voice synthesizer.
Even beyond this, Acrobat 6 has the advantage of being able to read many PDF
documents that were NOT created specifically for accessibility. In the past,
documents had to be created with tagged PDF in order to be read reliably by
screen readers. With Acrobat 6.0, I was able to read older documents that
were not in tagged PDF format, using the operating system voice synthesizer.
This is a huge step forward in many respects, because it places less of the
burden on the document authors. On the other hand, I feel that it is
necessary to caution people that the reading was not perfect. The operating
system voice synthesizers are more difficult to understand than high end
screen readers. Also, images without alternative text are still
inaccessible. There's no way for Acrobat 6.0 to compensate for that.
Similarly, the reading order of complex documents can still be confusing.
Adobe does allow you to modify the reading order, but I wouldn't place too
much confidence in this feature. It's a great idea, but it would be
better--and more reliable--if the content authors took care of this issue
(reading order) while creating the content.
All in all, though, I'm impressed. Acrobat 6.0 still can't read scanned
documents (unless they're converted to text) or fix authoring errors (e.g.
missing alt text), but it can increase the accessibility of documents that
were previously totally inaccessible.
I would still recommend creating tagged PDF documents as the most accessible
approach of making PDF files accessible to screen readers, but it is
heartening to see that software developers are taking the initiative to fix
issues with their own products.
ONE MORE CAVEAT: I would still recommend posting an HTML version of the file
in addition to the PDF version. This gives the user a choice of formats.
Plus, not everyone will have the latest Acrobat reader. Also, some people
find the reader to be inconvenient, cumbersome or confusing (especially
those with cognitive disabilities). So don't think that all your PDF
problems are solved yet, but the seriousness of those problems is
diminishing.
P.S. Again, I want to emphasize that this is not an official "software
review", but it is a summary of my first impressions.
Paul Bohman
Technology Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Center for Persons with Disabilities
www.cpd.usu.edu
Utah State University
www.usu.edu
From: Michael Burks
Date: Thu, May 29 2003 3:41PM
Subject: Challenge Response Systems, and Spam Filtering Systems
← Previous message | No next message
All,
I recently was forced to use a Challenge Response System to help prevent
spam, that definitely does not meet accessibility standards.
Does anyone have any ideas on this subject? The subject of prevening
spam and making the systems that do so accessible ?
Sincerely,
Mike Burks
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/