Hardware Draft Language Idea Board

Contents 1 Short Names 2 Standard Ports 2.1 NEW PROPOSAL 9/24/07 2.2 June 22 Proposed Language State: 3 Controls Language 4 Biometric Language 5 Simultaneous Controls 6 Operable Controls 7 Hardware Labels

Short Names

Need to evaluate short names for standard. Gregg V had some students take a first stab. They have proposed names on the following link:

http://teitac.org/wiki/SHORT_NAME_PROPOSAL

Standard Ports

NEW PROPOSAL 9/24/07

2.2-C - Audio Connection

When products provide auditory output beyond simple tonal feedback or signaling, one of the following must be true:

(a) Auditory output is available via audio transducer that is designed to be held up to the ear that meets 2.2-A (Magnetic Coupling), 2.2-B (Interference with Hearing Device), and 2.2-E (Volume - gain) and product does not require simultaneous use of keyboard; or

(b) A standard 2.5mm or 3.5mm audio jack at the standard signal levels used for headphones/headsets is provided or

(c) Product is a not designed to be located in a public location and an adapter from the product's audio output format to a 2.5mm or 3.5mm phone jack is commonly available or available from the manufacturer.

Note: RJ-9, USB, and Bluetooth connections all have commonly available adapters. Products (not designed for public locations) with these or other forms of audio connection that have adapters would meet 2.2-C-(c)

Rationale

• public phones have amplification and coupling and that meets needs of almost all users so shouldn’t need a jack
• users should not be required to carry ‘all’ adapters with them so public systems should not require them to have an adapter to use the product (other than a simple 2.5 to 3.5 or 3.5 to 2.5 adapter)
• RJ-9, USB, RCA, and Bluetooth connections all have commonly available adapters. Note was added since there was concern that unless in a note, purchasing agents may not recognize it as allowable.
• Addresses the issue of “private listening’ which is provided via the standard handset.
• Kiosks with keyboards usually require blind people to have both hands free.

How it would apply

• public phones would use (a)
• office phones could use (b) but would likely use (c)
• computers with build in speech conversation could use (b) or (c)
• televisions could use (b) or (c)
• Kiosks without keyboards could use (a) or (b)
• Kiosks WITH keyboards would have to use (b) (or, of course, both a and b)

June 22 Proposed Language State:

• "Where user interface connection capabilities are provided, whether wired or wireless, at least one connection shall comply with publicly available industry standards and all of the user interface functionality available on the non-standard connection(s) should be available on the standard connection."

ALTERNATE

• "Where user interface connection capabilities are provided, whether wired or wireless, at least one connection shall comply with publicly available industry standards and all of the product functionality that is controllable by the user through the non-standard connection(s) shall be controllable by the user via the standard connection using industry standard protocols for that type of input or output."

There has been discussion on the listserv relative to how this language addresses the responsibility of driver development, especially with KIOSK (closed) system interaction.

The context of the language relative to Hardware is that it is to ensure that the "the connection" can be made from the "physical" perspective.

One interpretation from the listserv of the language is:

• IF a company provides I/O functionality on a proprietary connector

• THEN it must provide same functionality on a std connector.

• This provision does not require that any AT drivers be provided.

• It doesn't require that any standard connector be provided. ( a wireless connection would suffice if standard)

• It doesn't require that any standard connection be provided UNLESS there are I/O functions on a proprietary connector.

• IF there is an I/O function on a proprietary connection, it DOES require a driver that provides I/O function on the standard connection.

Current Language:

Where provided, at least one of each type of expansion slots, ports, connectors, and wireless connections shall comply with publicly available industry standards.

The original language was derived from the computer section. Several concerns have been summarized from the listserv conversation (please correct if misinterpretted) including:

1. language implies that if you must have an industry standard for any type on the system
2. language does not address proprietary connectors on other products, e.g. mobile phones
3. AT opinion is that wireless allows for connection without needing to address physical connections
4. concern about the need to differentiate between connections for user interaction (e.g. USB) and connections for operation (e.g. the connection between a paper tray and printer)
5. concerns about language that would allow for propriatary connections - does not feel that proprietary benefit the government

Proposed Language:

1. Where alternate input or output connections are provided, such interface connectivity shall be available through a connection that complies with publicly available industry standards.
2. Where input or output connection capabilities, whether wired or wireless, are provided, such connection capabilities shall comply with publicly available industry standards.
3. Where MULTIPLE input or output connection capabilities, whether wired or wireless, are provided, AT LEAST ONE OF such connection capabilities shall comply with publicly available industry standards.
4. Where MULTIPLE input or output connection capabilities, whether wired or wireless, are provided, AT LEAST ONE OF such connection capabilities shall comply with publicly available industry standards and all of the interface functionality available on the non-standard connection would be available on the standard connection.
5. Where input or output connection capabilities are provided, whether wired or wireless, at least one connection shall comply with publicly available industry standards and all of the user interface functionality available on the non-standard connection(s) would be available on the standard connection.

Supporting definitions:

“Connection means a mechanism whereby interoperability between two devices is made possible, and includes the mechanical, electrical, and software interconnection between the two devices”

Also, we should be clear that the connections we’re talking about are those meant for human interaction (not machine to machine). So, a connector for a duplexer on a multifunction printer would definitely not apply. Something like:

“Standard Connection means an interconnection through which human interface/interaction is made possible”.

Controls Language

Types of controls matrix: Types of Input (Hardware, Touch, Human Touch etc)

There has been long discussion on the "touch" element of controls which has been summarized at Touch Controls.

Control Types:

Mechanical controls - stays the same as currently defined

Proposed names for non-mechanical controls:

1. Non-mechanically operated controls
2. Biophysical controls - controls that rely on biological elements (tissue, eye-track, etc.) of the user to complete the interaction or interface

Biometric Language

MOVED TO GENERAL

The language for 1194.25(d) and 1194.26(c) is the same and is as follows:

When biometric forms of user identification or control are used, an alternative form of identification or activation, which does not require the user to possess particular biological characteristics, shall also be provided.

Proposed language:

When biometric forms of user identification are used, an alternative form of identification, which does not require the user to possess particular biological characteristics, shall also be provided.

Simultaneous Controls

Suggest we add “simultaneous actions” to provision 1194.23 (k)(2)

Current language:

Controls and keys shall be operable with one hand and shall not require pinching, twisting of the wrist, or tight grasping. The force required to activate controls and keys shall be 5 lbs. (22.2 N) maximum.

Proposed language:

Controls and keys shall be operable with one hand and shall not require pinching, twisting of the wrist, tight grasping OR SIMULTANEOUS ACTIONS. The force required to activate controls and keys shall be 5 lbs. (22.2 N) maximum.

Operable Controls

The Subpart A definition is as follows:

• Operable controls - A component of a product that requires physical contact for normal operation. Operable controls include, but are not limited to, mechanically operated controls, input and output trays, card slots, keyboards, or keypads.

Proposed language:

• "Operable controls: any physical control that affects the operation of the product. Operable controls include, but are not limited to, mechanically operated controls, input and output trays, card slots, keyboards, keypads, keys, or buttons, including touch-screens."

Note I added individual keys and buttons, as I've inspected many devices that have only those features where the manufacture thought Section 508 didn't apply because it didn't have "a full keyboard".

There was an interesting exchange on the Listserv on this topic regarding full functionality and normal operation.

Hardware Labels

During the June 15 call, the topic of "readability" for physical labels and various LCD screens was raised.

The proposal is to create language that would address minimum contrast and brightness setting for screens on devices such as copiers.

Should this be a general technical requirement? Should this be two seperate provisions? A label is a fixed element that is dependent on the light in the environment. A screen is typically backlit in some manner and as such generates a different interaction relative to light performance.

Proposed New Section and Language:

• 2.4 If the product has visual output". All electronic visual displays must have a contrast ratio of at least N:1, as a default or as adjusted by the user.

Potential Harmonization Sources -

WCAG 2.0 - 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 have a contrast ratio of at least 3:1.

larger scale (text)

at least 18 point or 14 point bold

Note 1: Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce the familiarity of their letter forms are harder to read, especially at lower contrast levels.

Note 2: Font size is the size when the content is delivered. It does not include resizing that may be done by a user.

ISO 9241-3 - Display must be capable of generating a Luminance contrast ratio of 3:1 (clause 5.16)