Thread Subject: Re: note for focus cursor

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Peter Korn
Date: Wed, Sep 12 2007 4:50 PM

Hi Sean,

I think it is fair and appropriate to recognize platforms that provide
this kind of support in 508, and to encourage through market forces
their acquisition over platforms that don't. If an agency has a
business need to go with a platform that doesn't provide the necessary
infrastructure to make life reasonable on applications, so be it; but
there should be clear direction to agencies as to what makes for a good,
accessible (and accessibility-supporting) platform. Likewise, if the
agency chooses to go with a platform that lacks necessary
infrastructure, I would guess that most applications will not find it
within their ability to do all the necessary work themselves, and so
most apps would not meet some provisions. However, for an application
that did go through all of that work, it makes sense to recognize that.
Perhaps it would be appropriate to structure an "if...then" style clause
for applications that are being acquired for
non-accessibility-supporting platforms.

Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Let me restate it, I'm not saying any specific platform has a hard time of it or not; what I'm saying is that if any platform failed to meet the requirement, the cost of implementing an app on that platform would go up by several orders of magnitude - if you had to do it on your own.
>
> Let's say Windows doesn't do it (I believe it does). Then you'd have to rewrite Swing to take care of that.
>
> Or if Swing didn't do it (You say it does and I have no reason to doubt you), then MyCoolApp.java would have to essentially re-write or extensively patch Swing.
>
> Sun of course meets the description of 'larger software vendor' and your investment to make this happen was the Java platform; JoeSchmoeSoft or the Department of Ed don't have the time or manpower to make something like that happen.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
> Sent: 12 September 2007 22:59
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] note for focus cursor
>
> Hi Sean,
>
> I don't understand your AWT & Swing comments. AWT uses platform UI
> elements - Win32 on Windows, etc. If the Win32 elements are themed (and
> thereby is "highly visible"), then AWT will be as well. And Swing "has
> at least one mode" in the form of the platform native Look & Feel which
> will do this. Since on GNOME I have personally verified that our focus
> indicators meet the "20/20 vision on a 1024x768 15" screen at 2.5
> meters" test, and Swing's "GTK+ Look and Feel" nearly perfectly emulates
> and respects the desktop High-contrast-large-print theme setting, Swing
> apps likewise will work fine. Further, we supply the "Java Look and
> Feel" which is a cross platform look and feel in which we define our own
> high-contrast mode, allowing us to override what the underlying platform
> does if it is insufficient in this regard.
>
> I'm sorry if you think .NET and other Windows technologies will have a
> hard time with this. Perhaps the problem is that one or more of the
> critical aspects of the Windows high-contrast-large-print theme(s) don't
> do enough in this regard?
>
> I wonder if the built-in magnifier in Mac OS X would likewise satisfy
> this issue. If everything is magnified without the need to purchase
> extra AT, then it can be fairly send to be "built-in", and with focus
> indication magnified like everything else...
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>> Well your wording makes sense in the abstract now, but actually I
>> think that if the platform doesn't provide it, the chances of an
>> application doing it are slim to none on any major operating system or
>> platform.
>>
>> A few examples: In Java this would essentially require a re-write of
>> AWT (on older platforms), or a shed-load of work in Swing. In Cocoa
>> I'm not even sure this is possible, if it is it would certainly be
>> hard. In the .NET frameworks and XAML, or the Win Cntrl library again
>> you'd be looking at pretty much a ground up re-write. This is the sort
>> of thing a major developer like an Adobe might take on, but a smaller
>> vendor or a Government agency would never tackle it.
>>
>> The situation is somewhat easier on the web where designers typically
>> take much more responsibility for their interface look and feel (at
>> the cost of cognitive overload), but even then - if form controls
>> don't support it, it's a lot of work rolling your own,
>>
>> That's all aside from the added cost of doing the AT interoperability
>> again and getting it right.
>>
>> So I really feel to have a chance of real world deployment this has to
>> be scoped to platforms, and applications respecting the platform.
>>
>> Thanks,
>>
>> Sean Hayes
>> Incubation Lab
>> *Accessibility Business Unit
>> Microsoft*
>>
>> * *
>>
>> *Office: +44 118 909 5867**, *
>>
>> *Mobile: +44 **7875 091385*
>>
>> *From:* = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of
>> *Gregg Vanderheiden
>> *Sent:* 12 September 2007 22:03
>> *To:* 'TEITAC Web/Software Subcommittee'
>> *Subject:* Re: [teitac-websoftware] note for focus cursor
>>
>> Ah
>>
>> Yes - you are right. I missed the second part.
>>
>> Ok lets look at this approach.
>>
>> "Platform software must support at least one mode that provides a
>> highly visual indication of which user interface object currently has
>> the keyboard focus. Application software that provides user interface
>> objects must either use the focus mode provided by the platform
>> software or provide such a mode directly"
>>
>> This is sort of workable but the Application has to take more
>> responsibility. The system focus may be invisible on their background
>> for example.
>>
>> How about
>>
>> "Platform software and applications that have keyboard operable user
>> interfaces must support at least one mode that provides a highly
>> visual indication of which user interface object currently has the
>> keyboard focus. Application may provide the highly visible indication
>> directly or by utilizing the platform cursor where effective.
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>> ------------------------------------------------------------------------
>>
>> *From:* = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of
>> *Sean Hayes
>> *Sent:* Wednesday, September 12, 2007 2:53 PM
>> *To:* TEITAC Web/Software Subcommittee
>> *Subject:* Re: [teitac-websoftware] note for focus cursor
>>
>> It's the 'software must provide' bit that is the problem.
>>
>> Its ambiguous whether there is an implied [all] in there.
>>
>> I disagree that all apps can ignore it, the way i wrote it is in
>> two parts:
>>
>> Part 2 is : Application software that provides user interface
>> objects must either use the focus mode provided by the platform
>> software or provide such a mode directly"
>>
>> Where does it say, or not do anything at all?
>>
>> Sean Hayes
>> Incubation Lab
>> *Accessibility Business Unit
>> Microsoft*
>>
>> * *
>>
>> *Office: +44 118 909 5867**, *
>>
>> *Mobile: +44 **7875 091385*
>>
>> *From:* = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of
>> *Gregg Vanderheiden
>> *Sent:* 12 September 2007 20:43
>> *To:* 'TEITAC Web/Software Subcommittee'
>> *Subject:* Re: [teitac-websoftware] note for focus cursor
>>
>> The "one mode that" language already allows you to use system or
>> platform capabilities to meet it. If the platform doesn't have
>> them though, then the app inherits the responsibility.
>>
>> The way you wrote it - all apps can just ignore the provision
>> since it is restricted to the platform - even if the platform
>> isn't providing the focus cursor.
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>> ------------------------------------------------------------------------
>>
>> *From:* = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf
>> Of *Sean Hayes
>> *Sent:* Wednesday, September 12, 2007 2:10 PM
>> *To:* TEITAC Web/Software Subcommittee
>> *Subject:* Re: [teitac-websoftware] note for focus cursor
>>
>> Thanks, Greg. That does address that concern.
>>
>> On re-reading the provision however, I have another concern
>> with the section :
>>
>> "Software must support at least one mode that ..."
>>
>> Which implies that the application software must implement
>> this itself, but typically it is the platform software which
>> provides this functionality for applications, for example
>> embodied in a 'widget set' or library; and even if the
>> application designer could override the platform behaviour,
>> they typically would not do so in order to fit in with the
>> platform user interface guidelines
>>
>> In the case of a web application it may be the browser or
>> plugin which provides this (but not always).
>>
>> Perhaps a better wording would be something along the lines of:
>>
>> "Platform software must support at least one mode that
>> provides a highly visual indication of which user interface
>> object currently has the keyboard focus. Application software
>> that provides user interface objects must either use the focus
>> mode provided by the platform software or provide such a mode
>> directly"
>>
>> Sean Hayes
>> Incubation Lab
>> *Accessibility Business Unit
>> Microsoft*
>>
>> * *
>>
>> *Office: +44 118 909 5867**, *
>>
>> *Mobile: +44 **7875 091385*
>>
>> *From:* = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf
>> Of *Gregg Vanderheiden
>> *Sent:* 12 September 2007 19:39
>> *To:* 'TEITAC Web/Software Subcommittee'
>> *Subject:* [teitac-websoftware] note for focus cursor
>>
>> At the very close of the meeting - I noticed that this
>> provision does talk about "without moving the cursor". Thus
>> knowledge of the cursor WOULD be required as Sean had
>> identified. (apologies Sean). I have edited the note below to
>> include his comment (I think).
>>
>> I also put a generic note for those who are not designing
>> software.
>>
>> * NOTE: A focus cursor that is visually locatable by
>> people (familiar with what the focus cursor would look
>> like) who have 20/20 vision at 3.5 times the typical
>> viewing distance without moving the cursor is sufficient.
>> * NOTE: Since computer software would be displayed on
>> unknown screen sizes: for computer software a focus
>> cursor that is visually locatable by people (familiar
>> with the cursor) who have 20/20 vision at 2.5 meters
>> when software is displayed on a 38 cm (15 inch) diagonal
>> screen at 1024 x 768 pixels resolution, without moving
>> the cursor is sufficient.
>>
>>
>>
>> Gregg
>>
>> ------------------------
>>
>> Gregg C Vanderheiden Ph.D.
>> Professor - Depts of Ind. Engr. & BioMed Engr.
>> Director - Trace R & D Center
>> University of Wisconsin-Madison
>> _<http://trace.wisc.edu/>_ FAX 608/262-8848
>>
>> DSS Player at http://tinyurl.com/dho6b
>>
>> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>>
>> <http://trace.wisc.edu:8080/mailman/listinfo/>
>>
>> ------------------------------------------------------------------------
>>
>>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University