E-mail List Archives
Thread: Use of Audio Interferes with Screenreaders?
Number of posts in this thread: 5 (In chronological order)
From: Thomas Walczyk
Date: Thu, Feb 05 2004 3:01PM
Subject: Use of Audio Interferes with Screenreaders?
No previous message | Next message →
Hello!
Are there any guidelines or best practices concerning how audio may be
incorporated without hindering the use of a screenreader (such as JAWS)? I
am working on a web-based training course that includes audio narration. In
certain instances involving Flash animation with embedded audio, the
narrator automatically begins to speak when the user enters the page.
(Unfortunately, technical specifications limit the course to Flash 5 rather
than Flash MX.)
Although we provide audio transcripts and alternate text description of the
animation, there is still a problem in that both JAWS and the narrator are
speaking at the same time.
* Could a user experienced with JAWS adequately deal with this
situation?
* Would this situation (a screenreader and an audio file speaking at
the same time) be a violation of any of the WAI conformance levels? I could
not find anything in the standards that directly addresses this issue.
Many thanks!
--Tom--
--Tom Walczyk--
Senior In
From: John Foliot - WATS.ca
Date: Thu, Feb 05 2004 4:15PM
Subject: RE: Use of Audio Interferes with Screenreaders?
← Previous message | Next message →
Tom,
Hmmm... you've hit on a good one. Of course, in the "real world"
simultaneous audio tracks will be difficult to screen reader users.
To the first question:
Could a user experienced with JAWS adequately deal with this
situation?
This of course is not a fair question, as *how* much experience is required,
and what is your criteria for "adequate"? If two people were standing at
your desk, speaking to you simultaneously about two completely different
subjects, would you be able to fully comprehend and respond to both audio
streams? Perhaps, depends on the topic, right? But your experience in
"listening" is not the only skill brought into play, as you would also need
to (quickly) determine *the more important* stream, if you could in fact
only concentrate on one. But if you do not know which of the two is more
important, how can you decide? So this becomes then not only an issue for
the visually impaired user of screen reading AT, but also for users who may
have cognitive difficulties.
To the second question:
Would this situation... be a violation of any of the WAI conformance
levels?
This specific scenario is not directly addressed in either the current WCAG
1 or the draft WCAG 2, although perhaps it should be. The problem with WCAG
1 (and there are many of them) is that "auto-start" of multi-media content
is not addressed, and in WCAG 2 the authors are going for a more general
overview or "spirit of intent" document as opposed to specific do's and
don'ts. Yet neither addresses multi-media content in this way. So if you
are going for strictly "technical" conformance, then no, having two audio
streams commence simultaneously is not against the WCAG 1 Guidelines.
However, in the spirit of the guidelines (which, IMHO is the real point
here) this scenario is an accessibility "issue" which should be avoided. If
you need "documentation" to back up this position, it would only be through
inference:
WCAG 1 - Guideline 7. Ensure user control of time-sensitive content
changes.
"Ensure that moving, blinking, scrolling, or auto-updating objects or
pages may be paused or stopped."
The Guideline here discusses the fact that "...Some people with cognitive or
visual disabilities are unable to read moving text quickly enough or at
all." Close... Then there is checkpoint #7.5 "Until user agents provide
the ability to stop auto-redirect, do not use markup to redirect pages
automatically." While it speaks to "auto-redirect", one could expand this
to include "auto-start-anything", as what they authors here (I believe) were
looking at is giving control to the user.
WCAG 1 - Guideline 8. Ensure direct accessibility of embedded user
interfaces.
"Ensure that the user interface follows principles of accessible design:
device-independent access to functionality, keyboard operability,
self-voicing, etc."
Here, the guideline vaguely recommends that the ability to "work" an
embedded interface (or function) be accessible. It could be argued that
having two computer voices speaking to you at the same time removes the
ability to properly "control" the functionality. Checkpoint #8.1 states
"Make programmatic elements such as scripts and applets directly accessible
or compatible with Assistive technologies" Using my arguments so far, the
"applet" (embedded object - your Flash file) is not "directly"
accessible..., yes, but directly?...
WCAG 1 - Guideline 9. Design for device-independence.
"Use features that enable activation of page elements via a variety of
input devices."
Here, the guideline states: "Device-independent access means that the user
may interact with the user agent or document with a preferred input (or
output) device -- mouse, keyboard, voice, head wand, or other." I would
interpret this again as giving the user the choice as to how they initially
access the web content, including the Flash file. Making it auto-start
takes away the users preference (again, IMHO).
Looking forward, WCAG 2 comes pretty close to addressing this topic without
specifically mentioning it.
It proposes:
Guideline 2: OPERABLE. Ensure that Interface Elements in the Content are
Operable by Any User
2.2 [CORE] Users can control any time limits on their reading,
interaction, or responses unless control is not possible due to nature of
real time events or competition.
Benefits of Checkpoint 2.2 (Informative): "People with reading
disabilities, cognitive disabilities, and learning disabilities often need
more time than most people to read and comprehend written text. People with
physical disabilities might not be able to move quickly or accurately enough
to interact with moving objects. Content that is updated often might not be
processed and read in time or in the proper order by an Assistive technology
or voice browser."
I would argue that having an auto-start anything violates the basic premise
that "Users can control any time limits", but again, this is interpretive,
not specifically mandated. And while the authors speak of "moving objects",
the same issues are in fact present here with "moving audio" (i.e. audio
that starts without direct input from the user), but in a different way...
Anyway, I'm sure that this is a much longer response than you expected, but
you asked... <grin>
For me, bottom line, don't do it.
JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca 1.866.932.4878 (North America)
From: Richard Sweet
Date: Fri, Feb 06 2004 6:31AM
Subject: RE: Use of Audio Interferes with Screenreaders?
← Previous message | Next message →
I'm not an expert on Flash, so excuse that my ignorance on technical issues!
I would encourage you to use the audio narration from an accessiblity point
of view. Many users have disabilites (other than visual impairment) that
make an audio track beneficial. But addressing this particular issue, why
does the narrator have to speak 'automatically'? Could you not have a button
(or similar) to start it? Might not be ideal from a usability point of view,
but could have the advantage of allowing all users to 'repeat' the page's
commentary. Screen-reader users could then choose whether to read the
alternate text or listen to the narration. I suspect many would choose the
latter, as a pleasant break from the electronic voice!
A better alternative might be to provide an option right at the start of the
presentation to 'mute' the voiceover, indicating that this is recommended
for screenreaders.
A last resort: at the start, suggest that screenreader users hit 'Escape' on
loading a new page to cancel the reading. (They can still navigate around
either during or after the narration if required).
Richard
From: John Foliot - WATS.ca
Date: Fri, Feb 06 2004 8:49AM
Subject: RE: Use of Audio Interferes with Screenreaders?
← Previous message | Next message →
Richard,
Half right, half wrong...
I agree, having the flash file with a "start" button is the better way, not
only for the visually impaired, but as you pointed out, all users.
However, the other two suggestions you offered still exhibit the basic
problem... both the screen reader and the flash file start reading
automatically once the page has loaded. Have "hidden" text for the screen
reader which suggests that they hit "escape" or "mute" will start reading at
the same time as Mr. Flash Narration starts talking. Boom! No good...
Don't get me wrong, I am not saying don't have Flash narration... I'm all
for it if it is done properly (text alternative, alt/longdesc if so
required, etc., etc.). Where I personally take issue is with the
auto-start, and as I have outlined previously, while there is no direct
guideline or checkpoint which forbids the use of auto-start in multi-media
presentations, I believe it to be contrary to the "spirit" of universal
accessibility.
Cheers!
JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca 1.866.932.4878 (North America)
From: Thomas Walczyk
Date: Fri, Feb 06 2004 10:37AM
Subject: RE: Use of Audio Interferes with Screenreaders?
← Previous message | No next message
Thanks to you both for your thoughtful replies! Its clear we will have to
do some thinking about the auto-start issue. Perhaps the most elegant
solution would be to allow the user to globally turn the audio on or off in
the courseware, but that is rather difficult to achieve with the audio
embedded in separate Flash files.
I mentioned the "user experienced with JAWS" because several people I asked
about this issue said they thought that JAWS could be configured to wait for
a specific event (such as an audio file playing) before beginning to read
the page. After doing some research, I think they may be referring to the
option to press the CTRL key and stop the screenreader while the audio is
playing.
--Tom--