W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2006

RE: REwrite of 1.1.6

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Tue, 14 Feb 2006 14:17:34 -0600
To: "'David MacDonald'" <befree@magma.ca>, "'John M Slatin'" <john_slatin@austin.utexas.edu>, "'WCAG'" <w3c-wai-gl@w3.org>
Message-ID: <00a601c631a3$b1dd2bd0$ee8cfea9@NC6000BAK>
Correct.

 

What you describe goes beyond what is required (since only the collated
version is required by the sc) but since it does deliver the collated
version as the default - it would be sufficient.  

 


Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
The Player for my DSS sound file is at http://tinyurl.com/dho6b
<http://tinyurl.com/cmfd9>  

 

 


  _____  


From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of David MacDonald
Sent: Tuesday, February 14, 2006 10:35 AM
To: 'John M Slatin'; 'WCAG'
Subject: RE: REwrite of 1.1.6

 

>>>I'm sorry, but I don't understand. SC 1.1.6 (which is what this
discussion is about) requires a single document containing the text of both
the captions and the audio descriptions. As far as I know, this document is
not presented by the media player-- it's completely separate from the
multimedia presentation. There is nothing to turn on or off.

 

Say there is a server side technology such as PHP, or ASP , Cold Fusion etc
pushing delivery units. Let's say it's pushing HTML pages to a browser. It
pushes a collated transcript. In the top corner of the delivery unit there
is a button that says "hide descriptions". The user hits the button and the
server pushes a delivery unit forward that doesn't have the description.
This would not be a violation of 1.1.6 because there would be a collated
version available.

 

David MacDonald

.Access empowers people
            .barriers disable them.

www.eramp.com


  _____  


From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of John M Slatin
Sent: Tuesday, February 14, 2006 10:58 AM
To: David MacDonald; Andrew Kirkpatrick; WCAG
Subject: RE: REwrite of 1.1.6

 

David writes:

 

<blockquote>

2)       Server side delivery technique which allows descriptions to be
turned off if desired.

 

The current wording allows the creation extended descriptions and allows for
a mechanism to be added for turning them off. Proprietary software
manufacturers
can also create their own techniques that would allow descriptions to be
turned off. The current wording makes sure there is a version available
where
descriptions are delivered in a linear order without forcing keystrokes to
be used after each caption. And I think that is a good thing. I don't think
forcing screen reader users to jump around hundreds of times in a document
is fair. It is heartbreaking to work with blind people with repetitive
strain

</blockquote>

 

Current media players allow the user to toggle captions and audio
descriptions.

 

What am I missing?

 

John


"Good design is accessible design." 
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web  <http://www.utexas.edu/research/accessibility/>
http://www.utexas.edu/research/accessibility/

 

 

 


  _____  


From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of David MacDonald
Sent: Monday, February 13, 2006 8:46 pm
To: 'Andrew Kirkpatrick'; 'WCAG'
Subject: RE: REwrite of 1.1.6

Andrew says:

 

>> that's not exactly true, if someone wants to address  1.2.5 to reach
level 3 they might need to. [extended descriptions]

 

You are right.

 

1.1.6 For prerecorded multimedia content, a combined document presenting
captions and audio description transcription information in a manner that
allows users to access the information in linear order.

 

I would leave it as:

1.1.6 For prerecorded multimedia content, a combined document containing
both  <http://www.w3.org/WAI/GL/WCAG20/appendixA.html#captionsdef> captions
and transcripts of
<http://www.w3.org/WAI/GL/WCAG20/appendixA.html#audiodescdef> audio
descriptions of video is available. [How
<http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20060117/Overview.h
tml#text-equiv-text-doc>  to meet 1.1.6] 

And I would add 2 new advisory techniques. 

 

1)       Create "skip links" over descriptions in HTML

2)       Server side delivery technique which allows descriptions to be
turned off if desired.

 

The current wording allows the creation extended descriptions and allows for
a mechanism to be added for turning them off. Proprietary software
manufacturers can also create their own techniques that would allow
descriptions to be turned off. The current wording makes sure there is a
version available where descriptions are delivered in a linear order without
forcing keystrokes to be used after each caption. And I think that is a good
thing. I don't think forcing screen reader users to jump around hundreds of
times in a document is fair. It is heartbreaking to work with blind people
with repetitive strain injury (RSI). I think we should be helping people
with disabilities, rather than giving them compounded disabilities.

 

The current wording allows all the flexibility necessary I would say. It
says the combined document is available. It doesn't even say it is the
default presentation. And it allows for extended descriptions and it allows
for them to be turned off.

 

David MacDonald

 

.Access empowers people
            .barriers disable them.

www.eramp.com


  _____  


From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com] 
Sent: Sunday, February 12, 2006 9:39 PM
To: David MacDonald; w3c-wai-gl@w3.org
Subject: RE: REwrite of 1.1.6

 

David,

Its fine if people want to create extended audio descriptions...but they
have absolutely no obligation to do that under our guidelines. 

that's not exactly true, if someone wants to address 1.2.5 to reach level 3
they might need to.

But if they want to do that, it is fine to introduce code to jump *over*
audio descriptions. However, I don't think users who want to use
descriptions should be required jump *to* the descriptions and then back
again to the captions hundreds of times just to read the descriptions. That
would be like reading a novel while turning on and off the light - a
degraded experience. 

I've proposed this idea based on conversations I've had with a blind user of
audio description.  I don't think that it should always be used, but it has
its place, and not always as an enhanced version.  The likelihod that we'll
see multiple versions of audio descriptions approaches zero.  I'd like the
guideline to read something like:

 

 

I probably don't have the words right, but I don't think that when the best
information we have is either anecdotal or "mesearch" that the WCAG should
be precluding viable techniques.

 It's hard for me to imagine an organization that would create extended
descriptions to help blind people and then require them to go through the
experience of jumping back and forth every couple of sentences just to get
to them. To me that is counter intuitive. 

We need better data from users before declaring that counter intutive is
incorrect.

If they want to create extended descriptions, great, put a "skip over" link
for those who don't want to read them. Our current wording completely allows
that. But I don't think we should make people who do want to use
descriptions suffer by adding all kinds of unnecessary keystrokes just to
get to the information.

I'm not suggesting that this will be the only way, or even the most common
way, just that it shouldn't be prohibited.

AWK

 

 

 

Regards

David MacDonald

.Access empowers people
            .barriers disable them.

www.eramp.com


  _____  


From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Loretta Guarino Reid
Sent: Saturday, February 11, 2006 11:27 AM
To: David MacDonald; Andrew Kirkpatrick; 'Gregg Vanderheiden'; WCAG
Subject: Re: REwrite of 1.1.6

 

David, I would potentially expect our transcript to contain collated
captions and extended audio descriptions, that is, all the information
needed to understand the visuals, not just the amount of information that
can fit in the gaps of the dialog in the audio. And for something like a
physics class, which is presenting complex visual encodings of information,
the audio description part might well be something you'd like to skip over
when scanning for some specific piece of information.

I think the goal here is not to require any specific representation of the
information, but to be sure the information is available. I think any
"text-based" representation which is an accessible equivalent to the content
should satisfy, whether it is a plain text transcript, a marked-up html
version of the information that could contain skip links, or a version where
there is a web-like representation of the text with links to pieces of the
content. 

Loretta


On 2/11/06 7:57 AM, "David MacDonald" <befree@magma.ca> wrote:

>>What's the longest description you've needed to wade through?  That might
be a factor...

It depends.The end of the movie "Apocalypse Now" had long periods of no
dialogue.In that case there would be quite a bit of description between the
dialogue. Audio descriptions are limited to the available space between
dialogue so they are generally short.
 
In your example of the online professor.the descriptions would be generally
very short.especially in a lecture series. and descriptions are limited to
the space between the dialogue on the video. I've never seen a professor who
doesn't talk much in a class. (oops sorry Gregg :-) )
 
I would also suggest that the example is not "equivalent" to that of a
sighted person but rather "enhanced" because sighted people sit through the
descriptions in the video, unless they hit the fast forward button.
 
If we want to create that kind of "enhanced" experience of skipping the
descriptions then I suggest put the burden on the person who wants the
enhanced experience by putting in "skip description" links (like a skip nav)
that the user can use to bounce over the descriptions. (kind of like the
sighted person who would have to hit fast forward)
 
That way the default presentation includes the descriptions (without having
to bounce around) and the enhanced version allows the user to skip over it
with a link. 



David MacDonald



  


  _____  



From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
<mailto:gv@trace.wisc.edu%5d>  
Sent: Friday, February 10, 2006 9:21 PM
To: Andrew Kirkpatrick; w3c-wai-gl@w3.org
Subject: RE: REwrite of 1.1.6

Yes, I see what you are saying.    But I'm not sure what value having the
captions without the description would be?  



Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
The Player for my DSS sound file is at http://tinyurl.com/dho6b
<http://tinyurl.com/cmfd9> <http://tinyurl.com/cmfd9> 


  _____  



From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]
<mailto:w3c-wai-gl-request@w3.org%5d>  On Behalf Of Andrew Kirkpatrick
Sent: Friday, February 10, 2006 5:04 PM
To: Gregg Vanderheiden; w3c-wai-gl@w3.org
Subject: RE: REwrite of 1.1.6
Not everyone will want to read the descriptions intermixed with the
captions.  As a result, while it is fine to say that these different types
of information should be mixed together, it may not create the best
experience.  one method that would allow users to have easy access to the
descriptions within a transcript would be to link to the descriptions (the
descriptions could be in the same file, or even in a separate file) instead
of to include the description text directly. This way, the user could listen
to the description if desired, and skipped more easily.

The reason I mentioned this was that your suggested rewrite to 1.1.6 could
potentially make this technique insufficient to satisfy the requirement, and
I want to make sure that this would be allowed.

Is that more clear?

AWK


  _____  



From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
<mailto:gv@trace.wisc.edu%5d>  
Sent: Friday, February 10, 2006 1:53 PM
To: Andrew Kirkpatrick; w3c-wai-gl@w3.org
Subject: RE: REwrite of 1.1.6

I don't understand this suggestion.
 
Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
The Player for my DSS sound file is at http://tinyurl.com/dho6b
<http://tinyurl.com/cmfd9> <http://tinyurl.com/cmfd9> 


  _____  



From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]
<mailto:w3c-wai-gl-request@w3.org%5d>  On Behalf Of Andrew Kirkpatrick
Sent: Friday, February 10, 2006 9:38 AM
To: w3c-wai-gl@w3.org
Subject: RE: REwrite of 1.1.6
Gregg,

Proposed
 
 
1.1.6 For prerecorded multimedia content, a combined document containing
captions  <http://www.w3.org/WAI/GL/WCAG20/appendixA.html#captionsdef>
<http://www.w3.org/WAI/GL/WCAG20/appendixA.html#captionsdef> intermixed with
the audio description
<http://www.w3.org/WAI/GL/WCAG20/appendixA.html#audiodescdef>
<http://www.w3.org/WAI/GL/WCAG20/appendixA.html#audiodescdef>  transcripts
is available. [How to meet 1.1.6
<http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20060117/Overview.h
tml#text-equiv-text-doc>
<http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20060117/Overview.h
tml#text-equiv-text-doc> ]

This sounds fine to me, but I think that we should make sure that we accept
the case where a transcript includes links to audio descriptions
interspersed, as an alternative to the actual description text.    For
example:

Transcript:
This is the first spoken transcript text. This is more transcript.  (<a
href="#desc1">description 1</a>).  This is more transcript.  Blah blah
blah....

Descriptions:
<a name="desc1" id="desc1">1. </a>This is the first description

This would improve the experience for many users,and while it is untested,
I'd like to make sure that it is acceptable to use.

AWK

 

 
Received on Tuesday, 14 February 2006 20:17:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:42 GMT