[Accessibility] DRAFT for Review: Keyboard Access Func. Spec v0.75 and Generic Test Assertions v0.25

earl johnson Earl.Johnson at Sun.COM
Mon Oct 24 09:35:00 PDT 2005


Hi All;

Below is a summary of the changes that were made to the "Keyboard 
Access Functional Specification v0.76" and "Generic Assertions 
for Manual Testing, v0.25" documents. The updates include 
integrating feedback from Gunnar and Bill and our discussions on 
the gap analysis has been factored in, and some editing updates 
were also made. Editing comments and other feedback welcome, if 
things go right, the resulting edited version from this review 
will be our release candidate. Please send comments by 11/4.

Please review the autogenerated HTML version of the documents 
[URLs below], the autogenerated PDF munges the section numbering 
beyond understanding.

Thanks, Earl


Keyboard Access Functional Specification v0.76:
http://accessibility.freestandards.org/a11yspecs/kbd/AccessX-func-spec.html

Generic Assertions for Manual Testing, v0.25:
http://accessibility.freestandards.org/a11yspecs/kbd/AccessX-func-test-asserts.html


-------------

Summary of the Latest Edit to Functional Spec and Generic Test 
Assertions, 10/17/05

1. Added the following footnote to items 7.4,7.5,7.6 in the
functional spec only: "Common practice today is this
functionality turns off all the keyboard access features. This
specification does not go this far because the ABI this
specification is guided by, XKB, does not provide this support.
	PROBLEM NOTE: I followed formating guidance for
	 footnotes however couldn't get Epic, Sun's Docbook
	 editor, to display them.

2. Adopted 0.2 char/sec. repeat rate

3. Made the following edit to 7.4:
"... without keyboard activity; it still must be possible to turn
StickyKeys or SlowKeys on from the keyboard when this feature is
turned on. "

4. Placed a "Visual Bell" requirement 7.3. in the functional spec
and general test assertions [added requirement and associated tests].

5. Made changes to the treatment of audible signals in both
documents. In the FSGA discussions I think we kind of agreed to
define what gets sounded if beeps or up/down signals get
generated. I decided to define qualities audible signals must
meet instead of defining sounds to imply the spec doesn't care if
beeps or up/down tones or ? are used, only that their meaning are
understandable.
	a. Added a general section, 3.1., that defines how
	 feature and functionality on/off signals sound.
	b. Gathers in all the audible signal items introduced in
	 table 1 of the functional spec.
	c. Changed the text in table 2, item 3. to "Provide an
	 audible signal that indicates when a keyboard access
	 feature or feature functionality has changed state.
	d. In generic test asserts just pointed to existing test
	 asserts for table 1 instead of copy paste for following
	 new audible signal test asserts, they point to
	 T1 - 4.2, 4.3, 4.4, 4.5, 5.2 tests.

6. Moved the Overview section's content into the "What this Spec
Defines" section.





More information about the Accessibility mailing list