Re: Input needed before next AUWG call

That works thanks for your patience as I worked through the issue

Sent from my iPhone

On Mar 25, 2010, at 10:43 AM, "Jan Richards"  
<jan.richards@utoronto.ca> wrote:

> Hi Greg,
>
> Thanks for giving this a thorough review....
>
> What about dropping changing the language away from "alternative" as
> follows:
>
> B.2.1.1 Decision Support: If the authoring tool provides the option of
> producing an *excluded web content technology* for publishing, then  
> both
> of the following are true (Level A):
> (a) Warning: authors are warned that the authoring tool does not  
> provide
> accessibility support for that web content technology.
> (b) List Included Technologies: from the warning, authors can access a
> list of technologies for which the authoring tool does provide
> accessibility support (i.e., the *included web content technologies*).
>
>
> Then there is no presumption that the tool can second-guess the
> author...they are simply providing information to explain a warning.
>
> What do you think?
>
> Cheers,
> Jan
>
>
>
>
>
> On 25/03/2010 7:32 AM, Greg Pisocky wrote:
>> My replies within
>>
>> Greg Pisocky, Adobe Systems
>> gpisocky@adobe.com
>> 703.883.2810p | 703.883.2850f | 703.678.3541m
>>> -----Original Message-----
>>> From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org]  
>>> On
>>> Behalf Of Jan Richards
>>> Sent: Wednesday, March 24, 2010 1:47 PM
>>> To: WAI-AUWG List
>>> Subject: Input needed before next AUWG call
>>>
>>> Hi all,
>>>
>>> Here are the questions again that need answers this week (with more
>>> specific links for (2) and (3). ALSO an extra paragraph has been  
>>> added
>>> on Jutta's suggestion to the intent for B.2.2.7 so please take a  
>>> look:
>>>
>>> (1) B.2.1.1 Decision Support Proposal
>>> http://lists.w3.org/Archives/Public/w3c-wai-au/2010JanMar/0126.html
>>> ___Accept the proposal
>>> X Recommend changes (see comments field)
>>> ___The proposal needs more discussion (see comments field)
>>> ___Disagree with the proposal
>>> ___Neutral - will accept the consensus of the group
>>> Comments:[GGP:]  I like this proposal my concern is around the  
>>> timing of said warning, "when the option to save is presented"  
>>> that represents one possible scenario. Is the emphasis to be on  
>>> some sort of mechanism that informs the user what the tool is  
>>> capable of doing with various formats or how it informs them? In  
>>> the example provided, let's suppose after toiling away on some  
>>> piece of content our intrepid user chooses to launch the built in  
>>> caption editor. At that time they are informed that the captions  
>>> they edit with the tool's built in editor will be lost should the  
>>> user choose to later save the result as format A, B, but preserved  
>>> for any of the other available options. If so, I am okay.
>>
>> What is nagging at me is the implication that format X is a better  
>> choice than format Y because of the tool's ability to provide an  
>> additional accessibility attribute for format X. Maybe format X is  
>> a low definition format that only works with a limited number of  
>> players. Format Y might be more appropriate given the intended  
>> workflow creating content targeted for high definition players. To  
>> require the software to suggest using format X as the alternative  
>> to Y because this particular tool can add captions to X and not Y  
>> undermines the developer's intent which is to produce content  
>> appropriate for play on high definition players.
>>
>> So now I think I have worked this through in my mind (sorry to drag  
>> everyone through my slow train of thought, but I am sensitive to  
>> workflows). What bothers me is this notion that the tool needs to  
>> suggest an alternative.  And I quote "if a similar *included  
>> technology* is available, then it is suggested as an alternative."
>>
>> A tool can't possibly know about the author's ultimate intent to  
>> suggest that the so called "more accessible choice" is the correct  
>> alternative. That isn't always the case given that tools that  
>> manipulate source formats are not always suitable for manipulating  
>> all of the attributes.
>>
>> Can we eliminate the language that implies that the others are  
>> better and replace it with language that addresses is the issue of  
>> what may be gained or lost given all of the alternatives available  
>> to developers using the tool?
>>
>>>
>>> 2-B.2.2.6 Status Report: Reworded Intent and Examples
>>> http://lists.w3.org/Archives/Public/w3c-wai-au/2010JanMar/0135.html
>>> _X_[GGP:]  Accept the proposal
>>> ___Recommend changes (see comments field)
>>> ___The proposal needs more discussion (see comments field)
>>> ___Disagree with the proposal
>>> ___Neutral - will accept the consensus of the group
>>> Comments:
>>>
>>> 3-B.2.2.7 Metadata Production: Reworded Intent and Examples
>>> http://lists.w3.org/Archives/Public/w3c-wai-au/2010JanMar/0136.html
>>> _X  Accept the proposal
>>> ___Recommend changes (see comments field)
>>> ___The proposal needs more discussion (see comments field)
>>> ___Disagree with the proposal
>>> ___Neutral - will accept the consensus of the group
>>> Comments:
>>>
>>>
>>>
>>>
>>> --
>>> (Mr) Jan Richards, M.Sc.
>>> jan.richards@utoronto.ca | 416-946-7060
>>>
>>> Adaptive Technology Resource Centre (ATRC)
>>> Faculty of Information | University of Toronto
>>
>>
>
> -- 
> (Mr) Jan Richards, M.Sc.
> jan.richards@utoronto.ca | 416-946-7060
>
> Adaptive Technology Resource Centre (ATRC)
> Faculty of Information | University of Toronto

Received on Thursday, 25 March 2010 20:32:42 UTC