Thread Subject: Re: Problems on Call

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: Jim Tobias
Date: Thu, Jan 04 2007 2:20 PM

Did this call happen? I was on hold....

Anyway, I thought I would put my answers to some of the questions from the
topic list.

***

* Should keyboard short cuts be required on every step of a process
listed in the documentation.

Not if such guidance would be repetitive. For example, every time you want
to access the "File" menu in Windows you can press ALT+F. Do I want to see
that for every item in the File submenu? No. But all application-specific
shortcuts should be available in one place for easy reference, and peppered
throughout the documentation as needed.

* Within documentation, what accessibility and compatibility features
are included in the product and how they can be modified.

Not sure if this is a proposal or a re-statement of the current standard.
The current standard only talks about having the accessibility/compatibility
features available in alternate formats; clearly, this needs to be
clarified. I support such a list as part of an enhanced VPAT, and the same
list should appear in product documentation. Going beyond this, I would
like to see the use of standard terminology, so that whenever a product
claimed a feature (e.g. "a display that can be enlarged") we have a way of
understanding what's actually there and how it compares with another
product. This approach would be consistent with the WAI's concept of
"sufficient techniques", a non-exhaustive list of ways to meet the relevant
standard -- clear guidance to developers, clear product information to
purchasers.

* Cognitive issues in documentation

Lots of good data on reading level, etc. How about a standard that requires
documentation to be written so that it can be understood by the users for
which the product was intended? There's a problem with that, because there
are always "unexpected users". But it provides at least some guidance:
college level is okay for documenting a programming language, but not okay
for documenting a copier.

* When products have visibly discernible landmarks, how should these
be included in the documentation.

Important! How about a standard that says if there is a diagram of the
product, then there should be a corresponding description of the physical
layout





_____

From: Jennifer Dexter [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, January 04, 2007 3:43 PM
To: TEITAC documentation and technical support subcommittee
Subject: [teitac-documentation] Problems on Call



We are having some difficulty on the line. Stay tuned to e-mail for
updates.



Jennifer Dexter

Assistant Vice President, Government Relations

Easter Seals

1425 K Street, N.W.

Suite 200

Washington, DC 20005

202-347-3066

Fax: 202-737-7914



Please note change of address effective 6/26/06:



Be an angel of change. You can change the lives of people living with
disabilities. Earn your wings at http://www.easterseals.com
<http://www.easterseals.com/> ..


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Michele
Budris
Sent: Tuesday, January 02, 2007 4:52 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-documentation] Meeting Reminder: Thursday, Jan 4, 1:30pm ET




Documentation and Tech. Support Meeting


Date: 1/4/2007
Time: 1:30 PM - 2:00 PM Eastern Time

Details, Including captioning information and agenda are located on the WIKI
at http://teitac.org/wiki/Documentation:January_4



The phone number is (866)839-8145 and the International Access/Caller Paid
Dial In Number: (865)524-6352

The access code is 9395871#

RCC code is 62989. http://www.fedrcc.us//Enter.aspx?EventID=629898
<http://www.fedrcc.us/Enter.aspx?EventID=629898>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University