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

From: Jim Thatcher
Date: Mon, Oct 30 2006 4:05 PM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Hoffman, Allen: "Re: Group A: 21(c) Keyboard focus"
• Previous message in thread: Hoffman, Allen: "Re: Group A: 21(c) Keyboard focus"
• Messages sorted by: Author | Thread | Date

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

• Next message in Thread: Hoffman, Allen: "Re: Group A: 21(c) Keyboard focus"
• Previous message in Thread: Hoffman, Allen: "Re: Group A: 21(c) Keyboard focus"