Documentation:Draft Submission
Documentation > Draft Submission
This is a working copy of what will be submitted to the Access Board.
I. Material which can be described as “Changes to Existing Provisions”
- Modification – Material which modifies existing provisions.
- Rationale – Why is this change suggested?
| Current provision | Keep current language | Change Group? | Modification | Rationale: Why is this change suggested? |
|---|---|---|---|---|
| (a) Product support documentation provided to end-users shall be made available in alternate formats upon request, at no additional charge. | No | No | In progress | Is currently being interpreted in various ways, need to make more clear. |
| (b) End-users shall have access to a description of the accessibility and compatibility features of products in alternate formats or alternate methods upon request, at no additional charge. | No | No | In progress | Is currently being interpreted in various ways, need to make more clear. |
| (c) Support services for products shall accommodate the communication needs of end-users with disabilities. | No | No | NOTE: since this was discussed in the March 8 meeting and agreed to not be added here, it will not be in the submitted first draft.
From Barbara Lybarger: (c) Technical support shall be delivered in a manner that is functional for requesters with disabilities, such as: 1. appropriate telecommunication media, including but not limited to TTY, relay service, and video conference, and 2. instructions utilizing command structures appropriate to the disability of the requestor, including but not limited to keyboard equivalents required under S1194.21(?) and S22(?). | NOTE: since this was discussed in the March 8 meeting and agreed to not be added here, it will not be in the submitted first draft.
From Barbara Lybarger: This would create minimum levels for accessibility of the communication itself and of actual content of the support. |
II. Entirely New Provisions
| New provision | Rationale: What issue does this provision address? |
|---|---|
| RECOMMENDATION SUMMARY: The Documentation Subcommittee recommends that the Access Board clarify when and how keyboard shortcut information should be made available in documentation. This is important both for the final user and for providers of technical assistance who rely on the documentation to get information about things like keyboard shortcuts when a user with a disability calls and needs that information.
RECOMMENDED LANGUAGE: 1. All shortcuts for keyboard operation shall be enumerated in one place for easy reference. 2. When documenting specific mouse based actions, the keyboard commands shall be listed. Best Practice: The purpose of these points is to ensure someone using the keyboard as a primary device has a complete set of instructions and doesn't have to look in a separate reference table for the information. | |
III. Other Material
A. Recommendations on organization of the provisions
B. Issues this subcommittee is not addressing, but which should be addressed.
Is it possible or appropriate to ensuring that any training or technical support provided accommodates the functional capabilities of all participants and provides meaningful support. This can include not only accessibility needs of individuals with disabilities (as participants or trainers) and means of communicating with individuals with disabilities before and after training, but also commonly used adaptive technology used with the manufacturers and provider's E&ITs; and Solutions for accessibility and compatibility.
NOTE: The following comments from Jim Tobias were added March 9 and not discussed by the committee so they will not be included in the first draft.
From Jim Tobias: In the presentation on Cognitive Disability, it was said that remote assistance for computer software and hardware was a helpful feature. That is, the user can contact someone over a network who can log into the user's computer and either show him/her what needs to be done, or actually make those necessary changes remotely. Do we want to include such a requirement?
From Jim Tobias: Context-sensitive help is another important feature. For example, pressing F1 in some computer applications launches a help window that is already focused on what the user is trying to do.
