Re: User Agent Guidelines

JRGs response to Marja:
I think that your concerns are valid about ordering and that there should
be something in the guidelines about ordering.  In the short term the weak
solution is asking authors to put things in logical order.  This is weak
because it is dependent on the author to do the ordering.  Most authors
will not know it is important, or won't know how to do it with the tool
they are using to create WWW pages.  The stronger solution is probably
labeling of sections and have user agents recoginize some standard set of
"labels" that would be used to identify block level information.  Users
could use this to navigate to the sections of text they are interested in.
JOn


At 10:55 AM 5/5/98 +0200, Daniel Dardailler wrote:
>
>Marja, I'm just forwarding your comments to Jon.
>
>First this one:
>
>In User Agent Guidelines we want to be able to ignore the positioning
>information in the style sheet for the objects on the page. This is fine
>although I don't actually know exactly why. How does it contribute to the
>serializing of the html objects which I though was the goal of leaving the
>positioning out?
>
>Anyway, if designers do not pay any attention to the logical order of the
>HTML source code, I'm not sure if there are any other information that will
>carry info of the order in which the objects on the page should be
>logically presented. So at least, I think, we need a new guideline to the
>page authoring guidelines that asks people to keep the logical order of the
>elements in the source code. Another thing is then how the WYSIWYG tools
>keep that logical order. The user can edit different parts of the page
>positioned whereever at different times and that does not always implicate
>any order. Should the tool ask the logical order from the user?
>
>Is there something I'm missing?
>
>Marja
>
>
>
>> Here are some fast comments to User Agent Guidelines. I hope they are
helpful. While reading it I also corrected some typos although I guess they
were going to be corrected anyway.
>> 
>> Greetings!
>>    Marja
>> -----------
>> Comments to User Agent Guidelines 28-Apr-1998
>> 
>> Spellings in several places:
>> 
>> "impedded" change to "embedded"
>> "annimation" change to "animation"
>> "discription" change to "description"
>> 
>> Page 1: Rating and Classification/First line
>> 
>> The line "Each guideline is accompanied by a rating that describes its
importance and scenarios about how the :" ends unexpectedly. Maybe it
should be something like "... importance. In addition, s
>> cenarios describing the effects of a guideline, implementation ideas,
and test pages can be attached to the guideline.".
>> 
>> Page 2: Scenarios/First line
>> 
>> "... how the changes impacts" change to "... impact"
>> 
>> Page 2: Test Pages/First line
>> 
>> "explanitory" change to "explanatory"
>> 
>> Page 3: Presentation Adjustability
>> 
>> Shouldn't the color of links be also adjustable? If it is already taken
care of in 3 or 4, then it should be explained better.
>> 
>> Page 4: B. Default Browser Display Style/Paragraph 6
>> 
>> The external file should not only contain info of the default style but
at least also about the ignored formatting specifications. Furthermore,
other personal info e.g. of the favorite links etc. s
>> hould be included in this file so that the user does not have to install
many files while moving from one machine to another. An important thing is
also to be able to easily undo the settings when 
>> leaving the machine. So I think this issue needs to be more general and
located higher in this document hierarchy. 
>> 
>> Page 4: B. Ignore Page formatting Specifications/Paragraph 4
>> 
>> Should we be able to make a difference if the font or color is specified
in the page being rendered or, as recommended, in a style sheet. I would
guess that the user just wants to turn the color or
>>  the font specifications off or on and it doesn't matter where the
definitions are located. Are there some scenarios that prove this guess
wrong? If so, then maybe still the more detailed specifica
>> tions should be hidden and the basic on/off color etc. easily available?
>> 
>> Why exactly do we want to ignore the positioning information? If the
goal is to serialize the html objects, then how does the leaving ofthe
positioning out contribute to that goal?
>> 
>> When the positioning is left out and the designers do not pay any
attention to the logical order of the HTML source code, I'm not sure if
there are any other information that will carry info of the
>>  order in which the objects on the page should be logically presented.
So at least, I think, we need a new guideline to the page authoring
guidelines that asks people to keep the logical order of t
>> he elements in the source code. Another thing is then how the WYSIWYG
tools keep that logical order. The user can edit different parts of the
page  positioned whereever at different times and that 
>> does not always implicate any order. Should the tool ask the logical
order from the user?
>> 
>> Page 4: C. Alternative Representation of Images/Paragraph 1
>> 
>> Start a new paragraph after "When the user turns ... should be rendered
for the image.". In this way the IMG and the OBJECT details are in their
own paragraphs.
>> 
>> Some spaces are missing before and after ALT & LONGDESC.
>> 
>> I don't understand the NAME attribute part for IMG. Is that really
something that should be shown as an alternative description for an image?
I though the anchor can be just put somewhere in the do
>> cument to mark a place so that links can be made to it.
>> 
>> Another thing is why the LONGDESC attribute should be given as a default
to the user. I thought that the ALT is the default now and it would be
logical to keep it that way so that the users can the
>> n decide based on the ALT text if they want to see also the long
description.
>> 
>> Page 5: C. Alternative Representation of Images/Paragraph 1
>> 
>> Last word of first paragraph should be "text" instead of "image".
>> 
>> If the area for OBJECT text is smaller than for the image, should the
browser allow scrolling?
>> 
>> Is the file name part really necessary? If the file name is presented to
the user as an alternative text in case there is no alternative text, it
might look like it has been defined in the test pha
>> se and designers might rely on that rather than really defining the text.
>> 
>> Page 5: D. Alternative Representations for Video, Movies, and Animations
>> /Paragraph 1 & 2
>> 
>> "videoes" should be "videos"
>> 
>> Do the current current browsers have enough information available to do
this? Is it possible to define in HTML what is alternative audio or closed
captioning text?
>> 
>> Page 5: E. Alternative Representation of Embedded Applications/Paragraph 1
>> 
>> I would like to separate the APPLETs into own paragraph after the OBJECT
paragraph, especially since they are depreciated.
>> 
>> First line: "applicaitons" should be "applications"
>> Third line: "existance" should be "existence"
>> 
>> Page 5: F. Outline View of Page (In TOC this was Outline View of
Document)/Paragraph 1
>> 
>> First line "User has has the option ..." to be "User option ..."
>> Fifth line "some one" to be "someone"
>> Sixth line New paragraph after "... view the major topics within a
document."
>> Eight line "... full view would maintian..." to be "... full view should
maintain..."
>> 
>> Do there tag elements need to have class definitions are other kinds of
addresses to be referable? Should the shortcut links be in their own window
or at the beginning of the same window (vs. a MS 
>> Word document that can be divided into two parts).
>> 
>> Page 5: F. Outline View of Page (In TOC this was Outline View of
Document)/Paragraph 2
>> 
>> First line "Elements generated in the outline view become links..." to
be "Elements selected to the outline view are presented as links..."
>> Third line "orginal" to be "original"
>> 
>> Page 6: 2. Orientation Information/A. Maintenance of Document View and
Focus/Paragraph 2
>> 
>> Something is missing at the end of the second line.
>> 
>> Page 6: B. Document TITLE in title line/Paragraph 1
>> 
>> Does the title bar mean the title bar of a window?
>> 
>> Page 6: B. Document TITLE in title line/Paragraph 2
>> 
>> What is a status line? What does it mean that the TITLE is in status
line under user's command? Is the command equivalent to giving keyboard
commands that affect the status line? Isn't it enough to
>>  already have the TITLE in the title bar?
>> 
>> Page 6: C. Document summary information/Paragraph 1&2&3
>> 
>> Paragraph 1 and 2 are exactly same. What is the difference to the
paragraph 1?
>> 
>> On paragraph 1 the first line ends "...on page loading on status." I
don't understand what this means.
>> 
>> Page 6: D. Element Identification/Paragraph 1
>> 
>> How does this element info to be displayed on status line work with the
other info that also should be displayed on status line? If status line is
so important, it should be described somewhere as 
>> a whole in more detail.
>> 
>> Page 6: Navigation and Control/A. Sequential Navigation/Paragraph 1
>> 
>> What are the controls on page? Focus moving should be displayed in more
detail.
>> 
>> Page 7: D. Dyanmic (should be Dynamic) HTML Events/Paragraph 2
>> 
>> The line ends "... who do not have funcational use the mouse." should it
be something like "... who are unable to use the mouse."?
>> 
>> age 7: Visibility of Accessibility Features/A. Menu Commands/Paragraph 2
>> 
>> Isn't this the same thing as the outline view of the document described
earlier?
>> 
>> ---------
>> Couple of separate comments:
>> 
>> It would be nice to have one chapter that gives advices how similar
kinds of controls should be grouped together so that users don't have to go
to look them all over the browser. Some things might 
>> even be under one switch after the user has defined what that switch is
doing. Also some guidelines of where to put the controls would be nice. For
instance should they be readily available e.g. in
>>  a floating window or hidden in deep menu structures with other optional
attributes.
>> 
>> The animations should be easily stopped (and started again) be the user.
It might be even nice to be able to step through the animation at the
user's own pace.
>
>
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

Received on Tuesday, 5 May 1998 09:33:41 UTC