Re: Comments and Recommendations

Janina,
I too want the tool developer to make the help accessible.  And I want the help
to include a listing of the keyboard commands.  And, more importantly, I want
the tool itself [with and without the help] to be accessible, to be usable with
a screen reader or magnifier.

Janina wrote:
>What is so problematic about specifying
>this requirement? Is it less elegant? Is it ... well, let me not speculate,
>but simply ask. What's wrong with putting this in the reqs? And, if it
>doesn't go there, where does the industry get its check list of "required
>things" to fix?

It is problematic to list all the checklist requirements for software
accessibility.  First of all "accessible help" is only one of over a dozen
requirements on the Microsoft Windows checklist.  Enabling keyboard access to
all the functions of the tool is the first requirement on the checklist.
Another very important requirement is exposing the focus, another is adding
captions for sound, so I suppose we could start with the Microsoft list and add
them *all* to the authoring tools list.  But what if the tool is written in
Java, of course we would want them to follow the IBM guidelines for accessible
Java applications.  And what if the tool is on Unix, or OS/2, or AIX, or
Linux...  For the same reason we didn't list all the Web Content Accessibility
Guidelines checkpoints, but referred to them.  Checkpoint 7.1 does a good job
pointing to all the "applicable standards and checklists".  As evidence that a
tool developer would use 7.1 correctly, two IBM tool developers read 7.1 and
then sent me the applicable checklist [in this case it was the Microsoft Windows
checklist] with each checklist item marked yes or no and included comments about
if or when they could meet the requirement.  This was done for the whole
authoring tools checklist as well as the whole windows accessibility checklist.
The Microsoft Windows and IBM Java checklist item about "accessible help" are
very adequate and cover all the requirements for accessible help :

[1] Documentation
     Provide documentation in accessible format, such as ASCII text or HTML.
     Accessible documentation should contain descriptions of illustrations and
tables.
     Do not convey important information by color or graphics alone. Use color
and graphics redundantly to the text.
     Maintain high contrast between the text and its background.
     Do not use text smaller than 10 points in size.
     If possible, bind printed documentation to lie flat.

[2] 9.0 Documentation
     9.1 Provide clear and precise documentation on all accessibility features.
     9.2 Provide documentation in an accessible format, such as ASCII text or
HTML.
>
> [1] Microsoft software checklist
> http://www.microsoft.com/enable/dev/guidelines/software.htm#Documentation
> [2] IBM Software checklist
> http://www.austin.ibm.com/sns/accessjava.html#checklist
>

If you feel the Windows or Java or xxx checklist needs to be improved please
contact the appropriate owner, because I want the checklist improved not just
for authoring tools, but all applications that fall under that checklist.

Regards,
Phill Jenkins

Received on Wednesday, 6 October 1999 09:49:56 UTC