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

Re: Proposal for 7.5 [Was Re: Issue with checkpoint 7.5 (search) and serial...

From: Ian Jacobs <ij@w3.org>
Date: Fri, 25 Aug 2000 13:43:42 -0400
Message-ID: <39A6B04E.F26093DF@w3.org>
To: Eric Hansen <ehansen7@hotmail.com>
CC: w3c-wai-ua@w3.org
Hi Eric,

I would like to avoid defining a text element as something that can
be rendered in three modes. I prefer instead to say that in this
document, the term "text" means a sequence of characters from
a document character set (refer to discussion in HTML 4 specification
[1]
and more discussion in W3C WD on character model for the Web [2]). This
view of text seems to me to be both more intuitive and also more
consistent 
with current usage. I do agree with you that it is fundamental for
information
to be available in three modes, and text characters go a long way to
enabling that, but technology could allow other solutions.

Characters as (abstract) units of natural language information
differ from their their encodings on a computer and the glyphs 
or phonemes used to convey them. 

I wouldn't want to require the UA to search 
on anything other than those text characters in the document object 
that are rendered. (I would not want to require today a search
through phonemes or glyphs or other audio or graphical information.)

Where those characters come from (source, style sheets, scripts, etc.) 
shouldn't matter as long as they are (a) in the document object and 
(b) rendered (since searching through unrendered portions of content
would be confusing). So Harvey's question about style sheets is a 
good one, but as we've done in similar situations, we should "punt" 
and simply say "whatever is in the document object, however that's
constructed". 

Proposal, based on Eric's text:

<NEW BY IAN>
7.5 Allow the user to search through text that has been rendered. 
    The search must encompass all text within the
    viewport, both inside and outside the point of regard. Allow the 
    user to start a forward search from a location in content selected 
    or focused by the user. After a match, allow searching from 
    location of the match. Provide a case-insensitive search option 
    when applicable to the natural language of text. [Priority 2]

 Add to definitions:

 Text
    In this document, the term text refers to a sequence
    of characters in the sense of a "document character set"
    as used in SGML and XML. One example of a document character
    set is the Universal Character Set (refer to ISO10646 and
    Unicode).

 Add to techniques: (same as below).
</NEW BY IAN>

Of course, adding a definition of "text" implies that we need
to review how the term is used in the document. I suspect that
we use it in at least three ways:

1) What one can read (e.g., text messages).
   I doubt we use the term in this way a lot, as in
   "I found the text challenging but well-written."

2) Character glyphs (e.g., text size, conformance levels
   are spelled out in text as in Double-A (not sure)).
   
3) Characters in the sense described above. I think this
   is the sense that applies to searching and to text
   equivalents, text messages, text-to-speech, text input,
   text links, repair text, text browser (not sure here),   
   text field, and text transcript.
   text labels, text titles, 

A quick scan of the document leads me to believe that we
could define text as a character sequence and then fix
those instances of "text" that refer to character glyphs.

 - Ian


[1]  http://www.w3.org/TR/1999/REC-html401-19991224/charset.html
[2]  http://www.w3.org/TR/1999/WD-charmod-19991129/


Eric Hansen wrote:
> 
> Ian,
> 
> One concern I have about checkpoint 7.5 is that renderings of text elements
> (including text equivalents) do not necessarily look like "text" (i.e., text
> characters).
> 
> For example, our tacit if not explicit definition of a text element as
> something that can be rendered and understood in three modes:
> visually-displayed text, synthesized speech, and braille.
> 
> But that is only a MINIMUM REQUIREMENT for a text element. In a fourth or
> higher mode it could be displayed as virtually anything (text, a graphic, a
> movie, an animation, or virtually anything, etc.). Conversely, an element
> (i.e., parcel of pre-rendering content) that is a non-text element (i.e.,
> fails to render properly in any of the three modes), might actually be
> readily displayed visually (or otherwise) as text characters.
> 
> My understanding of the term "text content" is that this is pre-rendering
> content. We really ought to clarify what we mean by "text content" (or
> "non-text content") in this document. We have not discussed, to my
> knowledge, whether the term "text content" is an assertion that it is
> composed of one or more "text elements" (possibly including text
> equivalents). My inclination is to assume that non-text content is composed
> of one or more non-text elements and that text content is composed on one or
> more text elements, keeping in mind that "text element" denotes tri-modal
> (at a minimum) sensible output.
> 
> I am not sure that the phrase "rendered as text characters" is too limiting
> or not when we consider written languages such as Chinese.
> 
> <NEW BY ERIC>
> 7.5 Allow the user to search text content that is rendered as text
> characters. The search must [or should?] encompass all text within the
> viewport, both inside and outside the point of regard. Allow the user to
> start a forward search from a location in content selected or focused by the
> user. After a match, allow searching from location of the match. Provide a
> case-insensitive search option when applicable to the natural language of
> text. [Priority 2]
> 
> Add to Techniques:
> 
> 1) When the point of regard depends on time (e.g., an audio
> viewport), the user must be able to search through
> content that _will be_ available through that viewport. This
> is analogous to content rendered graphically that is
> reachable by scrolling.
> 
> 2) The user must be allowed to search among rendered
> text equivalents that are presented as text characters, as these are part of
> rendered text content.
> </NEW BY ERIC>
> 
> Thanks!
> 
> - Eric
> 
> ======
> Proposal for 7.5 [Was Re: Issue with checkpoint 7.5 (search) and serial
> renderings]
> From: Ian Jacobs (ij@w3.org)
> Date: Thu, Aug 24 2000
> 
> Message-ID: <39A589E8.C66E1D4D@w3.org>
> Date: Thu, 24 Aug 2000 16:47:36 -0400
> From: Ian Jacobs <ij@w3.org>
> To: w3c-wai-ua@w3.org
> Subject: Proposal for 7.5 [Was Re: Issue with checkpoint 7.5 (search) and
> serial   renderings]
> 
> Hello,
> 
> Here's a proposed new checkpoint for 7.5:
> 
> <NEW>
>    7.5 Allow the user to search within all rendered text content
>        accessible through a viewport, including rendered
>        text content outside the point of regard.
>        Allow the user to start a forward search from a location
>        in content selected or focused by the user.
>        After a match, allow searching from location of the
>        match. Provide a case-insensitive search option when
>        applicable to the natural language of text. [Priority 2]
> </NEW>
> 
> Add to Techniques:
> 
> 1) When the point of regard depends on time (e.g., an audio
> viewport), the user must be able to search through
> content that will be available through that viewport. This
> is analogous to content rendered graphically that is
> reachable by scrolling.
> 
> 2) The user must be allowed to search among rendered
> text equivalents, as these are part of rendered text
> content.
> 
> - Ian
> 
> Ian Jacobs wrote:
> >
> >Hello,
> >
> >Checkpoint 7.5 of the 18 August Guidelines [1] begins:
> >
> >     7.5 Allow the user to search for rendered text content,
> >         including rendered text equivalents.
> >
> >The definition of "rendered content" is "that part of content
> >rendered in a given viewport (whether visual, audio, or tactile)."
> >This definition limits severely what type of search would
> >be required through an audio viewport since there is very little
> >content rendered aurally at any given moment.
> >
> >To fix this problem, I'd like to propose a model that seems
> >to work for both two-dimensional and one-dimensional viewports:
> >   a) A viewport does not reveal all rendered content at once.
> >   b) The search requirement is for content that is rendered
> >      through the viewport, even though that content may not
> >      be available in the user's point of regard.
> >
> >I don't have a proposal for new wording yet. Perhaps it is sufficient
> >to add such a clarification in a Note after the checkpoint.
> >
> >Thanks,
> >
> >  - Ian
> >
> >[1] http://www.w3.org/WAI/UA/WD-UAAG10-20000818
> >--
> >Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
> >Tel:                         +1 831 457-2842
> >Cell:                        +1 917 450-8783
> 
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Friday, 25 August 2000 13:44:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:14 GMT