[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 be 
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 includes 
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: