Comments to the 19980814 version of the UA guidelines

Please find below some comments and suggestions for additions, or enhancements 
to the 19980814 version of the UA guidelines.
 
Best regards
 
Constantine Stephanidis
 
 
==============================================================================

Undoing a script execution
--------------------------
An issue not addressed in section 6.6 "Elements with associated (DHTML) events" 
is that of returning to the state of the document, or interaction, that was 
valid prior to the  activation of a DHTML event (or collection of events 
specified in a script).

Being able to do that, allows the user: (a) to recover from the accidental 
execution of a script, and (b) to "preview" modifications that will be made to 
the document by a script.

This functionality can be implemented as a generic undo command, i.e. a command 
available either as part of the global menu system / interaction environment, or 
a command made explicitly available immediately after the activation of events 
by the user, the availability of which would be determined by the next 
interaction steps of the user.

An alternative, but far more technically challenging approach would be for the 
UA to: (a) report all the modifications that a script will make to the current 
state of a document being viewed by the user (presupposes that the UA will be 
able to "comprehend", or "foresee" the modifications that specific commands will 
incur on a document, which is not always possible), and (b) to allow the user to 
accept, or reject these modifications before interaction with the document may 
commence again.
 
IN SUMMARY, we propose that an item be added in Section 6.6 "Elements with 
Associated (DHTML) events" which states that the UA should allow the user to 
(easily and quickly) revert to the state of the document, or the state of 
interaction, that was valid prior to an event execution.
 
 
 
Text only View of a Document
----------------------------

In section 4.7 "Alternative Views of a Document" Item 2, a "serialized" 
text-only view of the document is recommended. We propose that, in addition to 
this specific view, in which some of the document’s interactive elements are 
present, a new text-only view is added, with the following characteristics: (a) 
all non-textual elements are "serialized" in an identical way to that of the 
existing view, (b) all interactive elements are rendered as simple text 
(including links). The utility of the proposed view is mainly intended to allow 
blind users to go through large documents without being disoriented by 
additional information concerning the interactivity of document elements (for 
example, a link has to be differentiated from the rest of the text, either 
through sound, or specific text to denote the beginning and /or end of a link). 
This would be especially useful in long documents, containing a large amount of 
links. An alternative to adding a new text-only view would be to allow the user 
to turn off the presentation of interactive elements in the existing view.
 


Sequential Navigation Mechanism
-------------------------------

We are still troubled by the fact that the guidelines recommend that a UA 
employs two distinct sequential navigation mechanisms. One described in section 
6.1 "Sequential Navigation within a View" and one described in section 7.2 "Menu 
Commands", Item 2.

We believe that the UA should provide only one navigation mechanism, which will 
combine and enhance the functionality of the two mechanisms currently described 
in the guidelines.

The enhancement to the navigation model we are proposing involves two main 
tasks: (a) selection of the type of element by which the user will navigate the 
document, and (b) navigation within the document itself, including, but not 
necessarily limited to, the ability to move to the next, or  previous elements 
of the selected type in the document, as well as the ability to move to the very 
first and very last such elements in the document.

Selection of the type of element by which the user will navigate the document, 
is a task of simply selecting an option among mutually exclusive alternatives. 
The normative way of doing that, would be through a menu (e.g. a menu entitled 
"Navigate" and items such as "By Header", "By Paragraph", "By Link", etc.). An 
Item "All Elements" should be included in that menu, to allow all 
navigation-able elements to be visited sequentially. Very common, or frequently 
used options should of course have keyboard shortcuts, making them accessible in 
a single interaction step, from any point in the interface.

Navigation within the document itself, is also a task that involves selecting an 
option among mutually exclusive alternatives, and thus, it can also be done 
through items in the "Navigate" menu.
Naturally, the menu entries are not expected to be used as extensively as the 
respective keyboard shortcuts (e.g. arrow-up for previous element), but they can 
make the mechanism much more salient to both able bodied and disabled users.

The elements the user should be allowed to navigate by, are those elements in 
the rendered page that the user can distinguish from the rest, and identify as 
having particular characteristics. A user who comprehends document formatting 
and has basic understanding of the Web, will be able to identify the following 
elements as having a particular functionality :  links (including image map 
areas), elements with "longdesc", forms and form elements, tables, lists and 
list items, elements with DHTML events, paragraphs, sentences, headers. Thus the 
user should be allowed to navigate at least these elements.

With respect to providing document overviews and enabling "random" access to 
document elements, we believe that a far more usable and elegant solution, would 
be the use of separate views, along with view sychronization, as specified in 
section 4.7 "Alternative Views of the Document", Item 2. 

IN SUMMARY, we propose :
a) Section 7.2 Item 2 should be removed from the guidelines.
b) The navigation mechanism, described in section 6.1 "Sequential 
   navigation within a view" should be harmonized and unified among 
   element types.
c) The user should at least be allowed to navigate the following 
   elements: links (including image map areas), elements with 
   "longdesc", forms and form elements, tables, lists and list 
   items, elements with DHTML events, paragraphs, sentences, 
   headers.
d) Overviews and "random" access to document elements are achieved 
   through separate, synchronized views, rather than through menus.

The reasons we believe the proposed sequential navigation mechanism is better 
than the one provided for in the guidelines, have been elaborated in emails sent 
to the list in the recent past. These emails are included as an attachment.
 
 
 
Page History information
---------------------------------
In Section 5.2, "Document summary information", some additional pieces of 
information should be included to  those already proposed to be presented to the 
user. These are:
 
1) Whether the page has been visited before, or not.
2) If it has been visited before:
   a) The date of the last visit
   b) The number of times the page was visited.
   c) Whether this page exists in the user’s bookmarks.
3) The date it was last modified
 
This additional information can significantly assist the user in speeding up web 
browsing. If, for example, users know that they have visited the page before, 
and that the page has not been modified since the last time they visited it, 
then they may choose not to review  the page contents again.
 
The utility of the specific proposal is not limited to blind users, who will 
most probably benefit the most from the availability of the additional 
information. It may also assist other categories of sighted disabled users, who 
have difficulty in attaining this type of information by themselves (e.g. users 
with memory and cognition problems), as well as inexperienced users, 
irrespective of disability. Furthermore, it is possible to visually codify 
portions of the additional information, so that users can, by simply looking at 
a document, acquire that information (for example using page "aging" coloring 
schemes, marking the page with an appropriate icon if it is already bookmarked, 
etc.)
 
IN SUMMARY, we propose that an Item is added to section 5.2 which states that 
"When a page is loaded and on user demand, make available the page history 
information". 
 
 
 
Local DHTML event list
 ---------------------
 
While presenting an element with associated DHTML events to the user, the UA 
should either "attach" to the presentation a list containing these events, or, 
preferably, demarcate the element as having events associated with it . In the 
second case, users should be able to request that a list containing the events 
associated with the demarcated element be presented to them. This way, users 
would be able to review events in their proper context, and not disassociated 
from specific elements, as is the case with the "global" list of events.
 
IN SUMMARY, we propose that an item to that effect is added to section 6.6 
"Elements with Associated (DHTML) Event Behavior".



Issue 19. Physically Impaired Navigation.
-----------------------------------------

With respect to Issue 19, a proposal has been put forward that the size of page 
anchors is changed to accommodate users with poor motor skills. We assume that 
the proposal covers not only anchors, but all interactive elements in a rendered 
document.

We believe that, instead of changing the size of elements, the UA should provide 
navigation support for users with poor motor skills, through the use of  
alternative techniques for changing the interaction focus in a view.

Changing the size of elements creates the following problems. 
(a) The layout of the rendered document will change; thus,  the 
    possibility exists, that elements are aligned differently 
    than the author intended them to.
(b) The size of the document may change; thus, scrollbars may be 
    needed, when they were not needed before.
(c) If the value by which the element’s size changes is a user set 
    parameter, then the page authors will need to take into account 
    during the design stage, big variations in an element’s size.

We believe that the use of the following two techniques, which we have 
implemented in the unified AVANTI browser [1], developed by ICS-FORTH, Greece, 
present a better solution to the problems faced by users with poor motor skills.

The two techniques are called "touch-near" and "gravity".

"Touch-near"
The basis of this technique lies with the fact that (all) interactive elements, 
in addition to the physical space they occupy on the screen, occupy a larger 
virtual space with the actual element in its center. The virtual space which can 
be shaped either as a rectangle, or as an ellipse, is termed the element’s 
"active area". In practice, all interaction of the user within this virtual 
space is treated by the UA as interaction with the element itself. So, for 
example, if   the user clicks  anywhere inside the element’s active area, then 
the UA interprets this as a  click on the element, if the cursor moves inside 
the element’s active area, then the UA interprets it as a hover over the element, 
etc. Conflicts in the active areas of elements can be resolved by appropriate 
proximity algorithms. This feature is intended to facilitate users with poor 
motor control in their mouse-based interaction with elements, and allows for 
imprecise actions to be interpreted correctly by the UA, thus removing the 
burden of performing fine-detail mouse operations from the user.

"Gravity"
This technique is based on the physical concept of gravity. In particular, the 
idea is that interactive elements are capable of, automatically, or upon 
request, "attracting" the mouse cursor to the center of the physical area they 
occupy on the screen. The automatic activation policy is based on (configurable) 
user idle time and the element which attracts the cursor is the one that is 
closest to the cursor. Users can also activate "gravity" explicitly (e.g. by 
pressing both mouse buttons at the same time). The two activation policies may 
also coexist. Irrespective of the activation policy, the user must always be 
able to stop the attraction process at any phase, so that inadvertent activation 
of the feature, or attraction towards an element other than the one that was the 
user’s target can be avoided. This, for example, could be achieved through the 
user’s moving the mouse during the process of attraction. This feature is 
intended to assist the interaction of users who have problems moving the mouse 
with precision, users with problems of involuntary movement in the arms / hands, 
as well as users who find it strenuous, or painful to make extensive use of 
their hands to control mouse movement.

An important benefit to UA developers, that results from the employment of the 
above two techniques is that the size of elements does not need to be changed. 
This removes not only technical implementation problems, but also the problem of 
having parts of the document obscured by enlarged elements. 


IN SUMMARY, we propose that in section 3.3 "Selection, Focus, and Events", the 
following line  is added to the 5th paragraph, which talks about the focus in a 
view.
"The UA should provide alternative mechanisms for changing the interaction focus 
in a view, mechanisms that will support users with poor motor skills. 



Alternative presentation of Images
----------------------------------

Section 4.3 "Alternative representation of Images and Image Maps", Item 1 "Allow 
the user to turn off the display of images in favor of descriptive text."

1) If the author does not supply alternative content, then the UA should not 
render the word "Image", as specified in Section 4.3 Item 1,  but the word 
"Image" followed by some text that will distinguish one image from another, 
example "Image 1". The same should be done for all elements for which 
descriptive text may be used, e.g. video, audio, applets, Objects.

2) Section 4.3, item 1, specifies that if the author fails to supply alternative 
content, then the UA should render the word "Image" instead. Since images and, 
especially, image maps are used as interactive elements, we believe that 
demarcating all images with no alternative text as "Image"s (or, all areas in an 
image map with no alternative text as "Area") is not sufficient, as users will 
not be able to distinguish between them. As a remedy to this problem, we propose 
that elements are enumerated and that their number be included in the string 
used to represent them. Thus, for example, users would be able to remember that 
"Image 3" in a specific document is a link to an interesting document and would 
be able to select it using the available navigation acceleration facilities, 
without the need to review the context in which the element appears. The same 
approach should be used for all element types for which alternative text may be 
provided, e.g. video, audio, applets, objects.


3) In the case of visual rendering, if the user turns images off (descriptive 
text is displayed instead of the image bitmaps), then some provisions could be 
taken so that the layout of the page, is similar to the layout with images on. 
For example, if the image has Width and Height attributes defined, then, 
provided these dimensions are adequate for rendering the descriptive text in its 
entirety,  they should not be ignored (of course, the same is not true in the 
case that the indicated dimensions define a rectangle that is too small to fit 
the alternative text in). This way users would be able to view a page with more, 
or less preserved layout, which is sometimes very important, as spatial 
arrangement, proximity and relative sequencing are very often used to denote 
correlations, or relationships between elements. 

REFERENCES

1.  C. Stephanidis, A. Paramythis, M. Sfyrakis, A. Stergiou, N. Maou, A. 
    Leventis, G. Paparoulis, C. Karagiannidis, "Adaptable and Adaptive User 
    Interfaces for Disabled Users in AVANTI Project", 5th International 
    Conference on Intelligence in Services and Networks (IS&N '98), 
    "Technology for Ubiquitous Telecommunications Services", Antwerp, 
    Belgium, 25-28 May 1998. 

    http://www.ics.forth.gr/proj/at-hci/html/publications.html#ISN98

 

Subject: Re: Sequential Navigation within a View
Date: Fri, 14 Aug 1998 14:50:55 +0300
From: Napoleon Maou <maou@csi.forth.gr>
Organization: ICS-FORTH
To: Jon Gunderson <jongund@staff.uiuc.edu>
CC: maou <maou@csi.forth.gr>, w3c-wai-ua@w3.org

Thank you for your comments.

In their current form, the guidelines refer to two mechanisms, which are
used together to provide sequential navigation functionality within a view.
The first is described in section 6.1, "Sequential Navigation Within A View",
and the second in section 7.2, "Menu Commands", Item 1.

Our proposal combines the functionality of these two mechanisms, into one
generic sequential navigation mechanism. We believe that the strongest points
of the proposed approach lie with the simplicity and uniformity with which a
user will be able to navigate a document. Please note that this is independent

of the actual types of elements that the user will be allowed to navigate by.
This way the user will have to perform fewer interaction steps to navigate
among elements of the same type, having, furthermore, only one set of
navigation
commands to memorize (compare this, for example, to having to remember
different
keyboard commands to move to the next heading, previous form element, etc.)

Let us now move on to the issue of which elements should the user be allowed
to navigate by. The term "any elements" used in the initial proposal, was not
meant to imply that navigation by *every* HTML elements should be possible.
Rather, it was meant to refer to those elements in the rendered page that the
user can distinguish from the rest, and identify as having particular
characteristics.
In our view, the guidelines already assume that the user has a rather
good understanding of what a formatted text document is, as well as of the
functional and non-functional attributes of elements that may be encountered
within an HTML document.

The above is evident from the fact that the mechanism in section 6.1, allows
the user to sequentially visit links, form elements, images and image maps. A
direct implication of this is that the user knows what links, form elements,
frames, images and image maps are. In the opposite case, a truly novice and
inexperienced user will think that the browser arbitrarily scrolls to
different
parts of the document. Furthermore, by proposing the use of menus for header
navigation, the guidelines assume that the user knows what a header is. This
means that it is already assumed that the user comprehends at least part of
the
document's formatting.

Based on the above, the elements we believe the user should be at least
allowed
to navigate by are the following: links (including image map areas), elements
with
"longdesc", forms and form elements, tables,  lists and list items, elements
with
DHTML events, paragraphs, sentences, headers. All these are elements that the
user
can distinguish from the rest of the elements in a page, and identify them as
having
a particular property / functionality.

A second point you raised in your email concerns the employment of menus to
provide
an overview of the document. Although it is a very good idea to allow the user
to
get different overviews of the document, menus might not be the best approach
to
presenting them to the user. Menus excel when used to provide the user with an

overview of the functionality of an application and are rarely used when they
are
very long, not to mention when they entirely different (with the exception of
the
first few items) for every document the user visits. Imagine for example a
menu
containing the headers of a long research publication with descriptive section

headings. The menu would be hardly usable. Or, what about a menu containing
the
links in a "Links" page that is becoming a norm in almost all types of sites.
Presenting a limited list of the elements in the menu, as specified in Section

7.2, is a partial solution to the above problem, but introduces, in turn, a
new
problem, that of not allowing true "random" access to elements. If, for
example,
10 headers are included in the list, and there are 15 in the document, then
the
user will not be able to directly access the last 5 ones, which compromises
the
very usefulness of the current approach.

We believe that a far more usable and elegant solution for providing document
overviews and enabling "random" access to document elements, would be the use
of separate views, along with view synchronization, as specified in section
4.7 "Alternative Views of the Document", Item 1.

In summary, we propose that the navigation mechanism for sequential access to
different types of document elements should be harmonized and, even better,
unified across elements types. We further propose that overviews and "random"
access to document elements are achieved through separate, synchronized views
as already proposed by the guidelines, rather than through menus.

To better clarify the proposed approach I am including below the communication

with Bryan Campbell, in which specific examples of operation are included.
Comments and
suggestions are always more than welcome.

Best regards,

Napoleon

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hello Bryan,
Again I would like to apologize for taking such a long time to reply to your
mail.

Thanks for commenting on our proposal.

The number of keyboard commands the user needs to go through in order
to use the navigation mechanism we propose depends on the specific
choices developers will make in implementing the mechanism. Instead
of referring to key presses, therefore, please allow me to briefly
describe the idea in terms of "interaction steps". Naturally, the
ideal implementation would manage to allocate single (combined) key
presses to each interaction steps.

The enhancement to the navigation model we are proposing involves
two main tasks: (a) selection of the type of element (or elements, I
will explain this further below) by which the user will navigate the
document, and (b) navigation within the document itself, including,
but not necessarily limited to, the ability to move to the next
previous elements of the selected type in the document, as well as
the ability to move to the very first and very last such elements in
the document.

In terms of functionality one can distinguish between two variations
for task one. If navigation is limited to a single type of element at
any time (of course this does not include "normal" document navigation
whereby all elements are visited sequentially), then this is a task of
simply selecting an option among mutually exclusive alternatives. The
normative way of doing that would be through a menu (e.g. a menu
entitled "Navigate" and items such as "By Header", "By Paragraph",
"By Link", etc.) Very common, or frequently used options should of
course have keyboard shortcuts, making them accessible in a single
interaction step, from any point in the interface.

An alternative to the above would be for the user to be allowed to
select multiple types of elements to be visited during navigation.

One way to implement this would be through the use of a dialog, which
would present the user with a list of navigational elements and allow
him/her to selecting multiple types of elements to navigate by. In
this case, the implementation of the navigational mechanism requires
the following interaction "steps"
1) Open the dialog
2) "Next" and "Previous" commands, to scroll through the list of
   items
3) "Select" / "Unselect" command to add an element type to the
   current set of navigable elements
3) An "OK" and a "Cancel" command to close the dialog

The "OK" and "Cancel" commands above would be the standard "OK" and
"Cancel" keyboard commands used for all dialogs. The "Next" and
"Previous" commands could be the same keyboard commands used to
navigate between elements in the view.

Although this approach would significantly enhance the flexibility of
the navigation model, it would also be very demanding on the user,
imposing considerable load on short and long term memory, both in terms
of interaction, but also in terms of anticipated system behaviour (I could
elaborate on this if necessary). Furthermore, we don't believe that the
added flexibility outweighs the resulting increased complexity. Therefore,
we would prefer that only the former approach be included in the
guidelines.

In terms of interaction, the functionality of the second task (navigation
in the document itself) can be implemented using four "commands": Go-To-Next-
Element, Go-To-Previous-Element, Go-To-First-Element, and Go-To-Last-Element.
Of the four, only the first two (next and previous element) are of vital
importance. The latter two (first and last element) would be invaluable
though in long documents, especially ones of a known structure.

Attempting to address your question of how many keystrokes it would take to
make effective use of the proposed navigation model, I will go through a
very simple scenario (for the needs of the scenario I assumed that the
following correspondence between commands and keys exists: next element -
"Arrow-Down", previous element - "Arrow-Up", last element - "End", first
element - "Home"):

Assume you know that you want to select a link in a long document, but you
are not sure if it was the third from the end, or the second from the end
(note that the fact these is no other link between them does not imply that
these two are necessarily close to each other). Using the proposed approach
you would:
1) press "Alt-L" to switch to link navigation mode (assuming that because
   it is a very important mode it has its own shortcut)
2) press "End" to go to the last link in the document
3) press "Arrow-Up" to go to the second link from the end, review the link
   and possibly
4) press "Arrow-Up" again to go to the third link from the end

I would like to iterate that the rationale for proposing this modification
to the guidelines, is to ensure that the very good idea of supporting
alternative navigation models (modes) in the document, is supported in an
intuitive way, imposing as little interaction burden on the user as possible.
It is interesting to note that in most cases (I am tempted to say all but
perhaps I am missing some complex cases, so I will refrain from that) the
proposed approach is faster in terms of interaction steps and requires
fewer keyboard shortcuts than the one currently included in the guidelines.

We would be very interested to find out what you and other people on the
list think, especially after the above, more detailed description.

Best regards,

Napoleon

Napoleon Maou
Software Engineer
AT&HCI Laboratory
ICS-FORTH
voice : +3081391742
email : maou@ics.forth.gr
WWW   : www.ics.forth.gr

Jon Gunderson wrote:

> Your approach I think may work for an experienced user who understands
> tags.  But what about the niave user who won't know want to look for or
> situations where a user just wants to get an overview of the document with
> out having to read every element.
> Jon
>
> At 09:17 PM 7/31/98 +0300, maou wrote:
> >Hello,
> >My name is Napoleon Maou and I am a staff member at the Assistive
> >Technology and Human computer Interaction (AT&HCI) laboratory , at the
> >Foundation of Research and Technology Hellas (FORTH).
> >
> >I am interested in technologies that will make the Web, or any other
> >information system, accessible to people with disabilities.
> >At FORTH I have participated in the development of the AVANTI unified
> >browser, a browser that in addition to motor abled users, is accessible
> >by blind and motor impaired users.
> >
> >I would like to comment on the subject of sequential navigation within a
> >View.
> >
> >I believe that there should be only one generalized mechanism to
> >navigate elements within a view. Section 6.1 talks about a mechanism for
> >sequential navigation of links, form elements and elements with
> >longdesc( using keyboard commands ) , and section 7.2 talks about
> >another mechanism that can be used for sequential navigation of Headers
> >or other elements ( using menus and menu shortcuts ).
> >
> >The problems I see with the existence of two mechanisms are the
> >following
> >1)  There exist more than one keyboard commands or menu keyboard
> >shortcuts, which have essentially the same meaning. "Move to next item".
> >For example if we have menu items to navigate Headers and Paragraphs
> >then there will be a "Next Header", a "Next Paragraph" and a "Next
> >link/longdesc/form element" command.
> >2)  If the user wants to navigate Headers and paragraphs then the
> >current mechanisms does not allow him to do that. He can navigate
> >Headers or Paragraphs but not both at the same time.
> >3)  For people with motor disabilities using menus to navigate will be
> >very time consuming.
> >4)  For blind people there is the problem of having to memorize more
> >keyboard commands than are needed.
> >
> >Proposed Mechanism
> >---------------------------
> >I believe that the UA should provide to the user a simple generalized
> >mechanism to navigate any elements in the view. This mechanism should:
> >a)  Allow the user to select the elements he wants to navigate.
> >b)  Provide  commands to move among the elements of the view.
> >
> >A mechanism like that I believe will be easy to use and is general
> >enough to allow the user to navigate any element combinations.
> >
> >Napoleon Maou
> >
> >--
> >Napoleon Maou
> >Software Engineer
> >AT&HCI Laboratory
> >ICS-FORTH
> >voice : +3081391742
> >email : maou@ics.forth.gr
> >WWW   : www.ics.forth.gr
> >
> Jon Gunderson, Ph.D., ATP
> Coordinator of Assistive Communication and Information Technology
> Division of Rehabilitation - Education Services
> University of Illinois at Urbana/Champaign
> 1207 S. Oak Street
> Champaign, IL 61820
>
> Voice: 217-244-5870
> Fax: 217-333-0248
> E-mail: jongund@uiuc.edu
> WWW:    http://www.staff.uiuc.edu/~jongund
>         http://www.als.uiuc.edu/InfoTechAccess

--
Napoleon Maou
Software Engineer
AT&HCI Laboratory
ICS-FORTH
voice : +3081391742
email : maou@ics.forth.gr
WWW   : www.ics.forth.gr