Re: [PROPOSAL] Checkpoint 4.1 Configure text size.

At 09:39 PM 7/11/2001 -0400, Al Gilman wrote:
>At 05:25 PM 2001-07-11 , Jon Gunderson wrote:
> >Al,
> >This type of requirement is related to the old screen scraping mode of
> >accessing information from a user agent.  A refreshable braille display
> >following the guidelines should be using the DOM, not a graphical rendering
> >to gather information to be displayed.
>
>Is this response in line with the spirit of Tantek's original post?  He asked
>that browser implementers be given the latitude to eliminate font sizes that
>are of no earthly use to anyone.  Even if the screen scraping approach is
>obsolete, it is widely in use and so the  technique of setting the text
>size to
>something as small as '3' is certainly still relevant for many users.  I
>agree,
>I couldn't read the text at that size.  Pretty well Greeked.  I believe that
>the point should still be understood that text which is sized too small to
>read
>is _preferable or advantageous_, not merely of some (feasible) use, to this
>category of users with disabilities.  It is hardly "of no earthly use to
>anyone."
>
>I have to admit I am beyond my base of knowledge, here.  If the screen reader
>feeding the refreshable Braille display communicates with a browser via MSAA,
>will it see a fully laid out virtual Web page, or will it see just what
>appears
>in the window in the visual rendering?

JRG: MSAA is fairly fexible from my understanding, we could ask Tim Lacy 
what IE for Windows does.

>I understand that browsers need to expose the DOM, and that we want to
>encourage migration to this interface as superior.  On the other hand, screen
>reader makers have a lot to think about that is not all Web stuff.   Are you
>saying that browsers only need to support screen readers that use the DOM
>fully?  Is MSAA a "platform-standard accessibility API?"

JRG: We don't use the term "standard" to refer to technologies like MSAA 
anymore.  We just talk about APIs that support accessibility, since 
technologies like MSAA have not gone through a formal standards 
process.  MSAA has a lot of flexibility and Tim Lacy could probably tell us 
more about what MSAA does in IE, but it currently does expose DOM like 
information.

>I am confused.
>
>On the one hand, I am not sure that this concern of the Braille users rises
>above a P3 in priority.

JRG: I agree and 4.1 is at the P1 level.

>But on the other hand, I am equally not sure that access to the DOM removes
>this from all consideration.  Braille, while not visual, is a thoroughly
>spatial medium.  Does the Braille interface present the line of cells as a
>window which one can navigate around over a virtual embossed canvas?  Who does
>the line-breaking on that canvas?  Will the line-breaking be synched with the
>visual rendering even if the text is extracted from the DOM?  Speech
>interfaces
>have a 'cruise' mode where the interface will just read the whole thing.  This
>works in speech because it is rendering to an audio stream.  So it can just
>stream out the text in textual order from end to end.  Braille interfaces
>don't
>have this mode, because of the difference in the medium.
>
>Do we have anyone from Alva or another genuine Braille house that could
>comment
>on a) how things work today, and b) with access to the DOM, how things would
>work?

JRG: Developers who work with Braille include Glen Gordon, Hans Resbios and 
Aaron Smith

>At least in the past, we have not trusted mainstream software builders to know
>the limits of "what is of no earthly use to anyone," given that 'anyone'
>includes people with disabilities whos mode of using Information Technology
>varies a lot from individual to individual.  In particular, with regard to the
>'override' attribute on SMIL test variables, we negotiated for an got a change
>so that there is no way that the author can lock down data that they send to
>the user agent so that the user can't in any way call it up, at least as a
>function of the SMIL format.
>
>  <http://www.w3.org/TR/smil20/smil-content.html#q24>http://www.w3.org/TR/sm
>il20/smil-content.html#q24
>
>At the same time, SMIL players are encouraged to make things "exactly as the
>author wanted" the easiest to get, and to make it easier to make small
>perturbations than radical changes.  So that the ultimate in adjustment from
>nominal conditions is not necessarily reached casually or in one step.  Some
>override='hidden' track may be gibberish, but it is left to the user, in the
>last analysis (not the first), to determine that this gibberish is useless.
>The author doesn't always understand what can be gained from the data in an
>off-nominal mode of interaction.
>
>Similarly, I would think we could take a similar approach as what we wound up
>with in Checkpoints 2.1 through 2.3.  The user's ultimate range of control may
>run past the limits of what is useful, but is not curtailed by application
>author guesses as to what those limits are.  Here we are talking about tool
>designers, not multimedia authors; but they are not all (heck, we are not all)
>experts in the odd nooks and crannies of what works for people who have
>serious
>needs to do things a little differently.  I would commend the application
>developers for restricting _menus of nominated font size choices_ to those
>that
>they understand to be useful; relegating choices for which the application
>writers are not aware of any use to being accessible only by more obscure
>protocols such as using the text entry opportunity in the combo box to
>indicate
>a size of 3 which was not on the menu part of the combo box.  If the system
>APIs support it, and the user has to go out of their way to shoot
>themselves in
>this particular foot, it is not clear the application shold be programming in
>hard limits to deny the user this opportunity.  Does that make any sense?

JRG: The group can still decide on no change to the checkpoint.  In that 
case we will have a requirement that has dubious accessibility benefits for 
a number of operating systems, basically because we could not generate 
consensus on a better way to describe the required features.  I don't know 
of anyone with a disability who I have worked with who has ever wanted 
smaller fonts or comments in the working group that having smaller fonts 
sizes than what the user agent already provides was a P1 requirement 
.  That does mean somebody with a disability would not potentially benefit 
from smaller font sizes, we just have not documented the case as a P1 
requirement, so that weakens the validity of our document to developers.  I 
believe the working group wants the document to be valid as possible to 
developers.


Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
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
WWW: http://www.w3.org/wai/ua

Received on Thursday, 12 July 2001 11:18:02 UTC