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

Proposed rewording of the bundling clause (draft)

From: Jan Richards <jan.richards@utoronto.ca>
Date: Wed, 9 Mar 2005 10:32:08 -0500
Message-ID: <1110382328.422f16f888c7a@webmail.utoronto.ca>
To: w3c-wai-au@w3.org

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

The requirements of ATAG cover all aspects of the process by which authoring 
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 
(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:

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

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


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 16:51:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:53:05 GMT