RE: Issues from Microsoft ISSUE #1 Move 1.2.3 to level 3?

I don't think I explained the issue here very well.

The concern is this:  There is no way that I know of for a Web author to add real-time captions himself.  He must use a professional service, which can be quite expensive.  This is the only one of our guidelines that requires hiring an outside professional.  Amateurs can caption, and even audio describe, pre-recorded multi-media.  They may not do it as well as professionals, but it is possible to do it.  The live captioning requirement essentially puts level-2 compliance for live multi-media out of the reach of all but the largest of media companies.   Is this really what we want to do?

Even if we say that requiring a service is ok (and I'm not at all sure that it is), the technology for including that service is not described well in the techniques.  How do you integrate the captions into your site?  Can you generate the SMIL that's in the techniques in real time?  How?  Gregg mentioned putting the text coming from the professional service in another window.  How does that work?  What technologies are used?  If you had the text before the live broadcast, is it possible to synchronize it with the broadcast?  If so, how?  Is it possible to convert captions from television content to text that's usable on a web site?  How?

Is 1.2.3 too burdensome to require at level 2?  Should we move it to level 3?
If not, we at least need to beef up the techniques to answer the questions above.


________________________________
From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
Sent: Thursday, March 09, 2006 9:32 PM
To: Cynthia Shelly; w3c-wai-gl@w3.org
Subject: RE: Issues from Microsoft


Hi Cynthia

Good comments.  Thanks.

Couple of notes / questions.

RE Issue #1 - Question to everyone - can you post any information you have on tools that address Cynthia's question/comment - so that we can be sure to log them and use them per comment below.

RE Issue #2 - Cynthia, can you say specifically what information is more specific and objective.  Would be great to capture that.  Better yet - can you provide a specific suggested edit for including that in the definition of audio description?   That would greatly increase our ability to consider it for inclusion.

RE Issue #3
 - 4.1.5 is not about ensuring they stay exposed really.  It is about making sure that AT know when some of the thousands of elements it can 'see' have changed or been deleted without having to keep checking each of them every second.
-   4.1.1 is a completely different topic from the rest of 4.1.x items.  So much so that we considered for awhile separating it.
- I just noticed that the wordings in your post below are not the currently proposed wordings  (see previous posting and the survey)  the new proposed wordings are pasted below for convenience.

Do these work better for you?

Gregg




{NOTE  I put Web Units in where they would now go replacing the old term}
4.1.1 Web Units<http://trace.wisc.edu/wcag_wiki/index.php?title=Web_Pages_%28including_Web_Applications%29&action=edit> can be parsed unambiguously and the relationships in the resulting data structure are also unambiguous.
4.1.2 For each user interface component in the content, the name<http://trace.wisc.edu/wcag_wiki/index.php?title=Name&action=edit>, role<http://trace.wisc.edu/wcag_wiki/index.php?title=Role&action=edit>, and all perceivable properties<http://trace.wisc.edu/wcag_wiki/index.php?title=Perceivable_properties&action=edit> can be programmatically determined<http://trace.wisc.edu/wcag_wiki/index.php?title=Programmatically_determined&action=edit>.
4.1.4 Content and properties of user interface components can be programmatically set<http://trace.wisc.edu/wcag_wiki/index.php?title=Programmatically_set&action=edit> directly to any values to which they can be set through the user interface.
Note: Some examples of standardized properties that typically can be changed by the user interface include its value, whether it is currently selected, and whether it currently has the focus.
4.1.5 Any changes to user interface components in the content can be programmatically determined<http://trace.wisc.edu/wcag_wiki/index.php?title=Programmatically_determined&action=edit> without having to compare current and past values to detect change.

Becky also suggested
4.1.4 Values for content and attributes of user interface components which can be set through the user interface can be set programmatically.



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 Cynthia Shelly
Sent: Thursday, March 09, 2006 6:56 PM
To: w3c-wai-gl@w3.org
Subject: Issues from Microsoft

I did an internal review of the most recent WCAG 2.0 draft with several people from around Microsoft.  Here is the list of issues we're concerned about.  These are roughly in priority order.
MS Issue #1
Tools for real-time captioning of streaming audio and video.  The techniques for xxx show markup in SMIL, which doesn't seem like it could be done in real-time on live broadcasts.  Are there tools for captioning streaming media in real-time?  Are those tools inexpensive and simple enough that small shops could use them to caption live media?  If not, we don't think this can be a requirement at level 2, perhaps not at all.  If there are such tools, we need techniques about them.
MS Issue #2
We're concerned that the audio description requirement is not very testable.  The definition of audio description includes the word "important", which is pretty subjective.  There are links in the understanding document to more detailed and objective standards of what needs to be described.   We think this type of information needs to be in the normative document.
MS Issue #3
Inconsistent language between 4.1.1, 4.1.2 and 4.1.5.
4.1.1 Delivery units<appendixA.html> can be parsed unambiguously<appendixA.html> and the relationships in the resulting data structure are also unambiguous.
4.1.2 The role, state, and value can be programmatically determined<appendixA.html> for every user interface component in the Web content that accepts input from the user or changes dynamically in response to user input or external events
4.1.5 Changes to content, structure, selection, focus, attributes, values, state, and relationships of the user interface elements in the Web content can be programmatically determined<appendixA.html>.
4.1.1 and 4.1.2 are about exposing the properties initially, and 4.1.5 is about ensuring that they stay exposed (and accurate) if they change.  Can we make the language in these three SCs more consistent, so it's easier to understand the relationship between them?  The language in 4.1.5 seems to be the most complete, so I'd vote for making the other two more like it.
MS Issue # 4
The success criteria in 4.1 don't seem to be about future technologies.  They're about ensuring that the user interface is operable through assistive technology.  Perhaps they should be under Principal 2?  If they don't fit under any of the existing guidelines there, maybe we need a guideline there about properties of UI elements being available to AT.