Brainstorm Groupings

Group Definitions

Randy and I took a deeper dive into these topics and have basically organized the list into three groups.

Group 1 – In scope

These are topics specific to the issue of the hardware interaction/interface and are within our scope and the themes

Group 2 – Out of scope

These are topics that may need to be addressed, but we would recommend be handled by another subcommittee or potentially a new subcommittee

Group 3 – Product specific

These were topics specific to a product. Product specific concerns need to be maintained, but if the hardware interaction/interface guidance is well developed, then product specificity should not be an issue.

Group 1 - In Scope

What are the "corporeal" interations that need to be covered? Touch, visual, auditory, cognitive...

Comment - This is the core of what we've been tasked to do. Look at the different physical interactions (force, noises, light, colors, etc.) that are part of effectively interacting with the physical product (not the software or embedded firmware). The taxonomy and your list have a good start on this one. Just need to pull a structure together. Pull in work from General SC.

Cognition – color coding connectors, use of icons instead of text, etc

Comment – This is a required theme to be considered in this process.

The tactile requirement for when a device is all touch screen

Comment – This one is tough from a physical interaction perspective, but can it be managed via industry standard ports to allow for AT?

Existing standards - Hajime (Japan) mentioned several JIS standards

Comment – This is a required theme to be considered in this process.

Which requirements within 1194.26 should be maintained

Comment – The current requirements are focused on the “mechanical/physical” interaction and should serve as the basis for that particular type of interaction.. Need to determine if changes are warranted.

Biometrics requirement – may conflict with security requirements

Comment – I think this one is pretty clear relative to the current language. Especially, when you consider it is the agency that is calling for biometric and thereby “closing” the product. From an interface/interaction perspective the key to biometric may be non-biometric redundancy.

Group 2 - Out of Scope

BIOS – Uhmm...

Comment – outside of our scope; BIOS has nothing to do with an interface/interaction other than “BIOS must communicate”. The what and how is in the way the code is written.

Non-Computer-based E&IT (ie. LCD projector with a smart card)

Comment – We need to focus on the interaction/interface element on this one and still find ownership for the actual firmware/software that make the “system” once the card is inserted and a utility launches. The accessibility of any firmware or embedded software needs to be evaluated in another subcommittee.

Group 3 - Product Specific Situations

This will serve as a parking lot of product specific topics to ensure that they are considered as part of the overall hardware interface discussion.

Handheld portable devices –

Does the mechanical force requirements apply? What about connector requirements? Wireless interconnectivity should be in lieu of mechanical connections.

Comment – yes, I think the mechanical force requirements do apply and are acceptable as written. The connectors is a good question and does an accepted wireless option (RF, BT, IR) meet the intention for connectivity? I can see a strong logic to that discussion.

Keyboard layouts on handheld device –

Should they be required to be consistent?

Comment – Due to the variations in keyboard layouts on a worldwide basis don’t know that we want to specify a layout. This is one where perhaps a “should” rather than “shall” requirement may be best. The keyboard should follow either the “QWERTY” or “Sequential” (in alphabetic order layout), but may be dependent on the size of the device.

The “Product Line” idea –

If a product is too miniaturized to be useable by people with disabilities, then there is another product in the same family that isn’t, but has the same function. In other words, are we going to change the requirement that everything must be accessible to permit a branch in a product line to provide accessible and non-accessible versions?

Servers – Uhmm...

Comment – back office discussion, also reinforces the need to allow for disclosure approach (supports, partially supports, does not support)