7 Provisions Considered but Not Achieving Consensus

These provisions were discussed by the Committee, but did not reach the point of consensus. In some cases, the Committee agreed on the general point of the text, but could not reach final wording. In others, there was disagreement on whether it should be included as a provision at all. Notes with each provision considered provides further explanation.

Subpart B: Functional Performance Criteria E, I, and J

E – With Limited Hearing (no consensus) There were three versions of this provision under discussion Version 1: Where audio information is important for the use of a product, it must provide at least one mode that allows user control of volume and/or reduction of background noise. (See note on functional performance criteria and assistive technology.) Version 2: Products must provide at least one mode that allows access to all functionality of the product with limited hearing. (See note on functional performance criteria and assistive technology.) Version 3 Where audio information is required for the use of a product, the product must provide at least one mode that allows user control of volume and/or reduction of background noise. (See note on functional performance criteria and assistive technology.)

Viewpoints from Committee Members Trace: One of the comments around the FPC was that they were untestable. Indeed some of them were (just a few). Those have now all been made testable and accepted except for this one. FPC E - With Limited Hearing was one that was untestable since it said that you needed to provide enhanced audio but it was not clear what that meant or how enhanced it needed to be. Version 2 is similarly untestable. What does it mean to be usable with limited hearing. Usable with NO hearing is clear and testable. No is quantitative. But limit is wide open. Version 3 was proposed based on the discussions of version 1. It gives very specific means for addressing and is a proper parent of the technical provision. If other wording can be found that is fine as long as it is testable (e.g. a designer can tell when they have met it and 8 out of 10 people or better would agree). We don't want to cast the FPC back into untestable land because of this provision. Version 3 is best we have now.

IBM: Version 2 is worded like the other FPC. It was stated in the discussion that an FPC for limited hearing worded like the others would not be testable as there is no measurable specification for "limited hearing" as there is for FPC B and FPC H. Version 1 was proposed as providing volume control is the recommended solution to support people with limited hearing. Version 3 is a slight edit of version 1 that is more testable as it removes the word "important," which is a subjective judgment. IBM agrees that having an FPC that does not have a measurable specification of the disability is an issue and prefers version 3. Since Version 3 reads like a general technical requirement, however, we prefer to see this as a provision in C-1 General Technical Requirements.

I - Without Physical Contact (no consensus) There was one version under discussion, and disagreement about whether it should be included at all.

Products must provide at least one mode that allows access necessary to operate all functionality of the product without requiring any physical contact with the product beyond initial connection and setup of a special interface device. This does not apply to powering product up, changing consumables, configuration, set-up or maintenance. (See note on functional performance criteria and assistive technology.) Note: For initial setup, it is acceptable to use a physical connector (e.g., a USB connector) to connect the user's special interface device.

Rationale

1. It is well known that a large population of people with physical disabilities cannot reach out to touch a product or cannot reach out long enough to actually operate a product physically. 2. While it is preferable that no contact at all be required, some physical contact may be needed to turn power on, initialize a telephone call, load or remove paper or consumables, or change mode of operation. In some cases it may be required for the user to be assisted by a companion or bystander with these operations. 3. Assistive Technology examples:

The use of a standard network interface (e.g., USB, Ethernet, IEEE 1394, Wi-Fi, Bluetooth, etc.) that allows users to control the product using software via a wired or wireless network connection would meet this provision.

The use of the infra-red (“IR”) port used for remote controls in consumer electronics products would meet this provision.

4. Direct Access examples:

Voice dialing or voice control is an example of direct access. Access to voice dialing or voice control may require physical contact with the product to initiate the call or change mode of operation to enable voice recognition.

Viewpoints from Committee Members Microsoft: This wording sounds a lot like "products must provide a mode without requiring physical contact, except where physical contact is essential". We think this FPC is subjective as to what constitutes 'configuration' or 'set up' and is essentially unworkable as is.

Panasonic: FPC (I) as currently drafted would require compatibility with assistive technology for telecom products unless it provides advanced voice recognition capability that is not technically or economically feasible for most consumer products. For telecommunications products, a “press to operate voice control” feature that enables voice dialing with a minimal physical contact is a useful way of providing accessibility for many physically disabled individuals. A press to operate voice control feature allows telecommunication products to initiate or finish voice dialing via a minimal physical touch, but does not require continuous ability to touch and operate controls on the product. Only where such a feature is not readily achievable should compatibility with an external special interface device be required. Panasonic proposes separate versions for Section 508 and Section 255, and removing #1 in the rationale.

ATIA: In the refresh of Section 508 done five years ago, people with mobility impairments who are unable to touch or make physical contact were, for the most part, not considered in the Functional Performance Criteria. ATIA believes it is important to make sure this significant demographic of disabilities (second in size only to blindness and low vision) is addressed in the current refresh of Section 508. The argument that providing access for these individuals is too difficult should not be reason enough to keep the provision out of the new Functional Performance Criteria. Indeed, the same could have been said for many of the other types of disabilities addressed in the refresh five years ago. But since that time, spurred by the FPC in Section 508, solutions have been developed. We believe the same will occur in the coming years for people with no reach or touch, if the provision is included. Unless we include a Without Physical Contact FPC provision, there is a very real possibility that this segment of people with disabilities will continue to be left out of the equal opportunities that Section 508 was meant to provide to all (not just certain segments of disabilities).

J - With Cognitive, Language or Learning Limitations (no consensus) There was one version under discussion, and disagreement about whether it should be included at all, or could be written in a testable way. Products must provide at least one mode that accommodates cognitive, language, memory or learning impairments. (See note on functional performance criteria and assistive technology.)

Rationale The telecommunications guidelines include a requirement for provision of a mode that “minimizes the need for memory.” See §1193.41(i).

Viewpoints from Committee Members Microsoft: It is impossible to create a single FPC that covers such a wide group of people, the kinds of impairments listed here encompass too wide a spectrum to be meaningful. If anything like this was to be included it would:

a) need to be split out into much more delineated and specific categories b) much more scoped in terms of severity of condition (as written it would essentially mean products need to be operable by individuals with no effective functional cognitive ability (e.g., in a coma).

IBM: IBM does not support the inclusion of this FPC. It has the same issue as E - With Limited Hearing. The disabilities listed (cognitive, language, memory or learning impairments) are very broad and not measurable. We do include a number of provisions in Subpart C that support the needs of people with these disabilities.

Panasonic: Panasonic can not agree with FPC J - With Cognitive, Language or Learning Limitations, which is too broad, not measurable and thus impossible to achieve. Subpart C provisions are more appropriate for such disabilities.

Provisions from Subpart C

1-E: Visual information (no consensus)

There was one version under discussion, and disagreement about whether it should be included at all. This provision is linked to the incomplete 6-D. If both 1-E and 1-H reached consensus, the Committee planned to remove 6-D

All information that is needed for operation and use that is provided in visual form must also be available in at least one mode in audio form or in SIMPLE TACTILE FORM, either directly or through support for the following provisions in Section 3 <insert list>.

Visual CONTENT that includes TEXT and that is closed due to Digital Rights Management (DRM) such that it cannot be rendered in audio form by AT and other players must include an audio form that can be.

Note 1: Section 255 and Section 508 treat AT solutions differently, so review section XX of this document before implementing a solution. Note 2: Braille is not a simple tactile form. It is encouraged but cannot be used to satisfy this provision.

Viewpoints from Committee Members Microsoft: This provision seems largely redundant with respect to 3-O so we support its removal. If kept, the onus must generally be on a content owner to make a content product accessible. The hardware should not create additional barriers of course, but it should not be required that hardware remediate for failures in other peoples products. Rights management is an orthogonal issue, which is a policy constraint means of making a product closed, so 1-A kicks in; and that content product must be operable in and of itself. This part is redundant and should be removed.

IBM: IBM views this provision as unnecessary. The digital rights management issue is closed functionality and already covered by 1-A. Keys on hardware products must be tactilely discernible per 2.1-C. As the arrangement of keys is spatial, any hardware with keys whose layout must be memorized by blind users would fail this provision as the keys would not meet the definition of "simple tactile form". And finally, many of the provisions in section 3 are designed to enable visual information to be programmatically determined by screen readers which provide the information auditorially.

Trace & AFB: 1-E Visual Information is an important technical provision for individuals who are blind. It is not covered by other technical provisions. The AT compatibility provisions are often cited as covering this – but one of the key reasons this provision is necessary is for product that have one or more (or all) features that are closed. For these features of a product (or for products that are fully closed – such as most public and many shared products) all of the AT compatibility or “programmatically determined” provisions would not apply. (According to 2.1-A - Things that are ‘closed’ are exempted from all of the AT compatibility provisions including all provisions that talk about “programmatically determinable”. Instead product functionality that is closed must meet other provisions – and this is the one for access to visual information by those who cannot see. So removing this would mean that all closed products are exempt from being accessible to people who are blind. (e.g. at ticket machine - they could feel that there were buttons (per 2.1c) but not know what the buttons did or know what was on the screen. Clearly this provision is not redundant with existing technical provisions – especially for a product that has any closed function.

There was also some discussion about this not being needed because it was covered by a Functional Performance Criterion. But ALL of the technical provisions are covered one or more functional performance criteria. With that argument we could remove all the technical provisions.

It was argued in discussions that this was not reasonable because visual interfaces are so rich and relied upon in products. This is true. That is the reason that this provision is essential. Note that the provision does allow (for products that are not closed) use of the other AT compatibility provisions.

There was also concern that this one was not specific enough. It could easily be changed to be more specific – but this would reduce industry options. More specific language was posted to the list on 3/28/08 but the goal of the technical provisions generally is to be only as specific as necessary, in order to maximize a companies options in conforming.

The latter sentence deals with media controlled by DRM. Other provisions speak to content being programmatically determinable – but DRM controlled media are ‘closed’ and by definition are not ‘programmatically determinable. Where the media meets the other provisions – but maintains its closed functionality due to DRM, the media players need to then provide a DRM conformant way to play the information in audio. (If DRM is handled in a different provision – then the DRM sentence could be removed here.

Panasonic: Panasonic supports the goal of providing access to visual information necessary to operate E&IT and Telecommunications products. 1-E is in the technical provisions that applies to devices, but note 1 in the current draft is a requirement for content. E&IT cannot provide access to protected content that is encrypted or otherwise protected by digital rights management techniques. It would be technically difficult and legally impossible for manufacturers to violate U.S. law, which has severe penalties for circumvention, or to violate the terms of private licenses. The Federal agency or the developer/author of the content is the best party to assure accessibility. For example, the author of a DVD with visual menus can provide audio tags for each menu element that the DVD player simply plays when selected.

For telecommunications products, Section 255 requires a product to be accessible to and useable by persons with disabilities unless readily achievable. Only in the case it is not readily achievable to provide direct accessibility is the manufacturer required to ensure that the equipment or software is compatible with existing peripheral devices or specialized customer premises equipment commonly used by individuals with disabilities to achieve access, if readily achievable. Under Section 255, the scope of this provision is limited by U.S. statute to only information that is needed for operation and use the telecommunications functions of the product.

Sun: Sun feels that this provision is duplicative, unnecessary, and burdensome. Multiple existing and consensed provisions describe in detail the various aspects of making the visual interface accessible. The broad and general text of this proposed provision adds almost nothing that goes beyond the related Functional Performance Criteria "Without Vision". By duplicating such general text here in a technical provision, we would add significant uncertainty into the product development process, as E&IT producers and procurement would have to come to an understanding of what they are supposed to do to meet this provision as distinct from the other detailed technical provisions for visual interfaces. If there is some specific "hole" not covered by the existing specific technical provisions, it would be better to address that with a specific and narrowly tailored provision, rather than the broad and general language proposed here.

Japanese Standards Association: This provision overlaps with 2.1-C 4., 3-O and 3-M.

Additional Information

Text from Self-Contained/Closed

Source: {255}1194.43(a)

Testability: Expert evaluation

Disabilities: Blindness, Low Vision

1-G: Text Size (no consensus) There is the draft that was under discussion. There were still some open issues that prevented the Committee from reaching consensus on it.

For all public or shared products there must be at least one mode where all information that is required for product use and is provided in text or images of TEXT is readable by people with 20/20 vision at 3.5 times their typical viewing distance and where the mode is the default mode or the method for activating the mode meets this requirement except:

(a) Caption display: This requirement does not apply to the caption decoding functions of products that are governed by U.S. Federal Communications Commission (FCC) regulations 47 CFR 15.119 or to devices that provide equivalent functionality as stipulated by 4-A - Caption Processing. (b) Logos and Certifications: Safety LABELS, regulatory LABELS, and other marks (such as logos and certifications) are not included except where they are required by the user “for product use”. (c) Tactile Equivalents: If other means of visually conveying the information in the LABEL or instructions exists (e.g., uniquely tactilely discernible through shape), and the TEXT is not "required for product use" then the text size requirement does not apply. For example, a phone-like numeric keypad (with nib) or a tactilely unique cluster of arrow keys are usable without labels while softkeys (where the function changes and must be read from a display) would not be usable without the label. (d) Personal devices: Personal or personally assigned devices are not covered unless all users must use the same product (or same type of product) (e.g., policy or in order to work with system software or procedures). In that case it constitutes a ‘shared device’ since all must use the same one (the same type) and that product (or type) would need to meet provision. (e) Use of TEXT file: Providing TEXT in an accessible file on a device meets this requirement for information that is not location specific (e.g., LABELS are location specific). (f) Application to Software: Software that is not associated or purchased with any particular hardware (so the text does not have a physical size until it is displayed) can be evaluated on any typical display that the software is intended to work with.

Rationale The goal of this provision is to support people with low vision. People with vision worse than 20/70 typically use an assistive device, so this provision is aimed at supporting those with vision between 20/40 and 20/70.

For people with 20/20 vision viewing text at 40 cm (15.7 inch), 8pt type is a small but acceptable type size for running text and somewhat smaller text could be used for common labels where it is mostly identifying which key is which rather than having to read novel and/or un-expected information.

For people with 20/70 vision, an acceptable size for running text is approximately 28pts at 40 cm viewing distance and somewhat smaller text could be used for common labels

If we assume users with low vision can move in closer (half distance - 20 cm) to view text (and that their glasses allow this), 14 pt type would provide type that subtends the same visual angle (as 28 pt at 40 cm).

Although many users with low vision will use close vision coupled with glasses that focus their vision – it is too hard for designers to work off of this – and all glasses are custom. The 3.5 distance with 20/20 gives a measure that is repeatable and will yield text that is legible to who need larger clearer type. It also automatically allows text to be smaller if it is clear and requires it to be larger if it, for example, used very thin stem width. Some users with low vision have a field of view limitation. They can use small print modes if available. In general though, signage and other existing access regulations are based on the assumption that larger print is more universally accessible for people with low vision than print that is small to accommodate people with field of view limitations who cannot step back to shrink the size of the text in their view. (Note also that this provision does not require very large text – just text that is not small.

At a workstation, it is reasonable to assume that special reading aids (such as a moderate magnifying glass) would be available even if user’s vision is in the range of 20/30 to 20/70, and fonts can therefore be smaller. The sizes for devices designed to be used away from a person's workstation are aimed at those with low vision but not very low vision (beyond 20/70). This is based on an assumption that:

People with 20/70 vision or better would not usually carry a magnifying device with them.

People with worse than 20/70 vision would usually carry portable optical magnifying devices (including special glasses) with them.

Advisory Note to the Access Board The Note “Software that is not associated or purchased with any particular hardware (so the text does not have a physical size until it is displayed) can be evaluated on any typical display that the software is intended to work with.” eliminates all pixel calculations (which will not remain valid) and also separates stand alone software from software in a product. The provision is limited to public or shared products. These are things that a person cannot modify, mark up, or buy their own version of. It also can be things that they don't know about in advance of encountering. This allows personally (or personally assigned) cell phone, keyboards, etc to be excluded. However, this does open up the problem talked about on other provisions – that an agency would buy one type of cell phone (for example) and then write software that only works with that phone (or type of phone). The user with low vision may know of phones they could use – but none of them work with the software – so they have to use a phone that has only small print on it. In this case we believe the issue can be addressed with a note that explains “Personal or personally assigned devices are not covered unless all users must use the same product (or same type of product) (e.g.,policy or in order to work with system software or procedures). In that case it constitutes a ‘shared device’ since all must use the same one (the same type) and that product (or type) would need to meet provision.”

Viewpoints from Committee Members Microsoft: '3.5 times a typical distance' and 'readable' are too subjective to be adequately testable. bullet 3, label is inconsistent with the wording (tactile/visual). bullet 6. Software should only be covered in this provision if it mandates a specific display size for text regardless of display hardware and platform (i.e., 3-D did not apply), and that no non text cues (e.g., icons or position) could be utilized.

IBM: IBM views this provision as a potential conflict with 3-D User Preferences. Software that runs on platforms that support system wide settings for font size should respect the user's chosen font size.

TIA: Rationale in opposition to Versions 1 and 2. While Version 2 is a substantial improvement over Version 1, there are infirmities that need to be addressed. Specifically the requirement that low vision mode be the default mode or method of activating appears to be in contradiction to the clause stipulating "there must be at least one mode". It is preferable that the standard stipulate that a low vision setting be easily discernable and discoverable rather than to require every device to ship with the default on low vision. (Defaults are factory set for shipping.) Under the Personal Device exemption, it is not acceptable that an agency "by policy or procedure" could limit the opportunity for inaccessible products to be selected in procurement, but this is the effect of the current text. The provision should allow for adopting products which can support software that provides access. Lastly, the Application to Software provision needs to align with provision 3-D User Preferences by affirmatively stating that software meets this provision if its support 3-D and runs on platforms that provide system-wide settings for font size.

Canon: 1-G Text Size Versions 1 and 2 apply to public or shared products. The rationale for excluding personal products is because it is assumed that at a workstation, special reading aids (such as a moderate magnifying glass) would be available even if users vision is in the range of 20/30 to 20/70. However, the availability of special reading aids would also apply to shared products in users departments or general work area. Therefore, 1-G Text Size should apply to public products; there is no reason based on this rationale that shared products should be applicable.

It would be helpful to include the text sizes (previously removed) that may be used to meet this provision. Many public products, such as kiosks, ATMs, and copy machines may be used from a standing or seated position. Therefore, the 3.5 times typical viewing distance approach would depend on the height of the user which varies considerably, and whether the user is seated. In this case, having reference to the text sizes below from the March 11th version would be beneficial.

a) At least 12 points if text is a label and if the user can position their face close to the label b) At least 14 points for all other text where 1 point = 1/72.27 inches (on computer displays 1/72 inch).

Trace: Version 2 represents extensive efforts to address multiple different comments and is the language Trace recommends. It is complementary with other provisions such as 3-D User Preferences in that user preference can be used where they allow this size to be met (which is true for all common OSs today). However there are often software packages that are meant to be run in such a way that they suppress any ability to get to the OS settings. Kiosks are a good example. In those cases, relying on systems settings will not work.

Some cleanup of the default language may be needed to clarify. The current language could be made clearer by saying . where EITHER 1) the mode is the default mode or 2) the method for activating the mode meets this requirement. to make it clear that the default doesn’t need to meet this as long as the way to turn it on does meet this.

Japanese Standards Association: This provision must be applied to products that are used by a variety of people in public space. Please consider to add this condition in the provision.

Additional Information

Text from Self-Contained/Closed

Source: {255}1193.43(b)

Testability: Inspection

Disabilities: Low vision

3-P - User Interface Components (no consensus) There were two versions of this provision under discussion.

Version 1 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. Any notification of changes to these items must be available to user agents, including ASSISTIVE TECHNOLOGIES. Example: Frames must be titled with text that facilitates frame identification and navigation.

Version 2 For all user interface components, including form elements and those generated by scripts, the name, role, states, properties, and values must be PROGRAMMATICALLY DETERMINABLE. States, properties, and values that can be set by the user can also be programmatically set. Any notification of changes to these items must be available to user agents, including ASSISTIVE TECHNOLOGIES. Example: Frames must be titled with text that facilitates frame identification and navigation.

Rationale To ensure that interactive elements in non-HTML technologies, or those implemented by re-purposing HTML elements with JavaScript, properly expose information for AT interoperability.

Advisory Note to the Access Board The word "components" was used in this provision instead of "objects" since objects is a programming term and can be confusing to vendors. By using the term components it is more generic and will hopefully lead to less confusion.

Viewpoints from Committee Members IBM IBM supports version 2 of this provision. While this provision is technically redundant with 3-U, it is written to a different target audience. 3-U is intended for developers of traditional software applications and user agents who use programming APIs. It is harmonized with the ISO software accessibility standard (9241 part 171). 3-P, which is harmonized with the equivalent provision in WCAG 2.0, is targeted at developers of user interfaces that are rendered by user agents such as Web content that contains interactive form control elements or user interface components implemented with scripting languages.

Additional Information

Text from Web and Software

Source: {508}1194.21(l) & .22(n)

Impact: Significant: Rich Internet Applications will have to implement the ARIA standards. Significant positive impact to end users and agencies. IT-AT interoperability will be improved and less customization should be required.

3-SS: Visual Indication of Keyboard Shortcuts (no consensus) There were two versions of this provision under discussion, but final text was not agreed on.

Version 1 All KEYBOARD commands associated directly with user interface controls must be visible within the visual user interface in at least one mode, and available programmatically to AT on products that support AT interoperability.

Version 2 All KEYBOARD commands associated directly with user interface controls must be visible within the visual user interface in at least one mode. These notes are for both versions

Note 1: This includes commands such as those used to active a menu item or button (e.g.,the "S" of a "Save File" menu item), but does not include commands that are system-wide or common conventions for using an item (e.g.,a command to switch windows such as ALT-TAB, or a command to advance the caret in text such as Ctrl-Arrow). Note 2: User-configurable keyboard commands may be considered not directly tied to interface elements. However, when possible such user-configurable keyboard bindings should be visually presented as configured.

Viewpoints from Committee Members Microsoft: There may be more than one keyboard sequence associated with a user interface control, only one of these should need to be shown in the user interface. Suggest adding [At least one of any] to the beginning of this provision. The scoping of what is a keyboard command needs more work. Suggest removing both the notes and replacing it with the following text as part of the provision: “A keyboard command can be considered 'associated directly' when it is a keyboard command associated with a specific instance of a type of control, and that control association is not dependant on transient conditions of operation or user configuration.”

Adobe: Adobe supports a more clearly scoped version of 3-SS. Providing visual indication of keyboard shortcuts is beneficial, but has the potential to be overwhelming in some situations. With complex controls there may be several shortcuts for example a calendar control may have shortcuts for moving to the first or last dates in a month, moving to the next month, moving to the next year, as well as shortcuts for selecting contiguous and non-contiguous date ranges. Adobe recommends that 3-SS be an advisory note.

IBM: IBM notes that this provision is not included in either of the international accessibility standards for Web (WCAG 2.0) or software (ISO 9241 part 171), Its inclusion would create a unique requirement for the US assuming other countries harmonize with international standards. For most desktop software applications, this is not a problem as this feature is a widely accepted convention followed by most, but not all, platforms and applications. IBM acknowledges, however, that failure to identify the keyboard shortcuts in the user interface significantly impacts the productivity of sighted keyboard-only users and recommends that this provision be included as an advisory note.

W3C/WAI: We support version 2. However, even with this simplification, the remaining aspect of the provision still needed further discussion and development beyond the time available through the TEITAC process. Individual conversations with developers across most platforms appear to have resulted during the final weeks of TEITAC process in acknowledgment that there was a valid user need here for people with limited use of their hands who need visual indication of keyboard shortcuts without relying on pointing devices or extended sequential navigation to discover such shortcuts. But the variability of terminology for different forms of keyboard interaction, coupled with the varied feasibility of supporting visual indication of keyboard shortcuts, commands, navigation options, etc., means that the provision must be very clearly and carefully stated. In addition, since this user need had not been recognized at the appropriate level by ISO nor by W3C/WAI's User Agent Accessibility Guidelines 1.0, there was a concern about lack of harmonization if it became a requirement under Sec 508.

This issue has been taken up for further exploration through the development of W3C/WAI's User Agent Accessibility Guidelines 2.0, and several developers and user representatives have committed to refining an appropriate and feasible cross-platform requirement to meet this user need. W3C/WAI would like to offer such language to the Access Board as a suggested approach for meeting this need, at such time as we have been able to develop that language. This would also provide an avenue for addressing harmonization concerns that were raised regarding this user need.

Additional Information

Text from Committee

Source: New: Accompanies Subpart D: 1.1-B - Keyboard Shortcuts

External Reference: Possibly harmonized with ISO 9241-171 - 9.3.11

Testability: Inspection

Disabilities: Blindness, Dexterity

3-U: AT Interoperability (partial consensus) The Committee reached consensus on much of the text in this provision. In the draft below, the text in bold italics was not agreed to.

On platforms that support AT-E&IT interoperability, software that provides user interface components 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: 1. Expose object information including but not limited to:

a. Role, state(s), boundary, name, and description b. The row and column a component is in, and the headers for the row and column for that component, if it is in a table that has row or column headers, c. Current value and any minimum or maximum values, if the component represents one of a range of values d. Relationship this component has as a LABEL for another component, or being LABELED by another component e. Name of parent or containing element, and any children components f. TEXT contents, TEXT attributes, and the boundary of TEXT rendered to the screeng. Keyboard shortcuts and implicit designators.

In order to meet this provision, INTERACTIVE ELEMENTS encoded in data operated on by the software must be associated with sufficient information to programmatically determine a role, state(s), name, and description for the interactive element, that the software can obtain as readily as it can obtain the interactive element itself.

2. Expose a list of actions that can be executed on an object and allow ASSISTIVE TECHNOLOGY to programmatically execute any of those actions; 3. Expose information necessary to track and modify: focus, text insertion point, and selection attributes of user interface components; 4. Expose notification of events relevant to user interactions, including but not limited to changes in the component's state(s), value, name, description, or boundary

Note 1: This provision also applies to forms in the software. Note 2: Software that provides remote access to graphical user interfaces (GUIs) would need to ensure that AT has access to the information required by this provision. There are two known ways to accomplish this: run the AT remotely as well or run the AT locally and provide a mechanism for it to communicate accessibility information with the remote GUI.

Rationale The current provisions in Section 508 that address interoperability with AT are 1194.21(c), 1194.21(d) and 1194.21(f). "Sufficient information" in 1194.21(d) is not testable and the three requirements together are insufficient to meet the needs of assistive technology. The proposed provision is much more comprehensive. It details what type of object information must be provided and includes event notification, which is critical for assistive technology interoperability. It is also harmonized with ISO 9241-171 and is supported by the major accessibility APIs on desktop operating systems. The phrase beginning "or other services to cooperate with assistive technologies" is provided to allow for other methods of cooperating with assistive technology where platforms and APIs are insufficiently mature to support the necessary functions.

Advisory Note to the Access Board: This is one of the provisions that is affected by the difference of opinion or position on AT. See Viewpoints from Committee Members below for additional information. Note: The word "components" was used in this provision instead of "objects" since objects is a programming term and can be confusing to vendors. By using the term components it is more generic and will hopefully lead to less confusion.

Viewpoints from Committee Members Microsoft: In general we support this provision, which was carefully crafted between the various stakeholders, except for bullet g, which was added at the last minute. Bullet g. is redundant with item 2, and should be removed; or at the very least scoped as suggested for 3-SS, so that it refers to commands 'associated directly' with components, that is, when it is a keyboard command associated with a specific instance of a type of control, and that control association is not dependant on transient conditions of operation or user configuration.

IBM: IBM strongly supports removing or rewording item 1g of this provision to resolve issues keeping this provision from reaching consensus. Currently, AT interoperability with software requires a high degree of customization as software products are not exposing sufficient information programmatically. This provision was developed collaboratively by representatives of both IT and AT industry. When both software and assistive technology support the requirements in this provision in a common way which is currently supported by accessibility services on most desktop platforms, interoperability will improve and the need for customization will be reduced or eliminated. This is a big step forward from the current Section 508 requirements which do not go far enough.

Trace/AFB: We support this provision as written with the caveat that somewhere it is made clear that it means that all this information is provided in a way that it can be accessed and used by AT that is available to users. If the information is exposed so that AT can access it but there is no AT that does then employees with disabilities will not be able to use the product if it is purchased. We acknowledge the problems with bugs in the AT and consideration need to be made for these. But for a product to claim that it should be purchase-able because it will meet 508 intent (that people with disabilities can use it) through AT compatibility then there needs to be AT that will in fact work with it. This is a general issue for all provisions that talk about AT interoperability or programmatically Determinable.

Adobe: Adobe supports 3-U, with the exception of g, for reasons similar to that of 3-SS, which is that this is sufficiently broad to make testing imprecise.

Sun: Sun strongly supports all of the consensed portions of 3-U AT Interoperability - for reasons well stated already by IBM and ATIA. Like IBM, we feel the current language of 1g (the sole portion of 3-U without consensus) is troublesome. It is too broad, covering both "direct" keyboard shortcuts (e.g. the "Ctrl-P" of a Print menu item in a file menu), and "indirect" or "sequence" keyboard shortcuts (e.g. the sequence "Alt-F" followed by "P") - when we believe only the "direct" ones are intended. Likewise there are "implicit" designators (such as Alt-TAB to switch between top-level windows) that we believe are likewise not intended to be covered. As we ran out of time to finish working through the late suggested addition of 1g, we believe at this time it should either be removed, or re-written to address the issues just outlined. Sun suggest renaming this provision to “3-U Exposure via Accessibility Services”

ATIA: ATIA supports the inclusion of the AT Interoperability provision 3.U. ATIA has worked closely with representatives from the consumer groups and IT, and believes this provision is essential to improved compatibility between AT and E&IT. Many of the other compromises reached throughout the provisions are based upon the revisions to this section. The language in this draft goes further and is far more specific than the existing provisions. We believe this additional specificity is necessary to improve interoperability between AT and E&IT. We fully support all of the language in the draft version of this provision, and note the importance of Section 1.g. on keyboard shortcuts (which is also critical for access by persons with physical disabilities). ATIA also endorses the notes attached to this provision.

Additional Information

Text from Web and Software

Source: {508}1194.21(d), (c), & (f)

Impact: Significant: More specificity of the information that must be exposed to AT. Significant positive impact to end users and agencies. IT-AT interoperability will be improved and less customization should be required.

External Reference: Harmonized with ISO 9241-171

Testability: Expert evaluation

Disabilities: All

3-VV: Assistive Technology (no consensus) This provision was the subject of much discussion, and no agreement to include it was reached.

ASSISTIVE TECHNOLOGY must utilize the PLATFORM SOFTWARE ACCESSIBILITY SERVICES that meet section 3-V: Accessibility Services, to the extent that the information is appropriate to the AT function, in order to provide the alternative user interface(s) to people with disabilities. PLATFORM ACCESSIBILITY SERVICES includes but is not limited to the items listed in 3-U: AT Interoperability.

Rationale The purpose of 508 is to change the work environment such that people with disabilities can be hired into positions where the E&IT is already accessible. Since AT will remain a key component of that environment - for efficiency & productivity of the employee with a disability - E&IT and AT must work effectively together. Placing a burden solely on E&IT to achieve this result doesn't work for numerous reasons (articulated elsewhere). Since AT and E&IT are typically procured at different times under different procurements, the best way to ensure they work together is to require that both utilize the same mechanisms for inter-operating: namely the 3-V Accessibility Services providing the information enumerated in 3-U AT-IT Interoperability.

Advisory Note to the Access Board When we say that "E&IT works with AT" or "E&IT is accessible 'through AT'" or information presented by E&IT "programmatically determinable" we mean that E&IT either:

is known to work with AT that is available to users or has been tested with an API tool and passes where it has been shown that passing the tool will result in E&IT that will work with AT that is available to users

Viewpoints from Committee Members ATIA: ATIA vehemently opposes the inclusion of provision 3.VV in the 508 regulations. First, the professed purpose of the mandate is to improve interoperability between AT and E&IT. Unfortunately, it is a fallacy to believe that merely requiring AT to utilize APIs will result in automatic plug and play interoperability. At this point in time, neither AT nor E&IT can guarantee that the products will work seamlessly without further efforts, testing, and some degree of customization with respect to more complex AT. Use of an API should never serve as a proxy for actual interoperability. Interoperability is a process, and this provision creates the misimpression that if both E&IT and AT utilize an API, we will have magically solved interoperability problems. Indeed, it is quite possible for both E&IT and AT to utilize APIs and still be incompatible. ATIA believes that APIs are a significant improvement in technology that will go a long way towards improving interoperability. However, there are numerous circumstances in which APIs fall short, or improper implementation of APIs makes it impossible for AT to utilize APIs to achieve access. To that end, AT must have the discretion to utilize APIs as appropriate in developing AT, and E&IT should provide those APIs. As E&IT improves the implementation and depth of their APIs, that process alone will encourage more AT to adopt and utilize the APIs.

Additionally, the provision also misunderstands the nature of most Federal Government acquisition of AT. Most purchases of AT are not made under the traditional Section 508 purchase processes, but rather under Section 504 as an accommodation for specific individuals with disabilities. Consequently, the provision will not be applied in most AT purchases, and will therefore not have an impact on the AT industry, or prevent the federal government from acquiring AT that fails to use APIs. ATIA believes this provision exceeds the mandate of the TEITAC because it is overbroad to the extent that it touches on 504 purchases of AT.

Finally, ATIA is concerned that this provision will reduce the cooperative effort that has existed between AT and E&IT since the first 508 regulations. For the past 5 years, AT and IT have increasingly been working closely together to improve interoperability. These relationships run deep, and we expect they will continue in the future. We believe that the regulations should reflect an understanding of how our industries work together to arrive at interoperability. We should not encourage a situation in which E&IT could say we utilized the API, however, there is nothing else we can or will do to ensure interoperability with AT and we believe that the inclusion of this provision would do just that for some companies. We do agree that procurement officers should consider interoperability and the extent to which AT utilizes APIs in determining the likelihood of accessibility between the AT and E&IT it purchases, but we see this as a recommendation that should be made in the FAR rather than in the 508 regulations.

Sun: Sun feels strongly that this is an important provision which should be adopted by the Access Board. The technical standards enumerate the specific aspects of technology acquisitions that agencies should ensure are present before procuring E&IT. These three components: platform, application software, and assistive technology all have important roles to play in forming an accessible E&IT environment, and procurement must take this into account, else the result may be a failure of accessibility. It is important that we provide guidance to agencies for what needs to be present in procured AT in order for it to interoperate with E&IT. Without this provision or one like it, only the platform E&IT and application E&IT interoperability aspects are addressed.

Additional Information

Text from Web and Software

Source: New

Impact: None for current desktop operating system platforms. Significant for applications that are also platforms and for non-desktop platforms. All desktop operating system platforms meet the requirement. Not all applications that are also platforms and non-desktop platforms meet the requirement.

6-D: Caller and Status Information (no consensus) There were two versions under discussion. The Committee agreed that his provision will be removed if 1-E and 1-H reached consensus, however 1-E is also incomplete.

Version 1 Products with visual interfaces that display TELECOMMUNICATIONS status information (such as caller identification and similar TELECOMMUNICATIONS functions) must also make this information available for:

1. Users of TTYS, 2. Users of other TEXT conversation systems, and 3. Users who cannot see displays.

These products must also meet all accessibility provisions for software and CONTENT.

Version 2 Products with visual interfaces that display TELECOMMUNICATIONS status information must: 1. Provide at least one mode that does not require speech or hearing or speech to operate the visual display 2. At least one mode where information is available in a non-visual manner.

Examples of status or TEXT information includes caller identification.

These products must also meet all accessibility provisions for software and CONTENT.

The display capability of the TELECOMMUNICATIONS product must not be disabled when the phone is used in conjunction with a TTY device.

Viewpoints from Committee Members IBM: IBM notes that this provision, as worded, would be applicable to software products that display telecommunications status information. But since TTY devices connect to telecommunications equipment, not software, there is no known way for software to implement the requirement. And the requirements in this provision are already covered by 1-A, 1-D, and 1-H in the General Technical Provisions section. This provision therefore is not needed.

Trace: If provision 1-E (Visual information) is accepted then this provision is covered by other technical provisions. If 1-E (Visual information) is not then this is not fully covered. (Part of this would be a subset of 1-E. so 1-E would cover this but this would cover only a very small specific use-case of 1-E). Note that this applies both to TTYs and to VoIP real-time text devices/software.

Additional Information

Text from Telecommunications

Source: {508}1194.23(e)

Testability: Inspection

Disabilities: Deafness, Blindness

7-C: Prompts (no consensus) There were several versions of this provision under active discussion, but there was no decision as to whether it should be included.

Version 1 AUTHORING TOOLS with a user interface must provide a mode that prompts authors to create accessible CONTENT. Note: It is neither expected nor possible that prompts be available for every type of accessible content.

Version 5 An AUTHORING TOOL, or suite of tools used to author content, whether such suite is composed of tools from a single vendor or multiple vendors, must provide a mode which prompts authors to create accessible CONTENT for accessibility problems that the tool or suite has the capability to correct, for formats authored by that tool or suite that support compliance as explained in the definition of AUTHORING TOOL.

Version 7 An AUTHORING TOOL, or suite of tools used to author content, must provide a mode which prompts authors to create accessible CONTENT, for formats authored by that tool, for accessibility problems that the tool or suite has the capability to correct.

Note 1: It is neither expected nor possible that prompts be available for every type of accessible CONTENT. Note 2: A suite of AUTHORING TOOLS can be composed of tools from a single vendor or multiple vendors.

Advisory Notes to the Access Board 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 regarding version 7:

This standard as written lacks specificity, while at the same time acknowledging that it is likely impossible to specifically define all of the prompting needed for each accessible format. The result is a situation where both authoring tool software engineers and Government procurement officers will be unable to determine if they are meeting the standard. If included as is, it is anticipated there will be procurement difficulties where common understanding needs to be negotiated between sales people and purchasers, potentially on a sale-by-sale basis.

It is also unclear what an HTML authoring tool [potentially the most straightforward scenario] would need to do to for prompting to meet this standard.

This standard may need to be moved to a recommendation rather than a full standard unless we are willing to set what some people might feel is a very low bar that can be applied to all possible content that authoring tools may create.

Viewpoints from Committee Members SSA: Provision 2-D (Accessible Content) under Subpart D places a significant burden on federal agencies to produce accessible content, a provision that will affect a significant number of federal employees. Given the complexity of the 508 standards as proposed, the dependence on authoring tools to provide appropriate prompting is significant. Lack of clarity or resolution on what level of prompting is required will have a deleterious effect on each agency's ability to implement provision 2-D.

W3C/WAI: Version 7 of this provision includes several concepts which would be important to consider retaining in any further rewording of the provision, but it is also missing some important concepts. Specifically:

- It is important to retain the concept that the prompting capability can be either within an authoring tool, or within other authoring tools that are part of a suite of tools offered by a vendor. This flexibility would be helpful for some authoring tool vendors in meeting this provision, and could still provide prompting functions needed to facilitate production of accessible content, as long as prompting were supported within the suite for all formats which meet electronic content provisions. However this flexibility should not be so general as to permit that prompting could be accomplished with a tool that is not part of the suite being offered by a vendor. - Missing from this version however is the important concept that this requirement should only apply to tools which have a user interface. - In addition, a concern was raised regarding insufficient specificity of the provision to enable clear assessment of conformance. While we tried to address this with a scoping note stating that it is neither expected nor possible that prompts be available for every type of accessible content, this was still considered open to too much interpretation by procurement officers, leaving developers not knowing whether they had met the requirement until they were already engaged in procurement process around a completed product. I believe that it would be useful to find an appropriate way to more clearly scope this requirement, however without being overly prescriptive about which content types to prompt for, as that may be too constraining as technologies evolve. - The concept of "a mode which prompts" as opposed to a default configuration is important to retain so that prompting is not active in situations where it might interrupt the creative process; however it should be able to be configured so that it may apply at different points in the development process, for instance when reviewing image selection, or prior to publishing a document. - The suggestion has been made that this provision should be at the level of recommendation, not requirement. The capability for authoring tools to prompt for accessible content would have the potential to significantly facilitate the work of content developers in complying with electronic content provisions, if this were to become a requirement.

Additional Information

Text from Web and Software

Source: new

External Reference: ATAG, ISO9241-71

Testability: Inspection

Disabilities: All

7-D: Accessible Templates (No consensus) There were several versions of this provision under active discussion, but there was no decision as to whether it should be included.

AUTHORING TOOLS which provide pre-authored CONTENT, or templates to facilitate production of CONTENT, must provide at least one version that meets applicable Section 508 provisions. Note: This provision should not be applied to formats which are not enabled for accessibility support; nor does it require an accessible template for every template that is packaged with an authoring tool.

Viewpoints from Committee Members W3C/WAI: Accessible templates and accessible pre-authored content provided with authoring tools can be highly effective in facilitating conformance to a variety of electronic content provisions. Authoring tool vendors know their tools better than their customers and can more efficiently develop sample templates and pre-authored content, which can help model how to use the tool's features in ways that support accessible content provisions.

A significant concern with the wording of this provision however was apparently a potential ambiguity with the scoping of the provision, due to the phrasing "...at least one version that meets applicable Section 508 provisions," even with the accompanying note that this does not require an accessible template for every template that is packaged with an authoring tool." In other words, it could be interpreted as requiring only one template in all, which would not have significant benefit; or conversely it could be interpreted as requiring very many accessible templates. Further discussion would be needed to arrive at appropriate scoping of the requirement.

Version 5 Information about KEYBOARD shortcuts, including available KEYBOARD commands and KEYBOARD navigation mechanisms, must be listed in centrally located user documentation, and available in context-sensitive help.

Version 7 Information about KEYBOARD shortcuts and implicit designators must be listed in centrally located user documentation, and available in context-sensitive help.

Version 8 Information about KEYBOARD operation, including available KEYBOARD commands and KEYBOARD navigation mechanisms, must be listed in user documentation, such as online help, context-sensitive help, or printed user's guides.

Note: The inclusion of a comprehensive listing of keyboard shortcuts for an application in a documented location is suggested as some users benefit from a single, centralized resource. Note: Centrally located user documentation can be in more than one location, but should be able to be located through application help.

Version 9 Information about KEYBOARD operations, including available KEYBOARD commands and KEYBOARD navigation mechanisms, must be listed in electronic documentation, such as online and context-sensitive help.

Note: The inclusion of a documented comprehensive listing of KEYBOARD shortcuts for an application is suggested as some users benefit from a single, centralized resource.

Rationale The documentation of keyboard shortcuts can be hard to locate. This provision would require that this information be available in a useful form.

Viewpoints from Committee Members Microsoft: Replace “…must be listed…” with “…must be provided…”

IBM: IBM supports the inclusion of version 9, but would prefer to see it refer to either online or context-sensitive help. This version meets the need of keyboard-only users yet allows developers the flexibility to determine the most usable way to document them.

Wc3/WAI: Because of time constraints in the final TEITAC meeting, the language in version 9, which had apparently reached consensus between parties who had been involved in discussing the issue, could not be confirmed with the full committee for consensus. W3C/WAI supports that language. Since then, a comment was also received on this topic, suggesting substitution of "provided" instead of "listed." W3C/WAI would support that language equally. It is possible that on this topic, W3C/WAI's User Agent Accessibility Guidelines Working Group (UAWG) might also have more in depth discussion of appropriate and feasible ways to meet this user need, and if so will also offer any new insights and/or wording to the Access Board if those become available.

Additional Information

Text from Documentation and Technical Support

Source: New

Impact: +

Testability: Inspection

Disabilities: All

Definitions Considered but Not Completed There were several definitions considered, but which did not reach consensus. Some of these terms are not used in the provisions, but were drafted for earlier versions.

Accessible Content Format Version 1: A format that supports the creation of CONTENT to meet Section 508 requirements. Version 2: A data format that enables the encoding of information in such a manner that it is consistent with the relevant provisions of Section 508.

Application Software: Software which runs on and makes use of services provided by PLATFORM SOFTWARE. This includes "desktop" software bundled with an operating system, personal productivity applications, development tools, Web browsers, and other non-OS software.

Authoring Tool: (Recommended for acceptance, but never formally accepted.) Any software intended to create or modify electronic CONTENT for publication in one or more formats that support compliance with the user interface and CONTENT provisions. Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.

Blinking: Switch back and forth between two visual states in a way that is meant to draw attention. Note: See also flash (It is possible for something to be large enough and blink brightly enough at the right frequency to be also classified as a flash).

Captions: (Version 3 was agreed to by the task force, but the Committee did not have enough time to bring this definition back up for a consensus decision.)

Version 1: Captions are synchronized TEXT equivalents for audio information. Captions are similar to subtitles in that they convey the CONTENT of spoken dialog, but also include TEXT for non-spoken information such as important sound effects, music, laughter, and speaker identification and location. Captions should not obscure or obstruct relevant or key information. In some countries captions are called subtitles.

Version 2 (from WCAG 2.0): SYNCHRONIZED MEDIA or TEXT equivalents for audio information including both dialog and non-dialog audio information

Note 1: Captions are similar to dialog-only subtitles except captions convey not only the content of spoken dialog, but also equivalents for non-dialog audio information needed to understand the program content, including sound effects, music, laughter, speaker identification and location. Note 2: Closed Captions are captions that can be turned on and off in some players. Note 3: Open Captions are captions that cannot be turned off. For example, if the captions are visual equivalent images of text embedded in video. Note 4: Captions should not obscure or obstruct relevant information in the video. Note 5: In some countries, captions are called subtitles. Note 6: Video descriptions can be, but do not need to be, captioned since they are descriptions of information that is already presented visually.

Version 3: Synchronized “TEXT” and symbol equivalents for audio information.

Note 1: The term “text” in this definition refers both to electronic text and to images of text that might be embedded in video. Note 2: Captions are similar to dialogue-only subtitles except captions convey not only the spoken words, but also other audio information needed to understand the program content, including sound effects, music, laughter, tone of voice, speaker identification, and location. Note 3: Captions can be “closed” or “open”. Captions that are “closed” can generally be turned on and off by viewers. Captions that are “open” are any captions that cannot be turned off. For example, captions that are visual equivalent images of text embedded in video are “open.” Note 4: Captions should not obscure or obstruct relevant information in the video. Note 5: In some countries captions are called subtitles. Note 6: Video descriptions can be, but do not need to be, captioned because they are descriptions of information that is already presented visually.

Rationale for version 3: Some of the issues that came up on the side discussions that are all addressed above are as follows.

1. Captions are not just text but also include other symbols (music notes etc) that should be allowed. 2. The word ‘text’ is ambiguous since we allow images of text here but images of text cannot be used as text in other parts of these same guidelines. Need a note to clarify 3. If we just say visual equivalents – then sign language would satisfy this and it shouldn’t – that shouldn’t be called captioning. 4. Open captions are not just images of text embedded in video stream – but can be any captions that cannot be turned off and on. 5. Closed captions cannot be turned on and off in all players/viewers. 6. Can we use dialogue instead of dialog to avoid confusion with dialog boxes (in which captions can in fact be presented). 7. Non-verbal (which means non-word) can separate out visual signing from visual symbols like music notes but many people misread non-verbal to mean non-vocal or non-speech and that creates all sorts of new problems. the “non-spoken” is close here but the cue that the person is SHOUTING is non-verbal but not non-spoken so ‘non-spoken’ misses some of the important information. 8. Keep it simple - (at one time the definition had grown to “synchronized visual equivalents for both dialogue and non-dialogue audio information needed to understand the media content where the equivalents are either text or images of text combined with non-verbal visual elements (such as music notes).”) until we regrouped and went back to the simple one we had and just applied the essential fixes needed to it. 9. ‘symbols’ doesn’t cover font styling and color – but that could be covered by word ‘text’ in definition since they are characteristics of text and adding “and font styling and color” to the definition would make it more complete as the expense of making it more complex.

Caption Text: (This definition was proposed for removal, in favor of the term “Captions.) (Definition from WCAG).TEXT presented and synchronized with SYNCHRONIZED MEDIA to provide not only the speech, but also non-speech information conveyed through sound, including meaningful sound effects and identification of speakers.

Note 1: In some countries, the term "subtitle" is used to refer to dialogue only and "captions" is used as the term for dialogue plus sounds and speaker identification. In other countries, subtitle (or its translation) is used to refer to both. Note 2: Video descriptions can be, but do not need to be, captioned since they are descriptions of information that is already presented visually.

Enhanced Audio: Audio which has been enhanced through amplification and/or through a variety of audio signal processing to make it easier for people with hearing loss to understand. This definition was added to support 1-E - With Limited Hearing. If the provision is rewritten, it is not needed. Current drafts do not use this term.

Flash: A pair of opposing changes in luminance (RELATIVE LUMINANCE for software and CONTENT) that can cause seizures in some people if it is large enough and in the right frequency range.

Note 1: See GENERAL FLASH THRESHOLD AND RED FLASH THRESHOLD definitions for information about types of flash that are not allowed. Note 2: See also BLINKING.

Free-Standing: Standing on the floor and not intended to be placed on a table or built into a structure Example: The kiosk was a free-standing device that stood on the carpet in front of the registration desk. Note: The subcommittee is requesting input on whether this should be defined since it is used in other parts of the ADA regulations and could have impacts there.

General Flash and Red Flash Thresholds for Content and User Interfaces: A flash or rapidly changing image sequence is below the threshold (i.e., software or CONTENT passes) if any of the following is true:

1. There are no more than three General Flashes and / or no more than three Red Flashes within any one-second period; or 2. The combined area of FLASHES occurring concurrently occupies no more than a total of .006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen) at typical viewing distance where:

A General Flash is defined as a pair of opposing changes in RELATIVE LUMINANCE of 10% or more of the maximum RELATIVE LUMINANCE where the RELATIVE LUMINANCE of the darker image is below 0.80; and where "a pair of opposing changes" is an increase followed by a decrease, or a decrease followed by an increase, and

A Red Flash is defined as any pair of opposing transitions involving a saturated red. Exception: FLASHING that is a fine, balanced, pattern such as white noise or an alternating checkerboard pattern with "squares" smaller than 0.1 degree (of visual field at typical viewing distance) on a side does not violate the thresholds.

Note 1: For general software or Web CONTENT, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the CONTENT is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances (e.g.,15-17 inch screen at 22-26 inches). (Higher resolutions displays showing the same rendering of the CONTENT yield smaller and safer images so it is lower resolutions that are used to define the thresholds.) Note 2: A transition is the change in RELATIVE LUMINANCE (or relative luminance/color for red flashing) between adjacent peaks and valleys in a plot of relative luminance (or relative luminance/color for Red Flashing) measurement against time. A FLASH consists of two opposing transitions. Note 3: The current working definition in the field for "pair of opposing transitions involving a saturated red" is where, for either or both states involved in each transition, R/(R+ G + B) >= 0.8, and the change in the value of (R-G-B)x320 is > 20 (negative values of (R-G-B)x320 are set to zero) for both transitions. R, G, B values range from 0-1 as specified in “relative luminance” definition. (Harding and Binnie 2002) Note 4: Tools are available that will carry out analysis from video screen capture. However, no tool is necessary if FLASHING is less than or equal to 3 flashes in any one second period (content automatically passes (see #1 and #2 above).

Information Technology: Any equipment or interconnected system or subsystem of equipment, that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information. The term information technology includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources.

Interactive Elements: Elements of the user interface that are acted on by the user.

Manufacturer: A manufacturer of TELECOMMUNICATIONS or VoIP equipment or customer premises equipment that sells to the public or to vendors that sell to the public; a final assembler. This definition was requested to support Section 255. However, it is limited to telecommunications-related context, and is used more generally in the recommended provisions, so needed to be changed to be more general.

Menu: Set of selectable options. This came from one section of provisions, but is used in several places, and text was never created to make it more general

Peripheral Devices: Devices employed in connection with TELECOMMUNICATIONS or VoIP equipment or CUSTOMER PREMISES EQUIPMENT to translate, enhance, or otherwise transform TELECOMMUNICATIONS or VoIP services into a form accessible to individuals with disabilities. This definition was requested to support Section 255

Platform Accessibility Services: Services provided by a platform enabling interoperability with ASSISTIVE TECHNOLOGY, commonly in the form of accessibility APIs (application programming interfaces).

Programmatically Determinable

Version 1 Can be determined by software from data provided in a user-agent-supported manner such that various user agents including assistive technologies can extract and present this information to users in different modalities.

Version 2 Determinable by user agents, including ASSISTIVE TECHNOLOGIES, from the data provided. Note 1: Purpose is to allow user agents including ASSISTIVE TECHNOLOGIES to extract and present this information to users in different modalities. Note 2: Programmatically determinable requires that the information be determinable by existing ASSISTIVE TECHNOLOGIES.

Version 3 (WCAG) Determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities. Example 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology. Example 2: Determined from technology-specific data structures in a non-markup language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.

Real-time Text (RTT): Communications that employ the transmission of text wherein the characters are transmitted by a TERMINAL within a maximum of 1 second of character input. This would typically be for conversational purposes but also may be used in voicemail, IVR and other similar applications.

Relative Luminance: The relative brightness of any point in a colorspace, normalized to 0 for black and 1 for maximum white

The "^" character is the exponentiation operator. (Formula taken from sRGB and IEC-4WD.)

Note 2: Almost all systems used today to view Web CONTENT assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3. Note 3: If dithering occurs after delivery, then the source color value is used. For colors that are dithered at the source, the average values of the colors that are dithered should be used (average R, average G, and average B). Note 4: Tools are available that automatically do the calculations when testing contrast and FLASH. Note 5: A MathML version of relative luminance definition is available at the WCAG web site.

Simple Tactile Form: Tactile form that does not require the memorization of any spatial or temporal tactile patterns.

Note 1: Simple vibration or switch up/down positions are examples of simple tactile forms. Note 2: Braille, tactile Morse code, and vibration patterns are samples of more complex tactile forms that require memorization of non-trivial spatial and tactile patterns respectively, and therefore are not Simple Tactile Forms. Note 3: Different numbers of tactile buzzes, or different frequency buzzes would be non-trivial patterns, and would not be simple tactile forms.

Text: Sequence of characters that is PROGRAMMATICALLY DETERMINABLE, where the sequence is expressing something in human language.

Video Description: The insertion of verbal or auditory description(s) of on-screen visuals intended to describe important visual details that are not contained in, or that cannot be understood from, the main audio output alone. Video descriptions supplement the regular audio track of the program and are usually inserted between dialogue narration to provide information about actions, characters, and on-screen TEXT that appear without verbalization. Video descriptions are a way to let people who are blind or have low vision know what is happening on screen.

Advisory Notes to the Access Board The American Foundation for the Blind along with the National Center for Accessible Media at WGBH (NCAM), under contract from the Described and Captioned Media Program (U.S. Department of Education) administered by the National Association of the Deaf, is developing guidelines and best practices for authoring video description. As of August 2007, a first draft has been developed by an expert committee of academics, educators, producers, consumers and others. These guidelines should be completed by the end of 2008. This definition should not conflict with these guidelines

Proposed Additions to Subpart A but Not Accepted Exception: Narrow, Delineated Use (no consensus) The TEITAC could not reach an agreement on whether this should be added as a new exception, though there was general agreement that it identifies an important issue. The Committee agreed to provide this information to the Access Board for its consideration.

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.

Advisory Notes to the Access Board This exception is intended to address situations where conformance to the technical and performance standards can create 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.

Despite long discussions and exploration of approaches, (such as identifying products as "personal-private", the concept of a "product line" approach) we have not reached consensus on a viable approach to addressing the problem.

In favor: Some committee members support creating an exception to address this problem

In opposition: This is a dangerous and unnecessary exception, which is likely to be abused. "Products with narrow delineated use" is not clearly defined.

Exception: Emergency, Field, and First Response Use (no consensus) The Department of Homeland Security representative proposed a new exception. The Committee discussed this provision at length and could not reach consensus on if it was needed. It was felt “fundamental alteration” should be used instead of creating a new exception. There was also concern that it could create a loop hole for large groups to avoid accessibility requirements and possibly reduce the effectiveness of Section 508.

This part does not apply to any ELECTRONIC AND INFORMATION TECHNOLOGY operated by agencies in a field environment where the function, operation, or use is by a first responder, emergency, security, or law enforcement personnel. This exception does not apply to the agency systems administrative and business applications (including payroll, finance, logistics, and personnel management applications) or any application or system that is intended for use by members of the public.

Advisory Notes to the Access Board Currently the national security exception directly addresses the accessibility exception for electronic and information technologies used as integral parts of weapons or weapons systems, in command-and-control, cryptological activities, and for direct support of intelligence and military missions. The underlying theme of that exception is often what might be considered emergency, or field conditions, and physical requirements as a prerequisite for employment. These same conditions are met in situations such as first responders, fire-fighters, law-enforcement personnel in the field, etc. Because of this similarity some Federal agencies such as Department of Homeland Security, Department of Justice, some portions of the Department of the Treasury, for example, encounter Section 508 acquisitions situations which mirror those in the national Security exception, but which are uncovered now. This requires that the agencies either apply fundamental alteration exception to such purchases, which is not always the most accurate fit, or conduct the market research and take accessibility requirements in to account during the process for items never to be used by people with disabilities. While Section 508 standards are intended to lower barriers to employment, they are not intended to remove all such barriers where disabilities and performing the job are in practice and reality mutually exclusive. Note that first responders in practice can be Federal employees or members of the public; however this exception is not based upon this status, rather the work to be performed and the location that work is performed.

Economic impact: Low. This exception will lower the analysis level of Federal requiring officials by addressing this specific situation directly, and lower their potential market analysis workload as well. It will not impact industry negatively as it is not a requirement that they must change business practices or products to meet.

External Reference: Definition of "first responder": From Homeland Security Presidential Directive 8, (HSPD8), the term "first responder" refers to those individuals who in the early stages of an incident are responsible for the protection and preservation of life, property, evidence, and the environment, including emergency response providers as defined in section 2 of the Homeland Security Act of 2002 (6 U.S.C.101), as well as emergency management, public health, clinical care, public works, and other skilled support personnel (such as equipment operators) that provide immediate support services during prevention, response, and recovery operations.

Note: adoption of this provision will require reference of the Definition of First Responder in §1194.4 Definitions.

Open Issues:

The scope is defined as E&IT used by types of personnel, rather than by functions of the E&IT itself. The Committee does not believe that this provision should be based on (or create) disadvantaged classes of people with disabilities.

Several members of the Committee felt that this exception would be open to abuse. One example cited was post-911 field units which helped people locate their children. This could be designated a “first response” function, and people with disabilities would not be able to work in these roles.

Provisions Considered, but Dropped Basic Input/Output System (BIOS) Settings The General subcommittee considered two aspects to the question of whether a provision was needed to cover access to BIOS settings:

BIOS settings that are part of normal operation

Events when a user ends up in the Bios unexpectedly because program has malfunctioned

It also discussed:

Whether requiring users to interact with the BIOS of a system that routinely fails is routine operation or failure/maintenance, especially if the system provides friendly feedback and instruction.

Whether a separate provision is needed because interaction with the BIOS is a routine action for developers.

The subcommittee determined that a separate provision is not needed, because:

Access to the BIOS when the computer is up and running is not covered by the Closed Functionality Provision. All functionality (including setting the BIOS functions) should be operable directly or via AT. AT does not work during the initial "boot" operations, but these functions should be operable from OS after booting, and would take effect when the system is restarted.

If the system will not boot (and load the operating system), the computer or system is broken. This is covered by Subpart A: the scope of 508 is for normal operation, so does not apply in this situation.

If there is an operation during the boot sequence, such as a form to enter a password (especially where a BIOS password is required by agency), large enough print and an audible cue as to when to type the password would allow this to be accessible. Instructions can be given to users in advance, so only thing they need to know when to type the password.