Re: Proposed rewording of the bundling clause (draft)

I have concerns with the proposal, in relation to the following QA SpecGL [1]
normative requirements:

QA SpecGL Requirement: define the scope - I think that the proposal may 
have scope
implications, and so may need to be addressed in the ATAG "scope" section

QA SpecGL Requirement: Define the terms used in the normative parts of the
specification - I think that ATAG may need some additional definitions and 
consistent usage
as indicated following

QA SpecGL Requirement: Create conformance labels for each part of the 
conformance
model - as indicated following, I have difficulty understanding the 
conformance model
being proposed (perhaps a diagram would help?), and how such a conformance 
model
so constituted would relate to ATAG A, AA, or AAA..  The conformance model 
being
proposed seems to me somewhat complicated and confusing.. I think that an 
unambiguous
objective definition/criteria/rules of bundled vs. nonbundled might help?

QA SpecGL Requirement: If the technology is subdivided, then indicate which 
subdivisions
are mandatory for conformance - I think that there may be some implications 
on this requirement in
proposal..

QA SpecGL Requirement: If the technology is subdivided, then address 
subdivision constraints
- I think that there may be some implications on this requirement in proposal

More specific in-line comments following:

My apologies if I have misunderstood the proposal.

Thanks and best wishes
Tim Boland NIST

[1]:
http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/


At 10:32 AM 3/9/2005 -0500, you wrote:

>Hi,
>
>Here is a draft proposal for reworking the bundling clause as a a "process"
>clause. (item (1) from Monday's call) (this proposal would not effect any
>priorities, etc. - that is a different work item)
>
>Thoughts? Developer perspective? QA perspective?
>
>Cheers,
>Jan
>
>
>---
>
>PROPOSED NEW WORDING:
>
>3.2.2 Authoring Tools as part of an ATAG Conformant Process

What is an "ATAG-conformant process" (needs to be defined)?  What is a "process
workflow" (needs to be defined-workflow is defined in the glossary alone, 
but "process" is not)?



>The requirements of ATAG cover all aspects of the process by which authoring

What is a "process"?

>tools aid authors in the production of Web content. In some cases, the entire
>process will take place within a single comprehensive authoring tool, 
>while in
>other cases, the process will involve two or more authoring tools used 
>together

What is the definition of a "single comprehensive authoring tool" as opposed to
"separate authoring tools"?  Are these two different "classes of products" that
would implement ATAG differently, and have different ATAG conformance 
requirements?
   It seems that in one case, a (process?) is
"contained" within an authoring tool, whereas in the other case,  a process 
"contains"
multiple authoring tools.    To me, if this is correct, the relationship of 
process to
authoring tool seems somewhat convoluted.. I'm having difficulty 
understanding the
ATAG conformance model being suggested..


>(e.g. a markup editor with plug-ins) or separately (e.g. a markup editor, an
>image editor, a validation tool, etc.). In either case, any of the authoring
>tools may claim ATAG conformance provided that a description of the process
>workflow is provided (link: future example), and that the process workflow
>meets and documents the following conditions:


Must the description of the process workflow provided to the author in 
advance of use of said
workflow?



What are you testing here, the process workflow or the authoring tool?  Say 
"(all of) the
following conditions.."?


What is a "process
workflow" (needs to be defined-workflow is defined in the glossary alone, 
but "process" is not)?



>(a) All authoring tools must be identified by name. If more than one 
>authoring
>tool can be used at a particular point in the process (e.g. for image editing
>or accessibility evaluation and repair, etc.), then the description may
>identify two or more interchangeable tools.

"All authoring tools (used in the process workflow) must be.."?   Use 
"must" instead of "may"
(is the second sentence a normative requirement (objectively testable)?

>
>(b) All of the authoring tools in the process workflow must meet the 
>accessible
>authoring interface requirements (for the desired conformance level) 
>(link: the
>checkpoints for guideline 1).
>
>(c) At least one of the authoring tools must meet each of the accessible
>content production requirements (for the desired conformance level).

Does one specified authoring tool need to meet all of the accessible.., or
can different authoring tools meet different requirements (for example, 
authoring tool a
meets requirement c, authoring tool b meets requirement d, etc.)?


>(d) All tools that do not implement the checking (link: 3.2) and repair 
>(link:
>3.3) requirements must occur earlier in the process workflow than at least 
>one
>authoring tool that does implement these requirements.

All (authoring) tools..  Also possible testability problems with "proving a 
negative".
The reference of this requirement to other requirements may further complicate
the conformance model..



>OLD WORDING:
>
>3.2.2 Bundling Authoring Tools
>A conformance claim may cover more than one authoring tool used together 
>(e.g.
>a markup editor and an evaluation and repair tool or a multimedia editor 
>with a
>custom plug-in), each of which may or may not conform to ATAG 2.0 by
>themselves, as long as:
>
>- The authoring tools are distributed together.
>- The workflow used to determine the conformance of the tool bundle is 
>typical
>of how the tools are used together.
>
>
>
>
>--
>Jan Richards, User Interface Design Specialist
>Adaptive Technology Resource Centre (ATRC), University of Toronto
>
>   Email: jan.richards@utoronto.ca
>   Web:   http://jan.atrc.utoronto.ca
>   Phone: 416-946-7060
>   Fax:   416-971-2896
>
>
>Quoting Jan Richards <jan.richards@utoronto.ca>:
>
> >
> > Hi,
> >
> > Here are the main issues coming out of today's meeting:
> >
> > (0) Upcoming F2F timing and details?
> > => Jan to ask Jutta (this is the request)
> >
> > (1) To get a proposed rewording of the bundling clause that meets the
> > requirements set out here (http://lists.w3.org/Archives/Public/w3c-wai-
> > au/2005JanMar/0061.html) as well as the QA requirements (contact Tim B. for
> >
> > more info). The terminology may need to be changed from "bundle" to
> > "process".
> > => BUG entered
> >
> > (2) To get a proposed rewording of success criteria for 3.2 and 3.3 to
> > emphasize that only manual checking and repair is strictly required.
> > =BUG enetered
> >
> > (3) To get a proposal to bring in UAAG and WCAG (for Web based tools) as a
> > stand-in for ISO16071 (i.e. to make the same requirements on 
> developers). It
> >
> > is very important that the requirements not go beyond what is in the ATAG
> > last
> > call doc (i.e. ISO16071) and that the group have the opportunity to pare
> > these
> > requirements further if necessary. - this can be to a large extent based on
> >
> > Matt's work (http://lists.w3.org/Archives/Public/w3c-wai-
> > au/2005JanMar/0059.html)
> >
> > (4) To get a proposal for looks at how the priorities might be reorganized
> > around a single tool vs. whole process standpoint.
> > =>JR to examine more closely
> >
> > (5) BR and GP to undertake to provide the group with assessments of how 
> their
> >
> > primary tools (DreamWeaver, GoLive or Acrobat) do against ATAG. Due Mar.
> > 21.
> > => Jan to ask BF if he would like to join this effort.
> >
> >
> > Please report error or ommissions to the list.
> >
> > Cheers,
> > Jan
> >
> > --
> > Jan Richards, User Interface Design Specialist
> > Adaptive Technology Resource Centre (ATRC), University of Toronto
> >
> >   Email: jan.richards@utoronto.ca
> >   Web:   http://jan.atrc.utoronto.ca
> >   Phone: 416-946-7060
> >   Fax:   416-971-2896
> >
> >
> > Quoting Greg Pisocky <gpisocky@adobe.com>:
> >
> > >
> > > BR Bob Regan
> > > GP Greg Pisocky
> > > JR Jan Richards
> > > KM Karen Mardahl
> > > MM Matt May
> > > TB Tim Boland
> > >
> > >
> > > Meeting was chaired by Jan Richards acting in place of Jutta Treviranus
> > who
> > > was unavailable due to a prior commitment.
> > >
> > > Understanding that was reached with Bob Regan and Macromedia
> > >
> > > BR: Key thing that was being captured. How do we assemble the sets of
> > tools
> > > and what kind of requirements can we impose upon people. The concern is
> > two
> > > fold.
> > >
> > > 1) We can allow for bundling but this places a relationship into a
> > central
> > > role. For example the authoring tool by itself may not meet the
> > requirement
> > > but the bundle would.  So it becomes a buy or build consideration.
> > Putting
> > > our faith in another company's product is not wise. The other concern is
> > do
> > > customers understand this notion of bundling. I am talking about the
> > > supervisors who influence government level purchasing.
> > >
> > > JR Bundling and point 2 minimal success criteria. ATAG low level of
> > manual
> > > checking and repair system. Look for image tags without alt attributes.
> > So
> > > checking without automation could satisfy the requirement?
> > >
> > > GP We look upon it as one step in the process
> > >
> > > BR Authoring tool one step in the process
> > >
> > > MM Look at it from a quality assurance angle Are we writing a good
> > > specification one that discourages complication in implementation. We
> > need
> > > rules on what constitutes a bundle.
> > >
> > > JR We need to revisit the issue of bundling
> > >
> > > JR We need a clarification of the success criteria for 3.1, 3.2, and 3.3
> > > which is checking and repair. We just need to make it clear that manual
> > is
> > > all that is required. 3rd point is addressing Bob's issue concerning
> > > conformance of single tools or bundles.
> > >
> > > JR This is what our definition of bundling is now.
> > >
> > > JR THe resoloution, a bug will be entered to revisit bundling with regard
> > > to
> > > the understanding we have here. Someone will ma,ke a proposal to get rid
> > of
> > > the requirement or rework it along with the process terminology that a
> > > procurement official could use. Take into account bundled vs. non bundled
> > > tools. Action item to ping Barry about conformance,. Bob and Greg will
> > take
> > > alook into builidng conformance reports for their tools Clarification for
> > > 3.2 and 3.3
> > >
> > > Discussion of the revised scenario suggested by Jan.
> > >
> > > Before the concerns came up about bundling, We had concerns about the
> > > accessibiloity of the tools requirement, It was decided these should not
> > be
> > > two different documents. New scenario: what if they were in the same
> > > document. 2 sections and accessible authroing interface section and a
> > > support for accessible output section.
> > > Lots of concern about ISO and referring to a non-cost, non W3C
> > requirement.
> > >
> > >
> > > GP When it comes to things like 508 there is no choice
> > >
> > > MM My concern was standards that have a muliplicity of requirements. I
> > know
> > > for WCAG they have a set of high level principles that can be mapped to
> > 508
> > > and other similar legislation around the world.
> > >
> > > JR Matt has done a comparison of UAG 1 in comparison to 508. Matt your
> > > thoughts?
> > >
> > > MM UUAG in my view is a superset of 508. One checkpoint that I did not
> > see
> > > a
> > > similar thing. 1194.21 (k)
> > >
> > > JR Then a comparison with ISO 16071
> > >
> > > MM Some of UAG is geared specifically to web content. We could create a
> > > profile for UAAG that does that specifically.
> > >
> > > TB WCAG techniques task force talking about a baseline.
> > >
> > > JR The interdependence of all these requirements that were all developed
> > in
> > > the same way would be interesting.
> > >
> > > BR If UAAG is going to be tied in here, I get concerned. ISO gets nowhere
> > > without industry participation. If we are going to be tied to that, then
> > we
> > > have to scrub this really thourghouly.
> > >
> > > MM THe UAAG 1.0 spec has the largetst number of testimonials from
> > industry
> > > as far as support. Microsoft, IBM Mozilla
> > >
> > > JR If we screen out anything in UAAG that is not a part of ISO 16071
> > would
> > > that be acceptable
> > >
> > > MM UAAG is just about to get reopened
> > >
> > > JR Let's take the existing UAAG and use it as our stand in for ISO,
> > >
> > > JR If we have something local like UAAG and strip out anything we don't
> > > like
> > > it becomes our lens on ISO.,
> > >
> > > BR THe only thing I'll say is we should do a study of where we are all
> > at.
> > >
> > > JR What do people think of having a separate section within the same
> > > document?
> > >
> > > TB What would each contain
> > >
> > > JR Guideline becomes its own section.
> > >
> > > MM I would be in favor of taking guideline 1 and formulating that from
> > the
> > > stuff we are in favor of UAAG and call that the authoring tool
> > > accessibility
> > > guideline,
> > >
> > > JR Filter requirements from UAAG and filter what would be covered by ISO.
> > >
> > >
> > >
> >
> >

Received on Wednesday, 9 March 2005 21:29:29 UTC