Thread Subject: Re: Section 31A - May 30 Draft
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: Tom Brett
Date: Sun, Jun 03 2007 6:05 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Peter Wallack: "Re: Section 31A - May 30 Draft"
- Previous message in thread: Peter Korn: "Re: Section 31A - May 30 Draft"
- Messages sorted by: Author | Thread | Date
Guess I did miss that email. I was looking at the provisions on the WIKI
for this item and did not see a comment. I thought this was where the
latest comments/suggestions were to be posted.
>>'If I'm not mistaken, most AT allow you to change the keystroke
combinations used for specific commands, which is a not unreasonable way to
address this I think.'
Correct. Now looking at this from the stand point of member of the public
attempting to access public information...when I attempt to access public
information and find that my key combinations do not work would it be
necessary to have a place to go to determine if the Government has assigned
that key combination a different meaning?
Perhaps the EWG 7.1 May 30 Draft
(http://teitac.org/wiki/EWG:Draft_May_30#7._Information.2C_Documentation_and
_Support) would need to be clarified to make it clear that Documentation and
Support provisions needs to be made available to the public if the
application is publicly available. The Documentation & Support -1194.41-
provisions in the current standards generally are viewed as applying only to
Government employees.
When a person using AT finds that their key combination does not perform the
way that the AT has defined it, they would need to go to the
Help/Documentation/Support link, find that their key combination has been
assigned a different function and take the appropriate action to change the
key combination for their AT. This would add an additional level of
complexity for a person with disabilities to access Government E&IT but
would work, although that would seem to conflict with the Comparable access
provision. It would also tend to limit people with cognitive impairments
accessing public information by adding this additional step.
Tom Brett
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Saturday, June 02, 2007 9:40 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Section 31A - May 30 Draft
Tom,
Did you miss my e-mail yesterday with suggested language for this
provision? See
http://teitac.org/mailarchives/mail_message.php?id=4738&listid=3 for the
message. Basically my suggestion is that we greatly simplify this text, to:
"Applications shall not disrupt or disable documented accessibility
features of the platform."
If we want to clarify this further, we might add a second sentence:
"This includes, but is not limited to, system-wide keyboard
enhancements and assistive technologies includes with the platform."
I think the question of what to do when AT and a specific application
conflict must be solved by getting one of them to change. If I'm not
mistaken, most AT allow you to change the keystroke combinations used for
specific commands, which is a not unreasonable way to address this I think.
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> I agree, Peter, that it is unreasonable to ask developers to know all key
> combinations.
>
> I know this provision is has not been rewritten and that is why I am
asking
> the questions. The first sentence would imply, though, that if a
developer
> used a specific Jaws key combination that disabled my AT key combination
the
> software would not meet Section 508 standards for this provision.
>
> So what if the first sentence of the provision were written:
>
> Applications shall not disrupt or disable activated features of other
> products that are identified as accessibility features for the platform on
> which it is designed to run, where those features are developed and
> documented according to industry standards.
>
> Then the question arises on how do I use my AT when the key combination I
> require to perform my duties has been disabled. Perhaps the use of an API
> to facilitate a flexible key combination assignment would be the answer.
>
> Tom Brett
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
> Sent: Saturday, June 02, 2007 9:00 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Section 31A - May 30 Draft
>
> 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...
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>> 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?
>>
>>
>>
>> Tom Brett
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
- Next message in Thread: Peter Wallack: "Re: Section 31A - May 30 Draft"
- Previous message in Thread: Peter Korn: "Re: Section 31A - May 30 Draft"