[ossrp-control] Re: What Is A Screen Reader?

Hi Mary,
That's true--my example involved redesign of the dialog.  It was to make
a point that accessibility may involve a different design, but that is
not necessarily feasible in the interface of the application, itself.
 
Off the top of my head, if subgroups of fields were structured inside
group boxes (or other containers) within an object model, then it should
be possible to create a screen reader hot key that jumps from one group
box to another, or lists the titles of all group boxes, from which one
could choose one to enter.
 
If the dialog does not include such structural information, relying only
on spatial cues for subgrouping, then I suppose the screen reader should
attempt to analyze the layout if requested, and provide the
functionality just described based on huristic rather than accurate
analysis.  
 
If the user wants to identify specific pixel coordinates of different
controls, that should be possible, too.  I think the screen reader,
however, should be equipped to do some of these calculations for the
user, based on tested patterns of layout observed in popular
applications.
 
Jamal
-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Mary Otten
Sent: Thursday, May 05, 2005 8:15 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Jamal,
I agree 100% with your comment regarding the necessity of separating out
functional from esthetic information which may be obtained by a sighted
person from the visual appearance of objects on the screen, and also
that separating form from function is a good idea, at least when
possible. But to take your example, where you note that a multi-tab
dialogue might be the most efficient means for a screen reader user to
deal with optional subgroups, such an approach would require a change to
the application or form, i.e. it would require co-operation on the part
of the form or application's developer. In such instances where such
co-operation is not forthcoming, I wonder what might be gained if a
blind user could ascertain the semantics portrayed by the visual
presentation. And if they could get something useful, what good would it
do them? One would need an efficient method to skip the items one did
not need to access, in order to move to the next required field. How
might that b e accomplished using a keyboard, if the application makes
no such keystroke available?
Mary Otten
Senior Tester
Tecaccess 
--Original Message Text---
From: Jamal Mazrui
Date: Thu, 5 May 2005 16:22:32 -0400

Message Good point. That is a different, more complex example, but
certainly such scenarios are also common. I think the scenario that I
described often occurs with order forms on the web, typically asking for
contact and credit card information in a familiar pattern. 

In evaluating this issue, at least two questions seem relevant: (1) what
does spatial information convey about the function of the dialog? and
(2) to the extent that functional rather than asthetic information is
being conveyed, what is the best way to achieve an equivalent result
nonvisually? 

If there are optional subgroups of fields, then tabbing through all of
them is, indeed, inefficient. To achieve productive data entry, let us
separate function from presentation. The blind person probably does not
need to know, for example, how many pixels separate controls in order to
judge which ones are part of the same subgroup and which are part of
another. The fact that the border of group boxes uses a 3D rather than
simple style is inconsequential. The objective is to enable the blind
person to identify and navigate to the different subgroups. For the
screen reader user, a multi-page tab dialog might be the most efficient
solution rather than a single page dialog where subgroups are indicated
by spatial proximity. 

Jamal 



-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of David Lant
Sent: Thursday, May 05, 2005 3:46 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Jamal, 

Broadly I understand your point. However, there are situations where
simply going sequentially through the items in a dialog is not the
process required for daily use of a facility. If, for example, your job
is processing pay claims, and allocating charge codes to the relevant
portions of hourly rates, overtime rates, expenses and so on, it would,
and does, become extremely tedious having to tab through all the fields
that may have to be displayed to inform you what needs to be done. 

It may be much quicker, if the pieces of information are all grouped in
one control group, and the fields you need to fill in are in an adjacent
one. There may very likely be other data on the screen at the same time,
which don't relate directly to the job in hand. Sighted people visually
skip over that stuff, such as the box at the top giving the
identification summary of the person and their pay reference etc. They
see that the boxes they need to work with are all in two rectangles on
the right of the screen, one above the other, and so visually
concentrate on those. They will glance through the information in the
first box, to identify the hours being claimed, and will then click in
the second box to place an insertion pointer so they can type in the
relevant charge codes. 

For a blind person to do this, they would need to have a quick way to
rapidly get to the information in the upper right box, and read it.
Then, to equally rapidly, move to the lower right box, in order to start
filling in the information. It is true that the fact that these boxes
are on the right of the screen may be of no significance whatsoever as
far as both the blind and sighted person are concerned. But the
significance is that they separate out the information that has to be
dealt with, so that the details on the left of the screen can be largely
ignored unless something special turns up. 

This, I think, is the kind of scenario that Will is talking about. Not
just the fact that address fields are grouped together, but that you may
need to perform specific, and isolated tasks on that group, separate
from the rest of the data on the screen. 

All the best, 


David 
-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Jamal Mazrui
Sent: 05 May 2005 08:21
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Will, 
I agree that spatial relationships can and do convey a lot of
information to sighted users. I was not arguing that visual placement is
generally irrelevant, but maintain that it can be so for blind users
where it does not affect the interface we experience and the
functionality of the task at hand. 

For example, if the purpose of a dialog is to retrieve typical contact
information (name, address, phone, etc.) through a well-understood set
of fields, then it may be irrelevant to the blind user where the
controls are placed, as long as they speak properly. The layout of the
dialog is not an end in itself, but a means to an end, that of gathering
the data for a contact record. The database does not care, and does not
track, where the controls were placed in the input dialog that gathered
the data for the record that was saved. 

To elaborate, I might press tab successively hearing fields like "First
name", "last name," etc., filling each one in, including reviewing the
data in each edit box. If the tab order is logical and the field name
and current value speak as expected, than it does not matter to me how
the fields are aligned, what fonts are used for field names, what point
size the entered characters are, etc. 

Sighted users, on the other hand, are affected by such characteristics.
Even if the tab order is the same, logical sequence, they will be
confused if the "City" field is placed above the "First Name" field. If
a few fields are cramped together in one corner of the dialog in an
unpleasing manner aesthetically, their productivity will be reduced
because of the disorientation they experience, etc. 

Jamal 


-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson
Sent: Wednesday, May 04, 2005 4:25 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Jamal, 

"As a blind user, placement
can actually be irrelevant, having no effect on functionality." 

Based on psychology, semiotics and communications theory, I would have
to disagree with that statement. A control's relationship to other
controls and it's absolute positioning can be sources of semantic
information about that control's functionality. For example. buttons
grouped together may have similar functionality, buttons placed next to
a list box may perform an action on that list box or it's selected
index. On the web, a row of links placed in vertical alignment at the
top of a page are often used as a quick navigational group of links. 

So. spatial relationships and absolute positioning can add a lot of
meaning regarding functionality beyond that conveyed by a simple text
label. Users can, and often do, work out the full semantic nature of a
control, but this is often through trying out the control and seeing
what it does, which is inefficient at best, and possibly disasterous at
worst, imagine deleting something that you didn't actually mean to
delete. 

Will 
----- Original Message ----- 
From: Jamal Mazrui 
To: ossrp-control@xxxxxxxxxxxxx 
Sent: Monday, May 02, 2005 2:41 PM
Subject: [ossrp-control] Re: What Is A Screen Reader?


Just an observation to share. 

In trying to program dialog boxes under Windows, I have experienced the
situation where something I developed worked well with a screen reader,
yet I subsequently discovered that it was almost unusable for a sighted
person. A screen reader can tab from one control to another, and as long
as each control is properly labeled and otherwise voicing as one would
expect at the time it has focus, then the controls in the dialog serve
their purpose. It may be the case, however, that the controls are placed
in visually peculiar, unbalanced, or overlapping places on the screen,
thus making the dialog difficult for a sighted user. 

As a blind developer, I need to know the location of controls so that I
can meet the needs of both sighted and blind users. As a blind user,
placement can actually be irrelevant, having no effect on functionality.


Regards, 
Jamal 

-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Lyn Eagers
Sent: Saturday, April 30, 2005 11:19 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Will and Others, 

Will, I found your description of what a screen reader is quite
interesting. 

I train people to use screen readers and, from my experience, some blind
folk are interested in where things are on the screen (spacial
perception) and others are not. In particular, those who have had sight
and were extremely visual people find it important to know where things
are. Some, and I say some, so therefore not all, long term blind people
don't seem to be interested in the spacial factor. 

I am a long term blind person and have always tried to grasp a mental
picture of what is on the screen and where - probably because I teach
both kinds of blind people and sometimes assist sighted folk. 

Anyhow, I thought I'd share my experiences with you. 

Cheers, 
Lyn 

----- Original Message ----- From: Will Pearson 
To: ossrp-control@xxxxxxxxxxxxx ; uvip@xxxxxxxxxxxxxxx 
Sent: Sunday, May 01, 2005 11:58 AM
Subject: [ossrp-control] What Is A Screen Reader?



Hi, 

I thought I'd share my, rather academic, view of what a screen reader
is. It offers a little glimmer into what screen readers could
potentially do, and some of the pitfalls that the current crop of screen
readers have fallen into. All this is from the viewpoint of human
computer interaction, psychology and communications theory. 

OK. So, what is a screen reader? Well, it's actually a lot more than
people often assume it is. It's not just something that grabs the text
from the screen and reads it to you, well, at least it shouldn't be, it
is in fact the interface by which user and machine communicate semantic
meaning, relating to thoughts, concepts, actions and states. 

So, how did I arrive at this view? As some of you may know, I've been
researching into semantics and their role in software interfaces for a
while now. During this time, it's become apparent that software
interfaces are just intended to communicate semantic meaning, but as
we're not capable of extr sensory perception and telepathy with the
computer, we need some way to indicate our thoughts, concepts, actions,
etc. to the computer, and vice versa. The way this is visually done is
by placing elements on the screen, such as icons, buttons, etc. and
having their shape, colour, position on screen and relationships to one
another act as encoding channels by which the semantic meaning is
conveyed. Users then just point to an object, conveying the semantics of
which element they would like to interact with, and either click it or
select an action to perform on it from a menu. All this is just a form
of physical encoding of the semantic meaning between user and machine
and vice versa. 

So, as a screen reader is a replacement for the visual interface, it's
role is simply to act as an interface between user and machine and
convey the semantic meaning generated by the machine. However, there's a
nasty twist, and that is that a screen reader has to get the semantic
meaning that it is to communicate to the user from somewhere. As the
screen reader has no access to the internals of the machine, it's only
available source of semantics that the machine wishes to convey is the
visual interface, which uses encoding techniques such as colour, shape,
position and spatial relationship to convey it's semantics. So, a screen
reader should really be about extracting the semantics from the visual
display and encoding them in a non-visual form suitable for a blind
user, and this is where current screen readers fall down. To maintain
accurate and efficient communication with the user, all the semantics
that are conveyed visually need to be conveyed to the user. This incl
udes things like spatial positioning and spatial relationships between
interface elements, things that are currently lost to the user when they
are using one of the current screen readers. If this were to happen,
then the number of errors, and according back-tracks and reissuing of
commands that go along with errors, would decrease, and screen reader
users would be more efficient beasts. 

I haven't gone into design specifics, as they're for another day, and
these can dramatically affect efficiency as well, but that's my thoughts
of what a screen reader should be doing. In focusing on the semantics,
then it's likely that through the use of semantic translation access to
all those difficult accessibility problems could be increased. 

Will

Other related posts: