Thread Subject: Re: Provide highly visible keyboard focus and text cursors

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: Sean Hayes
Date: Mon, Jul 02 2007 7:00 AM

I'm not sure here.

If you define HTML+CSS as 'truly static content' and if the CSS styles the content, then it would need to provide styles that either don't clash with the platform provided focus, or take ownership of styling the focus.

OTOH if HTML+CSS counts as dynamic content, then I agree.

Sean Hayes
Standards and Policy Team
Corporate Accessibility Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman, Allen
Sent: 02 July 2007 13:46
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Provide highly visible keyboard focus and text cursors

Peter Korn wrote:
We missed you on the con-call yesterday. When content is truly static
content (and not executing code), the responsibility of a
platform-derived focus indication doesn't lie with content. It lies
with the software displaying that content. As far as the
platform-on-platform issues, I think focus indication belongs with
"color, contrast, and other individual display attributes" that must be
conveyed from the underlying platform, through the
platform-on-platform-application, to the app (e.g. from GNOME through
the Java runtime on to the Java application). I think our current draft
language - still in discussion and not yet final - addresses this.

I was on Wednesday, but was not available Thursday, sorry.
I concur with your statement about where the responsibility is for
cursor focus.


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: 28 June 2007 23:46
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Provide highly visible keyboard focus
and text cursors

Allen,

We missed you on the con-call yesterday. When content is truly static
content (and not executing code), the responsibility of a
platform-derived focus indication doesn't lie with content. It lies
with the software displaying that content. As far as the
platform-on-platform issues, I think focus indication belongs with
"color, contrast, and other individual display attributes" that must be
conveyed from the underlying platform, through the
platform-on-platform-application, to the app (e.g. from GNOME through
the Java runtime on to the Java application). I think our current draft
language - still in discussion and not yet final - addresses this.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> I think both Sean and Peter are really getting this beaten in to shape

> now.
>
> is there some language that can include the relationship of the
> content in to the whole platform-platform scenarios? It seems like
> without that relationship noted the end-to-endedness may not fully be
> achieved for what we are driving at.
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter

> Korn
> Sent: Wednesday, June 27, 2007 7:07 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Provide highly visible keyboard
> focus and text cursors
>
> Hi Peter,
>
> This is a lot of where the discussion about platform responsibility
> comes from that Andi referenced in call earlier today. This is also
> why I suggest that we consider including "focus indication" in the
> "color, contrast, and other individual display attributes" language of
> 1194.21(g) / 3b.F. We should encourage (if not outright require) the
> platform to define the visual focus indication mechanism, and further
> allow users to set it platform-wide. Then your app, using standard
> user interface elements defined by the platform, should automatically
> comply with the platform settings, which in turn should meet the
> standard (or the platform itself would fail to be 508 compliant).
>
> Of course, as you note, custom user interface elements would place the

> burden of implementing this on the developer of the custom element
> (and on the user of a custom element who has the responsibility of
> verifying that they are using compliant components).
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>
>> I'm trying to figure out who is ultimately responsible for satisfying

>> this provision. I fully recognize that if I invent my own widgets, it

>> is entirely up to me. But if I code a simple web page today using
>> simple components, the browser currently does *something* to indicate

>> focus on every component. Because of that, can I safely make the
>> assumption that the browser or OS is responsible for adhering to this

>> provision, or am I forced to guarantee compliance myself?
>> Peter Wallack
>> Accessibility Program Director
>> Oracle Corporation
>>
>>
>> Gregg Vanderheiden wrote:
>>
>>> Agree
>>>
>>> That is why the provision is OUTCOME oriented rather than method
>>>
> oriented.
>
>>> It says what the outcome should be but makes not mention of how it
>>> should be met.
>>>
>>>
>>> Gregg
>>> -- ------------------------------
>>> Gregg C Vanderheiden Ph.D.
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>>>> Peter Korn
>>>> Sent: Wednesday, June 27, 2007 3:23 PM
>>>> To: TEITAC Web/Software Subcommittee
>>>> Subject: Re: [teitac-websoftware] Provide highly visible keyboard
>>>> focus and text cursors
>>>>
>>>> Gregg,
>>>>
>>>> Many desktops offer a "mouse trails" option, in which the mouse
>>>> cursor briefly gets a tail or trail, where the last
>>>> ~1/2 second of previous positions remain briefly on the screen to
>>>> aid in their being located. It is easy to imagine something like
>>>> Sean's control key suggestion - a mode in which the focused item is

>>>> briefly more significantly visually indicated - aiding the user in
>>>> locating it when the TAB key is pressed.
>>>>
>>>> The larger point I want to make is that there are a variety of
>>>> innovative/novel ways in which one could aid users in visually
>>>> locating the focused object on the screen. Larger "marching ants"
>>>> or
>>>>
>
>
>>>> other static focus indication is only one of them. Whatever
>>>> standard
>>>>
>
>
>>>> we put forth should be general enough to allow for new and novel
>>>> approaches, so long as they meet the ultimate user need.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Peter Korn
>>>> Accessibility Architect,
>>>> Sun Microsystems, Inc.
>>>>
>>>>
>>>>
>>>>> Hmmm
>>>>>
>>>>> Boy - that is a good question. It is marginal at best. Each
>>>>>
>>>>>
>>>> time I hit
>>>>
>>>>
>>>>> the tab key I would have to hit the control key to figure
>>>>>
>>>>>
>>>> out where it
>>>>
>>>>
>>>>> went. Maybe if it did it each time it moved too..? But then
>>>>>
>>>>>
>>>> you have
>>>>
>>>>
>>>>> to change focus to find it. (sounds like the uncertainty
>>>>>
> principle).
>
>>>>> hmmmm
>>>>>
>>>>>
>>>>> Gregg
>>>>> -- ------------------------------
>>>>> Gregg C Vanderheiden Ph.D.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> -------------------------------------------------------------------
>>>> -
>>>> --
>>>>
>>>>
>>>>> --
>>>>>
>>>>> *From:* = EMAIL ADDRESS REMOVED =
>>>>> [mailto: = EMAIL ADDRESS REMOVED = ] *On
>>>>>
>>>>>
>>>> Behalf Of
>>>>
>>>>
>>>>> *Sean Hayes
>>>>> *Sent:* Wednesday, June 27, 2007 2:49 PM
>>>>> *To:* TEITAC Web/Software Subcommittee
>>>>> *Subject:* Re: [teitac-websoftware] Provide highly visible
>>>>> keyboard focus and text cursors
>>>>>
>>>>> It turns out I have my display set at 1400x1050, so that might
>>>>> explain my apparent loss of visual acuity J. I think I have a
>>>>> better understanding of what you are getting at now, I'll
think
>>>>> about it for a bit.
>>>>>
>>>>> One more question - if the control key, or similar could be
>>>>> configured to identify the focused widget in the same way as
>>>>>
> the
>
>>>>> pointer, would that also cover it?
>>>>>
>>>>> Sean Hayes
>>>>> Standards and Policy Team
>>>>> *Corporate Accessibility Group
>>>>> Microsoft
>>>>> *Phone:
>>>>> mob +44 7977 455002
>>>>> office +44 117 9719730
>>>>>
>>>>> *From:* = EMAIL ADDRESS REMOVED =
>>>>> [mailto: = EMAIL ADDRESS REMOVED = ] *On
>>>>>
>>>>>
>>>> Behalf Of
>>>>
>>>>
>>>>> *Gregg Vanderheiden
>>>>> *Sent:* 27 June 2007 20:35
>>>>> *To:* 'TEITAC Web/Software Subcommittee'
>>>>> *Subject:* Re: [teitac-websoftware] Provide highly visible
>>>>> keyboard focus and text cursors
>>>>>
>>>>> Not sure I follow what your question/problem is.
>>>>>
>>>>> It is possible to change the viewing size of the text.
>>>>>
>>>>>
>>>> It does not
>>>>
>>>>
>>>>> change the cursor however.
>>>>>
>>>>> Also, don't know about you but with my glasses on, I
>>>>>
>>>>>
>>>> can see which
>>>>
>>>>
>>>>> side of the comma the cursor is from 2.5 meters at
>>>>>
>>>>>
>>>> default settings.
>>>>
>>>>
>>>>> But reading the text from that distance isn't the point.
People
>>>>> with low vision can use close viewing to read text. But
>>>>>
>>>>>
>>>> they have
>>>>
>>>>
>>>>> to look at the full screen to find the cursors.
>>>>>
>>>>> For you that would be equivalent to finding the cursor
>>>>>
>>>>>
>>>> location at
>>>>
>>>>
>>>>> 2.5 meters, but reading the screen at .5 meters - or
>>>>>
>>>>>
>>>> maybe 1 meter.
>>>>
>>>>
>>>>> The control key lets you find the mouse pointer (on windows)
>>>>>
> but
>
>>>>> not the keyboard focus or character input.
>>>>>
>>>>> Does this help?
>>>>>
>>>>>
>>>>> Gregg
>>>>> -- ------------------------------
>>>>> Gregg C Vanderheiden Ph.D.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> -------------------------------------------------------------------
>>>> -
>>>> --
>>>>
>>>>
>>>>> --
>>>>>
>>>>> *From:* = EMAIL ADDRESS REMOVED =
>>>>> [mailto: = EMAIL ADDRESS REMOVED = ]
>>>>>
>>>>>
>>>> *On Behalf
>>>>
>>>>
>>>>> Of *Sean Hayes
>>>>> *Sent:* Wednesday, June 27, 2007 2:19 PM
>>>>> *To:* TEITAC Web/Software Subcommittee
>>>>> *Subject:* Re: [teitac-websoftware] Provide highly visible
>>>>> keyboard focus and text cursors
>>>>>
>>>>> One problem I have with this wording is that at 2.5 meters
>>>>> most of the UI is unintelligible (although if course that
>>>>> depends on OS settings); so while /locating/ the
>>>>>
>>>>>
>>>> element with
>>>>
>>>>
>>>>> focus may be possible; determining what the located
>>>>>
>>>>>
>>>> item /is/
>>>>
>>>>
>>>>> would be impossible.
>>>>>
>>>>> For example I can locate the flashing insertion
>>>>>
>>>>>
>>>> point in this
>>>>
>>>>
>>>>> text from across the room, but determining whether it is
>>>>> before or after the comma in this sentence eludes me.
>>>>>
>>>>> So it seems like a very partial interpretation of
>>>>>
>>>>>
>>>> locate, and
>>>>
>>>>
>>>>> I'm having a hard time understanding the user need this
>>>>> provision is attempting to satisfy. Perhaps the "Windows
>>>>> magnify with follow focus" mode is in fact a much better
>>>>> mechanism than drowning the item with a bright
>>>>>
>>>>>
>>>> yellow triangles.
>>>>
>>>>
>>>>> Sean Hayes
>>>>> Standards and Policy Team
>>>>> *Corporate Accessibility Group
>>>>> Microsoft
>>>>> *Phone:
>>>>> mob +44 7977 455002
>>>>> office +44 117 9719730
>>>>>
>>>>> *From:* = EMAIL ADDRESS REMOVED =
>>>>> [mailto: = EMAIL ADDRESS REMOVED = ]
>>>>>
>>>>>
>>>> *On Behalf
>>>>
>>>>
>>>>> Of *Gregg Vanderheiden
>>>>> *Sent:* 27 June 2007 19:28
>>>>> *To:* 'TEITAC Web/Software Subcommittee'
>>>>> *Subject:* [teitac-websoftware] Provide highly visible
>>>>> keyboard focus and text cursors
>>>>>
>>>>>
>>>>> *9.2.2 Provide highly visible keyboard
>>>>>
>>>>>
>>>> focus and text
>>>>
>>>>
>>>>> cursors *
>>>>>
>>>>> Software shall provide at least one mode where
>>>>>
>>>>>
>>>> keyboard focus
>>>>
>>>>
>>>>> cursors and text cursors shall be visually
>>>>>
>>>>>
>>>> locatable by people
>>>>
>>>>
>>>>> with unimpaired 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.
>>>>>
>>>>> EXAMPLE 1: The software provides an option of having a
>>>>>
> thick
>
>>>>> rectangle of contrasting color that moves to and
>>>>>
>>>>>
>>>> outlines the
>>>>
>>>>
>>>>> control or field that has keyboard focus.
>>>>>
>>>>> EXAMPLE 2: The software provides an option of having
>>>>>
> bright,
>
>>>>> yellow triangles extend from the top and bottom of the
text
>>>>> cursor.
>>>>>
>>>>>
>>>>> 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