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

Re: Why Greg Pisocky objects to B.2.1.1 as a Level A criteria

From: Jan Richards <jan.richards@utoronto.ca>
Date: Tue, 09 Mar 2010 12:08:34 -0500
Message-ID: <4B968092.5010606@utoronto.ca>
To: Greg Pisocky <gpisocky@adobe.com>
CC: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
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 Tuesday, 9 March 2010 17:09:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 9 March 2010 17:09:19 GMT