Thread Subject: Re: Problems on Call
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
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Jennifer Dexter: "Re: Call"
- Previous message in thread: Jennifer Dexter: "Problems on Call"
- Messages sorted by: Author | Thread | Date
Did this call happen? I was on hold....
Anyway, I thought I would put my answers to some of the questions from the
* 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
* 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
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
Assistant Vice President, Government Relations
1425 K Street, N.W.
Washington, DC 20005
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
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Michele
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
Time: 1:30 PM - 2:00 PM Eastern Time
Details, Including captioning information and agenda are located on the WIKI
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