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

Jan,

Sorry I went over it and read the example and yes, this works for me and I can accept the new proposed language and revised example.

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: Friday, March 19, 2010 9:43 AM
> To: WAI-AUWG List
> Subject: 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 20:33:02 UTC