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

ATAG2: B.2.1.1 proposal

From: Jan Richards <jan.richards@utoronto.ca>
Date: Thu, 11 Mar 2010 11:22:44 -0500
Message-ID: <4B9918D4.8030300@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
Received on Thursday, 11 March 2010 16:23:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 11 March 2010 16:23:21 GMT