Thread Subject: Re: 1-2 A NOTE & AT-IT interoperability
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.
From: Mike Paciello
Date: Sat, Oct 27 2007 6:40 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Takemura, Michael (HP Accessibility): "1-2 A NOTE & AT-IT interoperability"
- Previous message in thread: Jim Tobias: "Re: 1-2 A NOTE & AT-IT interoperability"
- Messages sorted by: Author | Thread | Date
I agree 100% with Jim.
We have a better chance of achieving consensus -- success -- when you focus
on how vested organizations on both sides of the procurement process share
knowledge that leads to increased accessibility and usability for employees
and citizens (where applicable).
Think about the components that make the procurement process a success for
the agencies and the vendors. Make an investment in language that is
collaborative in nature, clarifies roles and responsibility, and results in
outcomes that create a better value proposition all around.
- Mike
Mike Paciello
Cell: +1.603.566.7713
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Saturday, October 27, 2007 8:05 AM
To: 'TEITAC Committee'
Subject: Re: [teitac-committee] 1-2 A NOTE & AT-IT interoperability
Both the "turn on the accessibility features" provision and the "AT-IT
interoperability" provision(s) are about shared operational
responsibilities,
where the actions of more than one party are required for achievement of
access.
Given that we are not writing or formatting the regulations, I think we
should
pay attention to how we can best reflect our expert understanding of what
the most efficient division of responsibilities among the parties should be,
and see if we can live with that.
If IT vendors fully document the accessibility features in their products,
including how to turn them on and administer them, and also fully document
the results of their AT-IT compatibility testing, including any problems
and workarounds, I think they should have met their responsibility.
Moreover,
I think most companies are already doing this or able to do this without
much
of a stretch. This is perhaps more true of OEMs than of system integrators.
Agencies should know their IT and AT environments well enough to be able to
use that information, asking for more as part of the procurement process if
necessary, to be able to make their purchasing decision and implement the
products accessibly. Some agencies are already very good at this, although
overall performance is probably not as good as it needs to be.
I can't help but think that if we were engaged in re-designing the VPAT and
designing
other more advanced tools for sharing and coordinating information among IT
vendors,
AT vendors, and agencies (federal and other) we'd have moved these issues
further
along than we have by keeping the discussion so abstract.
***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias
> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Saturday, October 27, 2007 1:00 AM
> To: 'TEITAC Committee'
> Subject: Re: [teitac-committee] 1-2 A NOTE
>
> The question came up as to whether 1-2 A should be in
> technical provisions or not since it is or includes
> instructions as to what an agency must do to their system at
> installation and as it is run.
>
> First of course, all the provisions are to the agency.
>
> Second, What if the product is a service for providing the
> equipment to the
> government? Several people have said that the gov doesn't really but
> hardware so much anymore but rather 'seats'. That is a service which
> includes the hardware, setup and maintenance/running the
> system. So for those vendors it should be there since they
> would be the ones to do it.
>
> Since product developers will need to put NA next to many
> provisions that do not apply to their product, I wonder if it
> is that hard to but NA next to the couple provisions that say
> "agencies must" if they aren't doing those activities for the agency?
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter
> > Korn
> > Sent: Thursday, October 25, 2007 10:02 AM
> > To: TEITAC Committee
> > Subject: Re: [teitac-committee] 1-2 A NOTE
> >
> > Hi Gregg,
> >
> > I would be interested in hearing Terry Weaver's comments on this
> > (which we won't get on this particular mailing list).
> > In practice today, industry is asked to say "supports" for all
> > technical provisions.
> > Clearly we can't say that for things that must occur at the agency
> > site as part of agency policy. Perhaps some few industry
> contractors
> > may be invited to do some of these things in specific cases; but as
> > these provisions clearly don't belong in a VPAT for all
> products, it
> > makes a lot of sense to separate them out clearly from the
> rest of the
> > technical provisions.
> >
> >
> > Regards,
> >
> > Peter Korn
> > Accessibility Architect,
> > Sun Microsystems, Inc.
> >
> > > Hi Andi
> > >
> > > I think all of the provisions are about agency
> > responsibilities. The
> > > agency language was added to a few specific ones at the
> request of
> > > industry to indicate particular responsibilities that were
> > important
> > > but that companies couldn't be held responsible for. In
> some cases
> > > there were two tightly connected provisions that showed
> which part
> > > might be asked for in a purchase and which parts would have
> > to be up
> > > to the agency after delivery (unless they contracted for
> > that service in which chase the agency would be
> > > responsible for seeing that the contractor did it). So
> > even the 'agency'
> > > provisions might apply to a contractor delivering services to the
> > > government.
> > >
> > > Robert, Terry and many others pointed out that more and more the
> > > government isn't buying products themselves but products
> wrapped in
> > > setup and maintance services. Or more accurately, the
> > 'service of seeing that products are
> > > present in the government for the gov employees to use'.
> > The products
> > > don't actually necessarily ever become the governments.
> > >
> > > So I think that was the rationale for putting them in as
> > technical regs.
> > > - all the provisions are for the agency
> > > - that part may be purchased just like the rest.
> > >
> > >
> > > Thoughts?
> > >
> > >
> > > Gregg
> > > -- ------------------------------
> > > Gregg C Vanderheiden Ph.D.
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: = EMAIL ADDRESS REMOVED =
> > >> [mailto:teitac-committee- = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of Andi
> > >> Snow-Weaver
> > >> Sent: Wednesday, October 24, 2007 7:11 PM
> > >> To: TEITAC Committee
> > >> Subject: Re: [teitac-committee] 1-2 A NOTE
> > >>
> > >> I think provisions that describe agency responsibilities
> should be
> > >> separated from the technical provisions.
> > >>
> > >> Andi
> > >>
> > >>
> > >>
> > >>
> > >> "Baker, Robert
> > >> C."
> > >> <Robert.C.Baker@s
> > To
> > >> sa.gov> "TEITAC Committee"
> > >> Sent by:
> > < = EMAIL ADDRESS REMOVED = >
> > >> teitac-committee-
> > cc
> > >> = EMAIL ADDRESS REMOVED =
> > >> ac.org
> > Subject
> > >> Re:
> > [teitac-committee] 1-2 A
> > >> NOTE
> > >>
> > >> 10/23/2007 12:13
> > >> PM
> > >>
> > >>
> > >> Please respond to
> > >> TEITAC Committee
> > >> <teitac-committee
> > >> @list.teitac.org>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Peter wrote
> > >>
> > >> "* Products procured must be capable of being configured to be
> > >> accessible to and usable by people with disabilities while
> > >> simultaneously meeting the product specifications in the RFP"
> > >>
> > >> How about "Products procured must be capable of being
> > configured to
> > >> be accessible to and usable by people with disabilities while
> > >> simultaneously meeting the agency's product requirements"
> > >>
> > >>
- Next message in Thread: Takemura, Michael (HP Accessibility): "1-2 A NOTE & AT-IT interoperability"
- Previous message in Thread: Jim Tobias: "Re: 1-2 A NOTE & AT-IT interoperability"