Thread Subject: Re: meaning of SUPPORT
Note
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
Return to this mailing list's archives
From: Gregg Vanderheiden
Date: Tue, Apr 03 2007 10:30 AM
Subject: Re: meaning of SUPPORT
Good points
I think that we need to be specific about what "support" constitutes.
Perhaps something like
SUPPORT
1. - passes any accessibility information along with the standard form
of the information
2. - if the hardware already supports the physical aspects needed for
an accessibility feature, then the feature is provided
Specifically that would be things like:
o if a device has text display capability - it will display any text
that is sent to it to accompany voice
o if a device has video capability it will display accessibility
related video sent to it
o if a device has a camera or camera port it will allow use of it on
telecommunication calls
o if a device does not have the hardware needed to create or display
accessibility information - it will allow the connection of devices that do
- and pass the information on to them.
This does not mean that a device needs to add special hardware. Just that
any hardware that it does provide is not unnecessarily unable to be used for
accessibility reasons.
Thoughts?
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Jim Tobias
> Sent: Tuesday, April 03, 2007 10:52 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: [teitac-telecom] attempt at clarification
>
> Hi All,
>
> I'd like to do a better job of expressing my concerns about
> the current drafted telecom language.
>
> We are caught in a dilemma if we use language such as that
> proposed for
> 1194.23(a2):
>
> "Telecommunications products or systems that provide a
> function allowing voice communication and have sufficient
> bandwidth to support real-time video signing but do not
> themselves provide real-time video communication sufficient
> to support signing ... On IP systems it shall be possible to
> transmit text, video and speech in parallel in both directions."
>
> A vendor of an IP voice telecom system (VoIP) or federal
> agency might consider this requirement a fundamental
> alteration, requiring 2 additional functions (text and video)
> from a system intended only to deliver voice telephony. Our
> goal is to make sure that a federal employee or member of the
> public can participate in any conversation taking place on
> the product/system under consideration, whether that
> participation is by voice, text, or video, and whether it is
> direct or via relay. But it may not be possible, using the
> current framework, to require every one of those
> "participation options" from a product/system currently being
> considered for procurement. The breadth of options for
> participation is a function of the overall ICT environment of
> the agency, not the single procurement. An agency whose ICT
> infrastructure facilitates participation via text and video
> on the same voice call over *separate* systems, available on
> the same desktop computer for example, is meeting the intent
> of 508. TEITAC's job is to translate the intent into the
> language we recommend to the Access Board.
>
> However, on the other hand, returning the entire burden of
> compliance to the agency means that the agency would have to
> perform a complete functional assessment of their telecom
> participation options whenever it was procuring any telecom
> product, system, or service, to ensure that whatever they
> were going to buy facilitated all the participation options.
> This runs the risk of deteriorating into an "accommodation"
> perspective, in which the agency would merely have to assure
> itself that any deaf employees could use a separate
> videotelephone capability to participate in voice
> conversations via video relay.
>
> It's not clear to me that we can avoid the accommodation
> perspective altogether. Consider, using the drafted
> language, a system that "supports"
> sign language video. Unless every desktop unit has a camera,
> a deaf employee must be provisioned one separately. Do we
> want to require every unit to have a camera? (Note that this
> is the same issue we've bumped into regarding volume
> control.) The draft, patterned after the current requirement
> for TTY and amplifier connectivity, says that every unit
> "shall provide a standard connection point [for] attaching a
> real-time signing device", but cameras (unlike TTYs and
> amplifiers) come with many different physical connectors, and
> more ominously, many different video encoding protocols.
>
> I don't have a cut and dried answer to this dilemma. I do
> think, though, that our best course lies in drafting
> exceedingly clear functional goals (e.g. better than
> "participate in voice conversations via text or video
> relay") for the "top tier" and relegate the implementation
> strategies to the "second tier".
>
> Such an approach has an additional benefit: it invites active
> participation in the subcommittee's work from people without
> a strong technical background. Instead of focusing on purely
> technical details, we can work together to guarantee that we
> are addressing the real end users' needs.
>
>
>
> ***
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
>
WebAIM is an initiative of:
