Fwd: Re: Fwd: ATAG2: B.2.1.1 proposal

Hi all,

This is the proposal I sent to Greg. He hasn't had a a chance to provide 
feedback yet, but I wanted to get the thoughts of others:

The main points I am trying to get across in B.2.1.1 are:

ATAG is trying to be flexible:
- formats are neither intrinsically good nor bad
- authoring tools are allowed to produce any format they like
- authoring tools are allowed to conform to ATAG2 for only some or even
one of the formats they can produce (these are the Included technologies).

But there need to be limits:
- the formats automatically chosen by authoring tools already must be
"Included technologies" - ALREADY required by the definition of
"Included technologies" within the Conformance section.
- authors should be advised when an option will cause them to create
content in an Excluded format.
- if there is an obvious better choice this should be suggested (now to
define "obvious...")

So here is an adjusted proposal (also modified example). What do you think?

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) Suggest Alternative: if a similar *included technology* is
available, then it is suggested as an alternative.

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 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., images may be made accessible via HTML).

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

The wording "provides the option of producing an *excluded web content
technology* for publishing" is intended to (a) 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.

In (b), the wording "if a similar *included technology* is available,
then it is suggested as an alternative" is intended to refer to any
"included" technology options that are typically used to encode similar
types of web content (e.g., two video formats).

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 and 
suggest the video format that is supported by that closed-caption editor.


Cheers,
Jan










On 12/03/2010 4:50 PM, Jan Richards wrote:
> Hi Greg,
>
> Does the proposal address your concerns?
>
> Cheers,
> Jan
>
>
>
> -------- Original Message --------
> Subject: ATAG2: B.2.1.1 proposal
> Date: Thu, 11 Mar 2010 11:22:44 -0500
> From: Jan Richards <jan.richards@utoronto.ca>
> To: Greg Pisocky <gpisocky@adobe.com>
> CC: w3c-wai-au@w3.org <w3c-wai-au@w3.org>
>
> Hi Greg,
>
> One possibility might be to more tightly focus the wording of B.2.1.1 on
> "excluded technologies" (which we have already defined), since that is
> really the problem area:
>
> POSSIBLE RE-WORDING:
>
> 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:
> (a) Warning: authors are warned that the authoring tool is not able to
> provide accessibility support.
> (b) Suggest Alternative: Alternative *included technologies* are
> suggested (if any are available).
> Note: If a conformance claim is made, the claim cites the included and
> excluded technologies.
>
> INTENT: The intent of this success criterion is to help authors make
> decisions about which web content technologies to use that are informed
> by accessibility considerations. If accessibility is part of
> decision-making at this early point, it will reduce the likelihood that
> retrofits for accessibility will be required later on.
>
> The success criterion does not seek to judge the accessibility of
> 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., images may be
> made accessible via HTML). 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).
>
> The wording "provides the option of producing an *excluded web content
> technology* for publishing" is intended to (a) 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.
>
> In (b), the wording "Alternative *included technologies* are suggested
> (if any are available)" is intended to refer to any "included"
> technology options that are typically used to encode similar types of
> web content.
>
>
>
> ========================================
> CURRENT WORDING:
> B.2.1.1 Decision Support: If the authoring tool provides authors with a
> choice between web content technology options, then the following
> information is provided for each option: (Level A)
> (a) General Information: general information about the accessibility of
> the technology to end users; and
> (b) For Included Technologies: information on the accessible content
> support features provided for that technology by the authoring tool; and
> (c) For Excluded Technologies: both a warning that choosing that
> technology may result in web content accessibility problems and
> information on alternative included technologies (if available). Note:
> If a conformance claim is made, the claim cites the included and
> excluded technologies.
>
>
>
> On 09/03/2010 12:08 PM, Jan Richards wrote:
>> Hi Greg,
>>
>> For reference here is the CURRENT WORDING:
>> B.2.1.1 Decision Support: If the authoring tool provides authors with a
>> choice between web content technology options, then the following
>> information is provided for each option: (Level A)
>> (a) General Information: general information about the accessibility of
>> the technology to end users; and
>> (b) For Included Technologies: information on the accessible content
>> support features provided for that technology by the authoring tool; and
>> (c) For Excluded Technologies: both a warning that choosing that
>> technology may result in web content accessibility problems and
>> information on alternative included technologies (if available). Note:
>> If a conformance claim is made, the claim cites the included and
>> excluded technologies.
>>
>> On 08/03/2010 5:25 PM, Greg Pisocky wrote:
>>> If I am going to object, the least I can do is provide an explanation.
>>>
>>> In the implementation notes to B.2.1.1 there is significant reference to
>>> the “system” prompting as cursors move and checkboxes get checked and
>>> the like. This is not an insignificant engineering effort to provide a
>>> “system” with the necessary level of intelligence . The examples given
>>> certainly go beyond the notion that merely mentioning the various
>>> accessibility merits in the online help of various technologies an
>>> application may support is sufficient for meeting this criteria.
>>
>> JR: I'm not sure what text you are referring to. "Cursor" and "checkbox"
>> don't appear. "System" only appears a part of "Content management
>> System" in the "Choosing between calendar widgets" example.
>>
>>
>>> My other concern is the notion that every tool has to be an uber tool.
>>> Why is there is an expectation that an authoring tool which performs
>>> some functions on content be expected to perform all conceivable
>>> functions on that content? There’s nothing intrinsically wrong with a
>>> video editing tool that may support the image manipulation component of
>>> video (splicing, editing, etc.), but requires users to add or edit
>>> captioning in another tool – in fact it may be a more appropriate
>>> workflow depending upon the nature of the video being employed.
>>
>> JR: Right, but ATAG2 defines "authoring tool" as the end to end series
>> of tools one might use to produce video for the web. The video-editor
>> tool doesn't need to be able add captions as long as there is a
>> caption-editor in the process. HOWEVER, if the caption-editor is only
>> able to add captions to some of the formats that the video-editor is
>> able to produce, it would be better from the perspective of ATAG for the
>> video-editor to guide the author towards those that do.
>>
>>> Formats are typically not intrinsically accessible or inaccessible until
>>> they are provided context. An editing application often manipulates
>>> content that has no accessibility associated with it until it placed in
>>> other content, so for instance, how one chooses to implement video
>>> captioning could more be a function of what mechanism will be used to
>>> play back the video and not the video format and any captioning that
>>> would be required has to be authored elsewhere. Depending on the output
>>> mechanism, the producer would select an appropriate captioning file and
>>> method for editing the caption. It’s a rare tool that would have such
>>> insight into an author’s eventual intentions for any given piece of
>>> content.
>>
>> Right. If for example, the caption-editor can wrap captions around any
>> video format then there is no need of guidance by the video-editor.
>>
>>> More simplistically, it’s analogous to editing an image file .giff,
>>> .png, etc. Accessibility, in the form of alt text gets added if the
>>> image gets placed in HTML for instance, if going into a word processing
>>> application, alt text is provided through a different mechanism, the
>>> editing tool can’t really know.
>>>
>>> Saving a document as text and not HTML? Sorry, text is more accessible
>>> than HTML, I have to warn you. Well not if I plan to drop it in a word
>>> processor or desktop publishing application stripped of other encoding
>>> so I can reformat it to my own liking, so please stop annoying me with
>>> these silly admonitions.
>>
>> JR: This isn't about text vs. HTML. The included and exclsuded
>> technology condition is just an attempt by ATAG2 to be flexible to the
>> fact that real-world tools may produce many formats and may focus on
>> ATAG2 conformance of some of them before others.
>>
>>> In the two examples given, the scenarios imply that the application has
>>> sufficient logic to distinguish one flavor of format from another and
>>> how the author intends to use them.
>>>
>>> In my opinion this is too a high level of sophistication required in
>>> order to support an A level requirement. Few people are going to design
>>> such an authoring tool and fewer still will use one. If this is indeed
>>> reading too much into the requirement, then let’s find more realistic
>>> examples of the simple kinds of implementations people are envisioning,
>>> because these are rather elaborate.
>>
>> JR: Greg's objection has made me take a closer look at our wording.
>> Especially the UI overhead we require when the tool is doing everything
>> right and the technology is included. I wonder if we can be more clear
>> that the minimum requirements for (a) general and (b) included are for
>> documentation only?
>>
>> Cheers,
>> Jan
>>
>>
>>> Examples of Success Criterion B.2.1.1:
>>>
>>> * *Choosing video formats:* A video authoring tool can be used to
>>> edit three video formats: (1) an old video format that does not
>>> include text tracks, (2) a newer video format that has one text
>>> track and widespread support in players and (3) a very new
>>> multi-text track video format that currently has limited support
>>> in players. The authoring tool includes a built-in closed
>>> captioning utility for the newer format whereas captions can only
>>> be added to the older video format using a third party tool that
>>> adds them as open captioning. When authors save a new video file,
>>> the "Save As" dialog provides the three video formats are provided
>>> as choices. When focus moves to a format in the dialog an
>>> information area in the dialog briefly notes accessibility
>>> information (and other information, such as compression
>>> effectiveness) with links to more information in the
>>> documentation. For (1), it is noted that the built-in closed
>>> captioning utility will not be available and that captions are
>>> required for WCAG conformance. The (linked) further information
>>> notes that only open captioning is possible in this format and
>>> only using a third party tool. For (3), it is noted that player
>>> support is limited, which may limit access by some end users. The
>>> (linked) further information includes links to an "Accessibility
>>> Information" page maintained by the company that developed the new
>>> video format.
>>> * *Choosing between calendar widgets:* A content management system
>>> provides a date field for authors to add to their content. When
>>> the field is added, the system prompts authors to choose a
>>> calendar widget for the field that will appear to end users. All
>>> of the choices that conform to WCAG 2.0
>>> <http://www.w3.org/WAI/AU/2010/ED-IMPLEMENTING-ATAG20-20100303/#intro-rel-wcag>
>>>
>>>
>>> are labeled as accessible with links to more accessibility
>>> information provided by the makers of the widgets. Choices that do
>>> not conform include warnings to authors.
>>>
>>> *Greg Pisocky*
>>> Accessibility Specialist
>>> Adobe Systems Incorporated
>>> 8201 Greensboro Drive, Suite 1000
>>> McLean, VA 22102 USA
>>> 703.883.2810p, 703.883.2850f
>>>
>>> 703.678.3542c
>>>
>>>
>>> gpisocky@adobe.com <mailto:gpisocky@adobe.com>
>>>
>>> www.adobe.com/accessibility <http://www.adobe.com/accessibility>
>>>
>>> Concall Info
>>>
>>> * *69900* (from any Adobe office worldwide)
>>> * *408-536-9900 *(from any non-Adobe location in the 408 area code)
>>> * *1-877-220-5439 *(North America Toll Free)
>>> * *1-800-642-196* (Australia Toll Free)
>>> * *44-20-8606-1105* or ext. 81105 (London)
>>>
>>
>

-- 
(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 Friday, 19 March 2010 13:43:06 UTC