Thread Subject: Group A: 21(c) Keyboard focus

Return to this mailing list's archives

From: Andi Snow-Weaver
Date: Fri, Oct 27 2006 7:30 PM
Subject: Group A: 21(c) Keyboard focus

21(c) current wording:

A well-defined on-screen indication of the current focus shall be provided
that moves among interactive interface elements as the input focus changes.
The focus shall be programmatically exposed so that assistive technology
can track focus and focus changes.

ISO has two provisions that address this issue: "Software shall provide a
focus cursor that visually indicates which user interface element currently
has the keyboard input focus, as well as the focus location within that
element when one exists." ISO does not contain a provision specifically
addressing programmatic exposure of keyboard focus but it does include one
that requires using system standard input and output services. If you use
standard input services, doesn't that imply that the keyboard focus is
programmatically exposed?

ISO does have a provision on event notification which would cover keyboard
focus changes and all other type of user interaction events: "Software
shall provide assistive technology with notification of events relevant to
user interactions."

It includes the following expanatory note:

Events relevant to user interaction include, but are not limited to,
changes in user interface element status (such as creation of new user
interface elements, changes in selection, changes in focus and changes in
position), changes in attributes (such as size, colour and name), and
changes of relationships between user interface elements (such as when one
user interface element contains, names, describes or affects another). Just
as important are input events, such as key presses and mouse button
presses, and output events, such as writing text to the screen or playing
audio information. This also applies to user interface status values (such
as the states of toggle keys).

Do we want to make 508 broader and more comprehensive in this area?

This function is not required by 508 for Web content and applications
(1194.22). Do we need to add this for Web content and applications? WCAG
2.0 does not contain such a provision.

Andi

From: Brett, Thomas F
Date: Sat, Oct 28 2006 5:00 AM
Subject: Re: Group A: 21(c) Keyboard focus

Do we want to make 508 broader and more comprehensive in this area?

Yes.

Tom Brett

From: Barrett, Don
Date: Sat, Oct 28 2006 1:25 PM
Subject: Re: Group A: 21(c) Keyboard focus

"A well-defined on-screen indication of the current focus shall
"be provided that moves among interactive interface elements as
"the input focus changes.
"The focus shall be programmatically exposed so that assistive
"technology can track focus and focus changes.
The whole notion of programmatically exposed has always proven to be a
real problem in 508 implementation and testing. At least to my
knowledge, it isn't testable or measurable and without those qualities,
any standard is worthless. Remember, we are not designing a utopia nor
are we defining what the perfect world of accessibility would look like
in web and software. We are refreshing a Federal standard which must be
reasonable, meetable, measurable, and understandable.

"If you use standard input services, doesn't
"that imply that the keyboard focus is programmatically exposed?"

What are standard input/output services? Does that mean using only MFC
controls? Does it mean only using OS calls? If we can define these, I
think they re very very relevant, but the phrase itself is just too
generic.

"ISO does have a provision on event notification which would
"cover keyboard focus changes and all other type of user
"interaction events: "Software shall provide assistive
"technology with notification of events relevant to user interactions."
"
"It includes the following explanatory note:
"
"Events relevant to user interaction include, but are not
"limited to, changes in user interface element status (such as
"creation of new user interface elements, changes in selection,
"changes in focus and changes in position), changes in
"attributes (such as size, colour and name), and changes of
"relationships between user interface elements (such as when
"one user interface element contains, names, describes or
"affects another). Just as important are input events, such as
"key presses and mouse button presses, and output events, such
"as writing text to the screen or playing audio information.
"This also applies to user interface status values (such as the
"states of toggle keys).
"
"Do we want to make 508 broader and more comprehensive in this area?
"
I think we should, but here again, this is so broad and generic, it is a
principle, not a standard. The question we get most often is "what
exactly is the assistive technology looking for which will ensure
accessibility," so defining just how these events need to be exposed is
very important. Again, as stated before, we need a way to test for its
successful implementation as well.
Don

From: Fratkin, Mike
Date: Mon, Oct 30 2006 5:55 AM
Subject: Re: Group A: 21(c) Keyboard focus

I believe that we do need to make this provision broader. An aspect
that needs to be considered is not just the fact of a well-defined
focus, but where the focus should be in specific situations to be most
beneficial to a person with a disability.

As mentioned previously, in Search functions, the results of the Search
is most important and focus seems to vary from application to
application. It is generally at the top of the page, sometimes in the
Search input box but hardly ever focused on the number of hits or
indicating to the user that there were no hits.

For error handling, indicating the number of errors on a page and
guiding the user to the error fields is again an issue of focus and
needs to be considered. Additionally, Help screens where there are
frames with a table of contents in one frame and the actual contents in
another frames is also an issue of focus. When a item is selected in
the left or table of contents frame, typically, the right frame or
content changes. However, the actual focus stays on the left frame and
a screen magnification user would never know that something had changed.

So, it seems like focus issues so need a much broader attention.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Snow-Weaver
Sent: Friday, October 27, 2006 9:27 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-websoftware] Group A: 21(c) Keyboard focus


21(c) current wording:

A well-defined on-screen indication of the current focus shall be
provided that moves among interactive interface elements as the input
focus changes.
The focus shall be programmatically exposed so that assistive technology
can track focus and focus changes.

ISO has two provisions that address this issue: "Software shall provide
a focus cursor that visually indicates which user interface element
currently has the keyboard input focus, as well as the focus location
within that element when one exists." ISO does not contain a provision
specifically addressing programmatic exposure of keyboard focus but it
does include one that requires using system standard input and output
services. If you use standard input services, doesn't that imply that
the keyboard focus is programmatically exposed?

ISO does have a provision on event notification which would cover
keyboard focus changes and all other type of user interaction events:
"Software shall provide assistive technology with notification of events
relevant to user interactions."

It includes the following expanatory note:

Events relevant to user interaction include, but are not limited to,
changes in user interface element status (such as creation of new user
interface elements, changes in selection, changes in focus and changes
in position), changes in attributes (such as size, colour and name), and
changes of relationships between user interface elements (such as when
one user interface element contains, names, describes or affects
another). Just as important are input events, such as key presses and
mouse button presses, and output events, such as writing text to the
screen or playing audio information. This also applies to user interface
status values (such as the states of toggle keys).

Do we want to make 508 broader and more comprehensive in this area?

This function is not required by 508 for Web content and applications
(1194.22). Do we need to add this for Web content and applications? WCAG
2.0 does not contain such a provision.

Andi

From: Andrew Kirkpatrick
Date: Mon, Oct 30 2006 6:25 AM
Subject: Re: Group A: 21(c) Keyboard focus

> At least to my knowledge, it isn't testable or
> measurable and without those qualities, any standard is
> worthless. Remember, we are not designing a utopia nor are
> we defining what the perfect world of accessibility would
> look like in web and software. We are refreshing a Federal
> standard which must be reasonable, meetable, measurable, and
> understandable.

I'm not sure if you are saying that this isn't testable, but if so, I
don't agree. This is highly testable with tools that allow you to track
the focus programmatically.

> "Do we want to make 508 broader and more comprehensive in this area?"

> I think we should, but here again, this is so broad and
> generic, it is a principle, not a standard. The question we
> get most often is "what exactly is the assistive technology
> looking for which will ensure accessibility," so defining
> just how these events need to be exposed is very important.
> Again, as stated before, we need a way to test for its
> successful implementation as well.

We need to be careful that we're not defining specifically how
application frameworks and OS's need to convey their information. We
just need to indicate what the goal is. I can empathize with people
needing to understand how to evaluate a standard like this one, but this
is a technical standard and most of the frustration that has been
communicated to me has been by people who are not techically
knowledgable. I'd love to have tools that automatically evaluate for
this and other standards, but we don't have those right now.

Don, I'm not sure that I'm reading your response as intended, so I hope
that I'm not misrepresenting your position...

Thanks,
AWK

From: Barrett, Don
Date: Mon, Oct 30 2006 7:40 AM
Subject: Re: Group A: 21(c) Keyboard focus

"I'd love to have tools that automatically evaluate for this and other
standards, but we don't have those right now."

Yes, you are right, we need tools, and accessible tools; it's so
frustrating not to be able to use Object Inspector as a blind person.
To the extent that more robust tools are developed, the standards will
increase in their effectiveness to promulgate accessibility.

From: Hoffman, Allen
Date: Mon, Oct 30 2006 7:45 AM
Subject: Re: Group A: 21(c) Keyboard focus

We did have tools for this, (at least in the Microsoft Windows
platform), but that company went out of business. Seems like this kind
of testing capacity would be a natural extension for some AT products,
but I've never seen it included for that purpose. There are tools like
object inspector for Java. There seem to be open-source related testing
"systems" to perform specific sets of tests on software to validate the
functionality of such products coming, and some of these are now
beginning to include accessibility as part of the test. These kinds of
testing tasks need to be part of normal tool sets to become widely used
in my opinion. Begs the question if development tools have a special
place, and possible a special requirement to match in Section 508
technical standards? I don't see any specific location within existing
software or web standards that this fits into, so this area might have
to be addressed some other way if it is at all.

"I'd love to have tools that automatically evaluate for this and other
standards, but we don't have those right now."

"Yes, you are right, we need tools, and accessible tools; it's so
frustrating not to be able to use Object Inspector as a blind person.
To the extent that more robust tools are developed, the standards will
increase in their effectiveness to promulgate accessibility."

From: Jim Tobias
Date: Mon, Oct 30 2006 8:15 AM
Subject: Re: Group A: 21(c) Keyboard focus

> -----Original Message-----
> From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, October 30, 2006 9:43 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group A: 21(c) Keyboard focus
>
<snip>
> These kinds of testing
> tasks need to be part of normal tool sets to become widely
> used in my opinion. Begs the question if development tools
> have a special place, and possible a special requirement to
> match in Section 508 technical standards? I don't see any
> specific location within existing software or web standards
> that this fits into, so this area might have to be addressed
> some other way if it is at all.

Allen, this is a fascinating idea. It would be possible to add such a
requirement to 508: a provision to purchase development tools that support
both accessible content and testing for accessible content. Furthermore,
all web, software, and content developed for federal purposes could be
required to use such tools.

From: Andrew Kirkpatrick
Date: Mon, Oct 30 2006 8:40 AM
Subject: Re: Group A: 21(c) Keyboard focus

> Allen, this is a fascinating idea. It would be possible to
> add such a requirement to 508: a provision to purchase
> development tools that support both accessible content and
> testing for accessible content. Furthermore, all web,
> software, and content developed for federal purposes could be
> required to use such tools.

There is a whole industry that develops testing tools for various
technologies, I don't think that it is wise to remove competition and
innovation from that space by requiring that accessibility testing tools
be built into development tools.

I'm also concerned that the definition of "development tool" is
increasingly hard to pin down - does every CMS need to include this
functionality? Microsoft Word can create web pages from Word docs -
should Word inclue this also?

Testing tools are not the panacea that we'd all like them to be, I'm
worried that too much focus on integrated testing for accessibility
reinforces that misconception.

AWK

From: Jim Tobias
Date: Mon, Oct 30 2006 9:10 AM
Subject: Re: Group A: 21(c) Keyboard focus

> -----Original Message-----
> From: Andrew Kirkpatrick [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, October 30, 2006 10:37 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group A: 21(c) Keyboard focus
>
> > Allen, this is a fascinating idea. It would be possible to
> add such a
> > requirement to 508: a provision to purchase development tools that
> > support both accessible content and testing for accessible
> content.
> > Furthermore, all web, software, and content developed for federal
> > purposes could be required to use such tools.
>
> There is a whole industry that develops testing tools for
> various technologies, I don't think that it is wise to remove
> competition and innovation from that space by requiring that
> accessibility testing tools be built into development tools.

I agree, and that's why I explicitly didn't say "built in"; I said
"support". The goal is to make sure that a company selling a new tool gives
some thought to how its outputs would be evaluated for accessibility.

> I'm also concerned that the definition of "development tool"
> is increasingly hard to pin down - does every CMS need to
> include this functionality? Microsoft Word can create web
> pages from Word docs - should Word inclue this also?

What is a development tool? Important question, but one that can be
clarified with proper definitions. For example, what has the WAI experience
been?

> Testing tools are not the panacea that we'd all like them to
> be, I'm worried that too much focus on integrated testing for
> accessibility reinforces that misconception.

"Integrated" or "automated"? I'm talking about support for testing, not
building in every possible test; and there's lots of room for improvement in
non-automated testing tools without trying to force-fit a need for objective
measures.

From: Hoffman, Allen
Date: Mon, Oct 30 2006 9:40 AM
Subject: Re: Group A: 21(c) Keyboard focus

"I agree, and that's why I explicitly didn't say "built in"; I said
"support". The goal is to make sure that a company selling a new tool
gives some thought to how its outputs would be evaluated for
accessibility."

Continuing this thread:

I'll stay away from issues surrounding if, or if not, competition has to
be ensured for particular IT items, or at what level it should be
ensured--can of worms. However, when I mention development tools, I
would separate tools into "EIT development" tools, and "content"
development tools. I have not worked through this language development
process to the end yet, but here is a stab:

EIT which primary function is to produce software or web applications,
shall include a method to systematically review those products
source-code and/or interfaces to identify interface elements which lack
required accessibility information including focus, identity, state, and
operation. Note, probably needs longer list to include
text-descriptions of non-text elements, blinking items, tabular
displays, etc.

EIT which primary function is to produce information to be delivered by
other EIT items, must include the ability to systematically review
produced content and identify, and allow remediation of accessibility
attributes including alternate text, tabular data and header
association, logical reading-order, (and I'm sure more).

Given this kind of definition, something like Adobe Dream Weaver would
fall into the first group, while Microsoft Word would fall into the
second generally. it could be argued that "primary" might be a poor
choice of language as Microsoft Word can produce electronic forms, which
should, in my view, be classified as EIT.

However, this is why we have such as great group of folks on the
subcommittee to help us work it out.

From: Peter Korn
Date: Mon, Oct 30 2006 10:35 AM
Subject: Re: Group A: 21(c) Keyboard focus

Mike Fratkin wrote:
> I believe that we do need to make this provision broader. An aspect
> that needs to be considered is not just the fact of a well-defined
> focus, but where the focus should be in specific situations to be most
> beneficial to a person with a disability.
>
> As mentioned previously, in Search functions, the results of the Search
> is most important and focus seems to vary from application to
> application. It is generally at the top of the page, sometimes in the
> Search input box but hardly ever focused on the number of hits or
> indicating to the user that there were no hits.
>
> For error handling, indicating the number of errors on a page and
> guiding the user to the error fields is again an issue of focus and
> needs to be considered. Additionally, Help screens where there are
> frames with a table of contents in one frame and the actual contents in
> another frames is also an issue of focus. When a item is selected in
> the left or table of contents frame, typically, the right frame or
> content changes. However, the actual focus stays on the left frame and
> a screen magnification user would never know that something had changed.
>
> So, it seems like focus issues so need a much broader attention.
>

I think we should be careful with the word "focus", which generally
means "where keyboard input will go". This makes sense for something
like a search input box, but no the static text indicating the number of
hits.

What I think is wanted is a way for E&IT to indicate to AT that
"something new and interesting has happened here; you might want to
convey it to your user". What I think we don't want is for E&IT to
explicitly drive AT - that gets us into the dangerous territory of
designing for specific AT (e.g. this is what you need to do to make JAWS
say "number of search hits: 20").

We deal with this situation in the UNIX & Java worlds by giving things
the role STATUS_BAR, with the convention that screen readers will in
most cases want to read changes in the status bar to the user (there is
an event we fire in UNIX/Java to indicate that text has changed). A
user wanting less verbosity, or a custom script in the screen reader for
that app may then not speak those changes; but the information is there
for the user & AT to make that determination.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
> Snow-Weaver
> Sent: Friday, October 27, 2006 9:27 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [teitac-websoftware] Group A: 21(c) Keyboard focus
>
>
> 21(c) current wording:
>
> A well-defined on-screen indication of the current focus shall be
> provided that moves among interactive interface elements as the input
> focus changes.
> The focus shall be programmatically exposed so that assistive technology
> can track focus and focus changes.
>
> ISO has two provisions that address this issue: "Software shall provide
> a focus cursor that visually indicates which user interface element
> currently has the keyboard input focus, as well as the focus location
> within that element when one exists." ISO does not contain a provision
> specifically addressing programmatic exposure of keyboard focus but it
> does include one that requires using system standard input and output
> services. If you use standard input services, doesn't that imply that
> the keyboard focus is programmatically exposed?
>
> ISO does have a provision on event notification which would cover
> keyboard focus changes and all other type of user interaction events:
> "Software shall provide assistive technology with notification of events
> relevant to user interactions."
>
> It includes the following expanatory note:
>
> Events relevant to user interaction include, but are not limited to,
> changes in user interface element status (such as creation of new user
> interface elements, changes in selection, changes in focus and changes
> in position), changes in attributes (such as size, colour and name), and
> changes of relationships between user interface elements (such as when
> one user interface element contains, names, describes or affects
> another). Just as important are input events, such as key presses and
> mouse button presses, and output events, such as writing text to the
> screen or playing audio information. This also applies to user interface
> status values (such as the states of toggle keys).
>
> Do we want to make 508 broader and more comprehensive in this area?
>
> This function is not required by 508 for Web content and applications
> (1194.22). Do we need to add this for Web content and applications? WCAG
> 2.0 does not contain such a provision.
>
> Andi
>
>

From: Fratkin, Mike
Date: Mon, Oct 30 2006 10:46 AM
Subject: Re: Group A: 21(c) Keyboard focus

I agree for the most part, but it is not always strictly an AT issue.
If I am a keyboard only user, it would be helpful and again more
comparable or efficient to have the focus positioned at the logical
point of attention. This could be the "hits" or the number of errors.
The sighted mouse user can go directly to where he/she needs to go
whereas the keyboard or AT user must use multiple keystrokes to achieve
the same goal.

Mike Fratkin
SSA

Peter Korn wrote:

I think we should be careful with the word "focus", which generally
means "where keyboard input will go". This makes sense for something
like a search input box, but no the static text indicating the number of
hits.

What I think is wanted is a way for E&IT to indicate to AT that
"something new and interesting has happened here; you might want to
convey it to your user". What I think we don't want is for E&IT to
explicitly drive AT - that gets us into the dangerous territory of
designing for specific AT (e.g. this is what you need to do to make JAWS
say "number of search hits: 20").

We deal with this situation in the UNIX & Java worlds by giving things
the role STATUS_BAR, with the convention that screen readers will in
most cases want to read changes in the status bar to the user (there is
an event we fire in UNIX/Java to indicate that text has changed). A
user wanting less verbosity, or a custom script in the screen reader for
that app may then not speak those changes; but the information is there
for the user & AT to make that determination.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: Monday, October 30, 2006 12:31 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group A: 21(c) Keyboard focus

Mike Fratkin wrote:
> I believe that we do need to make this provision broader. An aspect
> that needs to be considered is not just the fact of a well-defined
> focus, but where the focus should be in specific situations to be most

> beneficial to a person with a disability.
>
> As mentioned previously, in Search functions, the results of the
> Search is most important and focus seems to vary from application to
> application. It is generally at the top of the page, sometimes in the

> Search input box but hardly ever focused on the number of hits or
> indicating to the user that there were no hits.
>
> For error handling, indicating the number of errors on a page and
> guiding the user to the error fields is again an issue of focus and
> needs to be considered. Additionally, Help screens where there are
> frames with a table of contents in one frame and the actual contents
> in another frames is also an issue of focus. When a item is selected
> in the left or table of contents frame, typically, the right frame or
> content changes. However, the actual focus stays on the left frame
> and a screen magnification user would never know that something had
changed.
>
> So, it seems like focus issues so need a much broader attention.
>


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
> Snow-Weaver
> Sent: Friday, October 27, 2006 9:27 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [teitac-websoftware] Group A: 21(c) Keyboard focus
>
>
> 21(c) current wording:
>
> A well-defined on-screen indication of the current focus shall be
> provided that moves among interactive interface elements as the input
> focus changes.
> The focus shall be programmatically exposed so that assistive
> technology can track focus and focus changes.
>
> ISO has two provisions that address this issue: "Software shall
> provide a focus cursor that visually indicates which user interface
> element currently has the keyboard input focus, as well as the focus
> location within that element when one exists." ISO does not contain a
> provision specifically addressing programmatic exposure of keyboard
> focus but it does include one that requires using system standard
> input and output services. If you use standard input services, doesn't

> that imply that the keyboard focus is programmatically exposed?
>
> ISO does have a provision on event notification which would cover
> keyboard focus changes and all other type of user interaction events:
> "Software shall provide assistive technology with notification of
> events relevant to user interactions."
>
> It includes the following expanatory note:
>
> Events relevant to user interaction include, but are not limited to,
> changes in user interface element status (such as creation of new user

> interface elements, changes in selection, changes in focus and changes

> in position), changes in attributes (such as size, colour and name),
> and changes of relationships between user interface elements (such as
> when one user interface element contains, names, describes or affects
> another). Just as important are input events, such as key presses and
> mouse button presses, and output events, such as writing text to the
> screen or playing audio information. This also applies to user
> interface status values (such as the states of toggle keys).
>
> Do we want to make 508 broader and more comprehensive in this area?
>
> This function is not required by 508 for Web content and applications
> (1194.22). Do we need to add this for Web content and applications?
> WCAG 2.0 does not contain such a provision.
>
> Andi
>
>

From: Jim Thatcher
Date: Mon, Oct 30 2006 10:46 AM
Subject: Re: Group A: 21(c) Keyboard focus

Andi quoted the current wording:
<blockquote>
1194.21(c) A well-defined on-screen indication of the current focus shall be
provided that moves among interactive interface elements as the input focus
changes. The focus shall be programmatically exposed so that assistive
technology can track focus and focus changes.
</blockquote>

And asked:
"Do we want to make 508 broader and more comprehensive in this area?"

And Don added:
"At least to my knowledge, it isn't testable or measurable"

I think that this provision (1194.21(c)) is fully testable and says what it
should. Furthermore it is one of the most important accessibility
requirements for all kinds of disabilities. This is talking about input
focus. When an interactive element receives focus, that fact is indicated by
a dotted rectangle or highlight and that fact can be programmatically
detected.

Testability is not necessarily automatic; not necessarily easy.

Peter Korn writes:
"What I think is wanted is a way for E&IT to indicate to AT that "something
new and interesting has happened here; you might want to convey it to your
user"

Sure - but that is a different situation from the requirement here - current
input focus, so important for all users who don't use a pointing device.

Jim
Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: Peter Korn
Date: Mon, Oct 30 2006 12:20 PM
Subject: Re: Group A: 21(c) Keyboard focus

Mike wrote:
> I agree for the most part, but it is not always strictly an AT issue.
> If I am a keyboard only user, it would be helpful and again more
> comparable or efficient to have the focus positioned at the logical
> point of attention. This could be the "hits" or the number of errors.
> The sighted mouse user can go directly to where he/she needs to go
> whereas the keyboard or AT user must use multiple keystrokes to achieve
> the same goal.
>

If the static text (in this example - the "hit count") can be
manipulated in some way - e.g. copied to the clipboard to be pasted
somewhere else - then I would think 1194.21(a) would hold sway here, and
I would think keyboard focus is appropriate. But if the information is
only for reading and not copying or other manipulation, then why should
keyboard focus go there? You write "...have the focus positioned at the
logical point of attention..." Unless I'm using AT like a screen
reader, to move the 'point of regard' (e.g. with flat review of JAWS),
why would you want keyboard focus on a read-only piece of text?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Sailesh Panchang
Date: Mon, Oct 30 2006 1:45 PM
Subject: Re: Group A: 21(c) Keyboard focus

Andi quoted the current wording:
<blockquote>
1194.21(c) A well-defined on-screen indication of the current focus shall be
provided that moves among interactive interface elements as the input focus
changes. The focus shall be programmatically exposed so that assistive
technology can track focus and focus changes.
</blockquote>
I think re-stating the above as follows will make it more understandable and
easier to interpret. Suggestion:
"(c) A well-defined on-screen indication shall be provided for every
interactive interface element as it gains input focus. The focus shall be
programmatically exposed so that assistive technology can track focus and
focus changes. "
The Guide states:
The position on a screen where an action will take place is referred to as
the "focus". For example, when a menu item in a program is highlighted -
meaning that if the user clicks the mouse or presses the enter key - the
feature will activate and that item has the focus. Providing a visual
indication of the focus allows someone who is viewing the screen to
accurately access the programs' features.
This is in line with Jim's assessment:
>This is talking about input focus. When an interactive element receives
>focus, that fact is indicated by a dotted rectangle or highlight and that
>fact can be programmatically detected.

My understanding is that this standard apparently does not have anything to
do with helping users locate the search results after hitting the search
button or identifying form controls that fail validation upon form
submission, etc.

Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =

From: Hoffman, Allen
Date: Mon, Oct 30 2006 2:40 PM
Subject: Re: Group A: 21(c) Keyboard focus

"My understanding is that this standard apparently does not have
anything to do with helping users locate the search results after
hitting the search button or identifying form controls that fail
validation upon form submission, etc."

I don't think it doesn't say that such focus changes have to occur, and
one can always argue that if the software or web author wants to leave
focus somewhere inappropriate it can be done, but if the visual focus,
for example the error message with a big OK button doesn't gain focus,
it should, and the change and new location should be exposed.

I like the rewrite however, it is the "gaining of focus" that is the
challenge so many times.

"(c) A well-defined on-screen indication shall be provided for every
interactive interface element as it gains input focus. The focus shall
be
programmatically exposed so that assistive technology can track focus
and focus changes. "

I still think it may be possible to just combine C and D to make one
standard to cover focus, identity, state, operation, and "content" as
they are all attributes in accessibility API(s). Or, one might just
write one for each, focus, identity, operation, state, and "content".

Of course we might also consider setting minimum standard for what is an
accessibility API. If you have an API that doesn't include the minimum
requirements, can it be considered valid for AT's usage? This might go
a long way towards harmonizing the multiple API(s) out there, e.g. set
the basic levels and then allow extensions.




Allen Hoffman
Department of Homeland Security
Office on Accessible systems & Technology

From: Jim Thatcher
Date: Mon, Oct 30 2006 4:05 PM
Subject: Re: Group A: 21(c) Keyboard focus

Allan Hoffman said:
"I still think it may be possible to just combine C and D to make one
standard to cover focus, identity, state, operation,..."

The requirement for identity, state, and role information (ll94.21(d))is
independent of focus tracking( ll94.21(d)). Once you know the focus object,
because of focus tracking, you can find out the information about that
object.

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman,
Allen
Sent: Monday, October 30, 2006 3:27 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group A: 21(c) Keyboard focus

"My understanding is that this standard apparently does not have
anything to do with helping users locate the search results after
hitting the search button or identifying form controls that fail
validation upon form submission, etc."

I don't think it doesn't say that such focus changes have to occur, and
one can always argue that if the software or web author wants to leave
focus somewhere inappropriate it can be done, but if the visual focus,
for example the error message with a big OK button doesn't gain focus,
it should, and the change and new location should be exposed.

I like the rewrite however, it is the "gaining of focus" that is the
challenge so many times.

"(c) A well-defined on-screen indication shall be provided for every
interactive interface element as it gains input focus. The focus shall
be
programmatically exposed so that assistive technology can track focus
and focus changes. "

I still think it may be possible to just combine C and D to make one
standard to cover focus, identity, state, operation, and "content" as
they are all attributes in accessibility API(s). Or, one might just
write one for each, focus, identity, operation, state, and "content".

Of course we might also consider setting minimum standard for what is an
accessibility API. If you have an API that doesn't include the minimum
requirements, can it be considered valid for AT's usage? This might go
a long way towards harmonizing the multiple API(s) out there, e.g. set
the basic levels and then allow extensions.




Allen Hoffman
Department of Homeland Security
Office on Accessible systems & Technology

From: Hoffman, Allen
Date: Tue, Oct 31 2006 6:20 AM
Subject: Re: Group A: 21(c) Keyboard focus

Allan Hoffman said:
"I still think it may be possible to just combine C and D to make one
standard to cover focus, identity, state, operation,..."
Jim Thatcher said
"The requirement for identity, state, and role information
(ll94.21(d))is independent of focus tracking( ll94.21(d)). Once you know
the focus object, because of focus tracking, you can find out the
information about that object."

Agreed.

I'm not particularly attached to combining these all, I'm just thinking
of them as interface element attributes that are generally set and
identifiable as a set. With a linear testing method, e.g. using
inspector or screen reader, you can use the focus as the "grabber" for
each element, and then enumerate the attributes. If this logic is
followed, then if C fails, D fails as well, right? Then I'm kind of
back to the combined approach. I suppose the problem with a combined
approach is that it really is a (or) test, if (not) focus (or) identity
(or) operation (or) state then test-fails; but we don't know which
failed at that point. maybe this could be broken down like the telecomm
keyboard standard K(1-4) items are, so that it is clear.

Allen Hoffman
Department of Homeland Security
Office on Accessible Systems & Technology


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
Thatcher
Sent: Monday, October 30, 2006 6:03 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Group A: 21(c) Keyboard focus

Allan Hoffman said:
"I still think it may be possible to just combine C and D to make one
standard to cover focus, identity, state, operation,..."

The requirement for identity, state, and role information (ll94.21(d))is
independent of focus tracking( ll94.21(d)). Once you know the focus
object, because of focus tracking, you can find out the information
about that object.

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Hoffman, Allen
Sent: Monday, October 30, 2006 3:27 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group A: 21(c) Keyboard focus

"My understanding is that this standard apparently does not have
anything to do with helping users locate the search results after
hitting the search button or identifying form controls that fail
validation upon form submission, etc."

I don't think it doesn't say that such focus changes have to occur, and
one can always argue that if the software or web author wants to leave
focus somewhere inappropriate it can be done, but if the visual focus,
for example the error message with a big OK button doesn't gain focus,
it should, and the change and new location should be exposed.

I like the rewrite however, it is the "gaining of focus" that is the
challenge so many times.

"(c) A well-defined on-screen indication shall be provided for every
interactive interface element as it gains input focus. The focus shall
be
programmatically exposed so that assistive technology can track focus
and focus changes. "

I still think it may be possible to just combine C and D to make one
standard to cover focus, identity, state, operation, and "content" as
they are all attributes in accessibility API(s). Or, one might just
write one for each, focus, identity, operation, state, and "content".

Of course we might also consider setting minimum standard for what is an
accessibility API. If you have an API that doesn't include the minimum
requirements, can it be considered valid for AT's usage? This might go
a long way towards harmonizing the multiple API(s) out there, e.g. set
the basic levels and then allow extensions.




Allen Hoffman
Department of Homeland Security
Office on Accessible systems & Technology

From: Jonathan Avila
Date: Tue, Oct 31 2006 6:40 AM
Subject: Re: Group A: 21(c) Keyboard focus

"[Don Barret wrote] The whole notion of programmatically exposed has always
proven to be a real problem in 508 implementation and testing. At least to
my knowledge, it isn't testable or measurable and without those qualities,
any standard is worthless. Remember, we are not designing a utopia nor are
we defining what the perfect world of accessibility would look like in web
and software. We are refreshing a Federal standard which must be
reasonable, meetable, measurable, and understandable.

[my comments] Testing for programmatic focus is very testable. Programmatic
focus can be exposed through several means. Depending on the type of
software and the platform different means can be used to verify programmatic
focus is being exposed. For example, in a win32 application focus is
exposed through standard APIs such as setFocus and drawFocusRect. In an
MSAA application focus is exposed through events and states. In JAVA focus
is exposed through events and states that are fed through the access bridge.
On web pages methods such as focus() are used and translated by the browser
into MSAA and API level programmatic focus.

"[Don Barret wrote ] What are standard input/output services? Does that
mean using only MFC controls? Does it mean only using OS calls? If we can
define these, I think they re very very relevant, but the phrase itself is
just too generic."

[my comments] I'm also concerned about the term input. While all people
may realize an edit field is an input control, some people might not assume
a button is also an input control. I prefer the term interactive components
to input.

Jonathan

From: Jim Thatcher
Date: Tue, Oct 31 2006 8:45 AM
Subject: Re: Group A: 21(c) Keyboard focus

Allan Hoffman: "If this logic is followed, then if C fails, D fails as well,
right?"

I don't think so. It is easy to have objects properties available (d) and
have the focus (c) broken.

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931