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

Re: Today's minutes

From: Jan Richards <jan.richards@utoronto.ca>
Date: Mon, 7 Mar 2005 20:40:20 -0500
Message-ID: <1110246020.422d028453109@webmail.utoronto.ca>
To: w3c-wai-au@w3.org

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 Tuesday, 8 March 2005 01:40:57 GMT

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