[Accessibility] Keyboard Access Gap Analysis

Bill Haneman Bill.Haneman at Sun.COM
Wed Sep 7 10:34:17 PDT 2005


earlj-home wrote:

> Here's a first draft. The FSGA-Kbd work hasn't had a chance to review 
> it yet. The format is .html.
>
> Earl
>
> ------------------------------------------------------------------------
>
>
>     Keyboard Access Gap Analysis, 090705
>
> The following identifies functionality difference between the FSGA 
> Keyboard Access Functional Specification and the same type of 
> functionality supported on Windows [the standard users will judge our 
> work against, I suspect Conformance testers will have nuetral opinions].
>
>    1. Global named features
>
Don't understand what is meant by 'Global named features'.  How about 
saying that "Some non-feature-specific controls are not global in their 
effect; spefically, the following controls affect only Sticky Keys  and 
Slow Keys".

>    1. don't affect all the keyboard access features, they only apply
>       to Sticky- and SlowKeys. The following functionality
>       highlighting this was extracted from Table 1:
>
>   1.
>       7.3. Provide a means of enabling the keyboard shortcuts for
>       StickyKeys and SlowKeys to be turned on/off; turning this
>       functionality off turns the features off and disables the
>       keyboard shortcuts.
>       7.4. Provide a time-out option that turns StickyKeys and
>       SlowKeys off automatically after a specified period of time
>       without keyboard activity; invoking StickyKeys or SlowKeys from
>       the keyboard must over-ride this feature.
>       7.5. Provide a never time out option for StickyKeys and
>       SlowKeys. It is strongly recommended that this functionality
>       cover all keyboard access features provided in the
>       implementation, not just for StickyKeys and SlowKeys
>
>    2. A specific keyboard gesture [key sequence] for turning MouseKeys
>       and RepeatKeys on or off is not defined [See Table 2, item 2].
>
Please add ""though a defacto standard sequence is available by 
convention)."

>   1.
>
>
>    2. The specification requires features to provide an audible signal
>       for various states provided in each feature. The functionality
>       defined in the FSGA specification that is required to generate a
>       signal is consistant with that provided on Windows. The
>       difference here is other platforms provide up and down tones to
>       signify states while the FSGA specification can only specify
>       beeps. Originally we defined both but removed the up/down tones
>       due to XKB's minimal audible support. [See Table 2, item 2].
>
"minimal audible support" ? 

I think we should just say that "because some otherwise compliant target 
platforms cannot support the generation of tones in multiple pitches,  
we omitted references to the pitch of audible signals from our spec".

>
> The following functionality is supported by XKB however we removed it 
> from the FSGA specification.
>
>    1. SoundSentry. The functionality bflashes the screen when a system
>       beep is sounded, it targets users with hearing disabilities.
>       Removing this support was a controversial decision. It was
>       originally included because our spec is based on XKB and it
>       didn't rightly land in the realm of other FSGA efforts. We
>       removed the functionality because it doesn't apply to keyboard
>       access and it only works when the system bell [beep] signals.
>
Don't call it SoundSentry, since such a thing does not exist in XKB.  
Call it "visual bell" please.

I would prefer to re-word this last point.

Bill

>------------------------------------------------------------------------
>
>_______________________________________________
>Accessibility mailing list
>Accessibility at freestandards.org
>http://mail.freestandards.org/mailman/listinfo/accessibility
>  
>




More information about the Accessibility mailing list