W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2001

Re: dissenting opinion (was Re: RE: checkpoint 3.4 again)

From: Charles McCathieNevile <charles@w3.org>
Date: Wed, 1 Aug 2001 18:59:50 -0400 (EDT)
To: "gregory j. rosmaita" <oedipus@hicom.net>
cc: <w3c-wai-gl@w3.org>
Message-ID: <Pine.LNX.4.30.0108011842550.3826-100000@tux.w3.org>
On Wed, 1 Aug 2001, gregory j. rosmaita wrote:
  on 28 july 2001, joe clark outlined two cases:

  In Case 1, authors may use illustrations; if they make that choice,
  the illustrations must meet certain goals.

  In Case 2, authors have no choice in the matter and must-- in every
  case, without exception, and irrespective of appropriateness,
  applicability, illustration skill, budget, or undue hardship--
  provide illustrations.

CMN There may be other interpretations. For example, to remove the hyperbole
we could start to specify cases where it is required to have illustrations,
and we can state that WCAG does not base its requirements on assessments of
an author's skill or budget (ever tried to produce a text equivalent to a few
hours of video footage?) as a general explanation of how we assigned
priorities, as in WCAG 1. I have argued elsewhere that questions of undue
hardship do not belong in checkpoints, they belong in policies on application
of the guidelines, since they differ markedly (for example an Australian
government site that provided complete compliance to Section 508 but no more
would probably fall well short of the Australian legal requirements), and
will continue to do so - this is a technical specification.

  initially, i was going to cast my support behind keeping 3.4 as it was in
  the first drafts of WCAG, with the following "success criterion":

  <SUCCESS checkpoint="3.4">
  Express key concepts and functionality using metadata.

  but that led me to conclude that checkpoint 3.4, if abstracted (and i
  believe it should be, along the lines sketched by kynn and al) is partially
  subsumed, if not actually covered, by WCAG2 checkpoint 1.3

  1.3 Use markup or a data model to provide the logical structure of content.

  in that, a machine could use the markup or the data model per 1.3 in order
  to satisfy 3.4, at least as far as indication/illustration of the logical
  structure of content and the relationships between elements...

CMN the problem with relying on the structuring of the content is that it
doesn't say anything about the meaning of the content, only the rough
relationship of differnt pieces of content. (On the other hand, it was clear
enough to designers that this needed to be available in graphic form that
every browser I have used (and that is tens of different browsers) has a
graphic representation of that structure - indeed, the reason why we talk
about it so often is because many authors produce a graaphic representation
of the structure but do not express one in a way browsers can interpret it,
so we ask them to change the way they express their content).
  which is really an ultra-abstraction of 1.1, so i tried again, and came up

  Utilize markup that enables multi-modal content to be associated with key
  functionalities, structural concepts, and data which is contained in single
  modality formats/forms. [Priority 1]

  which leaves me i don't know where, only quite far from what i hear anne
  expressing and quite far from what is in the new draft -- that every single
  thing needs an author-defined multi-modal equivalent, although i _think_
  that the last attempt could be construed to cover it...

CMN I think that you are close to where Anne is, and where I am. My
disagreement is that I don't think it is enough to simply assert that there
will be an equivalent out there already for some arbitrary resource (if there
was, we wouldn't have to add alt attributes any more, we could just use the
association to fetch them), and that authors need to explicitly make that
association. If there does happen to be content out there,they should by all
means use it to save themselves time.


Received on Wednesday, 1 August 2001 18:59:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:38 UTC