EWG:Draft July 6 Provisions Only
From TEITAC
Editorial Working Group > Working Draft July 6 - Provisions with no metadata or discussion
TEITAC Working Draft - July 6, 2007.
Please see the Updated July 18 draft
This page contains the full text of all provisions from the subcommittees as of July 6, 2007.
Subpart A
Technical Provisions
1. Requirements for All Product and Services
[1.1] Functional Performance Criteria
1.1-A - Without Vision
At least one mode must be provided that allows comparable access to product without using vision, directly or via AT.
1.1-B - With Limited Vision
At least one mode must be provided that allows comparable access to product without requiring visual acuity greater than 20/70. This mode must allow audio and enlarged text output to work together or independently, directly or via AT.
1.1-C - With Color Vision Deficits
At least one mode must be provided that allows comparable access to product with color vision deficits.
1.1-D - Without Hearing
At least one mode must be provided that allows comparable access to product without using hearing, directly or via AT.
1.1-E - With Limited Hearing
Where audio information is important for the use of a product, at least one mode must be provided that allows comparable access to product with enhanced audio, directly or via AT.
1.1-F - Without Speech
At least one mode must be provided that allows comparable access to product without using speech, directly or via AT.
1.1-G - With Limited Reach, Strength, or Manipulation
At least one mode must be provided that allows comparable access to product with limited reach and strength and without simultaneous actions, directly or via AT.
1.1-H - With No Reach or Touch
(provision text still being written)
1.1-I - With Cognitive, Language or Learning Limitations
At least one mode must be provided that accommodates cognitive, language or learning impairments, directly or via AT.
[1.2] General Technical Requirements
1.2-A - Closed Products
If any product functionality is closed, then individuals with disabilities must have comparable access to that functionality without the use of any assistive technologies that must be attached or installed. A personal assistive listening device that connects to the standard audio connection required in provision [ 2.3.C-AUDIO CONNECTION ] is not considered assistive technology.
1.2-B - Flashing
Products must not flash more than 3 times in any one second period, unless:
- Flashing created by software is under the general flash and red flash threshold.
- Flashing created by hardware is either:
- greater than YYY candelas; or
- greater than 20 candelas/sq meter and contiguously occupies more than a total of .006 steradians (25% of any 10 degree visual field).
1.2-C - Biometric ID
When biometric forms of user identification or control are used, an alternative form of identification or activation must also be provided unless all people can use the biometric device.
1.2-D - Pass Through
Products that transmit or conduct information or communication must pass through cross-manufacturer, non-proprietary, industry-standard codes, translation protocols, formats or other information necessary to provide the information or communication in a usable format.
Technologies which use encoding, signal compression, format transformation, or similar techniques must not remove information needed for access, or must restore it upon delivery.
Firewalls, routers, gateways and other products that pass real-time voice communication must also pass real-time text communication signals (including mixed voice & real-time text) that are standard for that technology platform without distortion or error beyond 1%.
1.2-E - Audio information
All information provided in audio form must also be available in visual form.
1.2-F - Visual Information
All information provided in visual form must also be available in audio form and, where appropriate, in tactile form.
1.2-G - Color
Color coding must not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
1.2-H - Text size
All information provided in text must be a minimum of 3/16 inch (4.8 mm) high, based on the uppercase letter "I" or, where the display size is not part of the product, 14 pt type.
1.2-I - Contrast
Note: Contrast is currently split out between software and hardware. If this approach is successful, then this placeholder provision will be deleted.
2. Provisions for Hardware Aspects of Products
[2.1] All Products with Hardware
2.1-A - Touch Operated
This provision has two proposals that are still under consideration.
Version 1 - If a product utilizes touch screens or touch-operated controls, an input method must be provided that complies with Mechanical Controls Section.
Version 2 - If a product utilizes touch screens or touch-operated controls, an equivalent means of input/interaction/control must be provided.
2.1-B - Free-Standing
Products which are freestanding, non-portable, and intended to be used in one location and which have operable controls must comply with the following. The position of any operable control shall be determined with respect to a vertical plane, which is 48 inches in length, centered on the operable control, and at the maximum protrusion of the product within the 48 inch length on products which are freestanding, non-portable, and intended to be used in one location and which have operable controls.
Products which are freestanding, non-portable, and intended to be used in one location and which have operable controls must comply with the following. Where any operable control is 10 inches or less behind the reference plane, the height must be 54 inches maximum and 15 inches minimum above the floor.
Products which are freestanding, non-portable, and intended to be used in one location and which have operable controls must comply with the following, Where any operable control is more than 10 inches and not more than 24 inches behind the reference plane, the height must be 46 inches maximum and 15 inches minimum above the floor.
Products which are freestanding, non-portable, and intended to be used in one location and which have operable controls must comply with the following. Operable controls must not be more than 24 inches behind the reference plane.
EWG proposed rework: Freestanding, non-portable products intended to be used in one location must have any operable controls positioned within reach.
The allowed position of any operable control must be determined with respect to a vertical plane, which is 48 inches in length, centered on the operable control, and at the maximum protrusion of the product within the 48 inch length (see Figure 1 of this part).
- If an operable control is 10 inches or less behind the reference plane, the height must be 54 inches maximum and 15 inches minimum above the floor.
- If an operable control is more than 10 inches and not more than 24 inches behind the reference plane, the height must be 46 inches maximum and 15 inches minimum above the floor.
- Operable controls must not be more than 24 inches behind the reference plane (see Figure 2 of this part).
2.1-C - Standard Connection
Where user interface connection capabilities are provided, whether wired or wireless, at least one connection must comply with publicly available industry standards and all of the product functionality that is controllable by the user through the non-standard connection(s) must be controllable by the user via the standard connection using industry standard protocols for that type of input or output.
EWG suggested edits for clarity If a product has user interface connection capabilities, whether wired or wireless, at least one connection must comply with publicly available industry standards.
If users can control any product functionality through a non-standard connection, they must also be able to control that functionality through a standard connection using industry standard protocols for that type of input or output.
2.1-D - Contrast for displays
This is a placeholder for a provision still being written.
2.1-E - Contrast for labels
This is a placeholder for a provision still being written.
[2.2] If the Product has Physical Controls
2.2-A - Mechanical Controls
All mechanically operated controls and keys:
- Must be tactilely discernible without activating the controls or keys.
- Must be operable with one hand and must not require pinching, twisting of the wrist, tight grasping, or simultaneous actions. The force required to activate controls and keys must be 5 lbs. (22.2 N) maximum.
- If key repeat is supported, the delay before repeat must be adjustable to at least 2 seconds. The key repeat rate must be adjustable to 2 seconds per character.
- The status of all locking or toggle controls or keys must be visually discernible, and discernible either through touch or sound.
[2.3] If the product has Audio Output
2.3-A - Magnetic Coupling
Where a telecommunications product delivers output by an audio transducer which is normally held up to the ear, a means for effective magnetic wireless coupling to hearing technologies must be provided that allows the user of such technologies to effectively utilize the telecommunication product. This guideline shall apply to wireless, wireline, cordless and Bluetooth applications.
2.3-B - Interference with Hearing Device
Interference to hearing technologies (including hearing aids, cochlear implants, and assistive listening devices) must be reduced to the lowest possible level that allows a user of hearing technologies to utilize the telecommunications product.
2.3-C - Audio Connection
When products provide auditory output, the audio signal must be provided at a standard signal level through an industry standard connector (connection???) that will allow for private listening.
2.3-D - Volume
All products with audio output must allow users to adjust the audio level. At peak volume output they must have less than 12 dB symmetrical clipping or a total harmonic distortion (THD) less than XXX dB
- For products used in a public place, the maximum volume level must be at least 80 dB SPL RMS
- For products that will not be used in public places or where the volume of the public place is controlled to be under 50 dBA SPL RMS, the maximum volume level must be at least 65 dB SPL RMS.
2.3-E - Volume (Gain)
There are 2 proposed versions, not settled within Telecom SC:
Version 1: For incoming voice signals:
Line powered telecommunications products must comply with FCC regulation §68.317 for volume control,
OR
- Telecommunications products must provide a built in gain adjustable up to a minimum of 20 dB. For incremental volume control, at least one intermediate step of 12 dB of gain must be provided.
- All other telecommunications products or systems that provide a function allowing voice communication must provide a gain adjustable up to a minimum of 20? dB with incremental volume control of at least one intermediate step of 12 dB of gain provided as measured and documented in accordance with the provisions of the FCC regulation §68.317 for volume control.
Version 2: (NEW TIA PROPOSAL as amended by Working Group on 6/25 conference call)
- Analog line-powered telecommunications products and wireline all cordless telephones (wireline or VoIP) must comply with FCC regulation §68.317 for volume control
- All cellular phones - (language pending outcome of ATIS study group 11 work).
- All other telecommunications products or systems that provide a function allowing voice communication must provide a gain adjustable from the normal unamplified level to at least 20 dB above the normal unamplified level as measured in accordance with the provisions of the FCC regulation §68.317 for volume control. The volume at the normal unamplified level setting must also meet the requirement in FCC regulation 68.317.
2.3-F - Volume Reset
If the product allows a user to adjust the receive volume to a level greater than 18 dB above normal unamplified level, a function must be provided to automatically reset the volume to a level not greater than 18 dB above normal unamplified level after every use. A manual override switch may be provided to prevent the automatic reset, subject to the conditions specified in FCC Memorandum Opinion and Order DA 01-578.
3. Software & General Behavior Provisions
[3.1] All products
Requirements that apply to all products: equivalence for visual information (active and passive), consistent use of images, no interference with access features, time/repeat adjustments, flashing, etc.
3.1-A - Disruption of Access Features
Applications must not, except by specific user request, disrupt the features of the platform that have an accessibility usage in the platform developer documentation.
3.1-B - Timing
For each time limit that is set by the software, at least one of the following is true:
- Turn off: the user is allowed to turn off the time limit before encountering it; or
- Adjust: the user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
- Extend: the user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "hit any key"), and the user is allowed to extend the time limit at least ten times; or
- Real-time Exception: the time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
- Essential Exception: the time limit is part of an activity where timing is essential and time limits can not be extended further without invalidating the activity.
- TBD: In Adjust, issue with "before encountering"
- TBD: In Essential Exception, still discussing the suggestion to add something about data integrity.
3.1-C - Software as platform and application
Software that is both a 'platform', and an 'application' running on another platform must:
- 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.
- define, expose, and translate accessibility service information between applications running within its platform and the underlying platform - so that those applications can meet the AT Interoperability provision.
- provide mechanisms for:
- moving the keyboard focus into and out of an application, and
- addressing central conflicts between keyboard mnemonics in the application and the host platform.
[3.2] If the Product has Visual Output or Display
3.2-A - Contrast
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.
- TBD: Add a requirement addressing default contrast.
- TBD: Add something to address unavailable elements.
3.2-B - Animation
When an informational animation is displayed that will last for more than three seconds, software must give the user a means to pause and restart the animation. When a decorative animation is displayed that will last for more than three seconds, software must give the user a means to stop the animation.
3.2-C - User Preferences
Applications must utilize user selected contrast and color selections and other individual display attributes when the availability of those selections are developed and documented according to industry standards.
[3.3] If the Product has Standard Keyboard or Keyboard Interface
3.3-A - Keyboard
All functionality of the product operable through the user interface is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
- Note: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.
- Note: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
[3.4] If Software runs on platform with Operating System with AT Support
3.4-A - AT Interoperability
Software that provides user interface objects must either use the accessibility services provided by platform software or other services to cooperate with assistive technologies when such services allow the software to meet the accessibility provisions of this standard. Using such services, software must:
- provide assistive technology with object information including but not limited to:
- role, state(s), boundary, name, and description
- any table row & column, and row & column headers (if the object is in a table)
- current value and any minimum or maximum (if the object represents one of a range of values)
- relationship this object has as a label for another, or being labelled by another
- parent or containing element, and any children objects
- text contents, text attributes, and the boundary of text rendered to the screen
- provide assistive technology with a list of actions that can be executed on an object and allow assistive technology to programmatically execute any of those actions;
- allow assistive technology to track and modify focus, text insertion point, and selection attributes of user interface objects;
- provide assistive technology with notification of events relevant to user interactions, including but not limited to changes in the object's state(s), value, name, description, or boundary
Note: This provision applies to forms in the software.
3.4-B - Bitmap Icons
When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images must be consistent throughout an application's performance.
3.4-C - Focus Indicator
Software must provide a visual indication of which user interface object currently has the keyboard focus. If the object is a text entry field, a visual indication of the text insertion point must be provided, and is sufficient.
- TBD: TEITAC action item for the visual indication to be well-defined or highly visible. Looking at ISO 9241-171 for testable criteria and harmonization.
4. Additional Provisions for Audio-Visual Content or Players/Displays
4-A - Caption Playback
Analog television, digital television and tuners, computer equipment, and other equipment must provide closed and open captions:
| Equipment of this type… | Uses this standard… | To provide these functions… |
|---|---|---|
| CEA 608 | Receive, decode and display signals from
|
| CEA 708 | Receive, decode and display signals from
|
| CEA 708 |
OR
|
4-B - Supplemental Audio Playback
Television tuners, including tuner cards for use in computers, must support video description:
- Analog-signal tuners must be equipped with secondary audio program playback circuitry
- Digital-signal tuners must be equipped with ancillary audio program playback circuitry
4-C - Play Control (Audio)
The product must provide the ability to interrupt, pause, and restart the audio at anytime.
5. Additional Provisions for Real-time Voice Conversation Functionality
5-A - Accessibility Configuration
In complying with this subpart, each agency must:
- Activate accessibility features and configure telecommunications products so that they are accessible to and usable by people with disabilities.
- Ensure access to and use of all telecommunications relay services as approved by the Federal Communications Commission pursuant to its authority under 47 U.S.C. Sec. 225, for incoming and outgoing calls, as needed to achieve functionally equivalent communication access by people with disabilities.
5-B - Real-time Text Reliability
There are 2 proposed versions, not settled within Telecom SC:
Version 1: Systems that support real-time voice communication must support at least one standard (for the system) means for real time text communication that is supported by all terminal, router, gateway and other products on that system, and that meets the following requirements:
- Provides transmission of characters with less than 1 second delay from entry;
- Provides transmission with less than 1% Total Character Error Rate under peak non-crisis network traffic;
- Support alternating speech and text in both directions on non-packet based systems and simultaneously speech and text in both directions on packet based systems.
- IP systems cannot rely upon audio channels for transmission of real-time text. {can delete 5 if interop provision and peak traffic clause are retained.
Version 2 (Trace Alternate Proposal): Real-time voice communication systems must support at least one means for real-time text communication that:
- Is standard for the system and supported by all terminal, router, gateway and other products on that system, and
- Provides transmission of characters with less than 1 second delay from entry; and
- Provides transmission with less than 1% Total Character Error Rate under peak non-crisis network traffic; and
- Supports intermixing of speech and text in both directions (simultaneously if and only if IP based), and
- If it is an IP based system, does not rely upon audio signals for transmission of real-time text.
5-C - Real-Time Text Interoperability
There are 3 proposed provisions, not settled within Telecom SC:
Version 1 Products that provide real-time text conversation functionality must do so in the standard format that is supported for that transport medium.
- Products that connect directly to the PSTN must support TIA 825 Baudot where they interface to the PSTN;
- Products that connect directly to the Internet via SIP must support RFC 4103 where they interface to the Internet via SIP;
- All other Products (including PBX, cellular, and peer to peer Internet phones) that do not connect to PSTN or use SIP over the Internet must support the standard real-time text format for that system. These systems only need to support TIA 825 Baudot at the juncture to the PSTN (if any) and only need to support RFC 4103 at the point where they connect to public SIP systems (if any).
Version 2 (Trace Proposal); Products that provide real-time text conversation functionality must
- provide real-time text functionality in the standard real-time text format that is specified for that system
- use TIA 825 Baudot where they interface to the PSTN
- support both RFC-4103 and RFC-4351 where they interface to other VoIP systems or to the Internet via SIP
Note: Closed systems, where the real-time text format of all the components is controlled and identical, may use any real-time text format that meets provisions for (Real-time Text Reliability) and (Real-time Text Interoperability).
Version 3 (TIA Proposal): Products that provide real-time text conversation functionality must do so in the standard format that is supported for that transport medium and provide level of service that does not exceed 1% Total Character Error Rate under normal network conditions.
- Products that connect directly to the PSTN, including packet based systems, must support TIA 825 Baudot where they interface to the PSTN.
- Packet based systems must support real-time text communication between text capable terminals.
5-D - VOIP Terminals and Real-Time Text
The user interface of IP terminals that provide real-time voice communication must meet the following provisions:
- IP terminal user interfaces that have a multiline display must display any real-time text that is received in the standard format for that platform.
- IP terminal user interfaces that have the ability to generate text must allow sending real-time text in the standard real-time text format for that platform.
- Such real time text send and receive capabilities must be synchronized with voice as part of the same communication session.
5-E - Voice Terminals without Real-Time Text
There are 3 proposed provisions, not settled within Telecom SC:
Version 1: Telecommunications terminals and other terminals capable of providing real-time voice communications which do not themselves provide TTY or other real-time text conversation functionality must comply with the following:
- All analog and TDM-digital wired terminals must support the connection of a TTY in the same location and with the permissions for use as the telephone. This must be accomplished by:
- Providing an RJ-11 jack on the telephone, or
- For an analog telephone, by the use of a Y-adapter that allows both the analog telephone and the TTY to be plugged into the same line outlet, or
- Having built-in capability to support an RJ11 module that can provide a connection point for TTYs.
- Other types of terminals covered by this section must support the connection of real-time text capable devices in conjunction with the voice call capability in the same location and the same permissions for use as the terminal.
- These products must either:
- Be capable of allowing simultaneous speech and text conversation without interference or
- Its microphone must be capable of being turned on and off to allow the user to intermix speech with text use.
Version 2 (NEW TIA PROPOSAL): Telecommunications products or systems [terminals and other terminals capable of providing real-time voice communications which do not themselves] provide TTY or other real-time text conversation functionality must comply with the following:
- All analog and TDM-digital wired terminals must support the connection of a TTY in the same location and with the permissions for use as the telephone. This may be accomplished by:
- Providing an RJ-11 jack on the telephone, or
- For an analog telephone, by the use of a Y-adapter that allows both the analog telephone and the TTY to be plugged into the same line outlet, or
- By having built-in capability to support an RJ11 module that can provide a connection point for TTYs.
- Packet based telecommunication systems must support the addition of terminals and terminal peripheral equipment that support real-time text functionality in conjunction with the voice call functionality in the same location and with the same permissions for use as the terminal.
- These products must either:
- Be capable of allowing simultaneous speech and text conversation without interference, or
- Its microphone must be capable of being turned on and off to allow the user to intermix speech with text use.
Version 3 (TRACE PROPOSAL): Terminals capable of providing real-time voice communications that do not themselves provide TTY or other real-time text conversation functionality shall comply with the following:
- All analog and TDM-digital wired terminals shall support the connection of a TTY in the same location and with the permissions for use as the telephone. This may must be accomplished by providing an RJ-11 jack on the telephone, or, in the case of an analog telephone, by the use of a Y-adapter that allows both the analog telephone and the TTY to be plugged into the same line outlet, or by having built in capability to support an RJ11 module that can provide a connection point for TTYs;
- Packet based telecommunication All other real-time voice communication systems shall support the ad hoc addition of terminals and terminal peripheral equipment that support real-time text functionality in conjunction with the voice call functionality in the same location andwith the same permissions for use as their voice terminal.
- Shall be capable of allowing simultaneous speech and text conversation without interference or its microphone shall be capable of being turned on and off to allow the user to intermix speech with text use.
5-F - IVR etc.
There are 2 proposed provisions, not settled within Telecom SC:
Version 1: Voice mail, messaging, auto-attendant, and interactive voice response telecommunications systems must make information available and be capable of recording Baudot TTY signals.
These systems must:
- Use the ITU-T G.711 standard for encoding and storing audio information. If an audio encoder other than G711 is employed, the vendor must provide evidence that the intelligibility is equal to or better than that provided by G.711;
- Provide full player controls that allow users to pause, rewind, slow down and repeat all messages and prompts, and adjust volume;
- Provide prompts (either as provided by the vendor or by the user) without any background sounds that would reduce intelligibility.
2. In using such systems agencies must:
- Preferably present the system user with 4, but no more than 6, menu choices at one time unless the user requests to hear more options.
- Provide easy to understand and act upon menu items and other navigational messages.
Version 2: Voice mail, messaging, auto-attendant, and interactive voice response telecommunications systems must:
- All functions that are accessible to voice users must also be directly accessible to users of real-time text.
- Use the ITU-T G.711 standard for encoding and storing audio information. If an audio encoder other than G711 is employed, the vendor must provide evidence that the intelligibility is equal to or better than that provided by G.711;
- Provide full player controls that allow users to pause, rewind, and repeat all messages and prompts;
- Provide prompts (either as provided by the vendor or by the user) without any background sounds that would reduce intelligibility.
NOTE: Relay services are not considered to be "directly accessible".
5-G - Caller and Status Information
Where provided, visual interfaces for telecommunications status information such as caller identification and similar telecommunications functions as part of interactive voice response systems or equivalents must also be available for users of TTYs or other text conversation systems, and for users who cannot see displays and must meet all accessibility provisions for software and content.
Suggested edit for clarity: Products with visual interfaces that display telecommunications status information (such as caller identification and similar telecommunications functions) as part of interactive voice response or equivalent systems must also make this information available for:
- Users of TTYs,
- Users of other text conversation systems, and
- Users who cannot see displays.
These products must also meet all accessibility provisions for software and content.
5-H - Video Support
Telecommunications products or systems which have the capacity to transmit video, text and voice communications must support internet protocol text and voice communications in X format and must have sufficient transmission bandwidth capacity to support video communication such as video relay and point to point video communications.
6. Electronic Content Provisions
[6.1] If Web Content or Web Applications
6.1-A - Color (Web)
Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
EWG proposed rework: Color coding must not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
6.1-B - Contrast (Web)
Text (and images of text) have a contrast ratio of at least 5:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 3:1.
6.1-C - Timing (Web)
Timing: For each time limit that is set by the content, at least one of the following is true:
- Turn off: the user is allowed to turn off the time limit before encountering it; or
- Adjust: the user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
- Extend: the user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "hit any key"), and the user is allowed to extend the time limit at least ten times; or
- Real-time Exception: the time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
- Essential Exception: the time limit is part of an activity where timing is essential and time limits can not be extended further without invalidating the activity.
- TBD: In Adjust, issue with "before encountering"
- TBD: In Essential Exception, still discussing the suggestion to add something about data integrity.
6.1-D - Flashing (Web)
Web content and applications do not contain anything that flashes more than 3 times in any one second period, unless the flashing is below the general flash and red flash thresholds.
6.1-E - Non-text Content
Non-text Content: All non-text content has a text alternative that presents equivalent information, except for the situations listed below.
- Controls-Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (See also User Interface Components provisions)
- Media, Test, Sensory: If non-text content is multimedia , live audio-only or live video-only content, a test or exercise that must be presented in non-text format , or primarily intended to create a specific sensory experience , then text alternatives at least identify the non-text content with a descriptive text label. (For multimedia, see also Audio and/or Video provisions)
- CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided and alternative forms in different modalities are provided to accommodate different disabilities.
- Decoration, Formatting, Invisible: If non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, then it is implemented such that it can be ignored by assistive technology.
6.1-F - Repeated Blocks
A mechanism must be available to bypass blocks of content that are repeated on multiple Web pages.
- TBD: "blocks of content" is vague. Since this is harmonized with WCAG, we are raising the issue with the WCAG group.
6.1-G - Keyboard
All functionality of the content operable through the user interface is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
- Note: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.
- Note: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
6.1-H - Link Purpose
The purpose of each link can be determined from the link text or the link text together with it's programmatically determined link context.
6.1-I - Information and Relationships
Information and relationships conveyed through presentation can be programmatically determined or are available in text, and notification of changes to these is available to user agents, including assistive technologies. For example:
- row and column headers are identified for data tables
- markup is used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
- markup is used to identify section headings
6.1-J - Focus Cursor (Web)
A focus cursor must be provided that visually indicates which user interface element currently has the keyboard input focus, as well as the focus location within that element when one exists. The focus cursor must be programmatically determinable so that assistive technology can track focus and focus changes.
6.1-K - User Interface Components
For all user interface components, including form elements and those generated by scripts, the name and role must be programmatically determinable, states, properties, and values that can be set by the user must be programmatically determinable and can be programmatically set, and notification of changes to these items is available to user agents, including assistive technologies. For example:
- Frames must be titled with text that facilitates frame identification and navigation.
6.1-L - Consistent Identification
Components that have the same functionality within a set of Web pages must be identified consistently.
6.1-M - Pausing
Moving, blinking, scrolling, or auto-updating information can be paused by the user unless it is part of an activity where timing or movement is essential. Moving content that is pure decoration can be stopped by the user.
6.1-N - Reading Order
When the sequence in which content is presented affects its meaning, a correct reading sequence is programmatically determinable.
- programmatically determinable is defined as: can be determined by software from data provided in a user-agent-supported manner such that various user agents including assistive tecnologies can extract and present this information to users in different modalities.
[6.2] If a Content Format
The Web and Software subcommittee was charged with looking at the issue of accessible content - e-mail, attachments in e-mail, etc. One issue is that the content format itself has to have certain features to enable the creation of accessible content. We therefore recommend adding a section that defines the necessary accessibility features. Agencies should store information only in compliant content formats and should therefore purchase products that support compliant content formats. Note that content creators still have to utilize the features in order for the content to actually be accessible.
6.2-A - Non-text Objects
A content format that supports non-text objects must provide an encoding mechanism to associate non-text objects with textual descriptions that a user-agent can display.
6.2-B - Multimedia (Format)
When a content format supports multimedia, an encoding mechanism must be provided to include synchronized text of verbal content, and audio descriptions of critical nonverbal activity displayable by a user-agent.
6.2-C - Reading Order
When a content format supports 2 dimensional display of information, an encoding mechanism must be provided to identify the logical linear reading order of the content displayable by a user-agent.
6.2-D - Table Headers
When a content format supports row and column headers in data tables, an encoding mechanism must be provided to identify row and column headers for data tables displayable by a user-agent.
6.2-E - Complex Table Headers
When a content format supports data tables that have two or more logical levels of row or column headers, an encoding mechanism must be provided to associate row and column headers with data cells, displayable by a user-agent.
6.2-F - Interactive Elements
When a content format supports interactive elements, an encoding mechanism must be provided to identify name, operation, and state, of any interactive elements displayable by a user-agent.
6.2-G - Links
When a content format supports links, an encoding mechanism must be provided to identify link text displayable by a user-agent.
6.2-H - Embedded Comments
When a content format supports embedded comments, an encoding mechanism must be provided to identify embedded comments and associate those comment locations within the document.
6.2-I - Images of Text
When a content format supports scanned images of text, an encoding mechanism must be provided to identify text of scanned images of text, displayable by a user-agent. Note, this means allowing for inclusion of the text of a scanned image of text.
6.2-J - Dynamic Information
When a content format supports dynamic presentations, graphs, or other extracted information, an encoding mechanism must be provided to include data used for any dynamic presentations, graphs, or other extracted information displayable by a user-agent.
[6.3] If Audio and/or Video Content
Note: The Audio Visual committee is still working on updates for these provisions.
6.3-A - Synchronized Alternatives
Equivalent alternatives for any multimedia presentation must be synchronized with the presentation.
6.3-B - Captions and Transcripts
All materials containing video and/or audio, regardless of format, that contain speech or other audio information necessary for the comprehension of the content, must comply with the following:
- Materials containing prerecorded audio and no additional time-based content must provide either a transcript or synchronized captions.
- Materials containing prerecorded video with concurrent audio must provide synchronized captions and may offer a transcript in addition to, but not in place of, the captions.
- Materials containing real-time audio, with or without video, must provide synchronized real-time captions.
6.3-C - Video Description and Full Text Equivalents
All materials containing video and/or audio, regardless of format, that contain visual information necessary for the comprehension of the content, must comply with the following:
- materials containing prerecorded video and no audio or other additional time-based content must provide either a separate text description of the video or provide an additional audio track to convey the informational content of the video.
- materials containing prerecorded video with concurrent audio must provide synchronized audio descriptions, or a separate text description of the video, to convey the informational content of the video.
- materials containing live video must provide synchronized audio descriptions in real time to convey the informational content of the video.
6.3-D - Open or Closed Captions/Descriptions
At the time of playback, captions and/or video descriptions must be either (a) capable of being turned on and off ("closed"), or (b) visible or audible to all users ("open").
6.3-E - Interactive Elements
All materials containing interactive elements that are part of the content must comply with 1194.21 [a-z] as well as 1194.24 a-e.
[6.4] Additional requirements for Web Content Authoring Tools
(new provisions to be added)
7. Information, Documentation and Support
[7.1] Product Documentation and Help
7.1-A - Accessible Documentation and Features
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 the relevant accessibility provisions in 1194 Subparts B and C. This includes, but is not limited to, reports, system documentation, and user training or technical support materials.
7.1-B - Keyboard Shortcuts
Information about keyboard shortcuts must be made available in documentation.
1. All shortcuts for keyboard operation must be listed in one place for easy reference.
2. When the documentation lists specific mouse based actions, the keyboard commands must also be listed.
7.1-C - Advisory Notes
Best practices for providing documentation to people with disabilities include:
1. 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.
2. 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.
3. Descriptions of a user interface should refer to elements by name or function, in addition to their location in the visual interface.
[7.2] Support and E&IT related services
7.2-A - Support Services
Help desk and technical support services for E&IT must accommodate the communication needs of users with disabilities. 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.
7.2-B - Advisory Notes
Best practices for providing support to people with disabilities include:
- 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.
