Thread Subject: Re: Section 31A - May 30 Draft
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 Wallack
Date: Sun, Jun 03 2007 11:15 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Hoffman, Allen: "Re: Section 31A - May 30 Draft"
- Previous message in thread: Tom Brett: "Re: Section 31A - May 30 Draft"
- Messages sorted by: Author | Thread | Date
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
Amen!!! To add to the issue, also consider when those applications are
translated (often automatically in the case of very large apps), and
then the number of unused keystroke combinations dwindles to just
about nothing. We have struggled with this problem, even to the extent
of - gasp! - experimenting with *removing* access keys when running in
'accessible' mode just to avoid the potential for conflicts. Clearly
not the direction the standards should be forcing us to go.<br>
<pre class="moz-signature" cols="72">Peter Wallack
Accessibility Program Director
Peter Korn wrote:
<blockquote cite="mid: = EMAIL ADDRESS REMOVED = " type="cite">
<pre wrap="">Hi Tom,
Asking mainstream software developers to find all of the keystroke
combinations used by all AT products (and all scripts of all AT
products, in all versions of those products) in order to avoid them is
untenable. There are simply too many possibilities for them to be aware
of, test with, etc.
Drawing the line at AT that comes with the platform (e.g. StickyKeys,
VoiceOver) makes sense to me. If the platform were to further work out
conventions with AT vendors and then publish those conventions (e.g. the
use of INS as a modifier key might be reserved for AT), it would further
make sense to me to put that "inside the line".
But I don't see how we can reasonably ask mainstream software to know
all of the keystrokes that all releases of AT in all use cases (e.g.
scripts) use so as to avoid using them in their own application. Also,
think about the reverse - what if a new release of your favorite AT
starts using a keystroke that a mainstream application has been using
for years. Should we now invoke 508 to strip that keystroke from that
application? We wouldn't think it right to require AT products to
canvass all mainstream applications in order to find out which
keystrokes are fair game...
Sun Microsystems, Inc.
<pre wrap="">The following provision was copied from the WIKI:
Applications shall not disrupt or disable activated features of other
products that are identified as accessibility features, where those
features are developed and documented according to industry standards.
Applications also shall not disrupt or disable activated features of
any operating system that are identified as accessibility features
where the application programming interface for those accessibility
features has been documented by the manufacturer of the operating
system and is available to the product developer.
Does the first sentence of this provision mean that I cannot develop
an application that disables a key combination unique to Jaws, such as
CNTL + ALT + RIGHT ARROW? Are assistive technology software
applications considered to be an industry standard even though these
AT applications are not considered by most developers to be mainstream?
I have talked to developers who feel that they can assign a function
to any key combination as long as it does not override a windows
documented accessibility feature. If they choose to use the CNTL +
ALT + RIGHT ARROW they have removed my ability to read table data.
What is the intent of this provision?