Re: [PROPOSAL] Checkpoint 4.1 Configure text size.

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?

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?"

I am confused.

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

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?

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?

Al

>Jon
>
>
>At 03:47 PM 7/11/2001 -0400, Al Gilman wrote:
>>At 02:36 PM 2001-07-11 , Jon Gunderson wrote:
>> >I don't like complicating the checkpoint with cascading requirements and
>> >ambiguous terms.
>>
>> >3. I don't think the minimum size needs to be specified or mentioned,
since
>> >any practical user agent will implement smaller sizes useful to people
with
>> >average vision.  I don't think many developers are going to start their
>> >design process using our document and say want we need to do to conform
>> >this document.  Most will be trying to add capabilities to current
>> >implementations to their technology.
>> >
>>
>>The users who want the smallest screen font are not visual users but Braille
>>users, IIRC.  We can't necessarily judge the low end of what is needed from
>>what works for the 20:20 eyeball.
>>
>>I am trying to check my sources, but the value I recall as in use was
'3.'  I
>>just succeeded in throwing WordPad into size '3' Arial.  But not for all
fonts
>>such as Fixedsys, which seems to bottom out at '9.'
>>
>>Al
>
>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>http://www.staff.uiuc.edu/~jongund
>WWW: <http://www.w3.org/wai/ua>http://www.w3.org/wai/ua
>

Received on Wednesday, 11 July 2001 21:29:38 UTC