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

ATAG2: Amended proposal for B.2.1.1 Decision Support

From: Jan Richards <jan.richards@utoronto.ca>
Date: Thu, 25 Mar 2010 16:58:00 -0400
Message-ID: <4BABCE58.80201@utoronto.ca>
To: Greg Pisocky <gpisocky@adobe.com>
CC: WAI-AUWG List <w3c-wai-au@w3.org>
Hi Greg,

No problem. I really do want to work out as many potential problems as 
possible before LC.

Now, how do other people feel about the rewording proposed (with 
knock-on changes to the Intent and Examples)?

AMENDED FULL PROPOSAL:
======================

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*).

Note: If a conformance claim is made, the claim cites the included and
excluded technologies.

Intent of Success Criterion B.2.1.1:
------------------------------------
The intent of this success criterion is to inform authors as early as
possible about the degree to which the authoring tool will be able to
provide accessible web content production support for the web content
technologies that it is capable of producing. If accessibility is part
of early decision-making, it will reduce the likelihood that retrofits
for accessibility will be required later on.

The success criterion makes absolutely no assumption about the 
accessibility or inaccessibility of any particular web content 
technologies, because any technology can be made accessible. For 
example, a technology with no intrinsic accessibility features can be 
made accessible in conjunction with another technology (e.g., bitmap 
images may be made more accessible via HTML text labels).

Instead, the success criterion depends on whether the authoring tool in
question actually supports the production of accessible content in the
technology (i.e., "included" technologies) or does not (i.e., "excluded"
technologies) through features like checking and repair.

The wording "provides the option of producing an *excluded web content
technology* for publishing" is intended to (1) rule out situations in
which authors make technology choices without guidance by the authoring
tool (e.g., by hand coding, by specifying a DTD) and (2) rule out
situations in which incomplete content is created in interim formats
that are not intended for publishing.

The intent of (b) is simply to inform the user, who has now just 
received a warning that the authoring tool lacks accessibility support 
for a given technology, that one or more other web content technologies 
produced by the authoring tool are supported by such accessibility 
support features. It is left to authors, to decide whether any of the 
"included technologies" might be appropriate for the task or whether 
they will continue on with their original selection.

Examples of Success Criterion B.2.1.1:
--------------------------------------
Choosing video formats:
A video authoring tool allows authors to save into several video file
formats. However, the authoring tool includes a built-in closed-caption
editor that only works with one of the file formats. While there is
nothing intrinsically "inaccessible" about any of the video formats,
when the option to save is presented, the formats that are not supported 
by the authoring tool's own closed-caption editor include warnings that 
caption support is not provided. In the warning's explanation, the video 
format that is supported by the closed-caption editor is identified.




Cheers,
Jan




On 25/03/2010 4:31 PM, Greg Pisocky wrote:
> 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
>

-- 
(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:58:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 25 March 2010 20:58:36 GMT