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 renderings]

From: Harvey Bingham <hbingham@acm.org>
Date: Thu, 24 Aug 2000 22:44:29 -0400
Message-Id: <4.3.2.7.2.20000824222021.00b9bd00@pop.tiac.net>
To: w3c-wai-ua@w3.org
At 2000-08-24 16:47-0400, Ian Jacobs <ij@w3.org> wrote:
>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>

HB: That seems to include prefix/suffix info added by a stylesheet for
rendering. So I could search for nested list item 3.5, even if that value
is only generated for a prefix through two layers of auto-enumerations by
the stylesheet counting list items and rendering them.


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

HB: Need we suggest: such search may be done unintelligibly fast,
to find the next, at which point of regard, the user-specific audio
rendering is used. Even at extremely fast forward rate, some clue
to positioning is useful. Just scaling frequency by say 50x speedup
would exceed the frequency range for hearing, unless samples are
taken and presented that are non-frequency-shifted, so what is heard
remains within the hearing range.

>2) The user must be allowed to search among rendered
>text equivalents, as these are part of rendered text
>content.

HB: Clarify: what recognizes a search match in other than the actual
text? The user? or some assistive technology working on pattern recognition
in an audio or video stream? Or is there an aspect of rendered text equivalent
that is a textual source on which to perform the search?

HB: I believe that sound pattern recognition against some audio source is
much harder than text against text. So if the text version of the audio text
alternative is available, search it, even if the input is voice: do
speech recognition to find search words. But probably display the
presumed words from the recognizer to use as search subjects into the
text, and allow correction, say of homonyms, or mis-recognized words.



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


Regards/Harvey Bingham
Received on Friday, 25 August 2000 00:13:14 GMT

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