Re: (Action) Issue 394: Proposed revision to checkpoint 2.1

Amaya provides a source view like other editors do.

But it also provides access to the document object. It processes some
information (what it can handle) to render it in a formatted way. For the
entire source it attempts to construct a tree of elements, which lists all
the attributes that each element has in the source. It is possible to use a
menu to get the value of any attribute on any element, in any view.

I will try to do this for ATAG anyway, so when I have the technique I will
share it. (I am trying to use http://www.w3.org/WAI/AU/sources to describe
the ways there are available for sharing techniqes across documents, as well
as describing how ATAG is created...)

cheers

chaals

On Tue, 9 Jan 2001, Jon Gunderson wrote:

  I agree with Ian.  I think that we should have a specific requirement for
  access to the document source.  While a document source view is the most
  common practice of providing access to the source, I think the concept of a
  document source view is to provide access to the source information.  If
  there are other ways to do this than a text editor view we can put them in
  the techniques document.

  Charles would you be willing to submit a technique on how Amaya provides a
  document source view?

  Jon



  At 11:35 PM 1/8/2001 -0500, Ian Jacobs wrote:
  >Charles McCathieNevile wrote:
  > >
  > > This includes a requirement for the unprocessed source. I am arguing that
  > > that is not necessary at a P1 level - if we want it as a requirement we
  > > should make it seperate, and P2.
  >
  >Here's my reasoning why I think it's important to move the
  >source view (or similar) requirement up to the checkpoint level.
  >While this may seem like a new requirement, it is, in my
  >opinion, an old, buried requirement.
  >
  >We require that all content be available through the user
  >interface. We have also said that, because some users may
  >not be able to access content when that content has
  >been processed according to specification
  >(e.g., scripts or style sheets), we require them to have
  >access to the raw, unprocessed content. I think that
  >we mean more than "a source view is probably a good idea
  >as a last ditch solution". I think that we have meant:
  >the user *must* be able to look at the source in case
  >of emergency.
  >
  >I don't think that requiring a source view formally
  >is a heavy burden since all user agents I am aware
  >of do this anyway.
  >
  >  - Ian
  >
  > > On Mon, 8 Jan 2001, Jon Gunderson wrote:
  > >
  > >   Charles and Ian,
  > >   We may be able to say something like this in Ian's proposal:
  > >
  > >   <NEW 2.1>
  > >   2.1 Make all content available through the user interface.
  > >   Provide access to the unprocessed source information in addition to other
  > >   views. [P1]
  > >
  > >   Note: Users must have access to the entire document object through
  > >   the user interface, including recognized equivalents, attributes,
  > >   style sheets, etc. This checkpoint does not require that all content
  > >   be available in every viewport. Access to the source information is an
  > >   important part of a solution for providing access to content, but is
  > >   not a sufficient solution on its own for all content. See guideline
  > >   5 for more information about programmatic access to content.
  > >
  > >   </NEW 2.1>
  > >
  > >   This implies a source view, but allows the developer other options.
  > >
  > >   JOn
  > >
  > >   At 08:05 PM 1/6/2001 -0500, Charles McCathieNevile wrote:
  > >   >This is two seperate requirements.
  > >   >
  > >   >In the past, (e.g. at the Princeton face to face meeting) I have
  > argued that
  > >   >a source view is not actually necessary.  Earlier versions of Amaya
  > did not
  > >   >make the source available, although they did provide a structured
  > view of the
  > >   >entire document object, and I believe that this would have satisfied the
  > >   >actual requirement.
  > >   >
  > >   >So I propose the following text:
  > >   >
  > >   >   <MyNew2.1>
  > >   >
  > >   >2.1 Make all content available through the user interface. [P1]
  > >   >
  > >   >Note: The user must have access to the entire document object (including
  > >   >recognized equivalents, attributes, style sheets, etc.) through the user
  > >   >interface. This allows the user to view content (markup, style sheets,
  > >   >scripts, etc.) after it has been processed. A document source view
  > alone does
  > >   >not satisfy this checkpoint. This checkpoint does not require that all
  > >   >content be available in every viewport. See guideline 5 for more
  > information
  > >   >about programmatic access to content.
  > >   >
  > >   >   </MyNew2.1>
  > >   >
  > >   >Essentially I have cut the requirement to have a source view per se
  > - it is a
  > >   >useful technique and should be included in the techniques. But if
  > there is
  > >   >access already to the document object, a source view is not actually
  > >   >necessary, so shouldn't be required by a checkpoint. Nor is it
  > sufficient to
  > >   >meet the checkpoint (which the checkpoint already says).
  > >   >
  > >   >cheers
  > >   >
  > >   >Charles McCN
  > >   >
  > >   >On Sat, 6 Jan 2001, Ian Jacobs wrote:
  > >   >
  > >   >   Hello,
  > >   >
  > >   >   Per my action item from the 30 November 2000 teleconference [1],
  > >   >   please consider this proposed change to checkpoint 2.1 to resolve
  > >   >   issue 394 [2]. The reviewer wrote:
  > >   >
  > >   >     "I feel the description of 2.1 is too vague on exactly what
  > portions
  > >   >     of the content are satisfied by providing a document source
  > >   >     view. You say it's good enough for some things, but not everything,
  > >   >     and give a few examples but no clear guidance on how to extrapolate
  > >   >     to other cases."
  > >   >
  > >   >   >From the 29 Dec 2000 draft:
  > >   >
  > >   >   <OLD 2.1>
  > >   >   2.1 Make all content available through the user interface. [P1]
  > >   >
  > >   >     Note: Users must have access to the entire document object through
  > >   >     the user interface, including recognized equivalents, attributes,
  > >   >     style sheets, etc. This checkpoint does not require that all
  > content
  > >   >     be available in every viewport. A document source view is an
  > >   >     important part of a solution for providing access to content,
  > but is
  > >   >     not a sufficient solution on its own for all content. See guideline
  > >   >     5 for more information about programmatic access to content.
  > >   >   </OLD 2.1>
  > >   >
  > >   >   Comments and observations:
  > >   >
  > >   >   1) If a document source view alone is not a sufficient solution, then
  > >   >   Notepad cannot conform to UAAG 1.0. (In any case, whether Notepad can
  > >   >   conform at P2 depends on whether plain text meets the requirements of
  > >   >   checkpoint 6.2.). I will assume for the moment that we don't want a
  > >   >   user agent that consists only of a source view to conform.
  > >   >
  > >   >   2) I think that 2.1 needs to state clearly that:
  > >   >
  > >   >     a) Most content will be used as rendered according to
  > specification.
  > >   >        This means that in general, users will not read CSS style sheets
  > >   >        or scripts, but will experience their effects after processing.
  > >   >
  > >   >     b) 2.1 also requires a source view for viewing unprocessed content,
  > >   >        because there are cases where that is the only way for the user
  > >   >        to get information.
  > >   >
  > >   >   3) It is possible to claim conformance for a user agent that doesn't
  > >   >   feature a source view in conjunction with Notepad. [I don't mean to
  > >   >   pick on Notepad <grin> - I mean any source-viewing tool here.] There
  > >   >   is no requirement in UAAG 1.0 that the two pieces of software must be
  > >   >   "integrated" to satisfy the requirements of the document.
  > >   >
  > >   >   So, I propose making the document source view requirement more
  > >   >   explicit in the checkpoint:
  > >   >
  > >   >
  > >   >    - Ian
  > >   >
  > >   >   [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0364
  > >   >   [2] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#394
  > >   >   [3] http://www.w3.org/WAI/UA/WD-UAAG10-20001229/
  > >   >
  > >   >
  > >   >
  > >   >--
  > >   >Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0)
  > 409 134 136
  > >   >W3C Web Accessibility
  > Initiative                      http://www.w3.org/WAI
  > >   >Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
  > >   >until 6 January 2001 at:
  > >   >W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
  > >   >France
  >
  >--
  >Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
  >Tel:                         +1 831 457-2842
  >Cell:                        +1 917 450-8783

  Jon Gunderson, Ph.D., ATP
  Coordinator of Assistive Communication and Information Technology
  Division of Rehabilitation - Education Services
  MC-574
  College of Applied Life Studies
  University of Illinois at Urbana/Champaign
  1207 S. Oak Street, Champaign, IL  61820

  Voice: (217) 244-5870
  Fax: (217) 333-0248

  E-mail: jongund@uiuc.edu

  WWW: http://www.staff.uiuc.edu/~jongund
  WWW: http://www.w3.org/wai/ua



-- 
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
until 6 January 2001 at:
W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France

Received on Tuesday, 9 January 2001 09:57:43 UTC