Thread Subject: Re: Basic questions
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: Gregg Vanderheiden
Date: Wed, Nov 15 2006 9:10 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Sean Hayes: "Re: Basic questions"
- Previous message in thread: awoolley@cusa.canon.com: "Re: Basic questions"
- Messages sorted by: Author | Thread | Date
> > GV: Good - but if they can install software it wouldn't be closed
> > would it?
> > Still good to cover here.
>
> That's the point -- I think the whole category of "closed"
> need no longer exist, except for #1 products, like
> calculators, and I'm suggesting we grant them an exception
> because there are accommodating alternatives.
I'm not sure I follow.
I think closed products (not as a category but as a characteristic) still
needs to exist. If a product does not allow connection of AT then it needs
to be directly accessible as it is delivered and installed. (except if it
is a small personal device that the user can easily get their manager to buy
another accessible version of for their own personal use - like calculators
etc.)
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
> Sent: Wednesday, November 15, 2006 9:44 AM
> To: 'TEITAC self contained/closed products subcommittee'
> Subject: Re: [teitac-closed] Basic questions
>
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Jim Tobias
> > > Sent: Wednesday, November 15, 2006 5:51 AM
> > > To: 'TEITAC self contained/closed products subcommittee'
> > > Subject: [teitac-closed] Basic questions
> > >
> > > Hi All,
> > >
> > > Please forgive me, but I feel that we're trying to make
> progress by
> > > small adjustments to the Standards but missing the larger picture.
> > > Here are the kinds of products I think we're trying to address:
> > >
> > > 1. appliance-type ICT, like calculators
> >
> > GV: We need to characterize this better to keep from copiers being
> > considered appliances (which they should be) but it is a good
> > category.
> > Maybe something like "personal workstation ICT below $xxx for which
> > there
> > are accessible alternative that the user can requisition".
> > A bit long but
> > it covers the main issues that would bar a person from
> being able to
> > get an accessible version.
>
> I don't think the price criterion will work. The idea is an
> ICT hardware product that never connects with anything else
> (somehow have to add fax machines that DO connect, but not
> for control purposes)
>
> > > 2. peripherals like printers that don't typically have
> > their own user
> > > interface
> >
> > GV: "their own local user interface" (hmmmm are there
> > enough of these?
> > And don't printers even have a local interface? I use the
> buttons on
> > mine all the time - and have no idea how to do those
> functions from my
> > computer.
> > But it guess if the product DID provide those remotely it could
> > function.
> > But it would seem to only make sense for devices with a
> small number
> > (or
> > none) of seldom used buttons.
>
> I don't understand this. It's feasible to add all the
> printer's functions to a remote utility. The printer could
> still have the buttons, but we would be requiring a remote
> capability for every function you could perform right in
> front of the thing. I honestly can't come up with a problem
> here. And I can't support any feasibility counter-argument
> either -- this is not hard to do. In fact, as we know, most
> of this capability is built into these products for QA
> testing in the factory; it's just not exposed to the user
>
> > > Let me propose a straw man.
> > >
> <snip>
> > >
> > > For #2, require that all functions be able to be performed from a
> > > workstation (a particular user's workstation or one
> > connected to the
> > > peripheral). This means that my screen-reader-equipped
> > computer can
> > > operate the printer/copier remotely, because all functions
> > (including
> > > status readout like empty paper trays) are exposed. This
> > would be a
> > > significant step forward, and appears to be fully feasible.
> >
> > GV: good but I don't think it should be accessible if it COULD be
> > controlled from a workstation attached. A workstation
> would need to
> > be
> > attached. (for copiers -- for printers I think the above
> > discussion would
> > hold and a personal workstation access could be used.
> Maybe the test
> > is 'if the interface on the device is not normally used to
> operate the
> > device"
>
> You're right; you're raising the agency's responsibility to
> actually connect the workstation or let the employee connect
> via his/her workstation.
> I was thinking of the procurement side of things -- what's in the RFP.
>
> > > For #3, require the terminal to (a) support all
> > accessibility features
> > > native to the operating system the terminal uses and
> > > (b) provide either permanently installed assistive technology
> > > functionality, or the use of a temporary installation of
> assistive
> > > technology. This means in (a) that the terminal basically
> > running an
> > > operating system must permit users to access the OS
> > features. In (b)
> > > it means the device must have been configured with AT (e.g.
> > built-in
> > > screen reader) or permit temporary AT (e.g. screen reader
> > on a flash
> > > drive, NCITS V2 network download of an alternate interface, EZ
> > > Access).
> >
> > GV: Good - but if they can install software it wouldn't be closed
> > would it?
> > Still good to cover here.
>
> That's the point -- I think the whole category of "closed"
> need no longer exist, except for #1 products, like
> calculators, and I'm suggesting we grant them an exception
> because there are accommodating alternatives.
>
>
- Next message in Thread: Sean Hayes: "Re: Basic questions"
- Previous message in Thread: awoolley@cusa.canon.com: "Re: Basic questions"