Re: Keyboard Navigation For Document Exploration In SVG 1.2

I think everything has it's place.  Different output modalities, as with who
or what is responsible for extracting the semantics, will be appropriate for
different users in different use contexts.  For example, tactile graphics
lack definition compared to auditory graphics, which in turn lack definition
compared to visual graphics.  So, if you wanted increased definition
auditory graphics hold benefits over tactile graphics, and they can also
indicate more than just two states *smile*.  However, in some use cases the
features confined by the anatomical, physiological and perceptual
limitations of tactation, may convey enough information and accurately
enough for the user to interpret the semantic meaning, in other cases they
may not.

I'm not ruling anything out, just adding to the arsenal of interface designs
that we have, so that we may be able to best choose the one most appropriate
for the user, the task and the context.

----- Original Message ----- 
From: "david poehlman" <>
To: "Will Pearson" <>
Cc: "Protocolls and formats" <>; <>
Sent: Monday, November 29, 2004 2:23 PM
Subject: Re: Keyboard Navigation For Document Exploration In SVG 1.2

> Will and all,
> Thanks for the explanation which fits with what I'd have expected in this
> situation and which, I can imagine would provide a rich environment under
> certain circulstances.  This presupposes a number of htings however and I
> feel may be treading on some dangerous ground with regard to backward
> compatibility and current capability and learning curve that semantically
> rich mark up can largely avoid.
> I think at the least, you'd have to specify the square as either vertical
> horrizontal lines so as you explore the square, it would say vertical line
> followed by its ifnormation such as length, position and color and
> thickness.  then, when you come to the horrizontal line, it would be
> expressed as a horrizontal line in the same fashion.
> Your example then as I understand it would look something like:
> verticle Line: 10, 10 20, 10 - color: green
> horrizontal line: 10, 20, 20, 20 - color: green
> verticle line: 10, 10, 10, 20 - color: green
> horrizontal line: 20, 10, 20, 20 - color: green
> I may not be getting this exactly right, but having a verticle line at the
> left, a horrizontal line at the top, a vertical line at the right and a
> horrizontal line at the bottom seems a fitting approach although still a
> high on the perceptual curve.
> The other problems I see is when we add stimuli we get into the realm of
> loosing a lot of our audience even though the mappings are already
> through the vOICe it is still quite difficult to use these relationships
> augment our environment in a meaningfull way and we also leave out those
> require a tactile approach.
> What lisa and others are proposing in a rich semantic approach can
> accomplish much of the same and meet the requirements of those who need a
> tactile approach and also at least to some degree maintain backward
> compatibility.
> Johnnie Apple Seed
> ----- Original Message ----- 
> From: "Will Pearson" <>
> To: "david poehlman" <>
> Cc: "Protocolls and formats" <>; <>
> Sent: Monday, November 29, 2004 5:46 AM
> Subject: Re: Keyboard Navigation For Document Exploration In SVG 1.2
> Hi Dave;
> For a green square you could have something like:
> Line: 10, 10 20, 10 - color: green
> line: 10, 20, 20, 20 - color: green
> line: 10, 10, 10, 20 - color: green
> line: 20, 10, 20, 20 - color: green
> Admittedly, it's a rather large set of attributes to process in order to
> work out it's a green square.  You would have to use something like the V
> Buffer to display them all, as according to George Miller's 1956 theory on
> short term memory, we can only remember between five and nine chunks of
> information in our short term memory.  So, whilst it's accessible, as
> can determine it's a gree square, it's not very usable, requiring an
> increased cognitive workload to determine the spatial relationships
> the lines in order to determine the shape as being a square.
> However, if we look beyond speech as an output modality, it becomes a lot
> easier.  As you're probably aware from my ASVS project, and to some
> from the work of Evreinov and Meijer, you can display shapes using sound
> pixels.  The basic concept is that you replace visual pixels of light with
> auditory pixels of sound.  This just changes the communications channel
> to convey the information, but will still allow the same perceptual
> techniques, such as the Gestalt laws of perception, to be applied to the
> auditory rendering as would be applied to the visual.  So, you could
> determine that something was a line by having pixels grouped together with
> the same horizontal alignment for vertical lines, and the same vertical
> alignment for horizontal lines.  Then by shothe lines in parallel, it
> becomes a lot easier and quicker to examine the spatial relationships
> between the lines and determine it's a square.  Most attributes, such as
> font size, bold, italic, etc. are just differences in spatial
> and having this parallelism makes for easier determination of spatial
> relationships.
> As for color, well we usually have a hearing range from 20Hz to 20KHz.
> We're capable of detecting changes in tonal frequency at around the 10Hz
> 15Hz mark, and so that would give us around 1300 to 2000 different states
> that could be signified through changes in frequency.  Build in mechanisms
> for zooming to overcome the differences in auditory definition compared to
> visual definition, and something to simulate saccade movements, and you've
> got an auditory equivalent to visual output, well, what you actually have
> the current thinking on my ASVS project *smile*, but it looks to work in
> theory *gsmile*.
> So, I think that if we look beyond speech, having the user extract the
> semantic meaning becomes a lot more usable.  I noticed from Al's draft
> agenda for this week's PF, that tactile graphics are on there.  Maybe this
> agenda item could be rescoped to include sonic graphics, although being
> output it's probably more in the domain of ua.
> Will
> ----- Original Message ----- 
> From: "david poehlman" <>
> To: "Will Pearson" <>
> Cc: "Protocolls and formats" <>
> Sent: Sunday, November 28, 2004 4:53 PM
> Subject: Re: Keyboard Navigation For Document Exploration In SVG 1.2
> > Will,  For most people, the leap is too hard to make.  Can you send us
> > example of what we'd have to extract meaning out of in text form?  The
> > entire discussion to this point follows:
> >
> > Johnnie Apple Seed
> >

Received on Monday, 29 November 2004 20:06:49 UTC