Dec 11 2007 TEITAC 9C
Telecommunications and Electronic and Information Technology Advisory Committee
December 11, 2007
Provisions for Consensus Review
Conference Bridge, FEDRCC, and Hand raising tool information can be found on the following Access Board web pages:
http://www.access-board.gov/sec508/update-index.htm
http://www.access-board.gov/sec508/refresh/agenda.htm
3-B - Contrast
Version 1, from Oct 26 draft:
Presentation of text (and images of text) in electronic documents must have a default contrast ratio of at least 5:1, except if the text is unavailable items or pure decoration. Large-scale text (or images of large-scale text) can allow a contrast ratio of at least 3:1.
Rationale: Harmonization with WCAG 2.0.
Version 2, proposed text from Sun
Presentation of text (and images of text) must have a default contrast ratio of at least 5:1, except if the text is unavailable items or pure decoration. Large-scale text (or images of large-scale text) can allow a contrast ratio of at least 3:1.
Comments to be resolved:
Comments from "Work In Progress" List
Needs to be more general
Since have this should remove 3P User Preferences, and 3E Color Adjustment
Need to get agreement if the current text is acceptable
Not clear if this applies to web pages
Comment from ITI
This provision should be more general.
Comments from ITAA
- Precede with "Except for large-scale text,"
- The provision must clarify what is meant by "unavailable items?"
Comments from CSD/Trace Center
- Disagree that impact is significant. By having specific measurable criteria, it reduces ambiguity and make is faster and easier to evaluate. Cost to print things with high or low contrast is the same. Impact should be negative – cost savings from easier evaluation. No increase in cost for higher contrast.
- OK to do ITAA "Except for large-scale text" intro
3-D - User Preferences
Applications must provide a mode that utilizes platform settings for color, contrast, font type, font size, and focus cursor. In the absence of platform settings for color and contrast, all text (and images of text) must have a contrast ratio of at least 5:1 except for unavailable items or pure decoration. Large scale text (or images of large scale text) must allow a contrast ratio of at least 3:1.
- Note: Application software that is is also a platform would need to expose the underlying platform's color, contrast, and other individual display settings to applications running within its platform, so that these applications can meet the User Preferences provision.
Rationale: In the current 508 provision, the phrases "shall not override" and "other display attributes" are vague and raise testability issues. The reworded provision clarifies that the application should utilize a definitive list of display settings. The reworded provision also requires a minimum contrast for scenarios where the platform does not provide color and contrast settings. This is needed so that users requiring good contrast will be provided with at least a 5:1 contrast ratio in the software user interface. The contrast requirements are harmonized with WCAG 2.0 and with 3-B Contrast.
Comments to be resolved:
Comments from "Work In Progress" List
Suggest add definition for "unavailable items" Unavailable items are interface elements which can not be selected, or interacted with accept as read-only items on screen due to application state or other reasons.
Comments from ITAA
Vendors find this provision is unclear. Is this a requirement on the platform, the application, or the content, or all, or some?
3-E - Color Adjustment
When a product permits a user to adjust color and contrast settings, at least one color selection capable of producing a minimum luminosity contrast ratio of 7:1 must be provided.
EWG suggestion: When a user interface permits a user to adjust color and contrast settings, at least one color selection capable of producing a minimum luminosity contrast ratio of 7:1 must be provided.
Rationale: Current provision is weak and unfailable. If an application doesn't permit the user to adjust color and contrast settings, it passes. If it does permit the user to adjust them, the requirement to provide "a variety of color selections capable of producing a range of contrast levels" is so subjective that they all pass.
7-C - Prompts (Discussed Dec 4, No Consensus)
Authoring tools with a user interface must provide a mode which prompts authors to create accessible content.
- Note: It is neither expected nor possible that prompts be available for every type of accessible content.
Rationale: Note: The committee recommends that advisory techniques be available and linked from this provision, regarding how to provide guidance on effective methods of prompting, as well as techniques to avoid.
Notes from Dec 4 plenary call:
- Request to add "or be compatible with additional tools that provide this function.”
- Request to add “used in conjunction with”
- Request to make this a function that an administrator could turn on so that the tools be used.
1.1-A - Accessible Documentation and Features
Version 1, from Oct 26 draft: Documentation for users on the installation, configuration, or use of the product including the description, installation, and use of accessibility and compatibility features, must conform to the relevant accessibility provisions in 1194 Subparts B and C. This includes, but is not limited to, reports, system documentation, user help, and user training or technical support materials. Features included in the product specifically to meet accessibility requirements must be documented. The documentation must be available in alternate formats upon request.
Version 2, proposed by Karen PS to be consistent with the telecommunications guidelines
§1193.33
Documentation for users on the installation, configuration, or use of the product including the description, installation, and use of accessibility, usability, and compatibility features, must conform to the relevant accessibility provisions in 1194 Subparts B and C.
This includes, but is not limited to, reports, system documentation, user help, installation guides for end-user installable devices covered by Section 255, and user training or technical support materials. Features included in the product specifically to meet accessibility requirements must be documented. The documentation must be available in alternate formats or modes upon request and, for the purposes of Section 255, at no additional charge.
Rationale: This draft combines two provisions for a clearer requirement and adds a requirement to document the accessibility features of a product.
Advisory Note: There is an overlap between general features and features that support accessiblity. Guidance on how to choose what features to document includes:
- Anything that changes user preferences, keyboard commands, special accessibility features that the product supports (i.e., captioning), and features that allow users to adjust the product to their needs.
- Any features that are used to meet this standard or to enhance accessibility
- Any features identified when completing the VPAT
Comments to be resolved:
Comments from ITAA
Insert “documentation” between “This” and “includes” in the second sentence.
1.1 - NEW - Accessible Documentation
New provision proposed by ITAA
ITAA supports the inclusion of an additional category of documentation requirements under Standards 1194.41 that clarifies accessibility requirements for all documentation other than user documentation, and defines the accessibility requirement for such EIT deliverables. These documentation products include: program progress reports, qa/qc plans, program management plans, white papers, analyses, etc. Various agencies such as the VA, EPA, have stated that all documentation submitted under their funding will be accessible - is this the operative statutory requirement?
1.1-B - Keyboard Shortcuts
Version 1:
Information about keyboard shortcuts must be made available in documentation.
- All shortcuts for keyboard operation must be listed in one place for easy reference.
- When the documentation lists specific pointing device based actions, the keyboard commands must also be listed.
Version 2:
Information about keyboard shortcuts must be made available in documentation.
- Keyboard shortcuts unique to the product or content must be programmatically determined, listed in context-sensitive help, or listed centrally for easy reference.
- When the documentation lists specific pointing device based actions that are unique to the product or content, the keyboard commands must also be listed.
Version 3: Information about keyboard shortcuts not inherited from the operating system must be made available in documentation.
- Shortcuts for keyboard operation must be listed for easy reference in contextual help, a central location, or other online documentation.
- Shortcuts must be programmatically determinable for AT.
- When the documentation lists specific pointing device based actions that are unique to the product or content, the keyboard commands must also be listed.
Rationale: The documentation of keyboard shortcuts can be hard to locate. This provision would require that this information be available in a useful form.
Rationale for Version 2: The requirement for information being "in one place" has the potential to add a large volume of pages (1,000's), and is too prescriptive. It could also lead to requiring multiple versions of the documentation since one application that can run on multiple platforms encounters different keyboard shortcuts based on the platform.
Rationale for Version 3: Clarification
Comments to be resolved:
Comments from "Work In Progress" List
Still looking for a way to express this provision that will meet the needs of all users (for example allowing for inclusion in either contextual help or consolidated documentation.
Still looking for a way to address applications that run on multiple platforms which can result in different shortcuts for the same action. Comment from ITI
ITI supports Version 2.
Comments from ITAA
- ITAA endorses version 3.
- In list item 3, add "equivalent" before "keyboard commands"
Comments from Japan/Haijime Yamada
Suggest changing the expressiong "operating system" in 7.1 B version 3 to "platform software" since the later is defined in the Definitions.
1.1-X - Advisory Notes
Best practices for providing documentation to people with disabilities include:
- Context-sensitive help
- Context-sensitive help, which offers documentation or support for the features and functions of the current page, screen or window should be offered, using a consistent set of accessible commands to access it.
- Text descriptions
- Documentation and training materials should include text descriptions of the interface. These descriptions should stand on their own and be understandable without relying on graphic images in the materials.
- User interface descriptions
- Descriptions of a user interface should refer to elements by name or function, in addition to their location in the visual interface.
Comments to be resolved:
Comments from "Work In Progress" List
Proposal for a best practice entry for compatibility of assistive technology with the product, so vendors can include information as to which AT they work with, installation and configuration information. No conclusion was reach.
1.2 Support and E&IT related services
Was section 7.2 in Oct 26 draft
1.2-A - Support Services
Version 1: Help desk and technical support services must offer information on the both basic use of the product and the accessibility features of the product, as well as information on how to install and configure assistive technology to work with the product. These support services must accommodate the communication needs of users with disabilities.
Version 2: Help desk and technical support services must offer information on the accessibility features of the product. These support services must accommodate the communication needs of users with disabilities.
Version 3, proposed by Karen PS to be consistent with the telecommunications guidelines
§1193.33
Help desk, technical support, and customer support services provided by call centers and in-person service centers, must accommodate the communication needs of users with disabilities, where these services are otherwise provided by agencies or manufacturers,. For the purposes of Section 255, such services must be made available at no additional charge. These support services must be able to offer information on the basic use of assistive technology, as well as complete and accurate information on how to install and configure assistive technology for optimum performance.
Discussion or Rationale:
Rationale for Version 1: This version ensures that users have access to support for both the product and any assistive technology they are using in one place.
Rationale for Version 2: This version is more specific regarding the type of support required. It eliminates the phrase "installing and configuring AT" in Version 1. Vendors feel they should be giving support information about their own product, not the AT. This input was also received from the AT vendors.
Comments to be resolved:
Comments from "Work In Progress" List
Reworded to be more specific regarding the type of support.
Question about if it's the accessibility configuration of the product, or the configuration of the AT with the product.
Concerns regarding the phrase "complete and accurate information on how to install and configure assistive technology for optimum performance." Vendors should be giving support information about their own product, not the AT. Recommendation to make these best practices since it's not possible for vendors to test all of their products with all the possible AT and know how it should all be configured.
We were reminded that this provision applies to the agency and not the product manufactures. It was mostly agreed that this clarification should be added to the provision. Agencies can contract for these services, but are generally the ones doing the first line support.
More research is needed on how section 508 differs from section 255 with regards to this.
Comments from ITAA
For the situation where the agency has the vendor provide support vendors cannot "comply" with this without the AT knowledge
Comments from NASCIO:
Agency requirements do not belong in "technical requirements" to be applied to EIT products/services. This includes 1.2-A, 1.2-C, 5-A, 5-F (1) & (3), and 7.2-A. These might all be adopted as agency policies (perhaps with much more specificity applicable to implementation in that agency), but not as EIT technical standards.
1.2-B - NEW - Manufacturer Contact
New provision proposed by Karen Peltz Strauss to be consistent with the telecommunications guidelines
For purposes of Section 255, manufacturers must include in general product information the contact method for obtaining the information required by this section.
1.2-C - NEW - Training
New provision proposed by Karen Peltz Strauss to be consistent with the telecommunications guidelines
Where manufacturers provide employee training, they must ensure that it is appropriate to each employee's function, and give consideration to the following factors in developing and providing that training::
1. Accessibility requirements of individuals with disabilities; 2. Means of communicating with individuals with disabilities; 3. Commonly used adaptive technology with the manufacturer’s products; 4. Designing for accessibility; 5. Solutions for accessibility and compatibility.
1.2-X - Advisory Notes
Best practices for providing support to people with disabilities include:
1. Remote assistance
Remote assistance programs allow someone to access a computer system remotely to provide support or instruction. This ability to demonstrate features of the computer software or hardware is helpful to people with cognitive disabilities. Applications should either make such a feature available or not disrupt tools that provide it.
1194.3 - E - Fundamental Alteration
(This section has alternate versions. Rationales are listed at the end of the section.)
Version 1
This part must not be construed to require a fundamental alteration in the nature of the E&IT, or its components, given the agency's specified product requirements, or business need.
Version 2 (Current Provision)
This part shall not be construed to require a fundamental alteration in the nature of a product or its components.
Rationale for Version 1: This proposed language specifically reminds agencies that their implementation of Section 508 must support both the agency's mission as well as their responsibilities under Section 508. This version also links the fundamental alteration to the agency's specified requirements (if they are able to specify their requirements), or their business need (if they are not able to specify the requirements up front).
Rationale for Version 2: Some TEITAC members indicated the additional language in version 1 is not needed as it is implicit. They recommend keeping the provision as it currently is.
Comments by Karen PS to be consistent with the telecommunications guidelines
Version 2 (Current Provision)
This section as it was originally written can apply to both Section 508 and 255 and it would be a lot simpler to leave as is.
Comments from CSD/Trace Center
No change to language. (Version 2) Also version 2 can be applicable to both section 255 and 508 while version 1 specifies E&IT, which is only section 508.
1194.3 - F - Service Areas
(This section has alternate versions. Rationales are listed at the end of the section.)
Current Provision
Products located in spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment are not required to comply with this part.
Version 1
Products designed for spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment and whose controls or interfaces can be executed solely from these spaces are not required to comply with this part. This part does apply to E&IT designed for spaces frequented only by service personnel, but whose controls or interfaces can be executed externally or remotely.
Version 2
Remove the provision entirely.
Rationale for Version 1: Additional wording attempts to restrict this exception to products that are specifically designed to be located in areas frequented only by service personnel rather than covering all products by virtue of their location. It also makes clear that being able to support the system remotely is acceptable.
Rationale for Version 2: Some TEITAC members and subcommittee members recommend the entire exception should be deleted. This recommendation is based on the preference that all products should conform regardless of location and use.
1194.3 - NEW - Narrow, Delineated Use
Self-contained, closed products with narrow, delineated personal use (such as calculators, electronic dictionaries, and audio recorders) for which an agency can document readily available specialized products in the commercial marketplace that collectively meet the functional performance criteria (e.g. have features such as speech output available on one unit, large visual display available on another, large keys/buttons available on another, etc.) are not required to comply with this part as a whole. Agencies must however provide specialized products with appropriate access features as necessary to meet the needs of end-users with disabilities.
Rationale: Much discussion has transpired regarding the need to address situations where conformance to the technical and performance standards creates access barriers by loading up a single product with multiple access features. For example, requiring all calculators to have speech output, large visual display, enlarged keys, and other access features built-in actually creates access barriers depending on the functional limitations of individuals with disabilities. While some committee members are supportive of creating an exception to address this problem, other do not support pursuing this idea. While much discussion has taken place and alternatives have been explored, such as identifying products as "personal-private" that could be considered as part of a product line (see proposed personal-private definition), consensus has not been reached on a viable approach to addressing the problem.
Comments from CSD/Trace Center
Not accept. (Rationale: Not needed and dangerous. Likely to be abused.)
1194.3 - NEW – Inherently Visual EIT Assets
a. There are E&IT deliverables that do not lend themselves to accessibility, nor do they lend themselves to equivalent facilitation because the information they impart is intended to be analyzed using motion, shape, color or other vision-dependent attribute, and/or because they present an ever-changing stream of information. Examples include: i. Weather simulation imagery that presents a moving visualizations of weather systems (required by National Weather Service) ii. Modeling and simulation results of physical phenomena that provides information (e.g., electronic sensor data transmitted by ocean buoys to illustrate ocean movement - NOAA, modeling and simulation of blast phenomena - DARPA, US Army iii. Real-time monitoring by systems that simultaneously provide imagery and electronic reports that can be transmitted via web-enabled methodologies to analysts elsewhere (e.g., container inspection or passenger inspection systems used by U.S. Customs Service) b. We recommend an exception be created to allow these applications to fall in a recognized are of the standard, rather than requiring stretching the application of some other provision.
Comments from CSD/Trace Center
1. Do NOT accept new provision from ITAA regarding 'Inherently Visual E&IT Assets. (Rationale: If we do it opens up an unending list of exceptions such ach inherently auditory, inherently fine motor, inherently simultaneous action, etc. There are many things that will not make sense for particular people with particular disabilities to do. This is covered through undue burden since it is technically not possible to do these. In addition adding accessibility to these types of products might cause a fundamental alteration to their nature or function, a basic defense to access under the Rehabilitation Act which already exists)
Non-controversial Definitions (1194.4)
The current draft has 48 terms defined. This question submits for consensus on the remaining 38 non-controversial definitions that follow:
- Agency
- Application Software
- Assistive Technology
- Authoring Tools
- CAPTCHA
- Captions
- Closed Product Functionality
- Content Format
- Contrast Ratio
- Customer Premises Equipment
- Decoration
- Enhanced Audio
- First Responder
- Functional Equivalent to TV
- Closed Captions
- General Flash and Red Flash Thresholds
- Information Technology Interconnected Voice over Internet Protocol (VoIP)
- Product Interconnected Voice over Internet Protocol (VoIP)
- Service Keyboard
- Keyboard Interface
- Large Scale Text
- Manufacturer Non-text
- Object
- Other Services To Cooperate With Assistive Technologies
- Peripheral Devices Platform
- Accessibility Services Platform
- Software Programmatically Determinable
- Readily Achievable
- Relative Luminance
- Specialized Customer Premises Equipment
- Synchronized Media
- Telecommunications
- Telecommunications Equipment
- Telecommunications Service Terminal
- TTY
- Unavailable Items
- Undue Burden
- Usable Video Description
The following 10 definitions have comment or no definitions. These will be considered if time allows:
- Content
- Decoration
- Electronic and Information Technology
- Enhanced Audio
- First Responder (no definition)
- Free-Standing (no definition)
- Interactive Elements (no definition)
- Menu
- Programmatically Determinable
- Real-time Text
