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

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.

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.

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.

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.

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