RE: Issues from Microsoft

Thanks for the quick reply.

#1 Thanks.  Looking forward to the responses.  Oh, and xxx should have been 1.2.3.  Meant to look that up and fill it in, but forgot in my effort to get this out quickly.  oops.

#2 It seems like we should have as much guidance on how to write good audio description as we do on how to write good alt-text, since audio description is arguably harder to do.  Has this already be discussed and decided against?

These are the links to the specific stuff from the understanding doc
http://www.joeclark.org/access/description/ad-principles.html
http://www.skillsforaccess.org.uk/howto.php?id=104

A colleague of mine suggested the guidelines at the FCC as well.  The how-to text from that is:

a describer viewing a program, and writing a script to describe key visual elements. The describer times the placement and length of the description to fit within natural pauses in the dialogue. The narration is recorded and mixed with the original program audio to create a full audio track with video description.

#3 Hmmm... I think we're in violent agreement.  4.1.5 is about updating the properties and throwing events that the properties are updated, right?  I think they're the same properties that are set in 4.1.2, and that the language should be consistent.  The new ones are better, though I'd still like to see it be more obvious that we're talking about the same properties.  I'll draft something today.

I'll run your explanation of the differences in 4.1.1 by the person who made that comment, and get back to the list as soon as he answers.

#4 What does everyone think about moving the SC in 4.1 to a new guideline under principal 2?  They really do seem to be about AT interoperability rather than future technologies.  This is a bigger change, so I understand if it needs to wait, but I'd like to hear what people think.


________________________________
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.