Thread Subject: Re: "closed software"

Return to this mailing list's archives

From: Gregg Vanderheiden
Date: Tue, Jan 02 2007 11:10 PM
Subject: Re: "closed software"

Hi Norman,

I agree with your premise that there shouldn't be any closed software.

But if there is software that is closed (not accessible to AT) for any
reason (business, technical or security) then we do want to require that it
is accessible - no? And I believe that there will be legitimate arguments
for some places where the software will be closed - and/or that there will
be no AT developed for or that can be used with the product.

I'm not talking about desktop computers necessarily.

What if we just said

1) that products need to be accessible either via available assistive
technology or directly accessible.

2) that products that require productivity (e.g. workstations) need to be
accessible to assistive technologies to allow matching of user abilities
necessary to achieve high levels of productivity.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Robinson, Norman B - Washington, DC
> Sent: Wednesday, December 27, 2006 2:54 PM
> To: TEITAC self contained/closed products subcommittee;
> TEITAC Web/Software Subcommittee
> Cc: TEITAC General Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] [teitac-closed] "closed software"
>
> Since I earlier offered a different perspective on "closed
> software", I thought I would respond to each item.
>
> 1. Security reasons: Security should be a part of a
> requirement in the same way accessibility should be a part of
> the requirement for a product. First, security options _CAN_
> be accessible (e.g., accessible CAPTCHAs or accessible login
> screens). Second, where there is a technical determination
> that no access to application programming interfaces (APIs)
> that work with assistive technology is allowed, there is a
> business justification. No matter what assistive technology
> can do, if the system designed to block user interaction to
> only one type of system interface for business reasons, that
> is an exception. However, I'd be amiss if I didn't say see "First".
>
> 2. Besides semantics, and debating among friends, software
> can't run without an operating system unless it, itself, IS
> the operating system.
>
> 3. What is the point of making a classification of "CLOSED SOFTWARE"?
> What does it mean to us in context of Section 508? Your
> example is one of being accessible through design. I'd say
> the example doesn't help the argument and problem we are
> trying to solve (if you'll please forgive me). We are
> concerned when software doesn't work with assistive
> technology and isn't designed to be accessible. I'd also say
> I have the expectation that this software is generally only
> used in conjunction with specialized hardware. Firefox web
> browser was considered to be too small a market for certain
> AT vendors. What does that mean? I think they have an API. I
> think this is complex interaction of _accessibility
> interfaces_ dependent on the operating system. Sorry, I'm an
> Amiga/Windows/OSX/Linux user and it varies considerably. It
> is too easy to just think in context of one platform,
> especially when embedded operating systems in phones are so
> plentiful and experiencing these same issues. Sorry to
> ramble, I think I need to discuss this some more.
>
> 4. Platform software issues are interesting. Is commercial
> availability exemptions? Tying it to vendor product and
> 'official' support is dangerous too; I'm sure my MS Windows
> vendor doesn't support me running Linux on my corporate
> desktop, but the screen reader and web browser works just
> fine for most of my needs. I think that is close to the
> earlier iPod firmware upgrade. But who cares? Even if a 3rd
> party or Apple made the software as an add-on to the product
> it can be made accessible. The debate so far has focused on
> the vendor not developing assistive technology. Third parties
> do and you can make things accessible without assistive technology.
>
> Sorry to disagree, but the closed software approach doesn't
> work well for Section 508 evaluation. I can't help but feel
> we're not asking the right questions. DRM is bad for
> end-users, security typically negatively impacts end-user
> experience, and accessibility is all about the user!
> This discussion is really useful for questioning vendors and
> how they support our business/agency. I don't think finding
> justification for closed software means we should place a
> label on software and treat it any differently from any other
> software. Closed software should be accessible and follow the
> same technical standards as any other software.
>
> Regards,
>
>
> Norman B. Robinson
> Section 508 Coordinator
> IT Governance, US Postal Service
> phone: 202.268.8246
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
> Vanderheiden
> Sent: Tuesday, December 19, 2006 12:45 PM
> To: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
> Web/Software Subcommittee'
> Cc: 'TEITAC General Interface Accessibility Subcommittee'
> Subject: Re: [teitac-closed] "closed software"
>
>
> Some possible examples of closed software.
>
> Maybe some things like: (numbered only to facilitate discussion)
>
> 1 - Software that for security reasons does not allow
> anything to access
> what it has on screen and which reads keyboard registers directly to
> avoid
> tampering or 'remote' typing.
>
> 2 - Software designed to run on a product without and
> operating system.
>
> 3 - Software that has no API for AT - but instead has built in
> accessibility
> since there is no AT vendor who will work with and support the unique
> capability of the software because the market is too small for AT
> vendors.
>
> 4 - Something like Randy pointed to (see just below). The hardware is
> not
> closed since new software can be loaded. But the platform/software is
> closed.
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>

From: Jim Tobias
Date: Thu, Jan 04 2007 10:15 AM
Subject: Re: "closed software"

I'm copying the Subpart A folks on this discussion because that's where the
AT definition will reside, and because I know some of them have definite
and expansive ideas about the definition of AT.

I agree that splitting hairs will not get us anywhere, and that we're
moving towards an environment in which there may well be a range of
AT functionality in an OS setting, an OS utility, a bundled application,
and a clearly third-party AT application requiring separate installation.

I'm not sure that "paying extra" is the best or only way to identify AT,
as price is certainly not the worst or only barrier to the use of AT. The
combination of lack of information and lack of confidence in altering their
computer's standard operation is what holds most people back. For
evidence, look at the Microsoft study on underutilization of the many
capabilities found free within Windows. Similarly, installing Gnopernicus
is not exactly a one-click experience.

> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 12:15 AM
> To: 'TEITAC General Interface Accessibility Subcommittee';
> 'TEITAC Web/Software Subcommittee'
> Cc: 'TEITAC self contained/closed products subcommittee'
> Subject: Re: [teitac-websoftware]
> [teitac-general][teitac-closed]"closed software"
>
> No. AT can be from same company.
>
> If the user has to pay extra for it - then I would call it AT.
>
> If it comes as part of the product - I would call it built
> in. Especially if it is shipped as part of the product to everyone.
>
> But I think we need to write our regs so that we don't have
> to get into such discussions or hair splitting. Because the
> way things are going it will be
> impossible to separate things into AT or not-AT. Use any
> definition you
> like and I will give you examples that fit both definitions
> at different times.
>
> The issue isn't whether it is AT or not. I belive that what
> we need to focus on is whether people with disabilities, with
> whatever they have, can access and use the products.
>
> Now - how to phrase the standards to do this...
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
> > Korn
> > Sent: Wednesday, January 03, 2007 2:07 PM
> > To: TEITAC Web/Software Subcommittee
> > Cc: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
> > General Interface Accessibility Subcommittee'
> > Subject: Re: [teitac-general] [teitac-websoftware]
> > [teitac-closed]"closed software"
> >
> > Hi Gregg,
> >
> > I don't understand this. Is it part of the definition of
> AT that it
> > comes from a 3rd party, separate from the OS? Or can it be
> the same
> > party as the OS, but just not with the OS (e.g. ScreenReader/2 for
> > OS/2)?
> >
> > Separately, today in the Web & Software SC call, Andi asked about
> > non-AT voice recognition software (is it only AT if it is called
> > "AT"?).
> >
> >
> > I suggest that Apple's VoiceOver (bundled with the OS X 10.4 and
> > later), and Gnopernicus & GOK (bundled with Solaris 10), and GOK &
> > Orca (bundled with Ubuntu GNU/Linux 6.10) *are* all AT. In exactly
> > the same way that we (now) say that WordPad is an application (even
> > though it is bundled with Windows).
> >
> >
> > Regards,
> >
> > Peter Korn
> > Accessibility Architect,
> > Sun Microsystems, Inc.
> > > I thought of that as I wrote it.
> > >
> > > Well, since it is built into the OS, the application that
> > work with it would
> > > be directly accessible since they are accessible without
> > needing any AT.
> > > Remember that any software with access built in would need
> > to rely on OS
> > > functions (speech, sound, keyboard etc). this would also
> > rely on the
> > > voiceover functionality.
> > >
> > > Since they have an API - it would ALSO be compatible with
> > any AT that was
> > > out there.
> > >
> > > Having an API only though - without AT support would not be
> > accessible (i.e.
> > > usable with people who have disabilities) if there was no
> > AT. That is why
> > > Apple built it into their system and have an API. They
> > support AT but are
> > > not subject to AT availability - which was a problem for
> > them - at least for
> > > screen readers.
> > >
> > >
> > > Gregg
> > > -- ------------------------------
> > > Gregg C Vanderheiden Ph.D.
> > >
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: = EMAIL ADDRESS REMOVED =
> > >> [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of David
> > >> Poehlman
> > >> Sent: Wednesday, January 03, 2007 4:38 AM
> > >> To: TEITAC Web/Software Subcommittee
> > >> Cc: 'TEITAC self contained/closed products
> subcommittee'; 'TEITAC
> > >> General Interface Accessibility Subcommittee'
> > >> Subject: Re: [teitac-general] [teitac-websoftware]
> [teitac-closed]
> > >> "closed software"
> > >>
> > >> greg, am I to understand then that your #2 excludes the
> Mac which
> > >> has its ownn AT?
> > >>
> > >> On Jan 3, 2007, at 1:02 AM, Gregg Vanderheiden wrote:
> > >>
> > >> Hi Norman,
> > >>
> > >> I agree with your premise that there shouldn't be any
> > closed software.
> > >>
> > >> But if there is software that is closed (not accessible to
> > >> AT) for any reason (business, technical or security) then we do
> > >> want to require that it
> > >> is accessible - no? And I believe that there will be
> legitimate
> > >> arguments
> > >> for some places where the software will be closed - and/or that
> > >> there will be no AT developed for or that can be used with the
> > >> product.
> > >>
> > >> I'm not talking about desktop computers necessarily.
> > >>
> > >> What if we just said
> > >>
> > >> 1) that products need to be accessible either via available
> > >> assistive technology or directly accessible.
> > >>
> > >> 2) that products that require productivity (e.g.
> > >> workstations) need to be accessible to assistive technologies to
> > >> allow matching of user abilities necessary to achieve
> high levels
> > >> of productivity.
> > >>
> > >>
> > >> Gregg
> > >> -- ------------------------------ Gregg C Vanderheiden Ph.D.
> > >>
> > >>
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: = EMAIL ADDRESS REMOVED =
> > >>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> > >>>
> > >> Of Robinson,
> > >>
> > >>> Norman B - Washington, DC
> > >>> Sent: Wednesday, December 27, 2006 2:54 PM
> > >>> To: TEITAC self contained/closed products subcommittee; TEITAC
> > >>> Web/Software Subcommittee
> > >>> Cc: TEITAC General Interface Accessibility Subcommittee
> > >>> Subject: Re: [teitac-general] [teitac-closed] "closed software"
> > >>>
> > >>> Since I earlier offered a different perspective on "closed
> > >>>
> > >> software",
> > >>
> > >>> I thought I would respond to each item.
> > >>>
> > >>> 1. Security reasons: Security should be a part of a
> > >>>
> > >> requirement in the
> > >>
> > >>> same way accessibility should be a part of the
> requirement for a
> > >>> product. First, security options _CAN_ be accessible (e.g.,
> > >>>
> > >> accessible
> > >>
> > >>> CAPTCHAs or accessible login screens). Second, where there is a
> > >>> technical determination that no access to application
> programming
> > >>> interfaces (APIs) that work with assistive technology
> is allowed,
> > >>> there is a business justification. No matter what assistive
> > >>>
> > >> technology
> > >>
> > >>> can do, if the system designed to block user interaction to
> > >>>
> > >> only one
> > >>
> > >>> type of system interface for business reasons, that is an
> > >>>
> > >> exception.
> > >>
> > >>> However, I'd be amiss if I didn't say see "First".
> > >>>
> > >>> 2. Besides semantics, and debating among friends, software
> > >>>
> > >> can't run
> > >>
> > >>> without an operating system unless it, itself, IS the operating
> > >>> system.
> > >>>
> > >>> 3. What is the point of making a classification of "CLOSED
> > >>>
> > >> SOFTWARE"?
> > >>
> > >>> What does it mean to us in context of Section 508? Your
> > >>>
> > >> example is one
> > >>
> > >>> of being accessible through design. I'd say the example
> > >>>
> > >> doesn't help
> > >>
> > >>> the argument and problem we are trying to solve (if
> you'll please
> > >>> forgive me). We are concerned when software doesn't work with
> > >>> assistive technology and isn't designed to be accessible.
> > >>>
> > >> I'd also say
> > >>
> > >>> I have the expectation that this software is generally
> > only used in
> > >>> conjunction with specialized hardware. Firefox web browser was
> > >>> considered to be too small a market for certain AT vendors.
> > >>>
> > >> What does
> > >>
> > >>> that mean? I think they have an API. I think this is complex
> > >>> interaction of _accessibility interfaces_ dependent on the
> > >>>
> > >> operating
> > >>
> > >>> system. Sorry, I'm an Amiga/Windows/OSX/Linux user and
> it varies
> > >>> considerably. It is too easy to just think in context of
> > >>>
> > >> one platform,
> > >>
> > >>> especially when embedded operating systems in phones are so
> > >>>
> > >> plentiful
> > >>
> > >>> and experiencing these same issues. Sorry to ramble, I
> > >>>
> > >> think I need to
> > >>
> > >>> discuss this some more.
> > >>>
> > >>> 4. Platform software issues are interesting. Is commercial
> > >>> availability exemptions? Tying it to vendor product and
> > 'official'
> > >>> support is dangerous too; I'm sure my MS Windows vendor doesn't
> > >>> support me running Linux on my corporate desktop, but
> the screen
> > >>> reader and web browser works just fine for most of my
> > >>>
> > >> needs. I think
> > >>
> > >>> that is close to the earlier iPod firmware upgrade. But
> > who cares?
> > >>> Even if a 3rd party or Apple made the software as an
> > add-on to the
> > >>> product it can be made accessible. The debate so far has
> > focused on
> > >>> the vendor not developing assistive technology. Third
> > >>>
> > >> parties do and
> > >>
> > >>> you can make things accessible without assistive technology.
> > >>>
> > >>> Sorry to disagree, but the closed software approach doesn't
> > >>>
> > >> work well
> > >>
> > >>> for Section 508 evaluation. I can't help but feel we're not
> > >>>
> > >> asking the
> > >>
> > >>> right questions. DRM is bad for end-users, security typically
> > >>> negatively impacts end-user experience, and accessibility
> > >>>
> > >> is all about
> > >>
> > >>> the user!
> > >>> This discussion is really useful for questioning vendors
> > >>>
> > >> and how they
> > >>
> > >>> support our business/agency. I don't think finding
> > >>>
> > >> justification for
> > >>
> > >>> closed software means we should place a label on software
> > >>>
> > >> and treat it
> > >>
> > >>> any differently from any other software. Closed software
> > should be
> > >>> accessible and follow the same technical standards as any other
> > >>> software.
> > >>>
> > >>> Regards,
> > >>>
> > >>>
> > >>> Norman B. Robinson
> > >>> Section 508 Coordinator
> > >>> IT Governance, US Postal Service
> > >>> phone: 202.268.8246
> > >>>
> > >>>
> > >>> -----Original Message-----
> > >>> From: = EMAIL ADDRESS REMOVED =
> > >>> [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Gregg
> > >>> Vanderheiden
> > >>> Sent: Tuesday, December 19, 2006 12:45 PM
> > >>> To: 'TEITAC self contained/closed products
> subcommittee'; 'TEITAC
> > >>> Web/Software Subcommittee'
> > >>> Cc: 'TEITAC General Interface Accessibility Subcommittee'
> > >>> Subject: Re: [teitac-closed] "closed software"
> > >>>
> > >>>
> > >>> Some possible examples of closed software.
> > >>>
> > >>> Maybe some things like: (numbered only to facilitate discussion)
> > >>>
> > >>> 1 - Software that for security reasons does not allow
> anything to
> > >>> access what it has on screen and which reads keyboard registers
> > >>> directly to avoid tampering or 'remote' typing.
> > >>>
> > >>> 2 - Software designed to run on a product without and operating
> > >>> system.
> > >>>
> > >>> 3 - Software that has no API for AT - but instead has built in
> > >>> accessibility since there is no AT vendor who will work
> with and
> > >>> support the unique capability of the software because the
> > market is
> > >>> too small for AT vendors.
> > >>>
> > >>> 4 - Something like Randy pointed to (see just below). The
> > >>>
> > >> hardware is
> > >>
> > >>> not closed since new software can be loaded. But the
> > >>> platform/software is closed.
> > >>>
> > >>> Gregg
> > >>> -- ------------------------------
> > >>> Gregg C Vanderheiden Ph.D.
> > >>>

From: Gregg Vanderheiden
Date: Sun, Jan 07 2007 7:55 PM
Subject: Re: "closed software"

Excellent post Randy,



We need to always remember that access has many dimensions. Some aspects
may be built in while others need AT interoperability and still others AT
compatibility/non-interference (e.g. hearing aids, wheelchairs).




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy
Marsden (Home)
Sent: Wednesday, January 03, 2007 10:18 AM
To: TEITAC General Interface Accessibility Subcommittee; TEITAC Web/Software
Subcommittee
Cc: TEITAC self contained/closed products subcommittee
Subject: Re: [teitac-websoftware] [teitac-general] [teitac-closed] "closed
software"

A screen reader is but one category of assistive technology. Because Apple
happened to make their own for the Mac doesn't mean all aspects of assistive
technology are covered. (Access for the mobility impaired, for example, is
not addressed by a screen reader).

Also, Apple's screen reader uses accessibility API's built into the
operating system, as any other assistive technology screen reader would. It
just happens that the same company makes both the IT and the screen reader.
So, technically, I think it would fit into Gregg's category 1: an IT
product that is compatible with external AT.

-Randy


From: David Poehlman < = EMAIL ADDRESS REMOVED = >
Reply-To: TEITAC General Interface Accessibility Subcommittee
< = EMAIL ADDRESS REMOVED = >
Date: Wed, 3 Jan 2007 05:37:33 -0500
To: TEITAC Web/Software Subcommittee < = EMAIL ADDRESS REMOVED = >
Cc: 'TEITAC self contained/closed products subcommittee'
< = EMAIL ADDRESS REMOVED = >, 'TEITAC General Interface Accessibility
Subcommittee' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [teitac-general] [teitac-websoftware] [teitac-closed] "closed
software"



greg, am I to understand then that your #2 excludes the Mac which has
its ownn AT?

From: Gregg Vanderheiden
Date: Sun, Jan 07 2007 8:50 PM
Subject: Re: "closed software"

I think Jim is correct. In fact I think that any definition of AT will
create problems.

See new NCD report
http://www.ncd.gov/newsroom/publications/2006/emerging_trends.htm

The question is:

- do we need to define AT?
- if so - which version do we use - and what are the implications in regs.
- if, as is posited, AT won't have any clear definition in the future, how
do we address AT compatibility?
- do we create a definition for a new subset of AT that we can define?
1 Personal AT (carried about and used with multiple devices - like
wheelchairs and hearing aids)
2 Adaptive AT (added to a specific product (e.g. screen reader)
3 Built in Accommodations (things that come with or download transparently
to user)

Something different?

These three need to be treated separately for example in the 508/255 regs.

3 should count as 'built in' and is part of "closed" products.
2 must be able to be connected or installed or product is closed
1 must be usable even on closed products (up to the standard spec'd level)

Etc


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Jim Tobias
> Sent: Thursday, January 04, 2007 10:01 AM
> To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General
> Interface Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
> Cc: 'TEITAC self contained/closed products subcommittee'
> Subject: Re: [teitac-subparta]
> [teitac-websoftware][teitac-general][teitac-closed]"closed software"
>
> I'm copying the Subpart A folks on this discussion because
> that's where the AT definition will reside, and because I
> know some of them have definite and expansive ideas about the
> definition of AT.
>
> I agree that splitting hairs will not get us anywhere, and
> that we're moving towards an environment in which there may
> well be a range of AT functionality in an OS setting, an OS
> utility, a bundled application, and a clearly third-party AT
> application requiring separate installation.
>
> I'm not sure that "paying extra" is the best or only way to
> identify AT, as price is certainly not the worst or only
> barrier to the use of AT. The combination of lack of
> information and lack of confidence in altering their
> computer's standard operation is what holds most people back.
> For evidence, look at the Microsoft study on
> underutilization of the many capabilities found free within
> Windows. Similarly, installing Gnopernicus is not exactly a
> one-click experience.
>
> > -----Original Message-----
> > From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> > Sent: Thursday, January 04, 2007 12:15 AM
> > To: 'TEITAC General Interface Accessibility Subcommittee'; 'TEITAC
> > Web/Software Subcommittee'
> > Cc: 'TEITAC self contained/closed products subcommittee'
> > Subject: Re: [teitac-websoftware]
> > [teitac-general][teitac-closed]"closed software"
> >
> > No. AT can be from same company.
> >
> > If the user has to pay extra for it - then I would call it AT.
> >
> > If it comes as part of the product - I would call it built in.
> > Especially if it is shipped as part of the product to everyone.
> >
> > But I think we need to write our regs so that we don't have to get
> > into such discussions or hair splitting. Because the way
> things are
> > going it will be
> > impossible to separate things into AT or not-AT. Use any
> > definition you
> > like and I will give you examples that fit both definitions at
> > different times.
> >
> > The issue isn't whether it is AT or not. I belive that
> what we need
> > to focus on is whether people with disabilities, with whatever they
> > have, can access and use the products.
> >
> > Now - how to phrase the standards to do this...
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter
> > > Korn
> > > Sent: Wednesday, January 03, 2007 2:07 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Cc: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
> > > General Interface Accessibility Subcommittee'
> > > Subject: Re: [teitac-general] [teitac-websoftware]
> > > [teitac-closed]"closed software"
> > >
> > > Hi Gregg,
> > >
> > > I don't understand this. Is it part of the definition of
> > AT that it
> > > comes from a 3rd party, separate from the OS? Or can it be
> > the same
> > > party as the OS, but just not with the OS (e.g.
> ScreenReader/2 for
> > > OS/2)?
> > >
> > > Separately, today in the Web & Software SC call, Andi asked about
> > > non-AT voice recognition software (is it only AT if it is called
> > > "AT"?).
> > >
> > >
> > > I suggest that Apple's VoiceOver (bundled with the OS X 10.4 and
> > > later), and Gnopernicus & GOK (bundled with Solaris 10),
> and GOK &
> > > Orca (bundled with Ubuntu GNU/Linux 6.10) *are* all AT.
> In exactly
> > > the same way that we (now) say that WordPad is an
> application (even
> > > though it is bundled with Windows).
> > >
> > >
> > > Regards,
> > >
> > > Peter Korn
> > > Accessibility Architect,
> > > Sun Microsystems, Inc.
> > > > I thought of that as I wrote it.
> > > >
> > > > Well, since it is built into the OS, the application that
> > > work with it would
> > > > be directly accessible since they are accessible without
> > > needing any AT.
> > > > Remember that any software with access built in would need
> > > to rely on OS
> > > > functions (speech, sound, keyboard etc). this would also
> > > rely on the
> > > > voiceover functionality.
> > > >
> > > > Since they have an API - it would ALSO be compatible with
> > > any AT that was
> > > > out there.
> > > >
> > > > Having an API only though - without AT support would not be
> > > accessible (i.e.
> > > > usable with people who have disabilities) if there was no
> > > AT. That is why
> > > > Apple built it into their system and have an API. They
> > > support AT but are
> > > > not subject to AT availability - which was a problem for
> > > them - at least for
> > > > screen readers.
> > > >
> > > >
> > > > Gregg
> > > > -- ------------------------------ Gregg C Vanderheiden Ph.D.
> > > >
> > > >
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: = EMAIL ADDRESS REMOVED =
> > > >> [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of David
> > > >> Poehlman
> > > >> Sent: Wednesday, January 03, 2007 4:38 AM
> > > >> To: TEITAC Web/Software Subcommittee
> > > >> Cc: 'TEITAC self contained/closed products
> > subcommittee'; 'TEITAC
> > > >> General Interface Accessibility Subcommittee'
> > > >> Subject: Re: [teitac-general] [teitac-websoftware]
> > [teitac-closed]
> > > >> "closed software"
> > > >>
> > > >> greg, am I to understand then that your #2 excludes the
> > Mac which
> > > >> has its ownn AT?
> > > >>
> > > >> On Jan 3, 2007, at 1:02 AM, Gregg Vanderheiden wrote:
> > > >>
> > > >> Hi Norman,
> > > >>
> > > >> I agree with your premise that there shouldn't be any
> > > closed software.
> > > >>
> > > >> But if there is software that is closed (not accessible to
> > > >> AT) for any reason (business, technical or security)
> then we do
> > > >> want to require that it
> > > >> is accessible - no? And I believe that there will be
> > legitimate
> > > >> arguments
> > > >> for some places where the software will be closed -
> and/or that
> > > >> there will be no AT developed for or that can be used with the
> > > >> product.
> > > >>
> > > >> I'm not talking about desktop computers necessarily.
> > > >>
> > > >> What if we just said
> > > >>
> > > >> 1) that products need to be accessible either via available
> > > >> assistive technology or directly accessible.
> > > >>
> > > >> 2) that products that require productivity (e.g.
> > > >> workstations) need to be accessible to assistive
> technologies to
> > > >> allow matching of user abilities necessary to achieve
> > high levels
> > > >> of productivity.
> > > >>
> > > >>
> > > >> Gregg
> > > >> -- ------------------------------ Gregg C Vanderheiden Ph.D.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: = EMAIL ADDRESS REMOVED =
> > > >>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> > > >>>
> > > >> Of Robinson,
> > > >>
> > > >>> Norman B - Washington, DC
> > > >>> Sent: Wednesday, December 27, 2006 2:54 PM
> > > >>> To: TEITAC self contained/closed products
> subcommittee; TEITAC
> > > >>> Web/Software Subcommittee
> > > >>> Cc: TEITAC General Interface Accessibility Subcommittee
> > > >>> Subject: Re: [teitac-general] [teitac-closed] "closed
> software"
> > > >>>
> > > >>> Since I earlier offered a different perspective on "closed
> > > >>>
> > > >> software",
> > > >>
> > > >>> I thought I would respond to each item.
> > > >>>
> > > >>> 1. Security reasons: Security should be a part of a
> > > >>>
> > > >> requirement in the
> > > >>
> > > >>> same way accessibility should be a part of the
> > requirement for a
> > > >>> product. First, security options _CAN_ be accessible (e.g.,
> > > >>>
> > > >> accessible
> > > >>
> > > >>> CAPTCHAs or accessible login screens). Second, where
> there is a
> > > >>> technical determination that no access to application
> > programming
> > > >>> interfaces (APIs) that work with assistive technology
> > is allowed,
> > > >>> there is a business justification. No matter what assistive
> > > >>>
> > > >> technology
> > > >>
> > > >>> can do, if the system designed to block user interaction to
> > > >>>
> > > >> only one
> > > >>
> > > >>> type of system interface for business reasons, that is an
> > > >>>
> > > >> exception.
> > > >>
> > > >>> However, I'd be amiss if I didn't say see "First".
> > > >>>
> > > >>> 2. Besides semantics, and debating among friends, software
> > > >>>
> > > >> can't run
> > > >>
> > > >>> without an operating system unless it, itself, IS the
> operating
> > > >>> system.
> > > >>>
> > > >>> 3. What is the point of making a classification of "CLOSED
> > > >>>
> > > >> SOFTWARE"?
> > > >>
> > > >>> What does it mean to us in context of Section 508? Your
> > > >>>
> > > >> example is one
> > > >>
> > > >>> of being accessible through design. I'd say the example
> > > >>>
> > > >> doesn't help
> > > >>
> > > >>> the argument and problem we are trying to solve (if
> > you'll please
> > > >>> forgive me). We are concerned when software doesn't work with
> > > >>> assistive technology and isn't designed to be accessible.
> > > >>>
> > > >> I'd also say
> > > >>
> > > >>> I have the expectation that this software is generally
> > > only used in
> > > >>> conjunction with specialized hardware. Firefox web
> browser was
> > > >>> considered to be too small a market for certain AT vendors.
> > > >>>
> > > >> What does
> > > >>
> > > >>> that mean? I think they have an API. I think this is complex
> > > >>> interaction of _accessibility interfaces_ dependent on the
> > > >>>
> > > >> operating
> > > >>
> > > >>> system. Sorry, I'm an Amiga/Windows/OSX/Linux user and
> > it varies
> > > >>> considerably. It is too easy to just think in context of
> > > >>>
> > > >> one platform,
> > > >>
> > > >>> especially when embedded operating systems in phones are so
> > > >>>
> > > >> plentiful
> > > >>
> > > >>> and experiencing these same issues. Sorry to ramble, I
> > > >>>
> > > >> think I need to
> > > >>
> > > >>> discuss this some more.
> > > >>>
> > > >>> 4. Platform software issues are interesting. Is commercial
> > > >>> availability exemptions? Tying it to vendor product and
> > > 'official'
> > > >>> support is dangerous too; I'm sure my MS Windows
> vendor doesn't
> > > >>> support me running Linux on my corporate desktop, but
> > the screen
> > > >>> reader and web browser works just fine for most of my
> > > >>>
> > > >> needs. I think
> > > >>
> > > >>> that is close to the earlier iPod firmware upgrade. But
> > > who cares?
> > > >>> Even if a 3rd party or Apple made the software as an
> > > add-on to the
> > > >>> product it can be made accessible. The debate so far has
> > > focused on
> > > >>> the vendor not developing assistive technology. Third
> > > >>>
> > > >> parties do and
> > > >>
> > > >>> you can make things accessible without assistive technology.
> > > >>>
> > > >>> Sorry to disagree, but the closed software approach doesn't
> > > >>>
> > > >> work well
> > > >>
> > > >>> for Section 508 evaluation. I can't help but feel we're not
> > > >>>
> > > >> asking the
> > > >>
> > > >>> right questions. DRM is bad for end-users, security typically
> > > >>> negatively impacts end-user experience, and accessibility
> > > >>>
> > > >> is all about
> > > >>
> > > >>> the user!
> > > >>> This discussion is really useful for questioning vendors
> > > >>>
> > > >> and how they
> > > >>
> > > >>> support our business/agency. I don't think finding
> > > >>>
> > > >> justification for
> > > >>
> > > >>> closed software means we should place a label on software
> > > >>>
> > > >> and treat it
> > > >>
> > > >>> any differently from any other software. Closed software
> > > should be
> > > >>> accessible and follow the same technical standards as
> any other
> > > >>> software.
> > > >>>
> > > >>> Regards,
> > > >>>
> > > >>>
> > > >>> Norman B. Robinson
> > > >>> Section 508 Coordinator
> > > >>> IT Governance, US Postal Service
> > > >>> phone: 202.268.8246
> > > >>>
> > > >>>
> > > >>> -----Original Message-----
> > > >>> From: = EMAIL ADDRESS REMOVED =
> > > >>> [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of Gregg
> > > >>> Vanderheiden
> > > >>> Sent: Tuesday, December 19, 2006 12:45 PM
> > > >>> To: 'TEITAC self contained/closed products
> > subcommittee'; 'TEITAC
> > > >>> Web/Software Subcommittee'
> > > >>> Cc: 'TEITAC General Interface Accessibility Subcommittee'
> > > >>> Subject: Re: [teitac-closed] "closed software"
> > > >>>
> > > >>>
> > > >>> Some possible examples of closed software.
> > > >>>
> > > >>> Maybe some things like: (numbered only to facilitate
> discussion)
> > > >>>
> > > >>> 1 - Software that for security reasons does not allow
> > anything to
> > > >>> access what it has on screen and which reads keyboard
> registers
> > > >>> directly to avoid tampering or 'remote' typing.
> > > >>>
> > > >>> 2 - Software designed to run on a product without and
> operating
> > > >>> system.
> > > >>>
> > > >>> 3 - Software that has no API for AT - but instead has
> built in
> > > >>> accessibility since there is no AT vendor who will work
> > with and
> > > >>> support the unique capability of the software because the
> > > market is
> > > >>> too small for AT vendors.
> > > >>>
> > > >>> 4 - Something like Randy pointed to (see just below). The
> > > >>>
> > > >> hardware is
> > > >>
> > > >>> not closed since new software can be loaded. But the
> > > >>> platform/software is closed.
> > > >>>
> > > >>> Gregg
> > > >>> -- ------------------------------ Gregg C Vanderheiden Ph.D.
> > > >>>

From: Rex Lint
Date: Mon, Jan 08 2007 1:00 PM
Subject: Re: "closed software"

Jim, Gregg, et. al.

Many manufacturers include "Out of the Box" (OOTB) applications with their
operating systems. These are not (necessarily) cutting edge, but intended
to provide SOME level of access to functionality. An example is WORDPAD (I
don't think they include NOTEPAD any more) by Microsoft, for simple, limited
editing.

Anyone who wants to do more than rudimentary editing would procure and use
some other, robust application - a word-processor. WORD is one, and there
are others. These feature-rich applications supplant the function of the
OOTB application(s).

Manufacturers have taken similar approaches to accessibility provisions.
Take NARRATOR on XP. It's not for extensive use, it's for getting access to
something on a VERY occasional basis. I think it's valuable because it
gives the general public the vision that it's possible to hear the contents
of a page instead of see it - good for simple demos about accessibility.

I'm sure the same situation applies to the use of O/S "Out of the Box"
accessibility utilities: people with specific disabilities will want to get
really robust "middleware" to address their needs.

So I see there is a range of software we're talking about in this thread -

* Utilities intended for limited, infrequent use,
* Applications that address the needs to accomplish a task
* Middleware that sits between applications and the OS or
applications and the user.

I think AT like screen readers fall in the middleware class.

I think a definition of AT that acknowledges this spectrum would be
appropriate:

Perhaps the utilities (particularly if done through a published API) could
form the basis of one level, "built-in" perhaps, accessibility.

Then compatibility with middleware-class AT (hopefully through the
sendor-supplied published API) would be enough to make the product rise to a
level classed as "accessible through AT." This approach would tend to make
"built-in" AT less desirable than "accessible through AT," to people with
disabilities.

This leaves unaddressed the question of "What if a product is 'accessible
through AT,' but there is no AT middleware available for it?"

As Gregg would say, "Hmmmm...."

Rex


Rex Lint,
Information Technology Association of America
PH: 603-860-7651


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Thursday, January 04, 2007 11:01 AM
To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General Interface
Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
Cc: 'TEITAC self contained/closed products subcommittee'
Subject: Re: [teitac-websoftware][teitac-general][teitac-closed]"closed
software"

I'm copying the Subpart A folks on this discussion because that's where the
AT definition will reside, and because I know some of them have definite
and expansive ideas about the definition of AT.

I agree that splitting hairs will not get us anywhere, and that we're
moving towards an environment in which there may well be a range of
AT functionality in an OS setting, an OS utility, a bundled application,
and a clearly third-party AT application requiring separate installation.

I'm not sure that "paying extra" is the best or only way to identify AT,
as price is certainly not the worst or only barrier to the use of AT. The
combination of lack of information and lack of confidence in altering their
computer's standard operation is what holds most people back. For
evidence, look at the Microsoft study on underutilization of the many
capabilities found free within Windows. Similarly, installing Gnopernicus
is not exactly a one-click experience.

> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 12:15 AM
> To: 'TEITAC General Interface Accessibility Subcommittee';
> 'TEITAC Web/Software Subcommittee'
> Cc: 'TEITAC self contained/closed products subcommittee'
> Subject: Re: [teitac-websoftware]
> [teitac-general][teitac-closed]"closed software"
>
> No. AT can be from same company.
>
> If the user has to pay extra for it - then I would call it AT.
>
> If it comes as part of the product - I would call it built
> in. Especially if it is shipped as part of the product to everyone.
>
> But I think we need to write our regs so that we don't have
> to get into such discussions or hair splitting. Because the
> way things are going it will be
> impossible to separate things into AT or not-AT. Use any
> definition you
> like and I will give you examples that fit both definitions
> at different times.
>
> The issue isn't whether it is AT or not. I belive that what
> we need to focus on is whether people with disabilities, with
> whatever they have, can access and use the products.
>
> Now - how to phrase the standards to do this...
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
> > Korn
> > Sent: Wednesday, January 03, 2007 2:07 PM
> > To: TEITAC Web/Software Subcommittee
> > Cc: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
> > General Interface Accessibility Subcommittee'
> > Subject: Re: [teitac-general] [teitac-websoftware]
> > [teitac-closed]"closed software"
> >
> > Hi Gregg,
> >
> > I don't understand this. Is it part of the definition of
> AT that it
> > comes from a 3rd party, separate from the OS? Or can it be
> the same
> > party as the OS, but just not with the OS (e.g. ScreenReader/2 for
> > OS/2)?
> >
> > Separately, today in the Web & Software SC call, Andi asked about
> > non-AT voice recognition software (is it only AT if it is called
> > "AT"?).
> >
> >
> > I suggest that Apple's VoiceOver (bundled with the OS X 10.4 and
> > later), and Gnopernicus & GOK (bundled with Solaris 10), and GOK &
> > Orca (bundled with Ubuntu GNU/Linux 6.10) *are* all AT. In exactly
> > the same way that we (now) say that WordPad is an application (even
> > though it is bundled with Windows).
> >
> >
> > Regards,
> >
> > Peter Korn
> > Accessibility Architect,
> > Sun Microsystems, Inc.
> > > I thought of that as I wrote it.
> > >
> > > Well, since it is built into the OS, the application that
> > work with it would
> > > be directly accessible since they are accessible without
> > needing any AT.
> > > Remember that any software with access built in would need
> > to rely on OS
> > > functions (speech, sound, keyboard etc). this would also
> > rely on the
> > > voiceover functionality.
> > >
> > > Since they have an API - it would ALSO be compatible with
> > any AT that was
> > > out there.
> > >
> > > Having an API only though - without AT support would not be
> > accessible (i.e.
> > > usable with people who have disabilities) if there was no
> > AT. That is why
> > > Apple built it into their system and have an API. They
> > support AT but are
> > > not subject to AT availability - which was a problem for
> > them - at least for
> > > screen readers.
> > >
> > >
> > > Gregg
> > > -- ------------------------------
> > > Gregg C Vanderheiden Ph.D.
> > >
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: = EMAIL ADDRESS REMOVED =
> > >> [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of David
> > >> Poehlman
> > >> Sent: Wednesday, January 03, 2007 4:38 AM
> > >> To: TEITAC Web/Software Subcommittee
> > >> Cc: 'TEITAC self contained/closed products
> subcommittee'; 'TEITAC
> > >> General Interface Accessibility Subcommittee'
> > >> Subject: Re: [teitac-general] [teitac-websoftware]
> [teitac-closed]
> > >> "closed software"
> > >>
> > >> greg, am I to understand then that your #2 excludes the
> Mac which
> > >> has its ownn AT?
> > >>
> > >> On Jan 3, 2007, at 1:02 AM, Gregg Vanderheiden wrote:
> > >>
> > >> Hi Norman,
> > >>
> > >> I agree with your premise that there shouldn't be any
> > closed software.
> > >>
> > >> But if there is software that is closed (not accessible to
> > >> AT) for any reason (business, technical or security) then we do
> > >> want to require that it
> > >> is accessible - no? And I believe that there will be
> legitimate
> > >> arguments
> > >> for some places where the software will be closed - and/or that
> > >> there will be no AT developed for or that can be used with the
> > >> product.
> > >>
> > >> I'm not talking about desktop computers necessarily.
> > >>
> > >> What if we just said
> > >>
> > >> 1) that products need to be accessible either via available
> > >> assistive technology or directly accessible.
> > >>
> > >> 2) that products that require productivity (e.g.
> > >> workstations) need to be accessible to assistive technologies to
> > >> allow matching of user abilities necessary to achieve
> high levels
> > >> of productivity.
> > >>
> > >>
> > >> Gregg
> > >> -- ------------------------------ Gregg C Vanderheiden Ph.D.
> > >>
> > >>
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: = EMAIL ADDRESS REMOVED =
> > >>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> > >>>
> > >> Of Robinson,
> > >>
> > >>> Norman B - Washington, DC
> > >>> Sent: Wednesday, December 27, 2006 2:54 PM
> > >>> To: TEITAC self contained/closed products subcommittee; TEITAC
> > >>> Web/Software Subcommittee
> > >>> Cc: TEITAC General Interface Accessibility Subcommittee
> > >>> Subject: Re: [teitac-general] [teitac-closed] "closed software"
> > >>>
> > >>> Since I earlier offered a different perspective on "closed
> > >>>
> > >> software",
> > >>
> > >>> I thought I would respond to each item.
> > >>>
> > >>> 1. Security reasons: Security should be a part of a
> > >>>
> > >> requirement in the
> > >>
> > >>> same way accessibility should be a part of the
> requirement for a
> > >>> product. First, security options _CAN_ be accessible (e.g.,
> > >>>
> > >> accessible
> > >>
> > >>> CAPTCHAs or accessible login screens). Second, where there is a
> > >>> technical determination that no access to application
> programming
> > >>> interfaces (APIs) that work with assistive technology
> is allowed,
> > >>> there is a business justification. No matter what assistive
> > >>>
> > >> technology
> > >>
> > >>> can do, if the system designed to block user interaction to
> > >>>
> > >> only one
> > >>
> > >>> type of system interface for business reasons, that is an
> > >>>
> > >> exception.
> > >>
> > >>> However, I'd be amiss if I didn't say see "First".
> > >>>
> > >>> 2. Besides semantics, and debating among friends, software
> > >>>
> > >> can't run
> > >>
> > >>> without an operating system unless it, itself, IS the operating
> > >>> system.
> > >>>
> > >>> 3. What is the point of making a classification of "CLOSED
> > >>>
> > >> SOFTWARE"?
> > >>
> > >>> What does it mean to us in context of Section 508? Your
> > >>>
> > >> example is one
> > >>
> > >>> of being accessible through design. I'd say the example
> > >>>
> > >> doesn't help
> > >>
> > >>> the argument and problem we are trying to solve (if
> you'll please
> > >>> forgive me). We are concerned when software doesn't work with
> > >>> assistive technology and isn't designed to be accessible.
> > >>>
> > >> I'd also say
> > >>
> > >>> I have the expectation that this software is generally
> > only used in
> > >>> conjunction with specialized hardware. Firefox web browser was
> > >>> considered to be too small a market for certain AT vendors.
> > >>>
> > >> What does
> > >>
> > >>> that mean? I think they have an API. I think this is complex
> > >>> interaction of _accessibility interfaces_ dependent on the
> > >>>
> > >> operating
> > >>
> > >>> system. Sorry, I'm an Amiga/Windows/OSX/Linux user and
> it varies
> > >>> considerably. It is too easy to just think in context of
> > >>>
> > >> one platform,
> > >>
> > >>> especially when embedded operating systems in phones are so
> > >>>
> > >> plentiful
> > >>
> > >>> and experiencing these same issues. Sorry to ramble, I
> > >>>
> > >> think I need to
> > >>
> > >>> discuss this some more.
> > >>>
> > >>> 4. Platform software issues are interesting. Is commercial
> > >>> availability exemptions? Tying it to vendor product and
> > 'official'
> > >>> support is dangerous too; I'm sure my MS Windows vendor doesn't
> > >>> support me running Linux on my corporate desktop, but
> the screen
> > >>> reader and web browser works just fine for most of my
> > >>>
> > >> needs. I think
> > >>
> > >>> that is close to the earlier iPod firmware upgrade. But
> > who cares?
> > >>> Even if a 3rd party or Apple made the software as an
> > add-on to the
> > >>> product it can be made accessible. The debate so far has
> > focused on
> > >>> the vendor not developing assistive technology. Third
> > >>>
> > >> parties do and
> > >>
> > >>> you can make things accessible without assistive technology.
> > >>>
> > >>> Sorry to disagree, but the closed software approach doesn't
> > >>>
> > >> work well
> > >>
> > >>> for Section 508 evaluation. I can't help but feel we're not
> > >>>
> > >> asking the
> > >>
> > >>> right questions. DRM is bad for end-users, security typically
> > >>> negatively impacts end-user experience, and accessibility
> > >>>
> > >> is all about
> > >>
> > >>> the user!
> > >>> This discussion is really useful for questioning vendors
> > >>>
> > >> and how they
> > >>
> > >>> support our business/agency. I don't think finding
> > >>>
> > >> justification for
> > >>
> > >>> closed software means we should place a label on software
> > >>>
> > >> and treat it
> > >>
> > >>> any differently from any other software. Closed software
> > should be
> > >>> accessible and follow the same technical standards as any other
> > >>> software.
> > >>>
> > >>> Regards,
> > >>>
> > >>>
> > >>> Norman B. Robinson
> > >>> Section 508 Coordinator
> > >>> IT Governance, US Postal Service
> > >>> phone: 202.268.8246
> > >>>
> > >>>
> > >>> -----Original Message-----
> > >>> From: = EMAIL ADDRESS REMOVED =
> > >>> [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Gregg
> > >>> Vanderheiden
> > >>> Sent: Tuesday, December 19, 2006 12:45 PM
> > >>> To: 'TEITAC self contained/closed products
> subcommittee'; 'TEITAC
> > >>> Web/Software Subcommittee'
> > >>> Cc: 'TEITAC General Interface Accessibility Subcommittee'
> > >>> Subject: Re: [teitac-closed] "closed software"
> > >>>
> > >>>
> > >>> Some possible examples of closed software.
> > >>>
> > >>> Maybe some things like: (numbered only to facilitate discussion)
> > >>>
> > >>> 1 - Software that for security reasons does not allow
> anything to
> > >>> access what it has on screen and which reads keyboard registers
> > >>> directly to avoid tampering or 'remote' typing.
> > >>>
> > >>> 2 - Software designed to run on a product without and operating
> > >>> system.
> > >>>
> > >>> 3 - Software that has no API for AT - but instead has built in
> > >>> accessibility since there is no AT vendor who will work
> with and
> > >>> support the unique capability of the software because the
> > market is
> > >>> too small for AT vendors.
> > >>>
> > >>> 4 - Something like Randy pointed to (see just below). The
> > >>>
> > >> hardware is
> > >>
> > >>> not closed since new software can be loaded. But the
> > >>> platform/software is closed.
> > >>>
> > >>> Gregg
> > >>> -- ------------------------------
> > >>> Gregg C Vanderheiden Ph.D.
> > >>>

From: Gregg Vanderheiden
Date: Mon, Jan 08 2007 4:40 PM
Subject: Re: "closed software"

Not sure what "AT middleware is". You said you thought screen readers were
middleware. (not sure what a screen reader is in the middle of - unless
all interfaces are middleware.) so I'm not sure I'm understanding you. But
let me take a stab and see if I misunderstood.

You asked

> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"

If I understand the proposition you mean "Only" accessible through AT
correct? (if it was also directly accessible then there is not problem).
But if the product is not usable by people with disabilities except through
AT and there is no AT - then I don't see how we could call it accessible.
Certainly, anyone with a disability that was employed in a government job
that would now be using that software would have to find another job or go
create their own AT for the software it would seem.

Did I misunderstand?

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Rex Lint
> Sent: Monday, January 08, 2007 11:17 AM
> To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General
> Interface Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
> Cc: 'TEITAC self contained/closed products subcommittee'
> Subject: Re:
> [teitac-websoftware][teitac-general][teitac-closed]"closed software"
>
> Jim, Gregg, et. al.
>
> Many manufacturers include "Out of the Box" (OOTB)
> applications with their operating systems. These are not
> (necessarily) cutting edge, but intended to provide SOME
> level of access to functionality. An example is WORDPAD (I
> don't think they include NOTEPAD any more) by Microsoft, for
> simple, limited editing.
>
> Anyone who wants to do more than rudimentary editing would
> procure and use some other, robust application - a
> word-processor. WORD is one, and there are others. These
> feature-rich applications supplant the function of the OOTB
> application(s).
>
> Manufacturers have taken similar approaches to accessibility
> provisions.
> Take NARRATOR on XP. It's not for extensive use, it's for
> getting access to something on a VERY occasional basis. I
> think it's valuable because it gives the general public the
> vision that it's possible to hear the contents of a page
> instead of see it - good for simple demos about accessibility.
>
> I'm sure the same situation applies to the use of O/S "Out of the Box"
> accessibility utilities: people with specific disabilities
> will want to get really robust "middleware" to address their needs.
>
> So I see there is a range of software we're talking about in
> this thread -
>
> * Utilities intended for limited, infrequent use,
> * Applications that address the needs to accomplish a task
> * Middleware that sits between applications and the OS or
> applications and the user.
>
> I think AT like screen readers fall in the middleware class.
>
> I think a definition of AT that acknowledges this spectrum would be
> appropriate:
>
> Perhaps the utilities (particularly if done through a
> published API) could form the basis of one level, "built-in"
> perhaps, accessibility.
>
> Then compatibility with middleware-class AT (hopefully
> through the sendor-supplied published API) would be enough to
> make the product rise to a level classed as "accessible
> through AT." This approach would tend to make "built-in" AT
> less desirable than "accessible through AT," to people with
> disabilities.
>
> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"
>
> As Gregg would say, "Hmmmm...."
>
> Rex
>
>
> Rex Lint,
> Information Technology Association of America
> PH: 603-860-7651
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Tobias
> Sent: Thursday, January 04, 2007 11:01 AM
> To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General Interface
> Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
> Cc: 'TEITAC self contained/closed products subcommittee'
> Subject: Re:
> [teitac-websoftware][teitac-general][teitac-closed]"closed
> software"
>
> I'm copying the Subpart A folks on this discussion because
> that's where the
> AT definition will reside, and because I know some of them
> have definite
> and expansive ideas about the definition of AT.
>
> I agree that splitting hairs will not get us anywhere, and that we're
> moving towards an environment in which there may well be a range of
> AT functionality in an OS setting, an OS utility, a bundled
> application,
> and a clearly third-party AT application requiring separate
> installation.
>
> I'm not sure that "paying extra" is the best or only way to
> identify AT,
> as price is certainly not the worst or only barrier to the
> use of AT. The
> combination of lack of information and lack of confidence in
> altering their
> computer's standard operation is what holds most people back. For
> evidence, look at the Microsoft study on underutilization of the many
> capabilities found free within Windows. Similarly,
> installing Gnopernicus
> is not exactly a one-click experience.
>
> > -----Original Message-----
> > From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> > Sent: Thursday, January 04, 2007 12:15 AM
> > To: 'TEITAC General Interface Accessibility Subcommittee';
> > 'TEITAC Web/Software Subcommittee'
> > Cc: 'TEITAC self contained/closed products subcommittee'
> > Subject: Re: [teitac-websoftware]
> > [teitac-general][teitac-closed]"closed software"
> >
> > No. AT can be from same company.
> >
> > If the user has to pay extra for it - then I would call it AT.
> >
> > If it comes as part of the product - I would call it built
> > in. Especially if it is shipped as part of the product to
> everyone.
> >
> > But I think we need to write our regs so that we don't have
> > to get into such discussions or hair splitting. Because the
> > way things are going it will be
> > impossible to separate things into AT or not-AT. Use any
> > definition you
> > like and I will give you examples that fit both definitions
> > at different times.
> >
> > The issue isn't whether it is AT or not. I belive that what
> > we need to focus on is whether people with disabilities, with
> > whatever they have, can access and use the products.
> >
> > Now - how to phrase the standards to do this...
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter
> > > Korn
> > > Sent: Wednesday, January 03, 2007 2:07 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Cc: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
> > > General Interface Accessibility Subcommittee'
> > > Subject: Re: [teitac-general] [teitac-websoftware]
> > > [teitac-closed]"closed software"
> > >
> > > Hi Gregg,
> > >
> > > I don't understand this. Is it part of the definition of
> > AT that it
> > > comes from a 3rd party, separate from the OS? Or can it be
> > the same
> > > party as the OS, but just not with the OS (e.g.
> ScreenReader/2 for
> > > OS/2)?
> > >
> > > Separately, today in the Web & Software SC call, Andi asked about
> > > non-AT voice recognition software (is it only AT if it is called
> > > "AT"?).
> > >
> > >
> > > I suggest that Apple's VoiceOver (bundled with the OS X 10.4 and
> > > later), and Gnopernicus & GOK (bundled with Solaris 10),
> and GOK &
> > > Orca (bundled with Ubuntu GNU/Linux 6.10) *are* all AT.
> In exactly
> > > the same way that we (now) say that WordPad is an
> application (even
> > > though it is bundled with Windows).
> > >
> > >
> > > Regards,
> > >
> > > Peter Korn
> > > Accessibility Architect,
> > > Sun Microsystems, Inc.
> > > > I thought of that as I wrote it.
> > > >
> > > > Well, since it is built into the OS, the application that
> > > work with it would
> > > > be directly accessible since they are accessible without
> > > needing any AT.
> > > > Remember that any software with access built in would need
> > > to rely on OS
> > > > functions (speech, sound, keyboard etc). this would also
> > > rely on the
> > > > voiceover functionality.
> > > >
> > > > Since they have an API - it would ALSO be compatible with
> > > any AT that was
> > > > out there.
> > > >
> > > > Having an API only though - without AT support would not be
> > > accessible (i.e.
> > > > usable with people who have disabilities) if there was no
> > > AT. That is why
> > > > Apple built it into their system and have an API. They
> > > support AT but are
> > > > not subject to AT availability - which was a problem for
> > > them - at least for
> > > > screen readers.
> > > >
> > > >
> > > > Gregg
> > > > -- ------------------------------
> > > > Gregg C Vanderheiden Ph.D.
> > > >
> > > >
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: = EMAIL ADDRESS REMOVED =
> > > >> [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of David
> > > >> Poehlman
> > > >> Sent: Wednesday, January 03, 2007 4:38 AM
> > > >> To: TEITAC Web/Software Subcommittee
> > > >> Cc: 'TEITAC self contained/closed products
> > subcommittee'; 'TEITAC
> > > >> General Interface Accessibility Subcommittee'
> > > >> Subject: Re: [teitac-general] [teitac-websoftware]
> > [teitac-closed]
> > > >> "closed software"
> > > >>
> > > >> greg, am I to understand then that your #2 excludes the
> > Mac which
> > > >> has its ownn AT?
> > > >>
> > > >> On Jan 3, 2007, at 1:02 AM, Gregg Vanderheiden wrote:
> > > >>
> > > >> Hi Norman,
> > > >>
> > > >> I agree with your premise that there shouldn't be any
> > > closed software.
> > > >>
> > > >> But if there is software that is closed (not accessible to
> > > >> AT) for any reason (business, technical or security)
> then we do
> > > >> want to require that it
> > > >> is accessible - no? And I believe that there will be
> > legitimate
> > > >> arguments
> > > >> for some places where the software will be closed -
> and/or that
> > > >> there will be no AT developed for or that can be used with the
> > > >> product.
> > > >>
> > > >> I'm not talking about desktop computers necessarily.
> > > >>
> > > >> What if we just said
> > > >>
> > > >> 1) that products need to be accessible either via available
> > > >> assistive technology or directly accessible.
> > > >>
> > > >> 2) that products that require productivity (e.g.
> > > >> workstations) need to be accessible to assistive
> technologies to
> > > >> allow matching of user abilities necessary to achieve
> > high levels
> > > >> of productivity.
> > > >>
> > > >>
> > > >> Gregg
> > > >> -- ------------------------------ Gregg C Vanderheiden Ph.D.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: = EMAIL ADDRESS REMOVED =
> > > >>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> > > >>>
> > > >> Of Robinson,
> > > >>
> > > >>> Norman B - Washington, DC
> > > >>> Sent: Wednesday, December 27, 2006 2:54 PM
> > > >>> To: TEITAC self contained/closed products
> subcommittee; TEITAC
> > > >>> Web/Software Subcommittee
> > > >>> Cc: TEITAC General Interface Accessibility Subcommittee
> > > >>> Subject: Re: [teitac-general] [teitac-closed] "closed
> software"
> > > >>>
> > > >>> Since I earlier offered a different perspective on "closed
> > > >>>
> > > >> software",
> > > >>
> > > >>> I thought I would respond to each item.
> > > >>>
> > > >>> 1. Security reasons: Security should be a part of a
> > > >>>
> > > >> requirement in the
> > > >>
> > > >>> same way accessibility should be a part of the
> > requirement for a
> > > >>> product. First, security options _CAN_ be accessible (e.g.,
> > > >>>
> > > >> accessible
> > > >>
> > > >>> CAPTCHAs or accessible login screens). Second, where
> there is a
> > > >>> technical determination that no access to application
> > programming
> > > >>> interfaces (APIs) that work with assistive technology
> > is allowed,
> > > >>> there is a business justification. No matter what assistive
> > > >>>
> > > >> technology
> > > >>
> > > >>> can do, if the system designed to block user interaction to
> > > >>>
> > > >> only one
> > > >>
> > > >>> type of system interface for business reasons, that is an
> > > >>>
> > > >> exception.
> > > >>
> > > >>> However, I'd be amiss if I didn't say see "First".
> > > >>>
> > > >>> 2. Besides semantics, and debating among friends, software
> > > >>>
> > > >> can't run
> > > >>
> > > >>> without an operating system unless it, itself, IS the
> operating
> > > >>> system.
> > > >>>
> > > >>> 3. What is the point of making a classification of "CLOSED
> > > >>>
> > > >> SOFTWARE"?
> > > >>
> > > >>> What does it mean to us in context of Section 508? Your
> > > >>>
> > > >> example is one
> > > >>
> > > >>> of being accessible through design. I'd say the example
> > > >>>
> > > >> doesn't help
> > > >>
> > > >>> the argument and problem we are trying to solve (if
> > you'll please
> > > >>> forgive me). We are concerned when software doesn't work with
> > > >>> assistive technology and isn't designed to be accessible.
> > > >>>
> > > >> I'd also say
> > > >>
> > > >>> I have the expectation that this software is generally
> > > only used in
> > > >>> conjunction with specialized hardware. Firefox web
> browser was
> > > >>> considered to be too small a market for certain AT vendors.
> > > >>>
> > > >> What does
> > > >>
> > > >>> that mean? I think they have an API. I think this is complex
> > > >>> interaction of _accessibility interfaces_ dependent on the
> > > >>>
> > > >> operating
> > > >>
> > > >>> system. Sorry, I'm an Amiga/Windows/OSX/Linux user and
> > it varies
> > > >>> considerably. It is too easy to just think in context of
> > > >>>
> > > >> one platform,
> > > >>
> > > >>> especially when embedded operating systems in phones are so
> > > >>>
> > > >> plentiful
> > > >>
> > > >>> and experiencing these same issues. Sorry to ramble, I
> > > >>>
> > > >> think I need to
> > > >>
> > > >>> discuss this some more.
> > > >>>
> > > >>> 4. Platform software issues are interesting. Is commercial
> > > >>> availability exemptions? Tying it to vendor product and
> > > 'official'
> > > >>> support is dangerous too; I'm sure my MS Windows
> vendor doesn't
> > > >>> support me running Linux on my corporate desktop, but
> > the screen
> > > >>> reader and web browser works just fine for most of my
> > > >>>
> > > >> needs. I think
> > > >>
> > > >>> that is close to the earlier iPod firmware upgrade. But
> > > who cares?
> > > >>> Even if a 3rd party or Apple made the software as an
> > > add-on to the
> > > >>> product it can be made accessible. The debate so far has
> > > focused on
> > > >>> the vendor not developing assistive technology. Third
> > > >>>
> > > >> parties do and
> > > >>
> > > >>> you can make things accessible without assistive technology.
> > > >>>
> > > >>> Sorry to disagree, but the closed software approach doesn't
> > > >>>
> > > >> work well
> > > >>
> > > >>> for Section 508 evaluation. I can't help but feel we're not
> > > >>>
> > > >> asking the
> > > >>
> > > >>> right questions. DRM is bad for end-users, security typically
> > > >>> negatively impacts end-user experience, and accessibility
> > > >>>
> > > >> is all about
> > > >>
> > > >>> the user!
> > > >>> This discussion is really useful for questioning vendors
> > > >>>
> > > >> and how they
> > > >>
> > > >>> support our business/agency. I don't think finding
> > > >>>
> > > >> justification for
> > > >>
> > > >>> closed software means we should place a label on software
> > > >>>
> > > >> and treat it
> > > >>
> > > >>> any differently from any other software. Closed software
> > > should be
> > > >>> accessible and follow the same technical standards as
> any other
> > > >>> software.
> > > >>>
> > > >>> Regards,
> > > >>>
> > > >>>
> > > >>> Norman B. Robinson
> > > >>> Section 508 Coordinator
> > > >>> IT Governance, US Postal Service
> > > >>> phone: 202.268.8246
> > > >>>
> > > >>>
> > > >>> -----Original Message-----
> > > >>> From: = EMAIL ADDRESS REMOVED =
> > > >>> [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of Gregg
> > > >>> Vanderheiden
> > > >>> Sent: Tuesday, December 19, 2006 12:45 PM
> > > >>> To: 'TEITAC self contained/closed products
> > subcommittee'; 'TEITAC
> > > >>> Web/Software Subcommittee'
> > > >>> Cc: 'TEITAC General Interface Accessibility Subcommittee'
> > > >>> Subject: Re: [teitac-closed] "closed software"
> > > >>>
> > > >>>
> > > >>> Some possible examples of closed software.
> > > >>>
> > > >>> Maybe some things like: (numbered only to facilitate
> discussion)
> > > >>>
> > > >>> 1 - Software that for security reasons does not allow
> > anything to
> > > >>> access what it has on screen and which reads keyboard
> registers
> > > >>> directly to avoid tampering or 'remote' typing.
> > > >>>
> > > >>> 2 - Software designed to run on a product without and
> operating
> > > >>> system.
> > > >>>
> > > >>> 3 - Software that has no API for AT - but instead has
> built in
> > > >>> accessibility since there is no AT vendor who will work
> > with and
> > > >>> support the unique capability of the software because the
> > > market is
> > > >>> too small for AT vendors.
> > > >>>
> > > >>> 4 - Something like Randy pointed to (see just below). The
> > > >>>
> > > >> hardware is
> > > >>
> > > >>> not closed since new software can be loaded. But the
> > > >>> platform/software is closed.
> > > >>>
> > > >>> Gregg
> > > >>> -- ------------------------------
> > > >>> Gregg C Vanderheiden Ph.D.
> > > >>>

From: Rex Lint
Date: Mon, Jan 08 2007 7:30 PM
Subject: Re: "closed software"

GV = Gregg
RL = Rex

GV: " Not sure what "AT middleware is"."
RL: My name for, lets say, a screen reader: It's not an "application"
that does work like a word process.
It's not a utility, like NARRATOR, analogous to your 30-second door
opener.
It's in the middle, between an application, the o/s and the
user.
GV: You asked
> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"
RL: I didn't really ask this. I proposed that there were levels of
accessibility, just like you proposed different speeds of
"door openers." I said that if you accept the idea of different
levels of accessibility, there was an open question that we've
been kicking around before, having to do with providing hooks for AT
but having no AT that took advantage of those hooks and thereby
provided access to the IT for people with disabilities.


Rex
---------

Rex Lint, Consultant
Chair, Section 508 Working Group
Information Technology Association of America
PH: 603-860-7651, FAX: 603-882-6612


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, January 08, 2007 6:25 PM
To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General Interface
Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
Cc: 'TEITAC self contained/closed products subcommittee'
Subject: Re: [teitac-closed][teitac-websoftware][teitac-general]"closed
software"

Not sure what "AT middleware is". You said you thought screen readers were
middleware. (not sure what a screen reader is in the middle of - unless
all interfaces are middleware.) so I'm not sure I'm understanding you. But
let me take a stab and see if I misunderstood.

You asked

> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"

If I understand the proposition you mean "Only" accessible through AT
correct? (if it was also directly accessible then there is not problem).
But if the product is not usable by people with disabilities except through
AT and there is no AT - then I don't see how we could call it accessible.
Certainly, anyone with a disability that was employed in a government job
that would now be using that software would have to find another job or go
create their own AT for the software it would seem.

Did I misunderstand?

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Rex Lint
> Sent: Monday, January 08, 2007 11:17 AM
> To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General
> Interface Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
> Cc: 'TEITAC self contained/closed products subcommittee'
> Subject: Re:
> [teitac-websoftware][teitac-general][teitac-closed]"closed software"
>
> Jim, Gregg, et. al.
>
> Many manufacturers include "Out of the Box" (OOTB)
> applications with their operating systems. These are not
> (necessarily) cutting edge, but intended to provide SOME
> level of access to functionality. An example is WORDPAD (I
> don't think they include NOTEPAD any more) by Microsoft, for
> simple, limited editing.
>
> Anyone who wants to do more than rudimentary editing would
> procure and use some other, robust application - a
> word-processor. WORD is one, and there are others. These
> feature-rich applications supplant the function of the OOTB
> application(s).
>
> Manufacturers have taken similar approaches to accessibility
> provisions.
> Take NARRATOR on XP. It's not for extensive use, it's for
> getting access to something on a VERY occasional basis. I
> think it's valuable because it gives the general public the
> vision that it's possible to hear the contents of a page
> instead of see it - good for simple demos about accessibility.
>
> I'm sure the same situation applies to the use of O/S "Out of the Box"
> accessibility utilities: people with specific disabilities
> will want to get really robust "middleware" to address their needs.
>
> So I see there is a range of software we're talking about in
> this thread -
>
> * Utilities intended for limited, infrequent use,
> * Applications that address the needs to accomplish a task
> * Middleware that sits between applications and the OS or
> applications and the user.
>
> I think AT like screen readers fall in the middleware class.
>
> I think a definition of AT that acknowledges this spectrum would be
> appropriate:
>
> Perhaps the utilities (particularly if done through a
> published API) could form the basis of one level, "built-in"
> perhaps, accessibility.
>
> Then compatibility with middleware-class AT (hopefully
> through the sendor-supplied published API) would be enough to
> make the product rise to a level classed as "accessible
> through AT." This approach would tend to make "built-in" AT
> less desirable than "accessible through AT," to people with
> disabilities.
>
> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"
>
> As Gregg would say, "Hmmmm...."
>
> Rex
>
>
> Rex Lint,
> Information Technology Association of America
> PH: 603-860-7651
>

From: Rex Lint
Date: Mon, Jan 08 2007 7:40 PM
Subject: Re: "closed software"

GV = Gregg
RL = Rex

GV:
" Not sure what "AT middleware is"."

RL:

My name for, lets say, a screen reader: It's not an "application" that does
work like a word processor.
It's not a utility, like NARRATOR, analogous to your 30-second door opener.
It's in the middle, between an application, the o/s and the user.

GV:

You asked
> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"

RL:

I didn't really ask this. I proposed that there were levels of
accessibility, just like you proposed different speeds of "door openers." I
said that if you accept the idea of different levels of accessibility, there
was an open question that we've been kicking around before, having to do
with providing hooks for AT but having no AT that took advantage of those
hooks and thereby provided access to the IT for people with disabilities.


Rex
---------

Rex Lint, Consultant
Chair, Section 508 Working Group
Information Technology Association of America
PH: 603-860-7651, FAX: 603-882-6612


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, January 08, 2007 6:25 PM
To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General Interface
Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
Cc: 'TEITAC self contained/closed products subcommittee'
Subject: Re: [teitac-closed][teitac-websoftware][teitac-general]"closed
software"

Not sure what "AT middleware is". You said you thought screen readers were
middleware. (not sure what a screen reader is in the middle of - unless
all interfaces are middleware.) so I'm not sure I'm understanding you. But
let me take a stab and see if I misunderstood.

You asked

> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"

If I understand the proposition you mean "Only" accessible through AT
correct? (if it was also directly accessible then there is not problem).
But if the product is not usable by people with disabilities except through
AT and there is no AT - then I don't see how we could call it accessible.
Certainly, anyone with a disability that was employed in a government job
that would now be using that software would have to find another job or go
create their own AT for the software it would seem.

Did I misunderstand?

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Rex Lint
> Sent: Monday, January 08, 2007 11:17 AM
> To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General
> Interface Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
> Cc: 'TEITAC self contained/closed products subcommittee'
> Subject: Re:
> [teitac-websoftware][teitac-general][teitac-closed]"closed software"
>
> Jim, Gregg, et. al.
>
> Many manufacturers include "Out of the Box" (OOTB)
> applications with their operating systems. These are not
> (necessarily) cutting edge, but intended to provide SOME
> level of access to functionality. An example is WORDPAD (I
> don't think they include NOTEPAD any more) by Microsoft, for
> simple, limited editing.
>
> Anyone who wants to do more than rudimentary editing would
> procure and use some other, robust application - a
> word-processor. WORD is one, and there are others. These
> feature-rich applications supplant the function of the OOTB
> application(s).
>
> Manufacturers have taken similar approaches to accessibility
> provisions.
> Take NARRATOR on XP. It's not for extensive use, it's for
> getting access to something on a VERY occasional basis. I
> think it's valuable because it gives the general public the
> vision that it's possible to hear the contents of a page
> instead of see it - good for simple demos about accessibility.
>
> I'm sure the same situation applies to the use of O/S "Out of the Box"
> accessibility utilities: people with specific disabilities
> will want to get really robust "middleware" to address their needs.
>
> So I see there is a range of software we're talking about in
> this thread -
>
> * Utilities intended for limited, infrequent use,
> * Applications that address the needs to accomplish a task
> * Middleware that sits between applications and the OS or
> applications and the user.
>
> I think AT like screen readers fall in the middleware class.
>
> I think a definition of AT that acknowledges this spectrum would be
> appropriate:
>
> Perhaps the utilities (particularly if done through a
> published API) could form the basis of one level, "built-in"
> perhaps, accessibility.
>
> Then compatibility with middleware-class AT (hopefully
> through the sendor-supplied published API) would be enough to
> make the product rise to a level classed as "accessible
> through AT." This approach would tend to make "built-in" AT
> less desirable than "accessible through AT," to people with
> disabilities.
>
> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"
>
> As Gregg would say, "Hmmmm...."
>
> Rex
>
>
> Rex Lint,
> Information Technology Association of America
> PH: 603-860-7651
>

From: Rex Lint
Date: Mon, Jan 08 2007 7:50 PM
Subject: Re: "closed software"

GV = Gregg
RL = Rex

GV:
" Not sure what "AT middleware is"."

RL:

My name for, lets say, a screen reader: It's not an "application" that does
work like a word processor.
It's not a utility, like NARRATOR, analogous to your 30-second door opener.
It's in the middle, between an application, the o/s and the user.

GV:

You asked
> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"

RL:

I didn't really ask this. I proposed that there were levels of
accessibility, just like you proposed different speeds of "door openers." I
said that if you accept the idea of different levels of accessibility, there
was an open question that we've been kicking around before, having to do
with providing hooks for AT but having no AT that took advantage of those
hooks and thereby provided access to the IT for people with disabilities.


Rex
---------

Rex Lint, Consultant
Chair, Section 508 Working Group
Information Technology Association of America
PH: 603-860-7651, FAX: 603-882-6612


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, January 08, 2007 6:25 PM
To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General Interface
Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
Cc: 'TEITAC self contained/closed products subcommittee'
Subject: Re: [teitac-closed][teitac-websoftware][teitac-general]"closed
software"

Not sure what "AT middleware is". You said you thought screen readers were
middleware. (not sure what a screen reader is in the middle of - unless
all interfaces are middleware.) so I'm not sure I'm understanding you. But
let me take a stab and see if I misunderstood.

You asked

> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"

If I understand the proposition you mean "Only" accessible through AT
correct? (if it was also directly accessible then there is not problem).
But if the product is not usable by people with disabilities except through
AT and there is no AT - then I don't see how we could call it accessible.
Certainly, anyone with a disability that was employed in a government job
that would now be using that software would have to find another job or go
create their own AT for the software it would seem.

Did I misunderstand?

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Rex Lint
> Sent: Monday, January 08, 2007 11:17 AM
> To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General
> Interface Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
> Cc: 'TEITAC self contained/closed products subcommittee'
> Subject: Re:
> [teitac-websoftware][teitac-general][teitac-closed]"closed software"
>
> Jim, Gregg, et. al.
>
> Many manufacturers include "Out of the Box" (OOTB)
> applications with their operating systems. These are not
> (necessarily) cutting edge, but intended to provide SOME
> level of access to functionality. An example is WORDPAD (I
> don't think they include NOTEPAD any more) by Microsoft, for
> simple, limited editing.
>
> Anyone who wants to do more than rudimentary editing would
> procure and use some other, robust application - a
> word-processor. WORD is one, and there are others. These
> feature-rich applications supplant the function of the OOTB
> application(s).
>
> Manufacturers have taken similar approaches to accessibility
> provisions.
> Take NARRATOR on XP. It's not for extensive use, it's for
> getting access to something on a VERY occasional basis. I
> think it's valuable because it gives the general public the
> vision that it's possible to hear the contents of a page
> instead of see it - good for simple demos about accessibility.
>
> I'm sure the same situation applies to the use of O/S "Out of the Box"
> accessibility utilities: people with specific disabilities
> will want to get really robust "middleware" to address their needs.
>
> So I see there is a range of software we're talking about in
> this thread -
>
> * Utilities intended for limited, infrequent use,
> * Applications that address the needs to accomplish a task
> * Middleware that sits between applications and the OS or
> applications and the user.
>
> I think AT like screen readers fall in the middleware class.
>
> I think a definition of AT that acknowledges this spectrum would be
> appropriate:
>
> Perhaps the utilities (particularly if done through a
> published API) could form the basis of one level, "built-in"
> perhaps, accessibility.
>
> Then compatibility with middleware-class AT (hopefully
> through the sendor-supplied published API) would be enough to
> make the product rise to a level classed as "accessible
> through AT." This approach would tend to make "built-in" AT
> less desirable than "accessible through AT," to people with
> disabilities.
>
> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"
>
> As Gregg would say, "Hmmmm...."
>
> Rex
>
>
> Rex Lint,
> Information Technology Association of America
> PH: 603-860-7651
>

From: Gregg Vanderheiden
Date: Wed, Jan 10 2007 7:40 AM
Subject: Re: "closed software"

Hmmmmm

There are, i think three parts to this. Or three situation that could lead
to AT not working with software.



1) There is a bug in the AT. It worked with the last version of the AT but
the new one had a bug. This is the AT's problem I would say.

2) the software does something new that AT hasn't seen before. The software
'enabled' access - but the AT doesn't work with it.
- this one is interesting.
a) if there is a perfect API that covers all aspects - and it is clear how
to use it - then one could say that the AT should have worked with the
software and it is a 'bug' in the AT if it doesn't.
b) if there are many APIs or if the API is not unambiguous or it is somewhat
an art to get the information from the API then I'm not sure it can be only
the AT companies responsibility.
- Until the new thing appeared there was no way for the AT to build to it.
- IT vendors have many many more resources to create new features or access
problems then AT does to solve them. It can't be a 'you just need to catch
up to me' situation.
- the APIs usually provide the basic information - but not the 'interface'.
That is for AT to provide. It takes the software company time to add the
interface for its new feature (even if it uses old technology) and so it
would for AT vendors. Time and money. And if software revamps its
interface it takes a LOT of time and money and testing to get it right.
Ditto for AT - but where does the time and money all come from.


3) software uses an API not supported by AT.
We discussed this one previously. AT vendors can barely keep up with
software as it is. Introducing a new API doesn't make AT appear. And if
there isn't any AT then there isn't any access (for what ever population
there isn't AT for).


The real danger is if we don't 'REQUIRE' a particular API - because we
'REQUIRE' AT vendors to support whatever API industry comes up with (by
saying it is sufficient to have an API).


Having said that - I REALLY like the idea of both sides building to an
API. But
1) it has to be a good and complete API
2) AT vendors will still need help keeping up
3) if there is not AT there is no access. API or not.

*** The API isn't there to substitute for access - but to facilitate it. And
make it less work for both sides. ***

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andi Snow-Weaver
> Sent: Wednesday, January 10, 2007 5:58 AM
> To: TEITAC Web/Software Subcommittee
> Cc: 'TEITAC General Interface Accessibility Subcommittee';
> 'TEITAC Subpart A Subcommittee'
> Subject: Re: [teitac-websoftware]
> [teitac-closed][teitac-general]"closed software"
>
> Gregg asked:
> is
> it?"
>
>
> To which Rex replied:
>
> > I didn't really ask this. I proposed that there were levels of
> accessibility, just like you proposed different speeds of
> "door openers."
> I
> there
> to do
> those
> disabilities.
>
> This is a very real situation and is exactly one of the
> general issues brought up in the Web and Software
> subcommittee which we will be discussing today. It happens
> all the time and not just for the newer APIs or those on
> non-Windows platforms. We have found that we can do all of
> the right things with the most well-supported API (MSAA) on
> the most well-supported platform
> (Windows) and prove that we have done so using inspection
> tools. Yet the screen readers sometimes won't work
> sufficiently with the software.
>
> Some would argue that the IT product in this case meets 508.
> Others would argue that it doesn't and point to the
> functional performance criteria. It depends on how you
> interpret support "for" assistive technology. Some lawyers
> would argue that, in the above case, support "for" assistive
> technology has been provided, it's just that the AT isn't
> using it properly.
>
> In our internal process in IBM, we call this being "enabled"
> for accessibility. It means the development team has done
> their part to make it possible for AT to work with it. But
> further customization of the AT may be required to make this
> actually work for someone. The question is, whose
> responsibility is it to ensure that the AT actually works?
>
> In other technology interoperability standards areas, it is
> quite normal to test "to the standard." So when customers
> need things to interoperate they look for things that claim
> conformance to the standard and there is a very high degree
> of probability that they will work.
>
> This is not the situation in 508 where, by some
> interpretations, conformance to the standard may depend on
> third party products which are not required by the regulation
> to conform to the standard. Am I the only one who finds this bizarre?
>
> I can see a lot of merit to Rex's argument for levels of
> accessibility.
>
> Andi
>
>

From: pina.dintino@scotiabank.com
Date: Wed, Jan 10 2007 7:45 AM
Subject: Re: "closed software"

I agree implicitly. Often confusion lies between accessibility,
functionality and usability, some things having accessibility features may
not actually be user friendly causing the need for scripts, customization,
etc.
When we claim that something is accessible, should there not be some
conformance to ensure it is actually working and usable with AT? If the
standards are to make things easier for users and ensure these users are
as productive as all, we need to ensure the tools, applications, etc can
actually be used with AT in a streamlined manner, not adding additional
work with extra key commands, sequences, additional peripherals, etc.
The guidelines need to be clear, concise while not limiting creativity or
innovation, but ultimately we need to consider what it takes for one to use
the tool no different than anyone not requiring any AT.

Let me be a little clearer. In the case of a PDA, I can purchase software
to make it work for a visually impaired person, but now I need to carry a
Maestro, additional software, peripherals, speakers, etc....I now need a
belt to carry everything so that I can use it with the AT. I also need to
learn to operate the maestro in order to access the PDA and need to ensure
it interfaces with everything else. What does that do to mobility, costs,
portability, etc.
Having different tiers for accessibility may be one way to start attacking
this and gaining some buy-in. We might want to consider further.



Pina D'Intino, PMP, ITIL Cert.
Systems Governance and Financial Services
Information Technology & Solutions
Sr. Manager, Service Management and Reporting
Office: (416) 866-6530
mobile: (416) 948-3348
Fax: (416) 866-4756
email: = EMAIL ADDRESS REMOVED =




Andi Snow-Weaver
< = EMAIL ADDRESS REMOVED = .
com> To
Sent by: TEITAC Web/Software Subcommittee
teitac-websoftwar < = EMAIL ADDRESS REMOVED =
= EMAIL ADDRESS REMOVED = >
itac.org cc
'TEITAC General Interface
Accessibility Subcommittee'
01/10/2007 08:58 < = EMAIL ADDRESS REMOVED = >,
AM 'TEITAC Subpart A Subcommittee'
< = EMAIL ADDRESS REMOVED = >
Subject
Please respond to Re: [teitac-websoftware]
TEITAC [teitac-closed][teitac-general]"clo
Web/Software sed software"
Subcommittee
<teitac-websoftwa
= EMAIL ADDRESS REMOVED =
g>






Gregg asked:
is
it?"


To which Rex replied:

> I didn't really ask this. I proposed that there were levels of
accessibility, just like you proposed different speeds of "door openers."
I
there
to do
those
disabilities.

This is a very real situation and is exactly one of the general issues
brought up in the Web and Software subcommittee which we will be discussing
today. It happens all the time and not just for the newer APIs or those on
non-Windows platforms. We have found that we can do all of the right things
with the most well-supported API (MSAA) on the most well-supported platform
(Windows) and prove that we have done so using inspection tools. Yet the
screen readers sometimes won't work sufficiently with the software.

Some would argue that the IT product in this case meets 508. Others would
argue that it doesn't and point to the functional performance criteria. It
depends on how you interpret support "for" assistive technology. Some
lawyers would argue that, in the above case, support "for" assistive
technology has been provided, it's just that the AT isn't using it
properly.

In our internal process in IBM, we call this being "enabled" for
accessibility. It means the development team has done their part to make it
possible for AT to work with it. But further customization of the AT may be
required to make this actually work for someone. The question is, whose
responsibility is it to ensure that the AT actually works?

In other technology interoperability standards areas, it is quite normal to
test "to the standard." So when customers need things to interoperate they
look for things that claim conformance to the standard and there is a very
high degree of probability that they will work.

This is not the situation in 508 where, by some interpretations,
conformance to the standard may depend on third party products which are
not required by the regulation to conform to the standard. Am I the only
one who finds this bizarre?

I can see a lot of merit to Rex's argument for levels of accessibility.

Andi

_______________________________________________
teitac-websoftware mailing list
= EMAIL ADDRESS REMOVED =
http://list.teitac.org/mailman/listinfo/teitac-websoftware




Notice of Confidentiality:
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately by return electronic transmission and then immediately delete this transmission, including all attachments, without copying, distributing or disclosing same.

Avis de confidentialité:
L’information transmise est strictement réservée à la personne ou à
l’organisme auquel elle est adressée et peut être de nature confidentielle. Toute lecture, retransmission, divulgation ou autre utilisation de cette information, ou toute action prise sur la foi de cette information, par des personnes ou organismes autres que son destinataire est interdite. Si vous avez reçu cette information par erreur, veuillez contacter son expéditeur immédiatement par retour du courrier électronique puis supprimer cette information, y compris toutes pièces jointes, sans en avoir copié, divulgué ou diffusé le contenu.

Aviso de Confidencialidad.
Este correo electrónico y/o el material adjunto es para uso exclusivo de la persona o entidad a la que expresamente se le ha enviado, y puede contener información confidencial o material privilegiado. Si usted no es el destinatario legítimo del mismo, por favor repórtelo inmediatamente al remitente del correo y bórrelo. Cualquier revisión, retransmisión, difusión o cualquier otro uso de este correo, por personas o entidades distintas a las del destinatario legítimo, queda expresamente prohibido. Este correo electrónico no pretende ni debe ser considerado como constitutivo de ninguna relación legal, contractual o de otra índole similar.
_______________________________________________
teitac-websoftware mailing list
= EMAIL ADDRESS REMOVED =
http://list.teitac.org/mailman/listinfo/teitac-websoftware

From: Gregg Vanderheiden
Date: Wed, Jan 10 2007 7:55 AM
Subject: Re: "closed software"

Hmmmmm

There are, i think three parts to this. Or three situation that could lead
to AT not working with software.



1) There is a bug in the AT. It worked with the last version of the AT but
the new one had a bug. This is the AT's problem I would say.

2) the software does something new that AT hasn't seen before. The software
'enabled' access - but the AT doesn't work with it.
- this one is interesting.
a) if there is a perfect API that covers all aspects - and it is clear how
to use it - then one could say that the AT should have worked with the
software and it is a 'bug' in the AT if it doesn't.
b) if there are many APIs or if the API is not unambiguous or it is somewhat
an art to get the information from the API then I'm not sure it can be only
the AT companies responsibility.
- Until the new thing appeared there was no way for the AT to build to it.
- IT vendors have many many more resources to create new features or access
problems then AT does to solve them. It can't be a 'you just need to catch
up to me' situation.
- the APIs usually provide the basic information - but not the 'interface'.
That is for AT to provide. It takes the software company time to add the
interface for its new feature (even if it uses old technology) and so it
would for AT vendors. Time and money. And if software revamps its
interface it takes a LOT of time and money and testing to get it right.
Ditto for AT - but where does the time and money all come from.


3) software uses an API not supported by AT.
We discussed this one previously. AT vendors can barely keep up with
software as it is. Introducing a new API doesn't make AT appear. And if
there isn't any AT then there isn't any access (for what ever population
there isn't AT for).


The real danger is if we don't 'REQUIRE' a particular API - because we
'REQUIRE' AT vendors to support whatever API industry comes up with (by
saying it is sufficient to have an API).


Having said that - I REALLY like the idea of both sides building to an
API. But
1) it has to be a good and complete API
2) AT vendors will still need help keeping up
3) if there is not AT there is no access. API or not.

*** The API isn't there to substitute for access - but to facilitate it. And
make it less work for both sides. ***

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andi Snow-Weaver
> Sent: Wednesday, January 10, 2007 5:58 AM
> To: TEITAC Web/Software Subcommittee
> Cc: 'TEITAC General Interface Accessibility Subcommittee';
> 'TEITAC Subpart A Subcommittee'
> Subject: Re: [teitac-websoftware]
> [teitac-closed][teitac-general]"closed software"
>
> Gregg asked:
> is
> it?"
>
>
> To which Rex replied:
>
> > I didn't really ask this. I proposed that there were levels of
> accessibility, just like you proposed different speeds of
> "door openers."
> I
> there
> to do
> those
> disabilities.
>
> This is a very real situation and is exactly one of the
> general issues brought up in the Web and Software
> subcommittee which we will be discussing today. It happens
> all the time and not just for the newer APIs or those on
> non-Windows platforms. We have found that we can do all of
> the right things with the most well-supported API (MSAA) on
> the most well-supported platform
> (Windows) and prove that we have done so using inspection
> tools. Yet the screen readers sometimes won't work
> sufficiently with the software.
>
> Some would argue that the IT product in this case meets 508.
> Others would argue that it doesn't and point to the
> functional performance criteria. It depends on how you
> interpret support "for" assistive technology. Some lawyers
> would argue that, in the above case, support "for" assistive
> technology has been provided, it's just that the AT isn't
> using it properly.
>
> In our internal process in IBM, we call this being "enabled"
> for accessibility. It means the development team has done
> their part to make it possible for AT to work with it. But
> further customization of the AT may be required to make this
> actually work for someone. The question is, whose
> responsibility is it to ensure that the AT actually works?
>
> In other technology interoperability standards areas, it is
> quite normal to test "to the standard." So when customers
> need things to interoperate they look for things that claim
> conformance to the standard and there is a very high degree
> of probability that they will work.
>
> This is not the situation in 508 where, by some
> interpretations, conformance to the standard may depend on
> third party products which are not required by the regulation
> to conform to the standard. Am I the only one who finds this bizarre?
>
> I can see a lot of merit to Rex's argument for levels of
> accessibility.
>
> Andi
>
>

From: David Poehlman
Date: Sat, Jan 20 2007 4:35 AM
Subject: Re: "closed software"

what's a tier?

Why not just have the product be accessible regardless of whether it
works with AT?

On Jan 10, 2007, at 9:40 AM, = EMAIL ADDRESS REMOVED = wrote:

I agree implicitly. Often confusion lies between accessibility,
functionality and usability, some things having accessibility
features may
not actually be user friendly causing the need for scripts,
customization,
etc.
When we claim that something is accessible, should there not be some
conformance to ensure it is actually working and usable with AT? If the
standards are to make things easier for users and ensure these users
are
as productive as all, we need to ensure the tools, applications, etc can
actually be used with AT in a streamlined manner, not adding additional
work with extra key commands, sequences, additional peripherals, etc.
The guidelines need to be clear, concise while not limiting
creativity or
innovation, but ultimately we need to consider what it takes for one
to use
the tool no different than anyone not requiring any AT.

Let me be a little clearer. In the case of a PDA, I can purchase
software
to make it work for a visually impaired person, but now I need to
carry a
Maestro, additional software, peripherals, speakers, etc....I now need a
belt to carry everything so that I can use it with the AT. I also
need to
learn to operate the maestro in order to access the PDA and need to
ensure
it interfaces with everything else. What does that do to mobility,
costs,
portability, etc.
Having different tiers for accessibility may be one way to start
attacking
this and gaining some buy-in. We might want to consider further.



Pina D'Intino, PMP, ITIL Cert.
Systems Governance and Financial Services
Information Technology & Solutions
Sr. Manager, Service Management and Reporting
Office: (416) 866-6530
mobile: (416) 948-3348
Fax: (416) 866-4756
email: = EMAIL ADDRESS REMOVED =




Andi Snow-Weaver
< = EMAIL ADDRESS REMOVED = .

com> To
Sent by: TEITAC Web/Software Subcommittee
teitac-websoftwar <teitac-
= EMAIL ADDRESS REMOVED =
= EMAIL ADDRESS REMOVED = >

itac.org cc
'TEITAC General Interface
Accessibility Subcommittee'
01/10/2007 08:58 <teitac-
= EMAIL ADDRESS REMOVED = >,
AM 'TEITAC Subpart A Subcommittee'
<teitac-
= EMAIL ADDRESS REMOVED = >

Subject
Please respond to Re: [teitac-websoftware]
TEITAC [teitac-closed][teitac-
general]"clo
Web/Software sed software"
Subcommittee
<teitac-websoftwa
= EMAIL ADDRESS REMOVED =
g>






Gregg asked:
is
it?"


To which Rex replied:

> I didn't really ask this. I proposed that there were levels of
accessibility, just like you proposed different speeds of "door
openers."
I
there
to do
those
disabilities.

This is a very real situation and is exactly one of the general issues
brought up in the Web and Software subcommittee which we will be
discussing
today. It happens all the time and not just for the newer APIs or
those on
non-Windows platforms. We have found that we can do all of the right
things
with the most well-supported API (MSAA) on the most well-supported
platform
(Windows) and prove that we have done so using inspection tools. Yet the
screen readers sometimes won't work sufficiently with the software.

Some would argue that the IT product in this case meets 508. Others
would
argue that it doesn't and point to the functional performance
criteria. It
depends on how you interpret support "for" assistive technology. Some
lawyers would argue that, in the above case, support "for" assistive
technology has been provided, it's just that the AT isn't using it
properly.

In our internal process in IBM, we call this being "enabled" for
accessibility. It means the development team has done their part to
make it
possible for AT to work with it. But further customization of the AT
may be
required to make this actually work for someone. The question is, whose
responsibility is it to ensure that the AT actually works?

In other technology interoperability standards areas, it is quite
normal to
test "to the standard." So when customers need things to interoperate
they
look for things that claim conformance to the standard and there is a
very
high degree of probability that they will work.

This is not the situation in 508 where, by some interpretations,
conformance to the standard may depend on third party products which are
not required by the regulation to conform to the standard. Am I the only
one who finds this bizarre?

I can see a lot of merit to Rex's argument for levels of accessibility.

Andi

From: David Poehlman
Date: Sat, Jan 20 2007 4:40 AM
Subject: Re: "closed software"

almost is only good in horse shoes.

On Jan 10, 2007, at 8:58 AM, Andi Snow-Weaver wrote:

Gregg asked:
is
it?"


To which Rex replied:

> I didn't really ask this. I proposed that there were levels of
accessibility, just like you proposed different speeds of "door
openers."
I
there
to do
those
disabilities.

This is a very real situation and is exactly one of the general issues
brought up in the Web and Software subcommittee which we will be
discussing
today. It happens all the time and not just for the newer APIs or
those on
non-Windows platforms. We have found that we can do all of the right
things
with the most well-supported API (MSAA) on the most well-supported
platform
(Windows) and prove that we have done so using inspection tools. Yet the
screen readers sometimes won't work sufficiently with the software.

Some would argue that the IT product in this case meets 508. Others
would
argue that it doesn't and point to the functional performance
criteria. It
depends on how you interpret support "for" assistive technology. Some
lawyers would argue that, in the above case, support "for" assistive
technology has been provided, it's just that the AT isn't using it
properly.

In our internal process in IBM, we call this being "enabled" for
accessibility. It means the development team has done their part to
make it
possible for AT to work with it. But further customization of the AT
may be
required to make this actually work for someone. The question is, whose
responsibility is it to ensure that the AT actually works?

In other technology interoperability standards areas, it is quite
normal to
test "to the standard." So when customers need things to interoperate
they
look for things that claim conformance to the standard and there is a
very
high degree of probability that they will work.

This is not the situation in 508 where, by some interpretations,
conformance to the standard may depend on third party products which are
not required by the regulation to conform to the standard. Am I the only
one who finds this bizarre?

I can see a lot of merit to Rex's argument for levels of accessibility.

Andi