Thread Subject: Re: Startingdiscussionson theAccessibility APIproposal

Return to this mailing list's archives

From: Jim Tobias
Date: Thu, Jan 04 2007 10:10 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Your concerns are justified, but you have the concepts backwards. Thinking
in
terms of an accessibility value chain guarantees that we are thinking of all
the steps
required to give the end user access. Separating the regs by narrow
targets, one product
or industry at a time, ignores the need for both technical and informational
interoperation.

There is no getting around the problem of assigning responsibilities to the
"proper"
parties. Luckily 508 burdens the purchaser, who has the best view of the
entire chain, from
OEM-type product to developed product to installed product to user and
administrator. In
theory. The problem remains one of information flow rather than raw
technological power, as
your example indicates -- Gregorian did not work closely enough with the AT
community.

But that raises another troubling point: why is the Accessibility API not
sufficient? If
Gregorian builds its software correctly, why is additional action required
by AT vendors?
If Gregorian cannot sell to the feds until one or more AT vendors acts to
make the new
product accessible, isn't that an imbalance of market power? I thought the
whole idea of
the Accessibility API was to eliminate that problem.

Maybe I'm misunderstanding something....


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 1:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibility APIproposal
>
> Why value chain is good concept - but we need to be very
> careful about its use in regulatory standards.
>
> I really like the accessibility value chain concept as a way
> to understand this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to structure our
> standards. And I don't think we should structure our
> standards around it. If we did then we would only require
> that software companies "enable" there software to be
> accessible - but they would have no responsibility to
> actually make sure that there was AT that did work with their
> software and did make it
> accessible. The result is that in fact it would be "meet
> accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new media
> technology. It is new, different and extremely compelling
> web software for shopping and transactions using a simulated
> person and live environment over narrow
> bandwidth. They implement it with an accessibility API but
> no one uses the
> technology (of course) til its release in Sept 2007. At its
> announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get up to
> speed (sort of like when dos went to windows) but this
> technology spreads at Internet speed because it is free
> downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we write
> out guidelines such that the sites and the Gregorian software
> company can say their software meets access standards,
> without actually requiring them to be supported by real live
> AT that is out there - and available to users.
>
> In fact AT vendors will remember the days before we required
> software to
> actually work with real AT. Software would come out with
> an accessibility
> API but AT vendors were not able get access to it and had
> very poor support
> from software vendors even after release. Only when the
> software was
> required to actually work with real AT did the vendors invite
> and support and even court AT vendors in the same way they
> invited, supported and courted other software and hardware
> vendors (for compatibility) when they released something new.
>
> So I think the "accessibility value chain" is a very
> important concept. But I don't think we should base our
> standards on it.
>
> I think that something is accessible if it can be used by
> real people who have disabilities, not just that it
> theoretically could be if only those other people had done their job.
>
> Accessible - means that it can be used by people with disabilities.
> That means it is either directly accessible. Or that it is
> accessible using the AT that the person with a disability has
> or can reasonably get (or in the case of the government - for
> its employees - AT they are given). For public websites, it
> would be the AT that the public at large has, can reasonably
> get, or is given.
>
> Any other definition of accessibility defeats the purpose the
> legislators laid out in creating 508. that is that people
> with disabilities could actually use the E&IT in the
> government alongside everyone else - and when it was
> purchased (not sometime in the future - if someone else does
> their job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting discussions on
> > theAccessibility APIproposal
> >
> > Sean Hayes wrote:
> >
> > "Firstly I agree that there is a problem that needs
> adressing here,
> > which is the equitable division of reponsibility on accessibility
> > between each entity involved in delivering a software product.
> > However, as we are all aware, this is very difficult problem given
> > the manner in which modern software is produced, which in most
> > significant products involves cooperation across multiple
> > organisations, not only the software product developer, but OS
> > vendors, hardware vendors, AT vendors and middleware vendors among
> > others. In some cases standards or industry practice
> already exists
> > around these interfaces, and in some cases it doesn't."
> >
> > I would like to take this opportunity to develop a little
> further the
> > concept of an "accessibility value chain", which Sean refers to
> > indirectly. I believe that clarifying these responsibilities is at
> > the heart of "modern" accessibility, because, as Sean notes, modern
> > software requires cooperation across multiple
> organizations, many of
> > whom have only indirect relationships.
> >
> > I would like to posit that the nature of this technical cooperation
> > has three distinct elements or phases:
> > capability, implementation, and preservation.
> > By
> > "capability" I mean that the software component contains all the
> > features necessary for accessible use or development.
> > Examples are the ability to add a text description to an image in a
> > web development tool, and the ability to record and play
> back Baudot
> > files in a voice mail platform. By "implementation" I mean
> that the
> > capability has actually been used by the next link in the
> chain. That
> > is, the web developer has actually added a text description to an
> > image, and the telecom manager has actually set up a voice
> mailbox so
> > a Baudot TTY user can receive messages. By "preservation"
> > I mean that
> > the next link in the chain is required not to interfere with the
> > accessibility feature already in place further up the chain. For
> > example, a digital cable system must not strip the captioning
> > information from a captioned video program during transmission.
> >
> > Most of the relationships in the chain are
> capability-implementation
> > ones, especially for web and software. Thus the current
> 508 requires
> > software to inherit system display settings, use standard OS text
> > presentation techniques, etc.
> >
> > I think this formulation may clarify for us where we want
> to go. For
> > example, we have mentioned adding OS requirements.
> > That is, current 508 requires "downlink" software to honor OS
> > accessibility features, but it doesn't require OSs to have those
> > features. I think we may agree on adding such a requirement,
> > especially if we use today's common OSs as models rather
> than dreaming
> > up new features OSs don't have yet.
> >
> > Another point that may meet more resistance, but seems
> clear to me, is
> > the utter inseperability of content from software once we
> agree that
> > there is an interlocking set of relationships in the web/software
> > arena. In the examples of the web page and voice mail
> system I used
> > above, how can the tools be abstracted from the content?
> My thinking
> > here is not very well developed, so I look forward to a dialogue.
> >
> >

From: Jessica M. Brodey
Date: Thu, Jan 04 2007 2:25 PM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Jim:

Speaking as a policy wonk in lay terms, I think that the common
misunderstanding here is that use of an accessibility API equals
accessibility. Just because there is an accessibility API does not mean
that every piece of AT automatically works all of the time - it just
increases the odds of existing AT working with new products. But, sometimes
new technologies come with new features. If the AT did not take into
account those new features or capabilities, support for those features still
needs to be built in. An accessibility API makes it easier to build in
support for those features, and makes it less burdensome for the AT vendors
to do so (and means supporting those features should be more standardized),
but it is not always automatic. Also, as I understand it, just because a
company uses the accessibility API does not mean it implements the API in
exactly the same way as another company, thus, it is possible a piece of AT
may not work perfectly with one product that uses the accessibility API but
may work perfectly with another, and thus it may not be fully compatible
with every product. So, the verdict is that an accessibility API could be
useful, could improve things, but does not mean that compliance with the API
will equal access.

Another problem is that adopting an accessibility API that is the "gold
standard" today may quickly be old and out of date in 6 months or a year.
While we are in danger of this for many aspects of 508, it is particularly
worrisome for how AT interfaces with IT, because it could stifle the growth
and expansion of new AT, particularly if the accessibility API becomes the
excuse or justification . . . "well, we used the accessibility API, we don't
have to be compatible with ACTUAL AT." At some point not too far off,
because the API won't be able to grow and evolve once put into regulation,
what started off as a means to improve accessibility could actually become
the one bar to providing real access.

Jessica Brodey

-----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'
Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
APIproposal

Your concerns are justified, but you have the concepts backwards. Thinking
in
terms of an accessibility value chain guarantees that we are thinking of all
the steps
required to give the end user access. Separating the regs by narrow
targets, one product
or industry at a time, ignores the need for both technical and informational
interoperation.

There is no getting around the problem of assigning responsibilities to the
"proper"
parties. Luckily 508 burdens the purchaser, who has the best view of the
entire chain, from
OEM-type product to developed product to installed product to user and
administrator. In
theory. The problem remains one of information flow rather than raw
technological power, as
your example indicates -- Gregorian did not work closely enough with the AT
community.

But that raises another troubling point: why is the Accessibility API not
sufficient? If
Gregorian builds its software correctly, why is additional action required
by AT vendors?
If Gregorian cannot sell to the feds until one or more AT vendors acts to
make the new
product accessible, isn't that an imbalance of market power? I thought the
whole idea of
the Accessibility API was to eliminate that problem.

Maybe I'm misunderstanding something....


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 1:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibility APIproposal
>
> Why value chain is good concept - but we need to be very
> careful about its use in regulatory standards.
>
> I really like the accessibility value chain concept as a way
> to understand this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to structure our
> standards. And I don't think we should structure our
> standards around it. If we did then we would only require
> that software companies "enable" there software to be
> accessible - but they would have no responsibility to
> actually make sure that there was AT that did work with their
> software and did make it
> accessible. The result is that in fact it would be "meet
> accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new media
> technology. It is new, different and extremely compelling
> web software for shopping and transactions using a simulated
> person and live environment over narrow
> bandwidth. They implement it with an accessibility API but
> no one uses the
> technology (of course) til its release in Sept 2007. At its
> announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get up to
> speed (sort of like when dos went to windows) but this
> technology spreads at Internet speed because it is free
> downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we write
> out guidelines such that the sites and the Gregorian software
> company can say their software meets access standards,
> without actually requiring them to be supported by real live
> AT that is out there - and available to users.
>
> In fact AT vendors will remember the days before we required
> software to
> actually work with real AT. Software would come out with
> an accessibility
> API but AT vendors were not able get access to it and had
> very poor support
> from software vendors even after release. Only when the
> software was
> required to actually work with real AT did the vendors invite
> and support and even court AT vendors in the same way they
> invited, supported and courted other software and hardware
> vendors (for compatibility) when they released something new.
>
> So I think the "accessibility value chain" is a very
> important concept. But I don't think we should base our
> standards on it.
>
> I think that something is accessible if it can be used by
> real people who have disabilities, not just that it
> theoretically could be if only those other people had done their job.
>
> Accessible - means that it can be used by people with disabilities.
> That means it is either directly accessible. Or that it is
> accessible using the AT that the person with a disability has
> or can reasonably get (or in the case of the government - for
> its employees - AT they are given). For public websites, it
> would be the AT that the public at large has, can reasonably
> get, or is given.
>
> Any other definition of accessibility defeats the purpose the
> legislators laid out in creating 508. that is that people
> with disabilities could actually use the E&IT in the
> government alongside everyone else - and when it was
> purchased (not sometime in the future - if someone else does
> their job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting discussions on
> > theAccessibility APIproposal
> >
> > Sean Hayes wrote:
> >
> > "Firstly I agree that there is a problem that needs
> adressing here,
> > which is the equitable division of reponsibility on accessibility
> > between each entity involved in delivering a software product.
> > However, as we are all aware, this is very difficult problem given
> > the manner in which modern software is produced, which in most
> > significant products involves cooperation across multiple
> > organisations, not only the software product developer, but OS
> > vendors, hardware vendors, AT vendors and middleware vendors among
> > others. In some cases standards or industry practice
> already exists
> > around these interfaces, and in some cases it doesn't."
> >
> > I would like to take this opportunity to develop a little
> further the
> > concept of an "accessibility value chain", which Sean refers to
> > indirectly. I believe that clarifying these responsibilities is at
> > the heart of "modern" accessibility, because, as Sean notes, modern
> > software requires cooperation across multiple
> organizations, many of
> > whom have only indirect relationships.
> >
> > I would like to posit that the nature of this technical cooperation
> > has three distinct elements or phases:
> > capability, implementation, and preservation.
> > By
> > "capability" I mean that the software component contains all the
> > features necessary for accessible use or development.
> > Examples are the ability to add a text description to an image in a
> > web development tool, and the ability to record and play
> back Baudot
> > files in a voice mail platform. By "implementation" I mean
> that the
> > capability has actually been used by the next link in the
> chain. That
> > is, the web developer has actually added a text description to an
> > image, and the telecom manager has actually set up a voice
> mailbox so
> > a Baudot TTY user can receive messages. By "preservation"
> > I mean that
> > the next link in the chain is required not to interfere with the
> > accessibility feature already in place further up the chain. For
> > example, a digital cable system must not strip the captioning
> > information from a captioned video program during transmission.
> >
> > Most of the relationships in the chain are
> capability-implementation
> > ones, especially for web and software. Thus the current
> 508 requires
> > software to inherit system display settings, use standard OS text
> > presentation techniques, etc.
> >
> > I think this formulation may clarify for us where we want
> to go. For
> > example, we have mentioned adding OS requirements.
> > That is, current 508 requires "downlink" software to honor OS
> > accessibility features, but it doesn't require OSs to have those
> > features. I think we may agree on adding such a requirement,
> > especially if we use today's common OSs as models rather
> than dreaming
> > up new features OSs don't have yet.
> >
> > Another point that may meet more resistance, but seems
> clear to me, is
> > the utter inseperability of content from software once we
> agree that
> > there is an interlocking set of relationships in the web/software
> > arena. In the examples of the web page and voice mail
> system I used
> > above, how can the tools be abstracted from the content?
> My thinking
> > here is not very well developed, so I look forward to a dialogue.
> >
> >

From: Eric Damery
Date: Thu, Jan 04 2007 3:00 PM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Jessica,

Very well said.

Just to follow up on this line of thought, another concern when making
the API the "gold standard" should be what the incentive will be for AT
to do anything beyond the API, if it becomes the measurement for
procurement. As I understand it, a limited API could make it easier to
swallow for I T but at the same time, stifle smaller AT companies from
being able to help achieve access for users if it requires anything
beyond it. I suspect the same will be true for AT designed in at the
system level.

Regards,
Eric Damery

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Thursday, January 04, 2007 4:21 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Jim:

Speaking as a policy wonk in lay terms, I think that the common
misunderstanding here is that use of an accessibility API equals
accessibility. Just because there is an accessibility API does not mean
that every piece of AT automatically works all of the time - it just
increases the odds of existing AT working with new products. But,
sometimes new technologies come with new features. If the AT did not
take into account those new features or capabilities, support for those
features still needs to be built in. An accessibility API makes it
easier to build in support for those features, and makes it less
burdensome for the AT vendors to do so (and means supporting those
features should be more standardized), but it is not always automatic.
Also, as I understand it, just because a company uses the accessibility
API does not mean it implements the API in exactly the same way as
another company, thus, it is possible a piece of AT may not work
perfectly with one product that uses the accessibility API but may work
perfectly with another, and thus it may not be fully compatible with
every product. So, the verdict is that an accessibility API could be
useful, could improve things, but does not mean that compliance with the
API will equal access.

Another problem is that adopting an accessibility API that is the "gold
standard" today may quickly be old and out of date in 6 months or a
year.
While we are in danger of this for many aspects of 508, it is
particularly worrisome for how AT interfaces with IT, because it could
stifle the growth and expansion of new AT, particularly if the
accessibility API becomes the excuse or justification . . . "well, we
used the accessibility API, we don't have to be compatible with ACTUAL
AT." At some point not too far off, because the API won't be able to
grow and evolve once put into regulation, what started off as a means to
improve accessibility could actually become the one bar to providing
real access.

Jessica Brodey

-----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'
Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
APIproposal

Your concerns are justified, but you have the concepts backwards.
Thinking in terms of an accessibility value chain guarantees that we are
thinking of all the steps required to give the end user access.
Separating the regs by narrow targets, one product or industry at a
time, ignores the need for both technical and informational
interoperation.

There is no getting around the problem of assigning responsibilities to
the "proper"
parties. Luckily 508 burdens the purchaser, who has the best view of
the entire chain, from OEM-type product to developed product to
installed product to user and administrator. In theory. The problem
remains one of information flow rather than raw technological power, as
your example indicates -- Gregorian did not work closely enough with the
AT community.

But that raises another troubling point: why is the Accessibility API
not sufficient? If Gregorian builds its software correctly, why is
additional action required by AT vendors?
If Gregorian cannot sell to the feds until one or more AT vendors acts
to make the new product accessible, isn't that an imbalance of market
power? I thought the whole idea of the Accessibility API was to
eliminate that problem.

Maybe I'm misunderstanding something....


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 1:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibility APIproposal
>
> Why value chain is good concept - but we need to be very careful about

> its use in regulatory standards.
>
> I really like the accessibility value chain concept as a way to
> understand this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to structure our
> standards. And I don't think we should structure our standards around

> it. If we did then we would only require that software companies
> "enable" there software to be accessible - but they would have no
> responsibility to actually make sure that there was AT that did work
> with their software and did make it
> accessible. The result is that in fact it would be "meet
> accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new media
> technology. It is new, different and extremely compelling web
> software for shopping and transactions using a simulated person and
> live environment over narrow
> bandwidth. They implement it with an accessibility API but
> no one uses the
> technology (of course) til its release in Sept 2007. At its
> announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get up to speed (sort

> of like when dos went to windows) but this technology spreads at
> Internet speed because it is free downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we write out
> guidelines such that the sites and the Gregorian software company can
> say their software meets access standards, without actually requiring
> them to be supported by real live AT that is out there - and available

> to users.
>
> In fact AT vendors will remember the days before we required software
> to
> actually work with real AT. Software would come out with
> an accessibility
> API but AT vendors were not able get access to it and had very poor
> support
> from software vendors even after release. Only when the
> software was
> required to actually work with real AT did the vendors invite and
> support and even court AT vendors in the same way they invited,
> supported and courted other software and hardware vendors (for
> compatibility) when they released something new.
>
> So I think the "accessibility value chain" is a very important
> concept. But I don't think we should base our standards on it.
>
> I think that something is accessible if it can be used by real people
> who have disabilities, not just that it theoretically could be if only

> those other people had done their job.
>
> Accessible - means that it can be used by people with disabilities.
> That means it is either directly accessible. Or that it is accessible

> using the AT that the person with a disability has or can reasonably
> get (or in the case of the government - for its employees - AT they
> are given). For public websites, it would be the AT that the public
> at large has, can reasonably get, or is given.
>
> Any other definition of accessibility defeats the purpose the
> legislators laid out in creating 508. that is that people with
> disabilities could actually use the E&IT in the government alongside
> everyone else - and when it was purchased (not sometime in the future
> - if someone else does their job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting discussions on
> > theAccessibility APIproposal
> >
> > Sean Hayes wrote:
> >
> > "Firstly I agree that there is a problem that needs
> adressing here,
> > which is the equitable division of reponsibility on accessibility
> > between each entity involved in delivering a software product.
> > However, as we are all aware, this is very difficult problem given
> > the manner in which modern software is produced, which in most
> > significant products involves cooperation across multiple
> > organisations, not only the software product developer, but OS
> > vendors, hardware vendors, AT vendors and middleware vendors among
> > others. In some cases standards or industry practice
> already exists
> > around these interfaces, and in some cases it doesn't."
> >
> > I would like to take this opportunity to develop a little
> further the
> > concept of an "accessibility value chain", which Sean refers to
> > indirectly. I believe that clarifying these responsibilities is at
> > the heart of "modern" accessibility, because, as Sean notes, modern
> > software requires cooperation across multiple
> organizations, many of
> > whom have only indirect relationships.
> >
> > I would like to posit that the nature of this technical cooperation
> > has three distinct elements or phases:
> > capability, implementation, and preservation.
> > By
> > "capability" I mean that the software component contains all the
> > features necessary for accessible use or development.
> > Examples are the ability to add a text description to an image in a
> > web development tool, and the ability to record and play
> back Baudot
> > files in a voice mail platform. By "implementation" I mean
> that the
> > capability has actually been used by the next link in the
> chain. That
> > is, the web developer has actually added a text description to an
> > image, and the telecom manager has actually set up a voice
> mailbox so
> > a Baudot TTY user can receive messages. By "preservation"
> > I mean that
> > the next link in the chain is required not to interfere with the
> > accessibility feature already in place further up the chain. For
> > example, a digital cable system must not strip the captioning
> > information from a captioned video program during transmission.
> >
> > Most of the relationships in the chain are
> capability-implementation
> > ones, especially for web and software. Thus the current
> 508 requires
> > software to inherit system display settings, use standard OS text
> > presentation techniques, etc.
> >
> > I think this formulation may clarify for us where we want
> to go. For
> > example, we have mentioned adding OS requirements.
> > That is, current 508 requires "downlink" software to honor OS
> > accessibility features, but it doesn't require OSs to have those
> > features. I think we may agree on adding such a requirement,
> > especially if we use today's common OSs as models rather
> than dreaming
> > up new features OSs don't have yet.
> >
> > Another point that may meet more resistance, but seems
> clear to me, is
> > the utter inseperability of content from software once we
> agree that
> > there is an interlocking set of relationships in the web/software
> > arena. In the examples of the web page and voice mail
> system I used
> > above, how can the tools be abstracted from the content?
> My thinking
> > here is not very well developed, so I look forward to a dialogue.
> >
> >

From: Lybarger, Barbara (MOD)
Date: Thu, Jan 04 2007 4:15 PM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

On this topic, I'm not nearly well enough informed on the content.
However, I question Jessica's reasoning, in that no set of standards
will help if they aren't followed by all the parties, here IT, AT and
all the players in between, and violators aren't chastised in some way
fair and reasonable way.

At it's core, the API proposal is like the standards for our electrical
power grids. The government regulates how the power source comes out,
and all the other parties set up their stuff so all the customers can
get at the power to run their lights. Most of the parties conform
because the alternative is that people can't safely and cost effectively
share the power. If anyone in the chain doesn't conform with the
standard, end users either have dark houses because the light bulbs
can't get the power, or they have a very bright house while it burns
down. Either way the government is looking to punish the one who caused
the problem.

People argued about innovation and standardization when the first power
grids were set up. Costs, safety and reliability won out over
unfettered innovation, but it didn't stifle innovation. Folks are still
inventing better, safer, cheaper ways of delivering power, and they are
being used to upgrade the power grid. The bottom line then and now is
that in a society we have to give up a little freedom to make sure we
all can get at shared resource cheaply, safely and reliable. The
technology equivalent may be this API or something like it. It is
needed so all of us can share, and conformance by all is essential for
it to work.

If this API proposal isn't perfect in some ways, what would make it
better so everyone would want to follow it? And then, what type of
enforcement system is needed so the non-likeminded in society get
brought into line?

Barbara Lybarger

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Thursday, January 04, 2007 4:21 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Jim:

Speaking as a policy wonk in lay terms, I think that the common
misunderstanding here is that use of an accessibility API equals
accessibility. Just because there is an accessibility API does not mean
that every piece of AT automatically works all of the time - it just
increases the odds of existing AT working with new products. But,
sometimes new technologies come with new features. If the AT did not
take into account those new features or capabilities, support for those
features still needs to be built in. An accessibility API makes it
easier to build in support for those features, and makes it less
burdensome for the AT vendors to do so (and means supporting those
features should be more standardized), but it is not always automatic.
Also, as I understand it, just because a company uses the accessibility
API does not mean it implements the API in exactly the same way as
another company, thus, it is possible a piece of AT may not work
perfectly with one product that uses the accessibility API but may work
perfectly with another, and thus it may not be fully compatible with
every product. So, the verdict is that an accessibility API could be
useful, could improve things, but does not mean that compliance with the
API will equal access.

Another problem is that adopting an accessibility API that is the "gold
standard" today may quickly be old and out of date in 6 months or a
year.
While we are in danger of this for many aspects of 508, it is
particularly worrisome for how AT interfaces with IT, because it could
stifle the growth and expansion of new AT, particularly if the
accessibility API becomes the excuse or justification . . . "well, we
used the accessibility API, we don't have to be compatible with ACTUAL
AT." At some point not too far off, because the API won't be able to
grow and evolve once put into regulation, what started off as a means to
improve accessibility could actually become the one bar to providing
real access.

Jessica Brodey

-----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'
Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
APIproposal

Your concerns are justified, but you have the concepts backwards.
Thinking in terms of an accessibility value chain guarantees that we are
thinking of all the steps required to give the end user access.
Separating the regs by narrow targets, one product or industry at a
time, ignores the need for both technical and informational
interoperation.

There is no getting around the problem of assigning responsibilities to
the "proper"
parties. Luckily 508 burdens the purchaser, who has the best view of
the entire chain, from OEM-type product to developed product to
installed product to user and administrator. In theory. The problem
remains one of information flow rather than raw technological power, as
your example indicates -- Gregorian did not work closely enough with the
AT community.

But that raises another troubling point: why is the Accessibility API
not sufficient? If Gregorian builds its software correctly, why is
additional action required by AT vendors?
If Gregorian cannot sell to the feds until one or more AT vendors acts
to make the new product accessible, isn't that an imbalance of market
power? I thought the whole idea of the Accessibility API was to
eliminate that problem.

Maybe I'm misunderstanding something....


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 1:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibility APIproposal
>
> Why value chain is good concept - but we need to be very careful about

> its use in regulatory standards.
>
> I really like the accessibility value chain concept as a way to
> understand this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to structure our
> standards. And I don't think we should structure our standards around

> it. If we did then we would only require that software companies
> "enable" there software to be accessible - but they would have no
> responsibility to actually make sure that there was AT that did work
> with their software and did make it
> accessible. The result is that in fact it would be "meet
> accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new media
> technology. It is new, different and extremely compelling web
> software for shopping and transactions using a simulated person and
> live environment over narrow
> bandwidth. They implement it with an accessibility API but
> no one uses the
> technology (of course) til its release in Sept 2007. At its
> announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get up to speed (sort

> of like when dos went to windows) but this technology spreads at
> Internet speed because it is free downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we write out
> guidelines such that the sites and the Gregorian software company can
> say their software meets access standards, without actually requiring
> them to be supported by real live AT that is out there - and available

> to users.
>
> In fact AT vendors will remember the days before we required software
> to
> actually work with real AT. Software would come out with
> an accessibility
> API but AT vendors were not able get access to it and had very poor
> support
> from software vendors even after release. Only when the
> software was
> required to actually work with real AT did the vendors invite and
> support and even court AT vendors in the same way they invited,
> supported and courted other software and hardware vendors (for
> compatibility) when they released something new.
>
> So I think the "accessibility value chain" is a very important
> concept. But I don't think we should base our standards on it.
>
> I think that something is accessible if it can be used by real people
> who have disabilities, not just that it theoretically could be if only

> those other people had done their job.
>
> Accessible - means that it can be used by people with disabilities.
> That means it is either directly accessible. Or that it is accessible

> using the AT that the person with a disability has or can reasonably
> get (or in the case of the government - for its employees - AT they
> are given). For public websites, it would be the AT that the public
> at large has, can reasonably get, or is given.
>
> Any other definition of accessibility defeats the purpose the
> legislators laid out in creating 508. that is that people with
> disabilities could actually use the E&IT in the government alongside
> everyone else - and when it was purchased (not sometime in the future
> - if someone else does their job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting discussions on
> > theAccessibility APIproposal
> >
> > Sean Hayes wrote:
> >
> > "Firstly I agree that there is a problem that needs
> adressing here,
> > which is the equitable division of reponsibility on accessibility
> > between each entity involved in delivering a software product.
> > However, as we are all aware, this is very difficult problem given
> > the manner in which modern software is produced, which in most
> > significant products involves cooperation across multiple
> > organisations, not only the software product developer, but OS
> > vendors, hardware vendors, AT vendors and middleware vendors among
> > others. In some cases standards or industry practice
> already exists
> > around these interfaces, and in some cases it doesn't."
> >
> > I would like to take this opportunity to develop a little
> further the
> > concept of an "accessibility value chain", which Sean refers to
> > indirectly. I believe that clarifying these responsibilities is at
> > the heart of "modern" accessibility, because, as Sean notes, modern
> > software requires cooperation across multiple
> organizations, many of
> > whom have only indirect relationships.
> >
> > I would like to posit that the nature of this technical cooperation
> > has three distinct elements or phases:
> > capability, implementation, and preservation.
> > By
> > "capability" I mean that the software component contains all the
> > features necessary for accessible use or development.
> > Examples are the ability to add a text description to an image in a
> > web development tool, and the ability to record and play
> back Baudot
> > files in a voice mail platform. By "implementation" I mean
> that the
> > capability has actually been used by the next link in the
> chain. That
> > is, the web developer has actually added a text description to an
> > image, and the telecom manager has actually set up a voice
> mailbox so
> > a Baudot TTY user can receive messages. By "preservation"
> > I mean that
> > the next link in the chain is required not to interfere with the
> > accessibility feature already in place further up the chain. For
> > example, a digital cable system must not strip the captioning
> > information from a captioned video program during transmission.
> >
> > Most of the relationships in the chain are
> capability-implementation
> > ones, especially for web and software. Thus the current
> 508 requires
> > software to inherit system display settings, use standard OS text
> > presentation techniques, etc.
> >
> > I think this formulation may clarify for us where we want
> to go. For
> > example, we have mentioned adding OS requirements.
> > That is, current 508 requires "downlink" software to honor OS
> > accessibility features, but it doesn't require OSs to have those
> > features. I think we may agree on adding such a requirement,
> > especially if we use today's common OSs as models rather
> than dreaming
> > up new features OSs don't have yet.
> >
> > Another point that may meet more resistance, but seems
> clear to me, is
> > the utter inseperability of content from software once we
> agree that
> > there is an interlocking set of relationships in the web/software
> > arena. In the examples of the web page and voice mail
> system I used
> > above, how can the tools be abstracted from the content?
> My thinking
> > here is not very well developed, so I look forward to a dialogue.
> >
> >

From: Jessica M. Brodey
Date: Thu, Jan 04 2007 4:40 PM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Barbara:

Unfortunately, unlike the power grid, AT isn't delivered through a single
delivery system, or attached in a universal manner. I am not arguing that
the Accessibility API has no merits. In fact, it does. However,
incorporating it into 508 in a manner such that it can be used to argue that
utilizing the accessibility API in and of itself is tantamount to providing
access is like arguing that having a power plant is good enough even if the
power company fails to connect the power lines to your housing complex, or
if the power company suddenly decides to switch to 250 volts when the rest
of the system is on 120. In this case, it isn't just an issue of
enforcement. And we do not want to make the argument that the power company
should be prohibited from switching to 250 volts, so to speak, if that is in
the best interests of technology development, just because the accessibility
API prohibits it. It may mean that when the switch happens, a new
accessibility API should emerge, but if we lock into a specific API in 508,
we could prevent the switch from occurring altogether.

ATIA's position is that an accessibility API has a role, but it is in the
business venue, or in the standards venue, not the regulatory venue. If we
want to include aspects of the accessibility API into 508, it should be as
Sean Hayes from Microsoft has advocated. We are concerned about an exact
and precise list that is finite and unable to evolve without reconvening a
new panel and a new refresh. We see an accessibility API as more of a good
business practice that is the best way to meet some of the specifications of
508, but which accessibility API may change and evolve over time.

Jessica

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lybarger,
Barbara (MOD)
Sent: Thursday, January 04, 2007 6:14 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

On this topic, I'm not nearly well enough informed on the content.
However, I question Jessica's reasoning, in that no set of standards
will help if they aren't followed by all the parties, here IT, AT and
all the players in between, and violators aren't chastised in some way
fair and reasonable way.

At it's core, the API proposal is like the standards for our electrical
power grids. The government regulates how the power source comes out,
and all the other parties set up their stuff so all the customers can
get at the power to run their lights. Most of the parties conform
because the alternative is that people can't safely and cost effectively
share the power. If anyone in the chain doesn't conform with the
standard, end users either have dark houses because the light bulbs
can't get the power, or they have a very bright house while it burns
down. Either way the government is looking to punish the one who caused
the problem.

People argued about innovation and standardization when the first power
grids were set up. Costs, safety and reliability won out over
unfettered innovation, but it didn't stifle innovation. Folks are still
inventing better, safer, cheaper ways of delivering power, and they are
being used to upgrade the power grid. The bottom line then and now is
that in a society we have to give up a little freedom to make sure we
all can get at shared resource cheaply, safely and reliable. The
technology equivalent may be this API or something like it. It is
needed so all of us can share, and conformance by all is essential for
it to work.

If this API proposal isn't perfect in some ways, what would make it
better so everyone would want to follow it? And then, what type of
enforcement system is needed so the non-likeminded in society get
brought into line?

Barbara Lybarger

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Thursday, January 04, 2007 4:21 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Jim:

Speaking as a policy wonk in lay terms, I think that the common
misunderstanding here is that use of an accessibility API equals
accessibility. Just because there is an accessibility API does not mean
that every piece of AT automatically works all of the time - it just
increases the odds of existing AT working with new products. But,
sometimes new technologies come with new features. If the AT did not
take into account those new features or capabilities, support for those
features still needs to be built in. An accessibility API makes it
easier to build in support for those features, and makes it less
burdensome for the AT vendors to do so (and means supporting those
features should be more standardized), but it is not always automatic.
Also, as I understand it, just because a company uses the accessibility
API does not mean it implements the API in exactly the same way as
another company, thus, it is possible a piece of AT may not work
perfectly with one product that uses the accessibility API but may work
perfectly with another, and thus it may not be fully compatible with
every product. So, the verdict is that an accessibility API could be
useful, could improve things, but does not mean that compliance with the
API will equal access.

Another problem is that adopting an accessibility API that is the "gold
standard" today may quickly be old and out of date in 6 months or a
year.
While we are in danger of this for many aspects of 508, it is
particularly worrisome for how AT interfaces with IT, because it could
stifle the growth and expansion of new AT, particularly if the
accessibility API becomes the excuse or justification . . . "well, we
used the accessibility API, we don't have to be compatible with ACTUAL
AT." At some point not too far off, because the API won't be able to
grow and evolve once put into regulation, what started off as a means to
improve accessibility could actually become the one bar to providing
real access.

Jessica Brodey

-----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'
Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
APIproposal

Your concerns are justified, but you have the concepts backwards.
Thinking in terms of an accessibility value chain guarantees that we are
thinking of all the steps required to give the end user access.
Separating the regs by narrow targets, one product or industry at a
time, ignores the need for both technical and informational
interoperation.

There is no getting around the problem of assigning responsibilities to
the "proper"
parties. Luckily 508 burdens the purchaser, who has the best view of
the entire chain, from OEM-type product to developed product to
installed product to user and administrator. In theory. The problem
remains one of information flow rather than raw technological power, as
your example indicates -- Gregorian did not work closely enough with the
AT community.

But that raises another troubling point: why is the Accessibility API
not sufficient? If Gregorian builds its software correctly, why is
additional action required by AT vendors?
If Gregorian cannot sell to the feds until one or more AT vendors acts
to make the new product accessible, isn't that an imbalance of market
power? I thought the whole idea of the Accessibility API was to
eliminate that problem.

Maybe I'm misunderstanding something....


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 1:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibility APIproposal
>
> Why value chain is good concept - but we need to be very careful about

> its use in regulatory standards.
>
> I really like the accessibility value chain concept as a way to
> understand this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to structure our
> standards. And I don't think we should structure our standards around

> it. If we did then we would only require that software companies
> "enable" there software to be accessible - but they would have no
> responsibility to actually make sure that there was AT that did work
> with their software and did make it
> accessible. The result is that in fact it would be "meet
> accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new media
> technology. It is new, different and extremely compelling web
> software for shopping and transactions using a simulated person and
> live environment over narrow
> bandwidth. They implement it with an accessibility API but
> no one uses the
> technology (of course) til its release in Sept 2007. At its
> announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get up to speed (sort

> of like when dos went to windows) but this technology spreads at
> Internet speed because it is free downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we write out
> guidelines such that the sites and the Gregorian software company can
> say their software meets access standards, without actually requiring
> them to be supported by real live AT that is out there - and available

> to users.
>
> In fact AT vendors will remember the days before we required software
> to
> actually work with real AT. Software would come out with
> an accessibility
> API but AT vendors were not able get access to it and had very poor
> support
> from software vendors even after release. Only when the
> software was
> required to actually work with real AT did the vendors invite and
> support and even court AT vendors in the same way they invited,
> supported and courted other software and hardware vendors (for
> compatibility) when they released something new.
>
> So I think the "accessibility value chain" is a very important
> concept. But I don't think we should base our standards on it.
>
> I think that something is accessible if it can be used by real people
> who have disabilities, not just that it theoretically could be if only

> those other people had done their job.
>
> Accessible - means that it can be used by people with disabilities.
> That means it is either directly accessible. Or that it is accessible

> using the AT that the person with a disability has or can reasonably
> get (or in the case of the government - for its employees - AT they
> are given). For public websites, it would be the AT that the public
> at large has, can reasonably get, or is given.
>
> Any other definition of accessibility defeats the purpose the
> legislators laid out in creating 508. that is that people with
> disabilities could actually use the E&IT in the government alongside
> everyone else - and when it was purchased (not sometime in the future
> - if someone else does their job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting discussions on
> > theAccessibility APIproposal
> >
> > Sean Hayes wrote:
> >
> > "Firstly I agree that there is a problem that needs
> adressing here,
> > which is the equitable division of reponsibility on accessibility
> > between each entity involved in delivering a software product.
> > However, as we are all aware, this is very difficult problem given
> > the manner in which modern software is produced, which in most
> > significant products involves cooperation across multiple
> > organisations, not only the software product developer, but OS
> > vendors, hardware vendors, AT vendors and middleware vendors among
> > others. In some cases standards or industry practice
> already exists
> > around these interfaces, and in some cases it doesn't."
> >
> > I would like to take this opportunity to develop a little
> further the
> > concept of an "accessibility value chain", which Sean refers to
> > indirectly. I believe that clarifying these responsibilities is at
> > the heart of "modern" accessibility, because, as Sean notes, modern
> > software requires cooperation across multiple
> organizations, many of
> > whom have only indirect relationships.
> >
> > I would like to posit that the nature of this technical cooperation
> > has three distinct elements or phases:
> > capability, implementation, and preservation.
> > By
> > "capability" I mean that the software component contains all the
> > features necessary for accessible use or development.
> > Examples are the ability to add a text description to an image in a
> > web development tool, and the ability to record and play
> back Baudot
> > files in a voice mail platform. By "implementation" I mean
> that the
> > capability has actually been used by the next link in the
> chain. That
> > is, the web developer has actually added a text description to an
> > image, and the telecom manager has actually set up a voice
> mailbox so
> > a Baudot TTY user can receive messages. By "preservation"
> > I mean that
> > the next link in the chain is required not to interfere with the
> > accessibility feature already in place further up the chain. For
> > example, a digital cable system must not strip the captioning
> > information from a captioned video program during transmission.
> >
> > Most of the relationships in the chain are
> capability-implementation
> > ones, especially for web and software. Thus the current
> 508 requires
> > software to inherit system display settings, use standard OS text
> > presentation techniques, etc.
> >
> > I think this formulation may clarify for us where we want
> to go. For
> > example, we have mentioned adding OS requirements.
> > That is, current 508 requires "downlink" software to honor OS
> > accessibility features, but it doesn't require OSs to have those
> > features. I think we may agree on adding such a requirement,
> > especially if we use today's common OSs as models rather
> than dreaming
> > up new features OSs don't have yet.
> >
> > Another point that may meet more resistance, but seems
> clear to me, is
> > the utter inseperability of content from software once we
> agree that
> > there is an interlocking set of relationships in the web/software
> > arena. In the examples of the web page and voice mail
> system I used
> > above, how can the tools be abstracted from the content?
> My thinking
> > here is not very well developed, so I look forward to a dialogue.
> >
> >

From: Peter Korn
Date: Thu, Jan 04 2007 9:40 PM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Hi Jessica,

> ATIA's position is that an accessibility API has a role, but it is in the
> business venue, or in the standards venue, not the regulatory venue. If we
> want to include aspects of the accessibility API into 508, it should be as
> Sean Hayes from Microsoft has advocated. We are concerned about an exact
> and precise list that is finite and unable to evolve without reconvening a
> new panel and a new refresh. We see an accessibility API as more of a good
> business practice that is the best way to meet some of the specifications of 508, but which accessibility API may change and evolve over time.
>

508 already includes aspects of an accessibility API. The seven
provisions enumerated in
http://teitac.org/wiki/Web_and_Software:_Programmatic_exposure_of_information
are existing places where 508 describes the programmatic information
that IT shall provide to AT. The current language doesn't call this
portions of an "accessibility API", but language like "focus shall be
programmatically exposed so that assistive technology can track focus
and focus changes" in 1194.21(c) aren't too far away from that.

And I think ATIA would agree with me that the seven provisions in
question constitute an insufficient set of information from which AT can
accomplish their task. Yet these seven represent "a list that is finite
and unable to evolve without reconvening a new panel and a new
refresh." In fact, it is the very process of refreshing these seven
provisions that gave rise to the accessibility API proposal - a much
richer enumeration of things we know are needed, and in support of which
the evolving, platform-specific accessibility APIs like UI Automation
can be used by IT vendors to interopreate with AT.

If ATIA is opposed to a finite list, then what does ATIA propose we do
with finite list we currently have - the seven provisions enumerated
above?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Jessica
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lybarger,
> Barbara (MOD)
> Sent: Thursday, January 04, 2007 6:14 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
> APIproposal
>
> On this topic, I'm not nearly well enough informed on the content.
> However, I question Jessica's reasoning, in that no set of standards
> will help if they aren't followed by all the parties, here IT, AT and
> all the players in between, and violators aren't chastised in some way
> fair and reasonable way.
>
> At it's core, the API proposal is like the standards for our electrical
> power grids. The government regulates how the power source comes out,
> and all the other parties set up their stuff so all the customers can
> get at the power to run their lights. Most of the parties conform
> because the alternative is that people can't safely and cost effectively
> share the power. If anyone in the chain doesn't conform with the
> standard, end users either have dark houses because the light bulbs
> can't get the power, or they have a very bright house while it burns
> down. Either way the government is looking to punish the one who caused
> the problem.
>
> People argued about innovation and standardization when the first power
> grids were set up. Costs, safety and reliability won out over
> unfettered innovation, but it didn't stifle innovation. Folks are still
> inventing better, safer, cheaper ways of delivering power, and they are
> being used to upgrade the power grid. The bottom line then and now is
> that in a society we have to give up a little freedom to make sure we
> all can get at shared resource cheaply, safely and reliable. The
> technology equivalent may be this API or something like it. It is
> needed so all of us can share, and conformance by all is essential for
> it to work.
>
> If this API proposal isn't perfect in some ways, what would make it
> better so everyone would want to follow it? And then, what type of
> enforcement system is needed so the non-likeminded in society get
> brought into line?
>
> Barbara Lybarger
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
> M. Brodey
> Sent: Thursday, January 04, 2007 4:21 PM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
> APIproposal
>
> Jim:
>
> Speaking as a policy wonk in lay terms, I think that the common
> misunderstanding here is that use of an accessibility API equals
> accessibility. Just because there is an accessibility API does not mean
> that every piece of AT automatically works all of the time - it just
> increases the odds of existing AT working with new products. But,
> sometimes new technologies come with new features. If the AT did not
> take into account those new features or capabilities, support for those
> features still needs to be built in. An accessibility API makes it
> easier to build in support for those features, and makes it less
> burdensome for the AT vendors to do so (and means supporting those
> features should be more standardized), but it is not always automatic.
> Also, as I understand it, just because a company uses the accessibility
> API does not mean it implements the API in exactly the same way as
> another company, thus, it is possible a piece of AT may not work
> perfectly with one product that uses the accessibility API but may work
> perfectly with another, and thus it may not be fully compatible with
> every product. So, the verdict is that an accessibility API could be
> useful, could improve things, but does not mean that compliance with the
> API will equal access.
>
> Another problem is that adopting an accessibility API that is the "gold
> standard" today may quickly be old and out of date in 6 months or a
> year.
> While we are in danger of this for many aspects of 508, it is
> particularly worrisome for how AT interfaces with IT, because it could
> stifle the growth and expansion of new AT, particularly if the
> accessibility API becomes the excuse or justification . . . "well, we
> used the accessibility API, we don't have to be compatible with ACTUAL
> AT." At some point not too far off, because the API won't be able to
> grow and evolve once put into regulation, what started off as a means to
> improve accessibility could actually become the one bar to providing
> real access.
>
> Jessica Brodey
>
> -----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'
> Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
> APIproposal
>
> Your concerns are justified, but you have the concepts backwards.
> Thinking in terms of an accessibility value chain guarantees that we are
> thinking of all the steps required to give the end user access.
> Separating the regs by narrow targets, one product or industry at a
> time, ignores the need for both technical and informational
> interoperation.
>
> There is no getting around the problem of assigning responsibilities to
> the "proper"
> parties. Luckily 508 burdens the purchaser, who has the best view of
> the entire chain, from OEM-type product to developed product to
> installed product to user and administrator. In theory. The problem
> remains one of information flow rather than raw technological power, as
> your example indicates -- Gregorian did not work closely enough with the
> AT community.
>
> But that raises another troubling point: why is the Accessibility API
> not sufficient? If Gregorian builds its software correctly, why is
> additional action required by AT vendors?
> If Gregorian cannot sell to the feds until one or more AT vendors acts
> to make the new product accessible, isn't that an imbalance of market
> power? I thought the whole idea of the Accessibility API was to
> eliminate that problem.
>
> Maybe I'm misunderstanding something....
>
>
>
>> -----Original Message-----
>> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Thursday, January 04, 2007 1:52 AM
>> To: 'TEITAC Web/Software Subcommittee'
>> Subject: Re: [teitac-websoftware] Starting discussionson
>> theAccessibility APIproposal
>>
>> Why value chain is good concept - but we need to be very careful about
>>
>
>
>> its use in regulatory standards.
>>
>> I really like the accessibility value chain concept as a way to
>> understand this - and to point out the way things work together.
>>
>> But I worry about it in a discussion of how to structure our
>> standards. And I don't think we should structure our standards around
>>
>
>
>> it. If we did then we would only require that software companies
>> "enable" there software to be accessible - but they would have no
>> responsibility to actually make sure that there was AT that did work
>> with their software and did make it
>> accessible. The result is that in fact it would be "meet
>> accessibility
>> standard" but be unusable by anyone with a disability.
>>
>> Take the following example.
>>
>>
>> The Gregorian Software company creates a marvelous new media
>> technology. It is new, different and extremely compelling web
>> software for shopping and transactions using a simulated person and
>> live environment over narrow
>> bandwidth. They implement it with an accessibility API but
>> no one uses the
>> technology (of course) til its release in Sept 2007. At its
>> announcement it
>> is adopted by Amazon, a slew of banks, etc. AT vendors
>> begin working with
>> it but it will be a year or more before they can get up to speed (sort
>>
>
>
>> of like when dos went to windows) but this technology spreads at
>> Internet speed because it is free downloadable plug in for most users.
>>
>> Suddenly these sites go black to AT users. But if we write out
>> guidelines such that the sites and the Gregorian software company can
>> say their software meets access standards, without actually requiring
>> them to be supported by real live AT that is out there - and available
>>
>
>
>> to users.
>>
>> In fact AT vendors will remember the days before we required software
>> to
>> actually work with real AT. Software would come out with
>> an accessibility
>> API but AT vendors were not able get access to it and had very poor
>> support
>> from software vendors even after release. Only when the
>> software was
>> required to actually work with real AT did the vendors invite and
>> support and even court AT vendors in the same way they invited,
>> supported and courted other software and hardware vendors (for
>> compatibility) when they released something new.
>>
>> So I think the "accessibility value chain" is a very important
>> concept. But I don't think we should base our standards on it.
>>
>> I think that something is accessible if it can be used by real people
>> who have disabilities, not just that it theoretically could be if only
>>
>
>
>> those other people had done their job.
>>
>> Accessible - means that it can be used by people with disabilities.
>> That means it is either directly accessible. Or that it is accessible
>>
>
>
>> using the AT that the person with a disability has or can reasonably
>> get (or in the case of the government - for its employees - AT they
>> are given). For public websites, it would be the AT that the public
>> at large has, can reasonably get, or is given.
>>
>> Any other definition of accessibility defeats the purpose the
>> legislators laid out in creating 508. that is that people with
>> disabilities could actually use the E&IT in the government alongside
>> everyone else - and when it was purchased (not sometime in the future
>> - if someone else does their job).
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On
>>>
>> Behalf Of Jim
>>
>>> Tobias
>>> Sent: Wednesday, January 03, 2007 9:35 AM
>>> To: 'TEITAC Web/Software Subcommittee'
>>> Subject: Re: [teitac-websoftware] Starting discussions on
>>> theAccessibility APIproposal
>>>
>>> Sean Hayes wrote:
>>>
>>> "Firstly I agree that there is a problem that needs
>>>
>> adressing here,
>>
>>> which is the equitable division of reponsibility on accessibility
>>> between each entity involved in delivering a software product.
>>> However, as we are all aware, this is very difficult problem given
>>> the manner in which modern software is produced, which in most
>>> significant products involves cooperation across multiple
>>> organisations, not only the software product developer, but OS
>>> vendors, hardware vendors, AT vendors and middleware vendors among
>>> others. In some cases standards or industry practice
>>>
>> already exists
>>
>>> around these interfaces, and in some cases it doesn't."
>>>
>>> I would like to take this opportunity to develop a little
>>>
>> further the
>>
>>> concept of an "accessibility value chain", which Sean refers to
>>> indirectly. I believe that clarifying these responsibilities is at
>>> the heart of "modern" accessibility, because, as Sean notes, modern
>>> software requires cooperation across multiple
>>>
>> organizations, many of
>>
>>> whom have only indirect relationships.
>>>
>>> I would like to posit that the nature of this technical cooperation
>>> has three distinct elements or phases:
>>> capability, implementation, and preservation.
>>> By
>>> "capability" I mean that the software component contains all the
>>> features necessary for accessible use or development.
>>> Examples are the ability to add a text description to an image in a
>>> web development tool, and the ability to record and play
>>>
>> back Baudot
>>
>>> files in a voice mail platform. By "implementation" I mean
>>>
>> that the
>>
>>> capability has actually been used by the next link in the
>>>
>> chain. That
>>
>>> is, the web developer has actually added a text description to an
>>> image, and the telecom manager has actually set up a voice
>>>
>> mailbox so
>>
>>> a Baudot TTY user can receive messages. By "preservation"
>>> I mean that
>>> the next link in the chain is required not to interfere with the
>>> accessibility feature already in place further up the chain. For
>>> example, a digital cable system must not strip the captioning
>>> information from a captioned video program during transmission.
>>>
>>> Most of the relationships in the chain are
>>>
>> capability-implementation
>>
>>> ones, especially for web and software. Thus the current
>>>
>> 508 requires
>>
>>> software to inherit system display settings, use standard OS text
>>> presentation techniques, etc.
>>>
>>> I think this formulation may clarify for us where we want
>>>
>> to go. For
>>
>>> example, we have mentioned adding OS requirements.
>>> That is, current 508 requires "downlink" software to honor OS
>>> accessibility features, but it doesn't require OSs to have those
>>> features. I think we may agree on adding such a requirement,
>>> especially if we use today's common OSs as models rather
>>>
>> than dreaming
>>
>>> up new features OSs don't have yet.
>>>
>>> Another point that may meet more resistance, but seems
>>>
>> clear to me, is
>>
>>> the utter inseperability of content from software once we
>>>
>> agree that
>>
>>> there is an interlocking set of relationships in the web/software
>>> arena. In the examples of the web page and voice mail
>>>
>> system I used
>>
>>> above, how can the tools be abstracted from the content?
>>>
>> My thinking
>>
>>> here is not very well developed, so I look forward to a dialogue.
>>>
>>>

From: Jessica M. Brodey
Date: Thu, Jan 04 2007 10:20 PM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Peter:

ATIA agrees that there are already aspects of an Accessibility API in 508.
We are opposed to creating and labeling something an "Accessibility API,"
enumerating it exactly in 508, and thus running the risk that companies can
say "hey, I used the accessibility API so I am 508 compliant" without actual
interoperability with AT. We want to be clear that while we think moving
towards incorporating an accessibility API is a good thing, it may not be
the lone solution to full interoperability, nor does an accessibility API
alone equate to actual access, and it should therefore not be used as the
measure for 508 compliance. We are also not certain that an accessibility
API expressed as such belongs in 508, which is a regulatory standard, as
opposed to in an industry standard.

ATIA would rather see enumerations written in broad brush strokes, not the
specifics that would indicate "use this particular accessibility API." I
apologize for not speaking to the specific language and sections as I am a
policy person, not a techie, but if you equate this to the world of the
Internet, we do not want to structure the regulations in a manner that would
say the equivalent of "supports Java version x," or even spell out all the
components or provisions in Java (without actually specifying it) that make
it obvious which version of Java we are pushing to support. We would rather
spell out characteristics that would allow a company to provide Java support
in satisfaction of that provision, OR could allow a company to go another
route and still satisfy the requirements of the regulation, or in three
years switch to Java version x2 without violating the regulation. I
understand that approach is sometimes frustrating for techies who often want
it to be spelled out in black in white. Unfortunately, it is the same
techies who also want the flexibility to innovate, and not be hemmed in when
the law is so specific that it prevents them from diverging. We need to
find a happy medium here . . . where we can include the elements of an
accessibility API to get at some of the benefits without nailing down such
specifics that we are locked into only one version of an accessibility API
that is too rigid and cannot evolve.

We need to focus on the end results - what we want to be able to achieve,
not the means of getting there. The distinction you pointed out, Peter, is
that while the descriptions in 1194.21(c) may comprise aspects of an
accessibility API, it does not dictate the nature of the accessibility API -
it is focused on the result of the access, not the means for providing the
access. Perhaps we can determine what aspects you feel are missing from the
existing provisions that are critical to an accessibility API, and write
them in language consistent with 1194.21?

Again . . . we think implementation of an accessibility API is a best
practice, and perhaps can be used/publicized in other aspects of this
process as a guide to understanding how to comply with the 508 requirements.

Jessica

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Thursday, January 04, 2007 11:38 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Hi Jessica,

> ATIA's position is that an accessibility API has a role, but it is in the
> business venue, or in the standards venue, not the regulatory venue. If
we
> want to include aspects of the accessibility API into 508, it should be as
> Sean Hayes from Microsoft has advocated. We are concerned about an exact
> and precise list that is finite and unable to evolve without reconvening a
> new panel and a new refresh. We see an accessibility API as more of a
good
> business practice that is the best way to meet some of the specifications
of 508, but which accessibility API may change and evolve over time.
>

508 already includes aspects of an accessibility API. The seven
provisions enumerated in
http://teitac.org/wiki/Web_and_Software:_Programmatic_exposure_of_informatio
n
are existing places where 508 describes the programmatic information
that IT shall provide to AT. The current language doesn't call this
portions of an "accessibility API", but language like "focus shall be
programmatically exposed so that assistive technology can track focus
and focus changes" in 1194.21(c) aren't too far away from that.

And I think ATIA would agree with me that the seven provisions in
question constitute an insufficient set of information from which AT can
accomplish their task. Yet these seven represent "a list that is finite
and unable to evolve without reconvening a new panel and a new
refresh." In fact, it is the very process of refreshing these seven
provisions that gave rise to the accessibility API proposal - a much
richer enumeration of things we know are needed, and in support of which
the evolving, platform-specific accessibility APIs like UI Automation
can be used by IT vendors to interopreate with AT.

If ATIA is opposed to a finite list, then what does ATIA propose we do
with finite list we currently have - the seven provisions enumerated
above?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Jessica
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lybarger,
> Barbara (MOD)
> Sent: Thursday, January 04, 2007 6:14 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
> APIproposal
>
> On this topic, I'm not nearly well enough informed on the content.
> However, I question Jessica's reasoning, in that no set of standards
> will help if they aren't followed by all the parties, here IT, AT and
> all the players in between, and violators aren't chastised in some way
> fair and reasonable way.
>
> At it's core, the API proposal is like the standards for our electrical
> power grids. The government regulates how the power source comes out,
> and all the other parties set up their stuff so all the customers can
> get at the power to run their lights. Most of the parties conform
> because the alternative is that people can't safely and cost effectively
> share the power. If anyone in the chain doesn't conform with the
> standard, end users either have dark houses because the light bulbs
> can't get the power, or they have a very bright house while it burns
> down. Either way the government is looking to punish the one who caused
> the problem.
>
> People argued about innovation and standardization when the first power
> grids were set up. Costs, safety and reliability won out over
> unfettered innovation, but it didn't stifle innovation. Folks are still
> inventing better, safer, cheaper ways of delivering power, and they are
> being used to upgrade the power grid. The bottom line then and now is
> that in a society we have to give up a little freedom to make sure we
> all can get at shared resource cheaply, safely and reliable. The
> technology equivalent may be this API or something like it. It is
> needed so all of us can share, and conformance by all is essential for
> it to work.
>
> If this API proposal isn't perfect in some ways, what would make it
> better so everyone would want to follow it? And then, what type of
> enforcement system is needed so the non-likeminded in society get
> brought into line?
>
> Barbara Lybarger
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
> M. Brodey
> Sent: Thursday, January 04, 2007 4:21 PM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
> APIproposal
>
> Jim:
>
> Speaking as a policy wonk in lay terms, I think that the common
> misunderstanding here is that use of an accessibility API equals
> accessibility. Just because there is an accessibility API does not mean
> that every piece of AT automatically works all of the time - it just
> increases the odds of existing AT working with new products. But,
> sometimes new technologies come with new features. If the AT did not
> take into account those new features or capabilities, support for those
> features still needs to be built in. An accessibility API makes it
> easier to build in support for those features, and makes it less
> burdensome for the AT vendors to do so (and means supporting those
> features should be more standardized), but it is not always automatic.
> Also, as I understand it, just because a company uses the accessibility
> API does not mean it implements the API in exactly the same way as
> another company, thus, it is possible a piece of AT may not work
> perfectly with one product that uses the accessibility API but may work
> perfectly with another, and thus it may not be fully compatible with
> every product. So, the verdict is that an accessibility API could be
> useful, could improve things, but does not mean that compliance with the
> API will equal access.
>
> Another problem is that adopting an accessibility API that is the "gold
> standard" today may quickly be old and out of date in 6 months or a
> year.
> While we are in danger of this for many aspects of 508, it is
> particularly worrisome for how AT interfaces with IT, because it could
> stifle the growth and expansion of new AT, particularly if the
> accessibility API becomes the excuse or justification . . . "well, we
> used the accessibility API, we don't have to be compatible with ACTUAL
> AT." At some point not too far off, because the API won't be able to
> grow and evolve once put into regulation, what started off as a means to
> improve accessibility could actually become the one bar to providing
> real access.
>
> Jessica Brodey
>
> -----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'
> Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
> APIproposal
>
> Your concerns are justified, but you have the concepts backwards.
> Thinking in terms of an accessibility value chain guarantees that we are
> thinking of all the steps required to give the end user access.
> Separating the regs by narrow targets, one product or industry at a
> time, ignores the need for both technical and informational
> interoperation.
>
> There is no getting around the problem of assigning responsibilities to
> the "proper"
> parties. Luckily 508 burdens the purchaser, who has the best view of
> the entire chain, from OEM-type product to developed product to
> installed product to user and administrator. In theory. The problem
> remains one of information flow rather than raw technological power, as
> your example indicates -- Gregorian did not work closely enough with the
> AT community.
>
> But that raises another troubling point: why is the Accessibility API
> not sufficient? If Gregorian builds its software correctly, why is
> additional action required by AT vendors?
> If Gregorian cannot sell to the feds until one or more AT vendors acts
> to make the new product accessible, isn't that an imbalance of market
> power? I thought the whole idea of the Accessibility API was to
> eliminate that problem.
>
> Maybe I'm misunderstanding something....
>
>
>
>> -----Original Message-----
>> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Thursday, January 04, 2007 1:52 AM
>> To: 'TEITAC Web/Software Subcommittee'
>> Subject: Re: [teitac-websoftware] Starting discussionson
>> theAccessibility APIproposal
>>
>> Why value chain is good concept - but we need to be very careful about
>>
>
>
>> its use in regulatory standards.
>>
>> I really like the accessibility value chain concept as a way to
>> understand this - and to point out the way things work together.
>>
>> But I worry about it in a discussion of how to structure our
>> standards. And I don't think we should structure our standards around
>>
>
>
>> it. If we did then we would only require that software companies
>> "enable" there software to be accessible - but they would have no
>> responsibility to actually make sure that there was AT that did work
>> with their software and did make it
>> accessible. The result is that in fact it would be "meet
>> accessibility
>> standard" but be unusable by anyone with a disability.
>>
>> Take the following example.
>>
>>
>> The Gregorian Software company creates a marvelous new media
>> technology. It is new, different and extremely compelling web
>> software for shopping and transactions using a simulated person and
>> live environment over narrow
>> bandwidth. They implement it with an accessibility API but
>> no one uses the
>> technology (of course) til its release in Sept 2007. At its
>> announcement it
>> is adopted by Amazon, a slew of banks, etc. AT vendors
>> begin working with
>> it but it will be a year or more before they can get up to speed (sort
>>
>
>
>> of like when dos went to windows) but this technology spreads at
>> Internet speed because it is free downloadable plug in for most users.
>>
>> Suddenly these sites go black to AT users. But if we write out
>> guidelines such that the sites and the Gregorian software company can
>> say their software meets access standards, without actually requiring
>> them to be supported by real live AT that is out there - and available
>>
>
>
>> to users.
>>
>> In fact AT vendors will remember the days before we required software
>> to
>> actually work with real AT. Software would come out with
>> an accessibility
>> API but AT vendors were not able get access to it and had very poor
>> support
>> from software vendors even after release. Only when the
>> software was
>> required to actually work with real AT did the vendors invite and
>> support and even court AT vendors in the same way they invited,
>> supported and courted other software and hardware vendors (for
>> compatibility) when they released something new.
>>
>> So I think the "accessibility value chain" is a very important
>> concept. But I don't think we should base our standards on it.
>>
>> I think that something is accessible if it can be used by real people
>> who have disabilities, not just that it theoretically could be if only
>>
>
>
>> those other people had done their job.
>>
>> Accessible - means that it can be used by people with disabilities.
>> That means it is either directly accessible. Or that it is accessible
>>
>
>
>> using the AT that the person with a disability has or can reasonably
>> get (or in the case of the government - for its employees - AT they
>> are given). For public websites, it would be the AT that the public
>> at large has, can reasonably get, or is given.
>>
>> Any other definition of accessibility defeats the purpose the
>> legislators laid out in creating 508. that is that people with
>> disabilities could actually use the E&IT in the government alongside
>> everyone else - and when it was purchased (not sometime in the future
>> - if someone else does their job).
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On
>>>
>> Behalf Of Jim
>>
>>> Tobias
>>> Sent: Wednesday, January 03, 2007 9:35 AM
>>> To: 'TEITAC Web/Software Subcommittee'
>>> Subject: Re: [teitac-websoftware] Starting discussions on
>>> theAccessibility APIproposal
>>>
>>> Sean Hayes wrote:
>>>
>>> "Firstly I agree that there is a problem that needs
>>>
>> adressing here,
>>
>>> which is the equitable division of reponsibility on accessibility
>>> between each entity involved in delivering a software product.
>>> However, as we are all aware, this is very difficult problem given
>>> the manner in which modern software is produced, which in most
>>> significant products involves cooperation across multiple
>>> organisations, not only the software product developer, but OS
>>> vendors, hardware vendors, AT vendors and middleware vendors among
>>> others. In some cases standards or industry practice
>>>
>> already exists
>>
>>> around these interfaces, and in some cases it doesn't."
>>>
>>> I would like to take this opportunity to develop a little
>>>
>> further the
>>
>>> concept of an "accessibility value chain", which Sean refers to
>>> indirectly. I believe that clarifying these responsibilities is at
>>> the heart of "modern" accessibility, because, as Sean notes, modern
>>> software requires cooperation across multiple
>>>
>> organizations, many of
>>
>>> whom have only indirect relationships.
>>>
>>> I would like to posit that the nature of this technical cooperation
>>> has three distinct elements or phases:
>>> capability, implementation, and preservation.
>>> By
>>> "capability" I mean that the software component contains all the
>>> features necessary for accessible use or development.
>>> Examples are the ability to add a text description to an image in a
>>> web development tool, and the ability to record and play
>>>
>> back Baudot
>>
>>> files in a voice mail platform. By "implementation" I mean
>>>
>> that the
>>
>>> capability has actually been used by the next link in the
>>>
>> chain. That
>>
>>> is, the web developer has actually added a text description to an
>>> image, and the telecom manager has actually set up a voice
>>>
>> mailbox so
>>
>>> a Baudot TTY user can receive messages. By "preservation"
>>> I mean that
>>> the next link in the chain is required not to interfere with the
>>> accessibility feature already in place further up the chain. For
>>> example, a digital cable system must not strip the captioning
>>> information from a captioned video program during transmission.
>>>
>>> Most of the relationships in the chain are
>>>
>> capability-implementation
>>
>>> ones, especially for web and software. Thus the current
>>>
>> 508 requires
>>
>>> software to inherit system display settings, use standard OS text
>>> presentation techniques, etc.
>>>
>>> I think this formulation may clarify for us where we want
>>>
>> to go. For
>>
>>> example, we have mentioned adding OS requirements.
>>> That is, current 508 requires "downlink" software to honor OS
>>> accessibility features, but it doesn't require OSs to have those
>>> features. I think we may agree on adding such a requirement,
>>> especially if we use today's common OSs as models rather
>>>
>> than dreaming
>>
>>> up new features OSs don't have yet.
>>>
>>> Another point that may meet more resistance, but seems
>>>
>> clear to me, is
>>
>>> the utter inseperability of content from software once we
>>>
>> agree that
>>
>>> there is an interlocking set of relationships in the web/software
>>> arena. In the examples of the web page and voice mail
>>>
>> system I used
>>
>>> above, how can the tools be abstracted from the content?
>>>
>> My thinking
>>
>>> here is not very well developed, so I look forward to a dialogue.
>>>
>>>

From: Travis Roth
Date: Fri, Jan 05 2007 8:20 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Jessica Brody wrote:
"ATIA would rather see enumerations written in broad brush strokes, not the
specifics that would indicate "use this particular accessibility API.""
And:
"We need to focus on the end results - what we want to be able to achieve,
not the means of getting there."

In reading the current "accesibility API" proposal it seems this is exactly
what it does, or is intended to do. I do not find anywhere where it
specifies how the implementation of the API should be carried out technology
wise?
It seems much more useful in stating what the end result should be than the
current 1194.21(c), 1194.21(d) and 1194.21(f) standards do.

I understand there is some desire to make broad statements that will stand
forever. However, it is entirely possible to make these type of statements
that cannot actually be used in the real world.
There needs to be a way for all parties involved to have "testable" items so
that compliance can be determined.

--
Travis Roth
Production Manager
TecAccess, LLC
(804) 749-8646 (office)
(402) 466-0907 (direct)
= EMAIL ADDRESS REMOVED =
www.TecAccess.net
Experts in Section 508 Compliance & Accessibility

NOTICE: This communication may contain privileged or other confidential
information. If you are not the intended recipient or believe that you may
have
received this communication in error, please reply to the sender indicating
that fact and delete the copy you received. Thank you.

From: Debbie Cook
Date: Fri, Jan 05 2007 10:30 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

One of the fundamental problems we currently have is that because AT has no
requirement to comply with any standards in order to work with IT, the It
may complay nd not work with any AT. So, just as IT companies go beyond the
minimum to compete so should AT. And frankly, while it's reasonable to
debate the merits of any components of a standard API, I think it's highly
desireable as a baseline for both AT and IT in terms of interoperability.
What now happens is that a given IT product is compatible with one AT and
not another. It is all too common that the bottom line for our IT
procuremens is that they must work with X or Y AT. That's not good for the
consumer or for the smaller AT vendor.
----- Original Message -----
From: "Eric Damery" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, January 04, 2007 1:46 PM
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal


Jessica,

Very well said.

Just to follow up on this line of thought, another concern when making
the API the "gold standard" should be what the incentive will be for AT
to do anything beyond the API, if it becomes the measurement for
procurement. As I understand it, a limited API could make it easier to
swallow for I T but at the same time, stifle smaller AT companies from
being able to help achieve access for users if it requires anything
beyond it. I suspect the same will be true for AT designed in at the
system level.

Regards,
Eric Damery

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Thursday, January 04, 2007 4:21 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Jim:

Speaking as a policy wonk in lay terms, I think that the common
misunderstanding here is that use of an accessibility API equals
accessibility. Just because there is an accessibility API does not mean
that every piece of AT automatically works all of the time - it just
increases the odds of existing AT working with new products. But,
sometimes new technologies come with new features. If the AT did not
take into account those new features or capabilities, support for those
features still needs to be built in. An accessibility API makes it
easier to build in support for those features, and makes it less
burdensome for the AT vendors to do so (and means supporting those
features should be more standardized), but it is not always automatic.
Also, as I understand it, just because a company uses the accessibility
API does not mean it implements the API in exactly the same way as
another company, thus, it is possible a piece of AT may not work
perfectly with one product that uses the accessibility API but may work
perfectly with another, and thus it may not be fully compatible with
every product. So, the verdict is that an accessibility API could be
useful, could improve things, but does not mean that compliance with the
API will equal access.

Another problem is that adopting an accessibility API that is the "gold
standard" today may quickly be old and out of date in 6 months or a
year.
While we are in danger of this for many aspects of 508, it is
particularly worrisome for how AT interfaces with IT, because it could
stifle the growth and expansion of new AT, particularly if the
accessibility API becomes the excuse or justification . . . "well, we
used the accessibility API, we don't have to be compatible with ACTUAL
AT." At some point not too far off, because the API won't be able to
grow and evolve once put into regulation, what started off as a means to
improve accessibility could actually become the one bar to providing
real access.

Jessica Brodey

-----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'
Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
APIproposal

Your concerns are justified, but you have the concepts backwards.
Thinking in terms of an accessibility value chain guarantees that we are
thinking of all the steps required to give the end user access.
Separating the regs by narrow targets, one product or industry at a
time, ignores the need for both technical and informational
interoperation.

There is no getting around the problem of assigning responsibilities to
the "proper"
parties. Luckily 508 burdens the purchaser, who has the best view of
the entire chain, from OEM-type product to developed product to
installed product to user and administrator. In theory. The problem
remains one of information flow rather than raw technological power, as
your example indicates -- Gregorian did not work closely enough with the
AT community.

But that raises another troubling point: why is the Accessibility API
not sufficient? If Gregorian builds its software correctly, why is
additional action required by AT vendors?
If Gregorian cannot sell to the feds until one or more AT vendors acts
to make the new product accessible, isn't that an imbalance of market
power? I thought the whole idea of the Accessibility API was to
eliminate that problem.

Maybe I'm misunderstanding something....


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 1:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibility APIproposal
>
> Why value chain is good concept - but we need to be very careful about

> its use in regulatory standards.
>
> I really like the accessibility value chain concept as a way to
> understand this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to structure our
> standards. And I don't think we should structure our standards around

> it. If we did then we would only require that software companies
> "enable" there software to be accessible - but they would have no
> responsibility to actually make sure that there was AT that did work
> with their software and did make it
> accessible. The result is that in fact it would be "meet
> accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new media
> technology. It is new, different and extremely compelling web
> software for shopping and transactions using a simulated person and
> live environment over narrow
> bandwidth. They implement it with an accessibility API but
> no one uses the
> technology (of course) til its release in Sept 2007. At its
> announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get up to speed (sort

> of like when dos went to windows) but this technology spreads at
> Internet speed because it is free downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we write out
> guidelines such that the sites and the Gregorian software company can
> say their software meets access standards, without actually requiring
> them to be supported by real live AT that is out there - and available

> to users.
>
> In fact AT vendors will remember the days before we required software
> to
> actually work with real AT. Software would come out with
> an accessibility
> API but AT vendors were not able get access to it and had very poor
> support
> from software vendors even after release. Only when the
> software was
> required to actually work with real AT did the vendors invite and
> support and even court AT vendors in the same way they invited,
> supported and courted other software and hardware vendors (for
> compatibility) when they released something new.
>
> So I think the "accessibility value chain" is a very important
> concept. But I don't think we should base our standards on it.
>
> I think that something is accessible if it can be used by real people
> who have disabilities, not just that it theoretically could be if only

> those other people had done their job.
>
> Accessible - means that it can be used by people with disabilities.
> That means it is either directly accessible. Or that it is accessible

> using the AT that the person with a disability has or can reasonably
> get (or in the case of the government - for its employees - AT they
> are given). For public websites, it would be the AT that the public
> at large has, can reasonably get, or is given.
>
> Any other definition of accessibility defeats the purpose the
> legislators laid out in creating 508. that is that people with
> disabilities could actually use the E&IT in the government alongside
> everyone else - and when it was purchased (not sometime in the future
> - if someone else does their job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting discussions on
> > theAccessibility APIproposal
> >
> > Sean Hayes wrote:
> >
> > "Firstly I agree that there is a problem that needs
> adressing here,
> > which is the equitable division of reponsibility on accessibility
> > between each entity involved in delivering a software product.
> > However, as we are all aware, this is very difficult problem given
> > the manner in which modern software is produced, which in most
> > significant products involves cooperation across multiple
> > organisations, not only the software product developer, but OS
> > vendors, hardware vendors, AT vendors and middleware vendors among
> > others. In some cases standards or industry practice
> already exists
> > around these interfaces, and in some cases it doesn't."
> >
> > I would like to take this opportunity to develop a little
> further the
> > concept of an "accessibility value chain", which Sean refers to
> > indirectly. I believe that clarifying these responsibilities is at
> > the heart of "modern" accessibility, because, as Sean notes, modern
> > software requires cooperation across multiple
> organizations, many of
> > whom have only indirect relationships.
> >
> > I would like to posit that the nature of this technical cooperation
> > has three distinct elements or phases:
> > capability, implementation, and preservation.
> > By
> > "capability" I mean that the software component contains all the
> > features necessary for accessible use or development.
> > Examples are the ability to add a text description to an image in a
> > web development tool, and the ability to record and play
> back Baudot
> > files in a voice mail platform. By "implementation" I mean
> that the
> > capability has actually been used by the next link in the
> chain. That
> > is, the web developer has actually added a text description to an
> > image, and the telecom manager has actually set up a voice
> mailbox so
> > a Baudot TTY user can receive messages. By "preservation"
> > I mean that
> > the next link in the chain is required not to interfere with the
> > accessibility feature already in place further up the chain. For
> > example, a digital cable system must not strip the captioning
> > information from a captioned video program during transmission.
> >
> > Most of the relationships in the chain are
> capability-implementation
> > ones, especially for web and software. Thus the current
> 508 requires
> > software to inherit system display settings, use standard OS text
> > presentation techniques, etc.
> >
> > I think this formulation may clarify for us where we want
> to go. For
> > example, we have mentioned adding OS requirements.
> > That is, current 508 requires "downlink" software to honor OS
> > accessibility features, but it doesn't require OSs to have those
> > features. I think we may agree on adding such a requirement,
> > especially if we use today's common OSs as models rather
> than dreaming
> > up new features OSs don't have yet.
> >
> > Another point that may meet more resistance, but seems
> clear to me, is
> > the utter inseperability of content from software once we
> agree that
> > there is an interlocking set of relationships in the web/software
> > arena. In the examples of the web page and voice mail
> system I used
> > above, how can the tools be abstracted from the content?
> My thinking
> > here is not very well developed, so I look forward to a dialogue.
> >
> >

From: Barrett, Don
Date: Fri, Jan 05 2007 10:35 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

The other piece of this is that A T is always playing catch up with new
I T technologies as they develop. Support for web-based tables and
JavaScript event handlers are two good examples. Once 508 specified
table markup for headers and cell associations for multi-level tables,
and functional text for scripts, A T vendors jumped on these issues, and
screen readers got better and better over time in handling these
elements. The more specific an API can be for mainstream I T vendors,
the more the marketplace will be established so A T can come in and meet
the specified market needs.

Rather than ATIA being afraid of an API, I should think they would
welcome it, as long as it is one their members can code to.

Don

From: Jessica M. Brodey
Date: Fri, Jan 05 2007 10:40 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Debbie Cook said: "One of the fundamental problems we currently have is that
because AT has no requirement to comply with any standards in order to work
with IT, the It may complay nd not work with any AT. So, just as IT
companies go beyond the minimum to compete so should AT. And frankly, while
it's reasonable to debate the merits of any components of a standard API, I
think it's highly desireable as a baseline for both AT and IT in terms of
interoperability. What now happens is that a given IT product is compatible
with one AT and not another. It is all too common that the bottom line for
our IT procuremens is that they must work with X or Y AT. That's not good
for the consumer or for the smaller AT vendor."

This is certainly true. The problem is, that for so many years, AT
companies have been forced to be inventive and create "work-arounds" in
order to provide access because there has not been a standard accessibility
API. We wholeheartedly agree that future IT and AT should be built on an
accessibility API to the extent feasible, that it will improve
interoperability, and would probably cut back significantly on development
costs for AT, in most cases. However, we do not want to force existing AT
companies out of business just because they do not have the money to revamp
their technologies and utilize an accessibility API when one did not exist
before, nor do we want to tell a company it cannot develop AT if the
accessibility API is inadequate to meet the needs of the AT it is trying to
develop, nor do we want to say that merely implementing an accessibility API
alone is a sufficient proxy for accessibility.

Jessica

----- Original Message -----
From: "Eric Damery" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, January 04, 2007 1:46 PM
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal


Jessica,

Very well said.

Just to follow up on this line of thought, another concern when making
the API the "gold standard" should be what the incentive will be for AT
to do anything beyond the API, if it becomes the measurement for
procurement. As I understand it, a limited API could make it easier to
swallow for I T but at the same time, stifle smaller AT companies from
being able to help achieve access for users if it requires anything
beyond it. I suspect the same will be true for AT designed in at the
system level.

Regards,
Eric Damery

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Thursday, January 04, 2007 4:21 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Jim:

Speaking as a policy wonk in lay terms, I think that the common
misunderstanding here is that use of an accessibility API equals
accessibility. Just because there is an accessibility API does not mean
that every piece of AT automatically works all of the time - it just
increases the odds of existing AT working with new products. But,
sometimes new technologies come with new features. If the AT did not
take into account those new features or capabilities, support for those
features still needs to be built in. An accessibility API makes it
easier to build in support for those features, and makes it less
burdensome for the AT vendors to do so (and means supporting those
features should be more standardized), but it is not always automatic.
Also, as I understand it, just because a company uses the accessibility
API does not mean it implements the API in exactly the same way as
another company, thus, it is possible a piece of AT may not work
perfectly with one product that uses the accessibility API but may work
perfectly with another, and thus it may not be fully compatible with
every product. So, the verdict is that an accessibility API could be
useful, could improve things, but does not mean that compliance with the
API will equal access.

Another problem is that adopting an accessibility API that is the "gold
standard" today may quickly be old and out of date in 6 months or a
year.
While we are in danger of this for many aspects of 508, it is
particularly worrisome for how AT interfaces with IT, because it could
stifle the growth and expansion of new AT, particularly if the
accessibility API becomes the excuse or justification . . . "well, we
used the accessibility API, we don't have to be compatible with ACTUAL
AT." At some point not too far off, because the API won't be able to
grow and evolve once put into regulation, what started off as a means to
improve accessibility could actually become the one bar to providing
real access.

Jessica Brodey

-----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'
Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
APIproposal

Your concerns are justified, but you have the concepts backwards.
Thinking in terms of an accessibility value chain guarantees that we are
thinking of all the steps required to give the end user access.
Separating the regs by narrow targets, one product or industry at a
time, ignores the need for both technical and informational
interoperation.

There is no getting around the problem of assigning responsibilities to
the "proper"
parties. Luckily 508 burdens the purchaser, who has the best view of
the entire chain, from OEM-type product to developed product to
installed product to user and administrator. In theory. The problem
remains one of information flow rather than raw technological power, as
your example indicates -- Gregorian did not work closely enough with the
AT community.

But that raises another troubling point: why is the Accessibility API
not sufficient? If Gregorian builds its software correctly, why is
additional action required by AT vendors?
If Gregorian cannot sell to the feds until one or more AT vendors acts
to make the new product accessible, isn't that an imbalance of market
power? I thought the whole idea of the Accessibility API was to
eliminate that problem.

Maybe I'm misunderstanding something....


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 1:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibility APIproposal
>
> Why value chain is good concept - but we need to be very careful about

> its use in regulatory standards.
>
> I really like the accessibility value chain concept as a way to
> understand this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to structure our
> standards. And I don't think we should structure our standards around

> it. If we did then we would only require that software companies
> "enable" there software to be accessible - but they would have no
> responsibility to actually make sure that there was AT that did work
> with their software and did make it
> accessible. The result is that in fact it would be "meet
> accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new media
> technology. It is new, different and extremely compelling web
> software for shopping and transactions using a simulated person and
> live environment over narrow
> bandwidth. They implement it with an accessibility API but
> no one uses the
> technology (of course) til its release in Sept 2007. At its
> announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get up to speed (sort

> of like when dos went to windows) but this technology spreads at
> Internet speed because it is free downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we write out
> guidelines such that the sites and the Gregorian software company can
> say their software meets access standards, without actually requiring
> them to be supported by real live AT that is out there - and available

> to users.
>
> In fact AT vendors will remember the days before we required software
> to
> actually work with real AT. Software would come out with
> an accessibility
> API but AT vendors were not able get access to it and had very poor
> support
> from software vendors even after release. Only when the
> software was
> required to actually work with real AT did the vendors invite and
> support and even court AT vendors in the same way they invited,
> supported and courted other software and hardware vendors (for
> compatibility) when they released something new.
>
> So I think the "accessibility value chain" is a very important
> concept. But I don't think we should base our standards on it.
>
> I think that something is accessible if it can be used by real people
> who have disabilities, not just that it theoretically could be if only

> those other people had done their job.
>
> Accessible - means that it can be used by people with disabilities.
> That means it is either directly accessible. Or that it is accessible

> using the AT that the person with a disability has or can reasonably
> get (or in the case of the government - for its employees - AT they
> are given). For public websites, it would be the AT that the public
> at large has, can reasonably get, or is given.
>
> Any other definition of accessibility defeats the purpose the
> legislators laid out in creating 508. that is that people with
> disabilities could actually use the E&IT in the government alongside
> everyone else - and when it was purchased (not sometime in the future
> - if someone else does their job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting discussions on
> > theAccessibility APIproposal
> >
> > Sean Hayes wrote:
> >
> > "Firstly I agree that there is a problem that needs
> adressing here,
> > which is the equitable division of reponsibility on accessibility
> > between each entity involved in delivering a software product.
> > However, as we are all aware, this is very difficult problem given
> > the manner in which modern software is produced, which in most
> > significant products involves cooperation across multiple
> > organisations, not only the software product developer, but OS
> > vendors, hardware vendors, AT vendors and middleware vendors among
> > others. In some cases standards or industry practice
> already exists
> > around these interfaces, and in some cases it doesn't."
> >
> > I would like to take this opportunity to develop a little
> further the
> > concept of an "accessibility value chain", which Sean refers to
> > indirectly. I believe that clarifying these responsibilities is at
> > the heart of "modern" accessibility, because, as Sean notes, modern
> > software requires cooperation across multiple
> organizations, many of
> > whom have only indirect relationships.
> >
> > I would like to posit that the nature of this technical cooperation
> > has three distinct elements or phases:
> > capability, implementation, and preservation.
> > By
> > "capability" I mean that the software component contains all the
> > features necessary for accessible use or development.
> > Examples are the ability to add a text description to an image in a
> > web development tool, and the ability to record and play
> back Baudot
> > files in a voice mail platform. By "implementation" I mean
> that the
> > capability has actually been used by the next link in the
> chain. That
> > is, the web developer has actually added a text description to an
> > image, and the telecom manager has actually set up a voice
> mailbox so
> > a Baudot TTY user can receive messages. By "preservation"
> > I mean that
> > the next link in the chain is required not to interfere with the
> > accessibility feature already in place further up the chain. For
> > example, a digital cable system must not strip the captioning
> > information from a captioned video program during transmission.
> >
> > Most of the relationships in the chain are
> capability-implementation
> > ones, especially for web and software. Thus the current
> 508 requires
> > software to inherit system display settings, use standard OS text
> > presentation techniques, etc.
> >
> > I think this formulation may clarify for us where we want
> to go. For
> > example, we have mentioned adding OS requirements.
> > That is, current 508 requires "downlink" software to honor OS
> > accessibility features, but it doesn't require OSs to have those
> > features. I think we may agree on adding such a requirement,
> > especially if we use today's common OSs as models rather
> than dreaming
> > up new features OSs don't have yet.
> >
> > Another point that may meet more resistance, but seems
> clear to me, is
> > the utter inseperability of content from software once we
> agree that
> > there is an interlocking set of relationships in the web/software
> > arena. In the examples of the web page and voice mail
> system I used
> > above, how can the tools be abstracted from the content?
> My thinking
> > here is not very well developed, so I look forward to a dialogue.
> >
> >

From: Debbie Cook
Date: Fri, Jan 05 2007 10:50 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

And there should be sufficient lead time before the application of any new
standard so that both IT and AT have an opportunity to implement. It is in
fact the work arounds that make it problematic for IT. If IT does not
conform to the existing work around, it gets declared inaccessible in the
final wash.
----- Original Message -----
From: "Barrett, Don" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, January 05, 2007 9:33 AM
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal


The other piece of this is that A T is always playing catch up with new
I T technologies as they develop. Support for web-based tables and
JavaScript event handlers are two good examples. Once 508 specified
table markup for headers and cell associations for multi-level tables,
and functional text for scripts, A T vendors jumped on these issues, and
screen readers got better and better over time in handling these
elements. The more specific an API can be for mainstream I T vendors,
the more the marketplace will be established so A T can come in and meet
the specified market needs.

Rather than ATIA being afraid of an API, I should think they would
welcome it, as long as it is one their members can code to.

Don

From: Brett, Thomas F
Date: Fri, Jan 05 2007 11:15 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Hey Don....just wanted to give you a little jab....never end a sentence
with a preposition as in:

Rather than ATIA being afraid of an API, I should think they would
welcome it, as long as it is one their members can code to.

Tom Brett,
2026061206
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Barrett, Don
Sent: Friday, January 05, 2007 12:33 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

The other piece of this is that A T is always playing catch up with new
I T technologies as they develop. Support for web-based tables and
JavaScript event handlers are two good examples. Once 508 specified
table markup for headers and cell associations for multi-level tables,
and functional text for scripts, A T vendors jumped on these issues, and
screen readers got better and better over time in handling these
elements. The more specific an API can be for mainstream I T vendors,
the more the marketplace will be established so A T can come in and meet
the specified market needs.

Rather than ATIA being afraid of an API, I should think they would
welcome it, as long as it is one their members can code to.

Don

From: Lazzaro, Joe (ITD)
Date: Fri, Jan 05 2007 11:50 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

I wholeheartedly support the concept of accessibility APIs, as they take
us away from the world of "special casing" in which we currently find
ourselves. A good example of such an API is the ATSPI (Assistive
Technology Service Provider Interface) on GNOME. This allows AT vendors
a single point of entry, and theoretically doesn't break when
applications rev.

Joe


Joe Lazzaro
Manager: Assistive Technology Group
Commonwealth of Massachusetts
Information Technology Division
One Ashburton Place
Room 1601
Boston, MA 02108
617-626-4410
www.Mass.Gov/ITD

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Friday, January 05, 2007 12:38 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Debbie Cook said: "One of the fundamental problems we currently have is
that because AT has no requirement to comply with any standards in order
to work with IT, the It may complay nd not work with any AT. So, just
as IT companies go beyond the minimum to compete so should AT. And
frankly, while it's reasonable to debate the merits of any components of
a standard API, I think it's highly desireable as a baseline for both AT
and IT in terms of interoperability. What now happens is that a given IT
product is compatible with one AT and not another. It is all too common
that the bottom line for our IT procuremens is that they must work with
X or Y AT. That's not good for the consumer or for the smaller AT
vendor."

This is certainly true. The problem is, that for so many years, AT
companies have been forced to be inventive and create "work-arounds" in
order to provide access because there has not been a standard
accessibility API. We wholeheartedly agree that future IT and AT should
be built on an accessibility API to the extent feasible, that it will
improve interoperability, and would probably cut back significantly on
development costs for AT, in most cases. However, we do not want to
force existing AT companies out of business just because they do not
have the money to revamp their technologies and utilize an accessibility
API when one did not exist before, nor do we want to tell a company it
cannot develop AT if the accessibility API is inadequate to meet the
needs of the AT it is trying to develop, nor do we want to say that
merely implementing an accessibility API alone is a sufficient proxy for
accessibility.

Jessica

----- Original Message -----
From: "Eric Damery" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee"
< = EMAIL ADDRESS REMOVED = >
Sent: Thursday, January 04, 2007 1:46 PM
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal


Jessica,

Very well said.

Just to follow up on this line of thought, another concern when making
the API the "gold standard" should be what the incentive will be for AT
to do anything beyond the API, if it becomes the measurement for
procurement. As I understand it, a limited API could make it easier to
swallow for I T but at the same time, stifle smaller AT companies from
being able to help achieve access for users if it requires anything
beyond it. I suspect the same will be true for AT designed in at the
system level.

Regards,
Eric Damery

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Thursday, January 04, 2007 4:21 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Jim:

Speaking as a policy wonk in lay terms, I think that the common
misunderstanding here is that use of an accessibility API equals
accessibility. Just because there is an accessibility API does not mean
that every piece of AT automatically works all of the time - it just
increases the odds of existing AT working with new products. But,
sometimes new technologies come with new features. If the AT did not
take into account those new features or capabilities, support for those
features still needs to be built in. An accessibility API makes it
easier to build in support for those features, and makes it less
burdensome for the AT vendors to do so (and means supporting those
features should be more standardized), but it is not always automatic.
Also, as I understand it, just because a company uses the accessibility
API does not mean it implements the API in exactly the same way as
another company, thus, it is possible a piece of AT may not work
perfectly with one product that uses the accessibility API but may work
perfectly with another, and thus it may not be fully compatible with
every product. So, the verdict is that an accessibility API could be
useful, could improve things, but does not mean that compliance with the
API will equal access.

Another problem is that adopting an accessibility API that is the "gold
standard" today may quickly be old and out of date in 6 months or a
year.
While we are in danger of this for many aspects of 508, it is
particularly worrisome for how AT interfaces with IT, because it could
stifle the growth and expansion of new AT, particularly if the
accessibility API becomes the excuse or justification . . . "well, we
used the accessibility API, we don't have to be compatible with ACTUAL
AT." At some point not too far off, because the API won't be able to
grow and evolve once put into regulation, what started off as a means to
improve accessibility could actually become the one bar to providing
real access.

Jessica Brodey

-----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'
Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
APIproposal

Your concerns are justified, but you have the concepts backwards.
Thinking in terms of an accessibility value chain guarantees that we are
thinking of all the steps required to give the end user access.
Separating the regs by narrow targets, one product or industry at a
time, ignores the need for both technical and informational
interoperation.

There is no getting around the problem of assigning responsibilities to
the "proper"
parties. Luckily 508 burdens the purchaser, who has the best view of
the entire chain, from OEM-type product to developed product to
installed product to user and administrator. In theory. The problem
remains one of information flow rather than raw technological power, as
your example indicates -- Gregorian did not work closely enough with the
AT community.

But that raises another troubling point: why is the Accessibility API
not sufficient? If Gregorian builds its software correctly, why is
additional action required by AT vendors?
If Gregorian cannot sell to the feds until one or more AT vendors acts
to make the new product accessible, isn't that an imbalance of market
power? I thought the whole idea of the Accessibility API was to
eliminate that problem.

Maybe I'm misunderstanding something....


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 1:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibility APIproposal
>
> Why value chain is good concept - but we need to be very careful about

> its use in regulatory standards.
>
> I really like the accessibility value chain concept as a way to
> understand this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to structure our
> standards. And I don't think we should structure our standards around

> it. If we did then we would only require that software companies
> "enable" there software to be accessible - but they would have no
> responsibility to actually make sure that there was AT that did work
> with their software and did make it
> accessible. The result is that in fact it would be "meet
> accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new media
> technology. It is new, different and extremely compelling web
> software for shopping and transactions using a simulated person and
> live environment over narrow
> bandwidth. They implement it with an accessibility API but
> no one uses the
> technology (of course) til its release in Sept 2007. At its
> announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get up to speed (sort

> of like when dos went to windows) but this technology spreads at
> Internet speed because it is free downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we write out
> guidelines such that the sites and the Gregorian software company can
> say their software meets access standards, without actually requiring
> them to be supported by real live AT that is out there - and available

> to users.
>
> In fact AT vendors will remember the days before we required software
> to
> actually work with real AT. Software would come out with
> an accessibility
> API but AT vendors were not able get access to it and had very poor
> support
> from software vendors even after release. Only when the
> software was
> required to actually work with real AT did the vendors invite and
> support and even court AT vendors in the same way they invited,
> supported and courted other software and hardware vendors (for
> compatibility) when they released something new.
>
> So I think the "accessibility value chain" is a very important
> concept. But I don't think we should base our standards on it.
>
> I think that something is accessible if it can be used by real people
> who have disabilities, not just that it theoretically could be if only

> those other people had done their job.
>
> Accessible - means that it can be used by people with disabilities.
> That means it is either directly accessible. Or that it is accessible

> using the AT that the person with a disability has or can reasonably
> get (or in the case of the government - for its employees - AT they
> are given). For public websites, it would be the AT that the public
> at large has, can reasonably get, or is given.
>
> Any other definition of accessibility defeats the purpose the
> legislators laid out in creating 508. that is that people with
> disabilities could actually use the E&IT in the government alongside
> everyone else - and when it was purchased (not sometime in the future
> - if someone else does their job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting discussions on
> > theAccessibility APIproposal
> >
> > Sean Hayes wrote:
> >
> > "Firstly I agree that there is a problem that needs
> adressing here,
> > which is the equitable division of reponsibility on accessibility
> > between each entity involved in delivering a software product.
> > However, as we are all aware, this is very difficult problem given
> > the manner in which modern software is produced, which in most
> > significant products involves cooperation across multiple
> > organisations, not only the software product developer, but OS
> > vendors, hardware vendors, AT vendors and middleware vendors among
> > others. In some cases standards or industry practice
> already exists
> > around these interfaces, and in some cases it doesn't."
> >
> > I would like to take this opportunity to develop a little
> further the
> > concept of an "accessibility value chain", which Sean refers to
> > indirectly. I believe that clarifying these responsibilities is at
> > the heart of "modern" accessibility, because, as Sean notes, modern
> > software requires cooperation across multiple
> organizations, many of
> > whom have only indirect relationships.
> >
> > I would like to posit that the nature of this technical cooperation
> > has three distinct elements or phases:
> > capability, implementation, and preservation.
> > By
> > "capability" I mean that the software component contains all the
> > features necessary for accessible use or development.
> > Examples are the ability to add a text description to an image in a
> > web development tool, and the ability to record and play
> back Baudot
> > files in a voice mail platform. By "implementation" I mean
> that the
> > capability has actually been used by the next link in the
> chain. That
> > is, the web developer has actually added a text description to an
> > image, and the telecom manager has actually set up a voice
> mailbox so
> > a Baudot TTY user can receive messages. By "preservation"
> > I mean that
> > the next link in the chain is required not to interfere with the
> > accessibility feature already in place further up the chain. For
> > example, a digital cable system must not strip the captioning
> > information from a captioned video program during transmission.
> >
> > Most of the relationships in the chain are
> capability-implementation
> > ones, especially for web and software. Thus the current
> 508 requires
> > software to inherit system display settings, use standard OS text
> > presentation techniques, etc.
> >
> > I think this formulation may clarify for us where we want
> to go. For
> > example, we have mentioned adding OS requirements.
> > That is, current 508 requires "downlink" software to honor OS
> > accessibility features, but it doesn't require OSs to have those
> > features. I think we may agree on adding such a requirement,
> > especially if we use today's common OSs as models rather
> than dreaming
> > up new features OSs don't have yet.
> >
> > Another point that may meet more resistance, but seems
> clear to me, is
> > the utter inseperability of content from software once we
> agree that
> > there is an interlocking set of relationships in the web/software
> > arena. In the examples of the web page and voice mail
> system I used
> > above, how can the tools be abstracted from the content?
> My thinking
> > here is not very well developed, so I look forward to a dialogue.
> >
> >

From: Lazzaro, Joe (ITD)
Date: Sun, Jan 07 2007 7:10 PM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

I wanted to reinforce my earlier email about the importance of APIs,
where I highlighted ATSPI on the GNOME platform.

>From my experience as a screen reader user, API support increases
reliability, and this translates to a more positive user experience.

There is a long history of API support in the IT industry, and this
should be encouraged. It's too fatalistic to assume that an API won't be
supported by the AT vendors. As many on this list will know, Microsoft
has developed MSAA (Microsoft Active Accessibility) as well as COM and
DOM, all used by AT vendors to make their solutions more reliable and
robust. I also applaud IBMs work on rolling out the IAccessible2, API
and giving it to the Free Standards Group, which will continue its
development. The work by Apple on its accessibility API is another
example of how the industry has been moving in this direction for a
significant time. The AT and IT industry need to work more closely on
this to make sure that the APIs are supported. While I'm on a roll, we
also need development tools that enforce accessibility, so that objects
can't be created unless they support accessibility features. One example
of this would be to force developers to include meaningful text
equivalents so that screen readers can accurately read controls,
buttons, check boxes, and other controls.

Joe


Joe Lazzaro
Manager: Assistive Technology Group
Information Technology Division
Commonwealth of Massachusetts
One Ashburton Place
Room 1601
Boston, MA 02108
Voice: 617-626-4410
Email: = EMAIL ADDRESS REMOVED =
Web: www.Mass.gov/ITD


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Lazzaro, Joe (ITD)
Sent: Friday, January 05, 2007 1:46 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

I wholeheartedly support the concept of accessibility APIs, as they take
us away from the world of "special casing" in which we currently find
ourselves. A good example of such an API is the ATSPI (Assistive
Technology Service Provider Interface) on GNOME. This allows AT vendors
a single point of entry, and theoretically doesn't break when
applications rev.

Joe


Joe Lazzaro
Manager: Assistive Technology Group
Commonwealth of Massachusetts
Information Technology Division
One Ashburton Place
Room 1601
Boston, MA 02108
617-626-4410
www.Mass.Gov/ITD

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Friday, January 05, 2007 12:38 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Debbie Cook said: "One of the fundamental problems we currently have is
that because AT has no requirement to comply with any standards in order
to work with IT, the It may complay nd not work with any AT. So, just
as IT companies go beyond the minimum to compete so should AT. And
frankly, while it's reasonable to debate the merits of any components of
a standard API, I think it's highly desireable as a baseline for both AT
and IT in terms of interoperability. What now happens is that a given IT
product is compatible with one AT and not another. It is all too common
that the bottom line for our IT procuremens is that they must work with
X or Y AT. That's not good for the consumer or for the smaller AT
vendor."

This is certainly true. The problem is, that for so many years, AT
companies have been forced to be inventive and create "work-arounds" in
order to provide access because there has not been a standard
accessibility API. We wholeheartedly agree that future IT and AT should
be built on an accessibility API to the extent feasible, that it will
improve interoperability, and would probably cut back significantly on
development costs for AT, in most cases. However, we do not want to
force existing AT companies out of business just because they do not
have the money to revamp their technologies and utilize an accessibility
API when one did not exist before, nor do we want to tell a company it
cannot develop AT if the accessibility API is inadequate to meet the
needs of the AT it is trying to develop, nor do we want to say that
merely implementing an accessibility API alone is a sufficient proxy for
accessibility.

Jessica

----- Original Message -----
From: "Eric Damery" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee"
< = EMAIL ADDRESS REMOVED = >
Sent: Thursday, January 04, 2007 1:46 PM
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal


Jessica,

Very well said.

Just to follow up on this line of thought, another concern when making
the API the "gold standard" should be what the incentive will be for AT
to do anything beyond the API, if it becomes the measurement for
procurement. As I understand it, a limited API could make it easier to
swallow for I T but at the same time, stifle smaller AT companies from
being able to help achieve access for users if it requires anything
beyond it. I suspect the same will be true for AT designed in at the
system level.

Regards,
Eric Damery

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Thursday, January 04, 2007 4:21 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Jim:

Speaking as a policy wonk in lay terms, I think that the common
misunderstanding here is that use of an accessibility API equals
accessibility. Just because there is an accessibility API does not mean
that every piece of AT automatically works all of the time - it just
increases the odds of existing AT working with new products. But,
sometimes new technologies come with new features. If the AT did not
take into account those new features or capabilities, support for those
features still needs to be built in. An accessibility API makes it
easier to build in support for those features, and makes it less
burdensome for the AT vendors to do so (and means supporting those
features should be more standardized), but it is not always automatic.
Also, as I understand it, just because a company uses the accessibility
API does not mean it implements the API in exactly the same way as
another company, thus, it is possible a piece of AT may not work
perfectly with one product that uses the accessibility API but may work
perfectly with another, and thus it may not be fully compatible with
every product. So, the verdict is that an accessibility API could be
useful, could improve things, but does not mean that compliance with the
API will equal access.

Another problem is that adopting an accessibility API that is the "gold
standard" today may quickly be old and out of date in 6 months or a
year.
While we are in danger of this for many aspects of 508, it is
particularly worrisome for how AT interfaces with IT, because it could
stifle the growth and expansion of new AT, particularly if the
accessibility API becomes the excuse or justification . . . "well, we
used the accessibility API, we don't have to be compatible with ACTUAL
AT." At some point not too far off, because the API won't be able to
grow and evolve once put into regulation, what started off as a means to
improve accessibility could actually become the one bar to providing
real access.

Jessica Brodey

-----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'
Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
APIproposal

Your concerns are justified, but you have the concepts backwards.
Thinking in terms of an accessibility value chain guarantees that we are
thinking of all the steps required to give the end user access.
Separating the regs by narrow targets, one product or industry at a
time, ignores the need for both technical and informational
interoperation.

There is no getting around the problem of assigning responsibilities to
the "proper"
parties. Luckily 508 burdens the purchaser, who has the best view of
the entire chain, from OEM-type product to developed product to
installed product to user and administrator. In theory. The problem
remains one of information flow rather than raw technological power, as
your example indicates -- Gregorian did not work closely enough with the
AT community.

But that raises another troubling point: why is the Accessibility API
not sufficient? If Gregorian builds its software correctly, why is
additional action required by AT vendors?
If Gregorian cannot sell to the feds until one or more AT vendors acts
to make the new product accessible, isn't that an imbalance of market
power? I thought the whole idea of the Accessibility API was to
eliminate that problem.

Maybe I'm misunderstanding something....


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 1:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibility APIproposal
>
> Why value chain is good concept - but we need to be very careful about

> its use in regulatory standards.
>
> I really like the accessibility value chain concept as a way to
> understand this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to structure our
> standards. And I don't think we should structure our standards around

> it. If we did then we would only require that software companies
> "enable" there software to be accessible - but they would have no
> responsibility to actually make sure that there was AT that did work
> with their software and did make it
> accessible. The result is that in fact it would be "meet
> accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new media
> technology. It is new, different and extremely compelling web
> software for shopping and transactions using a simulated person and
> live environment over narrow
> bandwidth. They implement it with an accessibility API but
> no one uses the
> technology (of course) til its release in Sept 2007. At its
> announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get up to speed (sort

> of like when dos went to windows) but this technology spreads at
> Internet speed because it is free downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we write out
> guidelines such that the sites and the Gregorian software company can
> say their software meets access standards, without actually requiring
> them to be supported by real live AT that is out there - and available

> to users.
>
> In fact AT vendors will remember the days before we required software
> to
> actually work with real AT. Software would come out with
> an accessibility
> API but AT vendors were not able get access to it and had very poor
> support
> from software vendors even after release. Only when the
> software was
> required to actually work with real AT did the vendors invite and
> support and even court AT vendors in the same way they invited,
> supported and courted other software and hardware vendors (for
> compatibility) when they released something new.
>
> So I think the "accessibility value chain" is a very important
> concept. But I don't think we should base our standards on it.
>
> I think that something is accessible if it can be used by real people
> who have disabilities, not just that it theoretically could be if only

> those other people had done their job.
>
> Accessible - means that it can be used by people with disabilities.
> That means it is either directly accessible. Or that it is accessible

> using the AT that the person with a disability has or can reasonably
> get (or in the case of the government - for its employees - AT they
> are given). For public websites, it would be the AT that the public
> at large has, can reasonably get, or is given.
>
> Any other definition of accessibility defeats the purpose the
> legislators laid out in creating 508. that is that people with
> disabilities could actually use the E&IT in the government alongside
> everyone else - and when it was purchased (not sometime in the future
> - if someone else does their job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting discussions on
> > theAccessibility APIproposal
> >
> > Sean Hayes wrote:
> >
> > "Firstly I agree that there is a problem that needs
> adressing here,
> > which is the equitable division of reponsibility on accessibility
> > between each entity involved in delivering a software product.
> > However, as we are all aware, this is very difficult problem given
> > the manner in which modern software is produced, which in most
> > significant products involves cooperation across multiple
> > organisations, not only the software product developer, but OS
> > vendors, hardware vendors, AT vendors and middleware vendors among
> > others. In some cases standards or industry practice
> already exists
> > around these interfaces, and in some cases it doesn't."
> >
> > I would like to take this opportunity to develop a little
> further the
> > concept of an "accessibility value chain", which Sean refers to
> > indirectly. I believe that clarifying these responsibilities is at
> > the heart of "modern" accessibility, because, as Sean notes, modern
> > software requires cooperation across multiple
> organizations, many of
> > whom have only indirect relationships.
> >
> > I would like to posit that the nature of this technical cooperation
> > has three distinct elements or phases:
> > capability, implementation, and preservation.
> > By
> > "capability" I mean that the software component contains all the
> > features necessary for accessible use or development.
> > Examples are the ability to add a text description to an image in a
> > web development tool, and the ability to record and play
> back Baudot
> > files in a voice mail platform. By "implementation" I mean
> that the
> > capability has actually been used by the next link in the
> chain. That
> > is, the web developer has actually added a text description to an
> > image, and the telecom manager has actually set up a voice
> mailbox so
> > a Baudot TTY user can receive messages. By "preservation"
> > I mean that
> > the next link in the chain is required not to interfere with the
> > accessibility feature already in place further up the chain. For
> > example, a digital cable system must not strip the captioning
> > information from a captioned video program during transmission.
> >
> > Most of the relationships in the chain are
> capability-implementation
> > ones, especially for web and software. Thus the current
> 508 requires
> > software to inherit system display settings, use standard OS text
> > presentation techniques, etc.
> >
> > I think this formulation may clarify for us where we want
> to go. For
> > example, we have mentioned adding OS requirements.
> > That is, current 508 requires "downlink" software to honor OS
> > accessibility features, but it doesn't require OSs to have those
> > features. I think we may agree on adding such a requirement,
> > especially if we use today's common OSs as models rather
> than dreaming
> > up new features OSs don't have yet.
> >
> > Another point that may meet more resistance, but seems
> clear to me, is
> > the utter inseperability of content from software once we
> agree that
> > there is an interlocking set of relationships in the web/software
> > arena. In the examples of the web page and voice mail
> system I used
> > above, how can the tools be abstracted from the content?
> My thinking
> > here is not very well developed, so I look forward to a dialogue.
> >
> >

From: Robinson, Norman B - Washington, DC
Date: Sun, Jan 07 2007 7:30 PM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

You'll see me commenting on the need for standards and the need
for _references_ to current implementations in the Section 508 refresh.
I don't mean that needs to be a part of law, but I do think it would
help the development community (the ones sitting at a vendor's office
creating software) if we point them in the right direction and inform
them of the most common APIs somehow.

I agree the definition of an API doesn't ensure accessibility.
But if we are going to split hairs on semantics, I'd say you aren't
compliant if you didn't _USE_ the API <grins>. If we have to debate
semantics we are focusing on the wrong problem or need to rewrite the
requirement (if it is clearly interpreted badly by most people). So I
agree with you that vendor use of an API isn't a clear basis for
measuring Section 508 compliance. I think the functional requirements
(goals) Section 508 has outlined for determining compliance have been
successful.

However, do we need to address the issues when vendors use many
different APIs to achieve accessibility? Does it move accessibility
forward, make electronic information and electronic technology more
accessible if we all, collectively, use the same APIs? Or is it better
to have many different vendors implementing their own APIs?

Is the defacto standard for an accessibility API on MS Windows
MSAA? Is it AT-SPI for Gnome? KDE AT-API for KDE? UA for OSX? What about
the Qt Accessibility Framework for MS Windows; it uses MSAA but has it's
own API. I've got acronym overload! Perhaps, after looking at these
things as the toolkits they are, we can agree there is a basic goodness
in having developers develop to the appropriate API for their
platform/operating system. Now, how could we, if so motivated, actually
force/beat/make them use a particular API; even if that would be wrong
of us? I don't think Section 508 would be the place to do that. I think
it has to be tied to business requirements. Certainly requiring MSAA on
the Linux platform won't get you anywhere - it doesn't exist!

We approach this in our policy
(http://www.usps.com/cpim/ftp/hand/as508a/508a_c5.html#508hdr8) and I
would say the short version is a prioritized list approach: 1. Support
native operating system and activated accessibility features. 2. Use
standard controls for particular operating systems where possible. 3. Be
careful when using custom controls or enhancing standard controls. 4.
Provide flexibility in using a variety of input methods. 5. Query
accessibility aids in use by the operating system and configure the
software applications automatically.

So using a API doesn't equate to access, but we should:
1. Support native operating systems accessibility (e.g., the
APIs for whatever development framework is being used should use the
operating systems accessibility features and not _reinvent_ their own).
- is there more than one native operating system API on
any platform? Help point this out!
2. If the API provides standard controls (which is generally the
purpose of a framework or development environment?) those standard
controls should follow #1.
- there are many developer toolkits or frameworks but do
they all use the native API? (Java Access Bridge uses MSAA doesn't it?
Qt?)
3. Developers should follow #1, via using standard controls
(#2).
4. Developers should test their products in a variety of
use-cases that include testing for users that might have a disability.
5. This is a repeat of #1 actually, as the operating system
would provide this through a standard interface (#1).

As we have developed our own policy, I can't help but think what
we need is a central policy document that isn't a part of the law but
the best practices that have been approved as acceptable. We need some
agency (the Access Board? GSA?) to maintain this and harmonize it with
any Section 508 updates. It would effectively replace an agencies
individual policy when the agency didn't invent it. Guidelines, not
Section 508 technical standards or regulations. Guidelines that meet the
technical standards but can be legally ignored as not _required_.

Wow. I think I just convinced myself that we shouldn't have API
specifications in the revision at all.

Have a great weekend,


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 Jessica
M. Brodey
Sent: Friday, January 05, 2007 12:17 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal


Peter:

ATIA agrees that there are already aspects of an Accessibility API in
508.
We are opposed to creating and labeling something an "Accessibility
API,"
enumerating it exactly in 508, and thus running the risk that companies
can
say "hey, I used the accessibility API so I am 508 compliant" without
actual
interoperability with AT. We want to be clear that while we think
moving
towards incorporating an accessibility API is a good thing, it may not
be
the lone solution to full interoperability, nor does an accessibility
API
alone equate to actual access, and it should therefore not be used as
the
measure for 508 compliance. We are also not certain that an
accessibility
API expressed as such belongs in 508, which is a regulatory standard, as
opposed to in an industry standard.

ATIA would rather see enumerations written in broad brush strokes, not
the
specifics that would indicate "use this particular accessibility API."
I
apologize for not speaking to the specific language and sections as I am
a
policy person, not a techie, but if you equate this to the world of the
Internet, we do not want to structure the regulations in a manner that
would
say the equivalent of "supports Java version x," or even spell out all
the
components or provisions in Java (without actually specifying it) that
make
it obvious which version of Java we are pushing to support. We would
rather
spell out characteristics that would allow a company to provide Java
support
in satisfaction of that provision, OR could allow a company to go
another
route and still satisfy the requirements of the regulation, or in three
years switch to Java version x2 without violating the regulation. I
understand that approach is sometimes frustrating for techies who often
want
it to be spelled out in black in white. Unfortunately, it is the same
techies who also want the flexibility to innovate, and not be hemmed in
when
the law is so specific that it prevents them from diverging. We need to
find a happy medium here . . . where we can include the elements of an
accessibility API to get at some of the benefits without nailing down
such
specifics that we are locked into only one version of an accessibility
API
that is too rigid and cannot evolve.

We need to focus on the end results - what we want to be able to
achieve,
not the means of getting there. The distinction you pointed out, Peter,
is
that while the descriptions in 1194.21(c) may comprise aspects of an
accessibility API, it does not dictate the nature of the accessibility
API -
it is focused on the result of the access, not the means for providing
the
access. Perhaps we can determine what aspects you feel are missing from
the
existing provisions that are critical to an accessibility API, and write
them in language consistent with 1194.21?

Again . . . we think implementation of an accessibility API is a best
practice, and perhaps can be used/publicized in other aspects of this
process as a guide to understanding how to comply with the 508
requirements.

Jessica

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: Thursday, January 04, 2007 11:38 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Hi Jessica,

> ATIA's position is that an accessibility API has a role, but it is in
the
> business venue, or in the standards venue, not the regulatory venue.
If
we
> want to include aspects of the accessibility API into 508, it should
be as
> Sean Hayes from Microsoft has advocated. We are concerned about an
exact
> and precise list that is finite and unable to evolve without
reconvening a
> new panel and a new refresh. We see an accessibility API as more of a
good
> business practice that is the best way to meet some of the
specifications
of 508, but which accessibility API may change and evolve over time.
>

508 already includes aspects of an accessibility API. The seven
provisions enumerated in
http://teitac.org/wiki/Web_and_Software:_Programmatic_exposure_of_inform
atio
n
are existing places where 508 describes the programmatic information
that IT shall provide to AT. The current language doesn't call this
portions of an "accessibility API", but language like "focus shall be
programmatically exposed so that assistive technology can track focus
and focus changes" in 1194.21(c) aren't too far away from that.

And I think ATIA would agree with me that the seven provisions in
question constitute an insufficient set of information from which AT can

accomplish their task. Yet these seven represent "a list that is finite

and unable to evolve without reconvening a new panel and a new
refresh." In fact, it is the very process of refreshing these seven
provisions that gave rise to the accessibility API proposal - a much
richer enumeration of things we know are needed, and in support of which

the evolving, platform-specific accessibility APIs like UI Automation
can be used by IT vendors to interopreate with AT.

If ATIA is opposed to a finite list, then what does ATIA propose we do
with finite list we currently have - the seven provisions enumerated
above?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Jessica
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Lybarger,
> Barbara (MOD)
> Sent: Thursday, January 04, 2007 6:14 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware]Startingdiscussionson
theAccessibility
> APIproposal
>
> On this topic, I'm not nearly well enough informed on the content.
> However, I question Jessica's reasoning, in that no set of standards
> will help if they aren't followed by all the parties, here IT, AT and
> all the players in between, and violators aren't chastised in some way
> fair and reasonable way.
>
> At it's core, the API proposal is like the standards for our
electrical
> power grids. The government regulates how the power source comes out,
> and all the other parties set up their stuff so all the customers can
> get at the power to run their lights. Most of the parties conform
> because the alternative is that people can't safely and cost
effectively
> share the power. If anyone in the chain doesn't conform with the
> standard, end users either have dark houses because the light bulbs
> can't get the power, or they have a very bright house while it burns
> down. Either way the government is looking to punish the one who
caused
> the problem.
>
> People argued about innovation and standardization when the first
power
> grids were set up. Costs, safety and reliability won out over
> unfettered innovation, but it didn't stifle innovation. Folks are
still
> inventing better, safer, cheaper ways of delivering power, and they
are
> being used to upgrade the power grid. The bottom line then and now is
> that in a society we have to give up a little freedom to make sure we
> all can get at shared resource cheaply, safely and reliable. The
> technology equivalent may be this API or something like it. It is
> needed so all of us can share, and conformance by all is essential for
> it to work.
>
> If this API proposal isn't perfect in some ways, what would make it
> better so everyone would want to follow it? And then, what type of
> enforcement system is needed so the non-likeminded in society get
> brought into line?
>
> Barbara Lybarger
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Jessica
> M. Brodey
> Sent: Thursday, January 04, 2007 4:21 PM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware]Startingdiscussionson
theAccessibility
> APIproposal
>
> Jim:
>
> Speaking as a policy wonk in lay terms, I think that the common
> misunderstanding here is that use of an accessibility API equals
> accessibility. Just because there is an accessibility API does not
mean
> that every piece of AT automatically works all of the time - it just
> increases the odds of existing AT working with new products. But,
> sometimes new technologies come with new features. If the AT did not
> take into account those new features or capabilities, support for
those
> features still needs to be built in. An accessibility API makes it
> easier to build in support for those features, and makes it less
> burdensome for the AT vendors to do so (and means supporting those
> features should be more standardized), but it is not always automatic.
> Also, as I understand it, just because a company uses the
accessibility
> API does not mean it implements the API in exactly the same way as
> another company, thus, it is possible a piece of AT may not work
> perfectly with one product that uses the accessibility API but may
work
> perfectly with another, and thus it may not be fully compatible with
> every product. So, the verdict is that an accessibility API could be
> useful, could improve things, but does not mean that compliance with
the
> API will equal access.
>
> Another problem is that adopting an accessibility API that is the
"gold
> standard" today may quickly be old and out of date in 6 months or a
> year.
> While we are in danger of this for many aspects of 508, it is
> particularly worrisome for how AT interfaces with IT, because it could
> stifle the growth and expansion of new AT, particularly if the
> accessibility API becomes the excuse or justification . . . "well, we
> used the accessibility API, we don't have to be compatible with ACTUAL
> AT." At some point not too far off, because the API won't be able to
> grow and evolve once put into regulation, what started off as a means
to
> improve accessibility could actually become the one bar to providing
> real access.
>
> Jessica Brodey
>
> -----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'
> Subject: Re: [teitac-websoftware] Startingdiscussionson
theAccessibility
> APIproposal
>
> Your concerns are justified, but you have the concepts backwards.
> Thinking in terms of an accessibility value chain guarantees that we
are
> thinking of all the steps required to give the end user access.
> Separating the regs by narrow targets, one product or industry at a
> time, ignores the need for both technical and informational
> interoperation.
>
> There is no getting around the problem of assigning responsibilities
to
> the "proper"
> parties. Luckily 508 burdens the purchaser, who has the best view of
> the entire chain, from OEM-type product to developed product to
> installed product to user and administrator. In theory. The problem
> remains one of information flow rather than raw technological power,
as
> your example indicates -- Gregorian did not work closely enough with
the
> AT community.
>
> But that raises another troubling point: why is the Accessibility API
> not sufficient? If Gregorian builds its software correctly, why is
> additional action required by AT vendors?
> If Gregorian cannot sell to the feds until one or more AT vendors acts
> to make the new product accessible, isn't that an imbalance of market
> power? I thought the whole idea of the Accessibility API was to
> eliminate that problem.
>
> Maybe I'm misunderstanding something....
>
>
>
>> -----Original Message-----
>> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Thursday, January 04, 2007 1:52 AM
>> To: 'TEITAC Web/Software Subcommittee'
>> Subject: Re: [teitac-websoftware] Starting discussionson
>> theAccessibility APIproposal
>>
>> Why value chain is good concept - but we need to be very careful
about
>>
>
>
>> its use in regulatory standards.
>>
>> I really like the accessibility value chain concept as a way to
>> understand this - and to point out the way things work together.
>>
>> But I worry about it in a discussion of how to structure our
>> standards. And I don't think we should structure our standards
around
>>
>
>
>> it. If we did then we would only require that software companies
>> "enable" there software to be accessible - but they would have no
>> responsibility to actually make sure that there was AT that did work
>> with their software and did make it
>> accessible. The result is that in fact it would be "meet
>> accessibility
>> standard" but be unusable by anyone with a disability.
>>
>> Take the following example.
>>
>>
>> The Gregorian Software company creates a marvelous new media
>> technology. It is new, different and extremely compelling web
>> software for shopping and transactions using a simulated person and
>> live environment over narrow
>> bandwidth. They implement it with an accessibility API but
>> no one uses the
>> technology (of course) til its release in Sept 2007. At its
>> announcement it
>> is adopted by Amazon, a slew of banks, etc. AT vendors
>> begin working with
>> it but it will be a year or more before they can get up to speed
(sort
>>
>
>
>> of like when dos went to windows) but this technology spreads at
>> Internet speed because it is free downloadable plug in for most
users.
>>
>> Suddenly these sites go black to AT users. But if we write out
>> guidelines such that the sites and the Gregorian software company can

>> say their software meets access standards, without actually requiring

>> them to be supported by real live AT that is out there - and
available
>>
>
>
>> to users.
>>
>> In fact AT vendors will remember the days before we required software

>> to
>> actually work with real AT. Software would come out with
>> an accessibility
>> API but AT vendors were not able get access to it and had very poor
>> support
>> from software vendors even after release. Only when the
>> software was
>> required to actually work with real AT did the vendors invite and
>> support and even court AT vendors in the same way they invited,
>> supported and courted other software and hardware vendors (for
>> compatibility) when they released something new.
>>
>> So I think the "accessibility value chain" is a very important
>> concept. But I don't think we should base our standards on it.
>>
>> I think that something is accessible if it can be used by real people

>> who have disabilities, not just that it theoretically could be if
only
>>
>
>
>> those other people had done their job.
>>
>> Accessible - means that it can be used by people with disabilities.
>> That means it is either directly accessible. Or that it is
accessible
>>
>
>
>> using the AT that the person with a disability has or can reasonably
>> get (or in the case of the government - for its employees - AT they
>> are given). For public websites, it would be the AT that the public
>> at large has, can reasonably get, or is given.
>>
>> Any other definition of accessibility defeats the purpose the
>> legislators laid out in creating 508. that is that people with
>> disabilities could actually use the E&IT in the government alongside
>> everyone else - and when it was purchased (not sometime in the future

>> - if someone else does their job).
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On
>>>
>> Behalf Of Jim
>>
>>> Tobias
>>> Sent: Wednesday, January 03, 2007 9:35 AM
>>> To: 'TEITAC Web/Software Subcommittee'
>>> Subject: Re: [teitac-websoftware] Starting discussions on
>>> theAccessibility APIproposal
>>>
>>> Sean Hayes wrote:
>>>
>>> "Firstly I agree that there is a problem that needs
>>>
>> adressing here,
>>
>>> which is the equitable division of reponsibility on accessibility
>>> between each entity involved in delivering a software product.
>>> However, as we are all aware, this is very difficult problem given
>>> the manner in which modern software is produced, which in most
>>> significant products involves cooperation across multiple
>>> organisations, not only the software product developer, but OS
>>> vendors, hardware vendors, AT vendors and middleware vendors among
>>> others. In some cases standards or industry practice
>>>
>> already exists
>>
>>> around these interfaces, and in some cases it doesn't."
>>>
>>> I would like to take this opportunity to develop a little
>>>
>> further the
>>
>>> concept of an "accessibility value chain", which Sean refers to
>>> indirectly. I believe that clarifying these responsibilities is at
>>> the heart of "modern" accessibility, because, as Sean notes, modern
>>> software requires cooperation across multiple
>>>
>> organizations, many of
>>
>>> whom have only indirect relationships.
>>>
>>> I would like to posit that the nature of this technical cooperation
>>> has three distinct elements or phases:
>>> capability, implementation, and preservation.
>>> By
>>> "capability" I mean that the software component contains all the
>>> features necessary for accessible use or development.
>>> Examples are the ability to add a text description to an image in a
>>> web development tool, and the ability to record and play
>>>
>> back Baudot
>>
>>> files in a voice mail platform. By "implementation" I mean
>>>
>> that the
>>
>>> capability has actually been used by the next link in the
>>>
>> chain. That
>>
>>> is, the web developer has actually added a text description to an
>>> image, and the telecom manager has actually set up a voice
>>>
>> mailbox so
>>
>>> a Baudot TTY user can receive messages. By "preservation"
>>> I mean that
>>> the next link in the chain is required not to interfere with the
>>> accessibility feature already in place further up the chain. For
>>> example, a digital cable system must not strip the captioning
>>> information from a captioned video program during transmission.
>>>
>>> Most of the relationships in the chain are
>>>
>> capability-implementation
>>
>>> ones, especially for web and software. Thus the current
>>>
>> 508 requires
>>
>>> software to inherit system display settings, use standard OS text
>>> presentation techniques, etc.
>>>
>>> I think this formulation may clarify for us where we want
>>>
>> to go. For
>>
>>> example, we have mentioned adding OS requirements.
>>> That is, current 508 requires "downlink" software to honor OS
>>> accessibility features, but it doesn't require OSs to have those
>>> features. I think we may agree on adding such a requirement,
>>> especially if we use today's common OSs as models rather
>>>
>> than dreaming
>>
>>> up new features OSs don't have yet.
>>>
>>> Another point that may meet more resistance, but seems
>>>
>> clear to me, is
>>
>>> the utter inseperability of content from software once we
>>>
>> agree that
>>
>>> there is an interlocking set of relationships in the web/software
>>> arena. In the examples of the web page and voice mail
>>>
>> system I used
>>
>>> above, how can the tools be abstracted from the content?
>>>
>> My thinking
>>
>>> here is not very well developed, so I look forward to a dialogue.
>>>
>>>

From: Robinson, Norman B - Washington, DC
Date: Sun, Jan 07 2007 8:15 PM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Greetings,

I think that Debbie Cook has hit a critical part of the problem
we have with assistive technologies.

Testing with assistive technology has been a cornerstone of
usability testing many of the Section 508 technical standards.
Sometimes, agencies even specify and rely on a specific vendor's
implementation to determine accessibility for their agency, tied closely
to how they interpret Section 508 compliance. I can imagine this is
confusing to some vendors when they think they have satisfied one
agencies specific requirement, can demonstrate a particular product
(electronic information & technology; E&IT) works with a specific
assistive technology, and yet they might not be strictly following the
Section 508 standards, thus not considered compliant by other agencies
that rely on a different vendor's assistive technology or that judge the
solution based on strict technical compliance, no matter what can be
demonstrated with assistive technologies.

We must somehow get the assistive technology vendors to use
specifications they can rely on and then we must insist their products
meet these standards. This will require validation and also require
vendors to test they can provide access against known standards (e.g.,
test a screen reader against all ACID2 test cases
(http://en.wikipeidia.org/wiki/Acid2).

This is also tied to the valid code or validation issue. We need
a way in which the vendor can test their implementation against a
standard and therefore be reasonably assured their product will work
when it encounters different content. The problem for us is that the
vendors do such a good job of providing access, they build software that
works around the specific deficiencies of another vendors product. They
build custom scripts and the end-user simply experiences a wonderful
product that provides access. I'm not against access, but when this
approach is taken we will always encounter the inherent problems of
tying a product to a specific implementation version that isn't a
standard. We will have to upgrade to the latest version of the assistive
technology. We will have limited choices of assistive technology.

The concepts expressed in 1194.5, Equivalent Facilitation also
makes it imperative that we consider the specific programming techniques
and standards (application programming interface or APIs). So your
content works with your screen reader. Consider what happens if tomorrow
an updated version of a PDF reader that everyone uses includes its own
screen reader. Lets pretend it doesn't work with my screen reader. I
think it is accessible because I can demonstrate accessibility - but
you'll have to use my own reader. And I don't support your other
operating system. And I require admin rights to install. And you must
get a encrypted key to use the product - for free of course - so I can
ensure digital rights management. Now consider what happens if each and
every office application on our computer's desktop does the same thing.
This works for web browsers too! Need I go on?

I think it may be appropriate to make specific well known API or
toolkit _recommendations_ a part of the Section 508 refresh. I think it
is fair to state since the Section 508 Technical Standards are just
that, we make recommendations such as contracting agencies should
consider requiring E&IT validation against known standards. Section
508v2 should clearly state contracting vehicles should request "standard
compliant content" somewhere. It isn't as if specifying Microsoft Active
Accessibility (MSAA;
http://en.wikipedia.org/wiki/Microsoft_Active_Accessibility) version 2.0
as a minimum for developing MS Windows software will harm accessibility
on a MS Windows platform! (What we do when MSAA is to be discontinued or
the MS Windows APIs themselves change is another matter I won't address
here.) We need the same for web content.

I know this issue is debated by many reasonable people, however
just because we can have accessible content that doesn't meet the
validation, people dismiss the idea we should require validation.
Validation works when it can be tested. I've advocated the Section 508
provisions for web content and Internet applications are simply a subset
of the software standards. Well, for most of the software standards the
actual programming languages themselves have very strict requirements
for building applications - the API - that aren't simply something you
test against but you must use or else your application won't compile and
won't run! Coding purest will see my crude description for what it is,
the important part is I'm speaking about compiled programming languages
(http://en.wikipedia.org/wiki/Compiled_language). Summary: the process
requires correct _valid_ code. The process which is used to build the
software _validates_ the code before it ever can be used by the
end-user.

In web content and Intranet applications use document markup
languages. Vendors build content but don't necessarily validate the
implementations. A short list of known standards for web content are
XHTML 1.0 Strict, CSS 2.0, and SVG 1.1. We should require this as a
recommendation for all web content in the refresh. (XTML 1.0 is from
2000 - 6 years ago!) And beyond that specific reference in the refresh,
we need to push the vendors to test their assistive technology against
the test cases (e.g., ACID2 tests for HTML and CSS).

Sorry for such a long post. There are many related issues with
API issues that perhaps belong in the software discussion, but are
related to web (as the web browser is, in fact, software!) and important
when web applications are being created without the strict requirements
of compiled code or validation. For applications on the desktop, there
are probably a list of resources we could develop for each and every
operating system (I use AmigaOS, Linux, OSX, Solaris every now and then,
and MS Windows - there is more than just MS Windows users that need
access!). Should we do this as part of the refresh? Is it appropriate?

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 Debbie
Cook
Sent: Friday, January 05, 2007 12:27 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal


One of the fundamental problems we currently have is that because AT has
no
requirement to comply with any standards in order to work with IT, the
It
may complay nd not work with any AT. So, just as IT companies go beyond
the
minimum to compete so should AT. And frankly, while it's reasonable to
debate the merits of any components of a standard API, I think it's
highly
desireable as a baseline for both AT and IT in terms of
interoperability.
What now happens is that a given IT product is compatible with one AT
and
not another. It is all too common that the bottom line for our IT
procuremens is that they must work with X or Y AT. That's not good for
the
consumer or for the smaller AT vendor.
----- Original Message -----
From: "Eric Damery" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee"
< = EMAIL ADDRESS REMOVED = >
Sent: Thursday, January 04, 2007 1:46 PM
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal


Jessica,

Very well said.

Just to follow up on this line of thought, another concern when making
the API the "gold standard" should be what the incentive will be for AT
to do anything beyond the API, if it becomes the measurement for
procurement. As I understand it, a limited API could make it easier to
swallow for I T but at the same time, stifle smaller AT companies from
being able to help achieve access for users if it requires anything
beyond it. I suspect the same will be true for AT designed in at the
system level.

Regards,
Eric Damery

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Thursday, January 04, 2007 4:21 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Jim:

Speaking as a policy wonk in lay terms, I think that the common
misunderstanding here is that use of an accessibility API equals
accessibility. Just because there is an accessibility API does not mean
that every piece of AT automatically works all of the time - it just
increases the odds of existing AT working with new products. But,
sometimes new technologies come with new features. If the AT did not
take into account those new features or capabilities, support for those
features still needs to be built in. An accessibility API makes it
easier to build in support for those features, and makes it less
burdensome for the AT vendors to do so (and means supporting those
features should be more standardized), but it is not always automatic.
Also, as I understand it, just because a company uses the accessibility
API does not mean it implements the API in exactly the same way as
another company, thus, it is possible a piece of AT may not work
perfectly with one product that uses the accessibility API but may work
perfectly with another, and thus it may not be fully compatible with
every product. So, the verdict is that an accessibility API could be
useful, could improve things, but does not mean that compliance with the
API will equal access.

Another problem is that adopting an accessibility API that is the "gold
standard" today may quickly be old and out of date in 6 months or a
year.
While we are in danger of this for many aspects of 508, it is
particularly worrisome for how AT interfaces with IT, because it could
stifle the growth and expansion of new AT, particularly if the
accessibility API becomes the excuse or justification . . . "well, we
used the accessibility API, we don't have to be compatible with ACTUAL
AT." At some point not too far off, because the API won't be able to
grow and evolve once put into regulation, what started off as a means to
improve accessibility could actually become the one bar to providing
real access.

Jessica Brodey

-----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'
Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
APIproposal

Your concerns are justified, but you have the concepts backwards.
Thinking in terms of an accessibility value chain guarantees that we are
thinking of all the steps required to give the end user access.
Separating the regs by narrow targets, one product or industry at a
time, ignores the need for both technical and informational
interoperation.

There is no getting around the problem of assigning responsibilities to
the "proper"
parties. Luckily 508 burdens the purchaser, who has the best view of
the entire chain, from OEM-type product to developed product to
installed product to user and administrator. In theory. The problem
remains one of information flow rather than raw technological power, as
your example indicates -- Gregorian did not work closely enough with the
AT community.

But that raises another troubling point: why is the Accessibility API
not sufficient? If Gregorian builds its software correctly, why is
additional action required by AT vendors?
If Gregorian cannot sell to the feds until one or more AT vendors acts
to make the new product accessible, isn't that an imbalance of market
power? I thought the whole idea of the Accessibility API was to
eliminate that problem.

Maybe I'm misunderstanding something....


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 1:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibility APIproposal
>
> Why value chain is good concept - but we need to be very careful about

> its use in regulatory standards.
>
> I really like the accessibility value chain concept as a way to
> understand this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to structure our
> standards. And I don't think we should structure our standards around

> it. If we did then we would only require that software companies
> "enable" there software to be accessible - but they would have no
> responsibility to actually make sure that there was AT that did work
> with their software and did make it
> accessible. The result is that in fact it would be "meet
> accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new media
> technology. It is new, different and extremely compelling web
> software for shopping and transactions using a simulated person and
> live environment over narrow
> bandwidth. They implement it with an accessibility API but
> no one uses the
> technology (of course) til its release in Sept 2007. At its
> announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get up to speed (sort

> of like when dos went to windows) but this technology spreads at
> Internet speed because it is free downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we write out
> guidelines such that the sites and the Gregorian software company can
> say their software meets access standards, without actually requiring
> them to be supported by real live AT that is out there - and available

> to users.
>
> In fact AT vendors will remember the days before we required software
> to
> actually work with real AT. Software would come out with
> an accessibility
> API but AT vendors were not able get access to it and had very poor
> support
> from software vendors even after release. Only when the
> software was
> required to actually work with real AT did the vendors invite and
> support and even court AT vendors in the same way they invited,
> supported and courted other software and hardware vendors (for
> compatibility) when they released something new.
>
> So I think the "accessibility value chain" is a very important
> concept. But I don't think we should base our standards on it.
>
> I think that something is accessible if it can be used by real people
> who have disabilities, not just that it theoretically could be if only

> those other people had done their job.
>
> Accessible - means that it can be used by people with disabilities.
> That means it is either directly accessible. Or that it is accessible

> using the AT that the person with a disability has or can reasonably
> get (or in the case of the government - for its employees - AT they
> are given). For public websites, it would be the AT that the public
> at large has, can reasonably get, or is given.
>
> Any other definition of accessibility defeats the purpose the
> legislators laid out in creating 508. that is that people with
> disabilities could actually use the E&IT in the government alongside
> everyone else - and when it was purchased (not sometime in the future
> - if someone else does their job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting discussions on
> > theAccessibility APIproposal
> >
> > Sean Hayes wrote:
> >
> > "Firstly I agree that there is a problem that needs
> adressing here,
> > which is the equitable division of reponsibility on accessibility
> > between each entity involved in delivering a software product.
> > However, as we are all aware, this is very difficult problem given
> > the manner in which modern software is produced, which in most
> > significant products involves cooperation across multiple
> > organisations, not only the software product developer, but OS
> > vendors, hardware vendors, AT vendors and middleware vendors among
> > others. In some cases standards or industry practice
> already exists
> > around these interfaces, and in some cases it doesn't."
> >
> > I would like to take this opportunity to develop a little
> further the
> > concept of an "accessibility value chain", which Sean refers to
> > indirectly. I believe that clarifying these responsibilities is at
> > the heart of "modern" accessibility, because, as Sean notes, modern
> > software requires cooperation across multiple
> organizations, many of
> > whom have only indirect relationships.
> >
> > I would like to posit that the nature of this technical cooperation
> > has three distinct elements or phases:
> > capability, implementation, and preservation.
> > By
> > "capability" I mean that the software component contains all the
> > features necessary for accessible use or development.
> > Examples are the ability to add a text description to an image in a
> > web development tool, and the ability to record and play
> back Baudot
> > files in a voice mail platform. By "implementation" I mean
> that the
> > capability has actually been used by the next link in the
> chain. That
> > is, the web developer has actually added a text description to an
> > image, and the telecom manager has actually set up a voice
> mailbox so
> > a Baudot TTY user can receive messages. By "preservation"
> > I mean that
> > the next link in the chain is required not to interfere with the
> > accessibility feature already in place further up the chain. For
> > example, a digital cable system must not strip the captioning
> > information from a captioned video program during transmission.
> >
> > Most of the relationships in the chain are
> capability-implementation
> > ones, especially for web and software. Thus the current
> 508 requires
> > software to inherit system display settings, use standard OS text
> > presentation techniques, etc.
> >
> > I think this formulation may clarify for us where we want
> to go. For
> > example, we have mentioned adding OS requirements.
> > That is, current 508 requires "downlink" software to honor OS
> > accessibility features, but it doesn't require OSs to have those
> > features. I think we may agree on adding such a requirement,
> > especially if we use today's common OSs as models rather
> than dreaming
> > up new features OSs don't have yet.
> >
> > Another point that may meet more resistance, but seems
> clear to me, is
> > the utter inseperability of content from software once we
> agree that
> > there is an interlocking set of relationships in the web/software
> > arena. In the examples of the web page and voice mail
> system I used
> > above, how can the tools be abstracted from the content?
> My thinking
> > here is not very well developed, so I look forward to a dialogue.
> >
> >

From: Lybarger, Barbara (MOD)
Date: Sun, Jan 07 2007 8:45 PM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

On the topic at hand and assuming for a moment that agreement on doing a
standard API approach could be reached, I see three issues in the
discussion so far that if taken one by one might be resolvable.
1. The issue of the cost of moving to a new standard could be dealt with
in a variety of ways. The first thing that comes to mind is a longer
phase in for the AT vendors to conform their products to the new API
requirements.
2. The new product that go beyond the API could be dealt with through
the notion of equivalency Peter Korn has been talking about, or by later
updates to the standards.
3. That the API is only part of the accessibility picture could be dealt
with by saying so with sufficient clarity and detail that everyone
involved in the process has a reasonable chance to "get it."

Ending with a general observation -- It is a real pleasure participating
in this discussion. The level of analysis and cooperation to solve this
multileveled puzzle is amazing. The time stamps alone on a lot of these
emails demonstrates that the work is going well beyond the standard 9 to
5. It demonstrates a commitment to the success of this project that
goes way beyond the run of the mill. That commitment to the public good
is something I admire.

Barbara Lybarger


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Friday, January 05, 2007 12:38 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Debbie Cook said: "One of the fundamental problems we currently have is
that because AT has no requirement to comply with any standards in order
to work with IT, the It may complay nd not work with any AT. So, just
as IT companies go beyond the minimum to compete so should AT. And
frankly, while it's reasonable to debate the merits of any components of
a standard API, I think it's highly desireable as a baseline for both AT
and IT in terms of interoperability. What now happens is that a given IT
product is compatible with one AT and not another. It is all too common
that the bottom line for our IT procuremens is that they must work with
X or Y AT. That's not good for the consumer or for the smaller AT
vendor."

This is certainly true. The problem is, that for so many years, AT
companies have been forced to be inventive and create "work-arounds" in
order to provide access because there has not been a standard
accessibility API. We wholeheartedly agree that future IT and AT should
be built on an accessibility API to the extent feasible, that it will
improve interoperability, and would probably cut back significantly on
development costs for AT, in most cases. However, we do not want to
force existing AT companies out of business just because they do not
have the money to revamp their technologies and utilize an accessibility
API when one did not exist before, nor do we want to tell a company it
cannot develop AT if the accessibility API is inadequate to meet the
needs of the AT it is trying to develop, nor do we want to say that
merely implementing an accessibility API alone is a sufficient proxy for
accessibility.

Jessica

----- Original Message -----
From: "Eric Damery" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee"
< = EMAIL ADDRESS REMOVED = >
Sent: Thursday, January 04, 2007 1:46 PM
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal


Jessica,

Very well said.

Just to follow up on this line of thought, another concern when making
the API the "gold standard" should be what the incentive will be for AT
to do anything beyond the API, if it becomes the measurement for
procurement. As I understand it, a limited API could make it easier to
swallow for I T but at the same time, stifle smaller AT companies from
being able to help achieve access for users if it requires anything
beyond it. I suspect the same will be true for AT designed in at the
system level.

Regards,
Eric Damery

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jessica
M. Brodey
Sent: Thursday, January 04, 2007 4:21 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Jim:

Speaking as a policy wonk in lay terms, I think that the common
misunderstanding here is that use of an accessibility API equals
accessibility. Just because there is an accessibility API does not mean
that every piece of AT automatically works all of the time - it just
increases the odds of existing AT working with new products. But,
sometimes new technologies come with new features. If the AT did not
take into account those new features or capabilities, support for those
features still needs to be built in. An accessibility API makes it
easier to build in support for those features, and makes it less
burdensome for the AT vendors to do so (and means supporting those
features should be more standardized), but it is not always automatic.
Also, as I understand it, just because a company uses the accessibility
API does not mean it implements the API in exactly the same way as
another company, thus, it is possible a piece of AT may not work
perfectly with one product that uses the accessibility API but may work
perfectly with another, and thus it may not be fully compatible with
every product. So, the verdict is that an accessibility API could be
useful, could improve things, but does not mean that compliance with the
API will equal access.

Another problem is that adopting an accessibility API that is the "gold
standard" today may quickly be old and out of date in 6 months or a
year.
While we are in danger of this for many aspects of 508, it is
particularly worrisome for how AT interfaces with IT, because it could
stifle the growth and expansion of new AT, particularly if the
accessibility API becomes the excuse or justification . . . "well, we
used the accessibility API, we don't have to be compatible with ACTUAL
AT." At some point not too far off, because the API won't be able to
grow and evolve once put into regulation, what started off as a means to
improve accessibility could actually become the one bar to providing
real access.

Jessica Brodey

-----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'
Subject: Re: [teitac-websoftware] Startingdiscussionson theAccessibility
APIproposal

Your concerns are justified, but you have the concepts backwards.
Thinking in terms of an accessibility value chain guarantees that we are
thinking of all the steps required to give the end user access.
Separating the regs by narrow targets, one product or industry at a
time, ignores the need for both technical and informational
interoperation.

There is no getting around the problem of assigning responsibilities to
the "proper"
parties. Luckily 508 burdens the purchaser, who has the best view of
the entire chain, from OEM-type product to developed product to
installed product to user and administrator. In theory. The problem
remains one of information flow rather than raw technological power, as
your example indicates -- Gregorian did not work closely enough with the
AT community.

But that raises another troubling point: why is the Accessibility API
not sufficient? If Gregorian builds its software correctly, why is
additional action required by AT vendors?
If Gregorian cannot sell to the feds until one or more AT vendors acts
to make the new product accessible, isn't that an imbalance of market
power? I thought the whole idea of the Accessibility API was to
eliminate that problem.

Maybe I'm misunderstanding something....


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, January 04, 2007 1:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibility APIproposal
>
> Why value chain is good concept - but we need to be very careful about

> its use in regulatory standards.
>
> I really like the accessibility value chain concept as a way to
> understand this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to structure our
> standards. And I don't think we should structure our standards around

> it. If we did then we would only require that software companies
> "enable" there software to be accessible - but they would have no
> responsibility to actually make sure that there was AT that did work
> with their software and did make it
> accessible. The result is that in fact it would be "meet
> accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new media
> technology. It is new, different and extremely compelling web
> software for shopping and transactions using a simulated person and
> live environment over narrow
> bandwidth. They implement it with an accessibility API but
> no one uses the
> technology (of course) til its release in Sept 2007. At its
> announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get up to speed (sort

> of like when dos went to windows) but this technology spreads at
> Internet speed because it is free downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we write out
> guidelines such that the sites and the Gregorian software company can
> say their software meets access standards, without actually requiring
> them to be supported by real live AT that is out there - and available

> to users.
>
> In fact AT vendors will remember the days before we required software
> to
> actually work with real AT. Software would come out with
> an accessibility
> API but AT vendors were not able get access to it and had very poor
> support
> from software vendors even after release. Only when the
> software was
> required to actually work with real AT did the vendors invite and
> support and even court AT vendors in the same way they invited,
> supported and courted other software and hardware vendors (for
> compatibility) when they released something new.
>
> So I think the "accessibility value chain" is a very important
> concept. But I don't think we should base our standards on it.
>
> I think that something is accessible if it can be used by real people
> who have disabilities, not just that it theoretically could be if only

> those other people had done their job.
>
> Accessible - means that it can be used by people with disabilities.
> That means it is either directly accessible. Or that it is accessible

> using the AT that the person with a disability has or can reasonably
> get (or in the case of the government - for its employees - AT they
> are given). For public websites, it would be the AT that the public
> at large has, can reasonably get, or is given.
>
> Any other definition of accessibility defeats the purpose the
> legislators laid out in creating 508. that is that people with
> disabilities could actually use the E&IT in the government alongside
> everyone else - and when it was purchased (not sometime in the future
> - if someone else does their job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting discussions on
> > theAccessibility APIproposal
> >
> > Sean Hayes wrote:
> >
> > "Firstly I agree that there is a problem that needs
> adressing here,
> > which is the equitable division of reponsibility on accessibility
> > between each entity involved in delivering a software product.
> > However, as we are all aware, this is very difficult problem given
> > the manner in which modern software is produced, which in most
> > significant products involves cooperation across multiple
> > organisations, not only the software product developer, but OS
> > vendors, hardware vendors, AT vendors and middleware vendors among
> > others. In some cases standards or industry practice
> already exists
> > around these interfaces, and in some cases it doesn't."
> >
> > I would like to take this opportunity to develop a little
> further the
> > concept of an "accessibility value chain", which Sean refers to
> > indirectly. I believe that clarifying these responsibilities is at
> > the heart of "modern" accessibility, because, as Sean notes, modern
> > software requires cooperation across multiple
> organizations, many of
> > whom have only indirect relationships.
> >
> > I would like to posit that the nature of this technical cooperation
> > has three distinct elements or phases:
> > capability, implementation, and preservation.
> > By
> > "capability" I mean that the software component contains all the
> > features necessary for accessible use or development.
> > Examples are the ability to add a text description to an image in a
> > web development tool, and the ability to record and play
> back Baudot
> > files in a voice mail platform. By "implementation" I mean
> that the
> > capability has actually been used by the next link in the
> chain. That
> > is, the web developer has actually added a text description to an
> > image, and the telecom manager has actually set up a voice
> mailbox so
> > a Baudot TTY user can receive messages. By "preservation"
> > I mean that
> > the next link in the chain is required not to interfere with the
> > accessibility feature already in place further up the chain. For
> > example, a digital cable system must not strip the captioning
> > information from a captioned video program during transmission.
> >
> > Most of the relationships in the chain are
> capability-implementation
> > ones, especially for web and software. Thus the current
> 508 requires
> > software to inherit system display settings, use standard OS text
> > presentation techniques, etc.
> >
> > I think this formulation may clarify for us where we want
> to go. For
> > example, we have mentioned adding OS requirements.
> > That is, current 508 requires "downlink" software to honor OS
> > accessibility features, but it doesn't require OSs to have those
> > features. I think we may agree on adding such a requirement,
> > especially if we use today's common OSs as models rather
> than dreaming
> > up new features OSs don't have yet.
> >
> > Another point that may meet more resistance, but seems
> clear to me, is
> > the utter inseperability of content from software once we
> agree that
> > there is an interlocking set of relationships in the web/software
> > arena. In the examples of the web page and voice mail
> system I used
> > above, how can the tools be abstracted from the content?
> My thinking
> > here is not very well developed, so I look forward to a dialogue.
> >
> >

From: Peter Korn
Date: Mon, Jan 08 2007 12:40 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Hi Norm,

I think the discussion we are now all having about API-based
accessibility is really great. I have only one, small
comment/correction to make to your message:

> ...
> - there are many developer toolkits or frameworks but do
> they all use the native API? (Java Access Bridge uses MSAA doesn't it?
> Qt?)
>

The Java Access Bridge does not use MSAA. When we began development of
the bridge, we spoke at length with Windows AT vendors and discovered
that most used MSAA differently for each app they provided access to
(MSAA implementation wasn't uniform, different apps overloaded the
various API calls differently in order to convey information that MSAA
wasn't really designed to convey, and AT vendors already had mature
reverse-engineering techniques for much of the information MSAA provided
so they continued to use those techniques for many apps). Also, because
the Java Foundation Classes use Direct Draw on Windows for rendering
text (bypassing GDI and the display driver text calls), we needed an API
that would provide rich text information - something MSAA didn't do.

We considered using MSAA for the stuff that MSAA provided, and then a
supplemental API for what MSAA didn't provide but which we needed. But
in the end (and given that it was no more work at the time for Windows
AT vendors to support a new API for Java), we just rolled our own.


It is interesting to note that IAccessible2 is essentially the first
option we considered - using MSAA for what MSAA does and then
supplementing it with what MSAA doesn't do (with a supplement that looks
*remarkably* like the Java Accessibility API).


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Hoffman, Allen
Date: Mon, Jan 08 2007 6:45 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

I suppose this is late in the game now, but I think a good step by step
presentation on the accessibility stack would be helpful for many of us
in the software/web group. How does MSAA or UI, accessibility-API, etc
all fit together currently, and where these interlocking layers of
accessibility may be going might be helpful.

Would anyone like to set up a 2 or 3 member group to pull together
something like this for a future meeting?

I have names I'd like to hear but won't nominate anyone as I don't know
your time constraints.

I think topics that include:

What accessibility API(s) do;
What accessibility API(s) are available generally now?
How AT(s) use the API(s)
How AT(s) are using the API(s) now generally
Where the DOM fits into the accessibility chain;
Where are accessibility API(s) and associate AT(s) missing

A clear overview of this, even though many of us do know this stuff,
might be well worth the effort to pull it together.




Allen Hoffman -- 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: Monday, January 08, 2007 2:36 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Hi Norm,

I think the discussion we are now all having about API-based
accessibility is really great. I have only one, small
comment/correction to make to your message:

> ...
> - there are many developer toolkits or frameworks but do
they all
> use the native API? (Java Access Bridge uses MSAA doesn't it?
> Qt?)
>

The Java Access Bridge does not use MSAA. When we began development of
the bridge, we spoke at length with Windows AT vendors and discovered
that most used MSAA differently for each app they provided access to
(MSAA implementation wasn't uniform, different apps overloaded the
various API calls differently in order to convey information that MSAA
wasn't really designed to convey, and AT vendors already had mature
reverse-engineering techniques for much of the information MSAA provided
so they continued to use those techniques for many apps). Also, because
the Java Foundation Classes use Direct Draw on Windows for rendering
text (bypassing GDI and the display driver text calls), we needed an API
that would provide rich text information - something MSAA didn't do.

We considered using MSAA for the stuff that MSAA provided, and then a
supplemental API for what MSAA didn't provide but which we needed. But
in the end (and given that it was no more work at the time for Windows
AT vendors to support a new API for Java), we just rolled our own.


It is interesting to note that IAccessible2 is essentially the first
option we considered - using MSAA for what MSAA does and then
supplementing it with what MSAA doesn't do (with a supplement that looks
*remarkably* like the Java Accessibility API).


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Jim Tobias
Date: Mon, Jan 08 2007 7:00 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Allen wrote:

"I suppose this is late in the game now, but I think a good
step by step presentation on the accessibility stack would be
helpful for many of us in the software/web group. How does
MSAA or UI, accessibility-API, etc all fit together
currently, and where these interlocking layers of
accessibility may be going might be helpful. Would
anyone like to set up a 2 or 3 member group to pull
together something like this for a future meeting?"

We have a burgeoning list of topics for presentation at TEITAC
plenaries, all of which are worthy. But I'm wondering if, given the
scarcity and infrequency of face-to-face, it wouldn't be better
to create an archivable webcast instead. That way, immediately
interested attendees could participate and others would have a
rich resource for future reference.

From: Lazzaro, Joe (ITD)
Date: Mon, Jan 08 2007 8:35 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Just spoke with Larry, and he's ok.

Joe



Joe Lazzaro
Manager: Assistive Technology Group
Information Technology Division
Commonwealth of Massachusetts
One Ashburton Place
Room 1601
Boston, MA 02108
Voice: 617-626-4410
Email: = EMAIL ADDRESS REMOVED =
Web: www.Mass.gov/ITD


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
Tobias
Sent: Monday, January 08, 2007 9:01 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Allen wrote:

"I suppose this is late in the game now, but I think a good step by
step presentation on the accessibility stack would be helpful for many
of us in the software/web group. How does MSAA or UI,
accessibility-API, etc all fit together currently, and where these
interlocking layers of accessibility may be going might be helpful.
Would anyone like to set up a 2 or 3 member group to pull together
something like this for a future meeting?"

We have a burgeoning list of topics for presentation at TEITAC
plenaries, all of which are worthy. But I'm wondering if, given the
scarcity and infrequency of face-to-face, it wouldn't be better to
create an archivable webcast instead. That way, immediately interested
attendees could participate and others would have a rich resource for
future reference.

From: Robinson, Norman B - Washington, DC
Date: Mon, Jan 08 2007 2:40 PM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

I'll second that Allen (that an accessibility stack
description/model/index would be useful).

I also can't help but comment that the previous versions of MSAA were (I
thought) unencumbered by patent issues. We need something open and
consistent if we ever are to make a suggestion that industry consider
using a specific API.

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
Hoffman, Allen
Sent: Monday, January 08, 2007 8:42 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal


I suppose this is late in the game now, but I think a good step by step
presentation on the accessibility stack would be helpful for many of us
in the software/web group. How does MSAA or UI, accessibility-API, etc
all fit together currently, and where these interlocking layers of
accessibility may be going might be helpful.

Would anyone like to set up a 2 or 3 member group to pull together
something like this for a future meeting?

I have names I'd like to hear but won't nominate anyone as I don't know
your time constraints.

I think topics that include:

What accessibility API(s) do;
What accessibility API(s) are available generally now?
How AT(s) use the API(s)
How AT(s) are using the API(s) now generally
Where the DOM fits into the accessibility chain;
Where are accessibility API(s) and associate AT(s) missing

A clear overview of this, even though many of us do know this stuff,
might be well worth the effort to pull it together.




Allen Hoffman -- 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: Monday, January 08, 2007 2:36 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Hi Norm,

I think the discussion we are now all having about API-based
accessibility is really great. I have only one, small
comment/correction to make to your message:

> ...
> - there are many developer toolkits or frameworks but do
they all
> use the native API? (Java Access Bridge uses MSAA doesn't it?
> Qt?)
>

The Java Access Bridge does not use MSAA. When we began development of
the bridge, we spoke at length with Windows AT vendors and discovered
that most used MSAA differently for each app they provided access to
(MSAA implementation wasn't uniform, different apps overloaded the
various API calls differently in order to convey information that MSAA
wasn't really designed to convey, and AT vendors already had mature
reverse-engineering techniques for much of the information MSAA provided
so they continued to use those techniques for many apps). Also, because
the Java Foundation Classes use Direct Draw on Windows for rendering
text (bypassing GDI and the display driver text calls), we needed an API
that would provide rich text information - something MSAA didn't do.

We considered using MSAA for the stuff that MSAA provided, and then a
supplemental API for what MSAA didn't provide but which we needed. But
in the end (and given that it was no more work at the time for Windows
AT vendors to support a new API for Java), we just rolled our own.


It is interesting to note that IAccessible2 is essentially the first
option we considered - using MSAA for what MSAA does and then
supplementing it with what MSAA doesn't do (with a supplement that looks
*remarkably* like the Java Accessibility API).


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Hoffman, Allen
Date: Tue, Jan 09 2007 7:45 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Norman Robinson wrote:
"I'll second that Allen (that an accessibility stack
description/model/index would be useful).

I also can't help but comment that the previous versions of MSAA were (I
thought) unencumbered by patent issues. We need something open and
consistent if we ever are to make a suggestion that industry consider
using a specific API."

I don't think we can say industry *must* use a specific API, but maybe
we can say that OS(s) have a requirement to include such an API and make
it available for use, and then require AT vendors to as possible make
use of available API9s). some of that is already there, but not
directly.

I don't think we can specify the openness of the API or cost factors.



Allen Hoffman -- 202-447-0303
DHS office on Accessible systems & technology

From: Jonathan Avila
Date: Tue, Jan 09 2007 7:55 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

In regards to this API, I think the term may be confusing and turn people
away from it. I believe what you are really talking about is an API
specification or an interface and not an implemented API. However even
this imply specific calling conventions. While I think this might be good I
don't see all of private sector embracing this because it could be to
restrictive. I also have concerned about the availability of such as
interface. For example, take web pages. The user agent would have to
follow this API in order to expose web page content to assistive technology.
AT vendors and web page authors have no control over when companies like
Microsoft release new versions of IE and should not be held hostage when
their application runs on this type of platform. As long as section 508 has
an equivalent facilitation clause companies will continue to use that
instead of this API. In addition, I believe some in the public sector will
worry about this API squashing innovation.

Don't get me wrong, I think an defined interface such as this could really
promote access; I'm just concerned about the backlash something like this
could have.

Jonathan

From: Lazzaro, Joe (ITD)
Date: Tue, Jan 09 2007 9:30 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

It will be a long time before there is one all-encompassing
accessibility API that runs across all platforms. Lambs will lie down
next to the lions when that happens. But we can specify that operating
systems should have accessibility APIs with a specified feature set.
That, I believe, is very doable both technically and politically.

Joe




Joe Lazzaro
Manager: Assistive Technology Group
Commonwealth of Massachusetts
Information Technology Division
One Ashburton Place
Room 1601
Boston, MA 02108
617-626-4410
www.Mass.Gov/ITD


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Hoffman, Allen
Sent: Tuesday, January 09, 2007 9:39 AM
To: TEITAC Web/Software Subcommittee
Cc: Peterson, Bill
Subject: Re: [teitac-websoftware]Startingdiscussionson theAccessibility
APIproposal

Norman Robinson wrote:
"I'll second that Allen (that an accessibility stack
description/model/index would be useful).

I also can't help but comment that the previous versions of MSAA were (I
thought) unencumbered by patent issues. We need something open and
consistent if we ever are to make a suggestion that industry consider
using a specific API."

I don't think we can say industry *must* use a specific API, but maybe
we can say that OS(s) have a requirement to include such an API and make
it available for use, and then require AT vendors to as possible make
use of available API9s). some of that is already there, but not
directly.

I don't think we can specify the openness of the API or cost factors.



Allen Hoffman -- 202-447-0303
DHS office on Accessible systems & technology

From: Jessica M. Brodey
Date: Tue, Jan 09 2007 10:05 AM
Subject: Re: Startingdiscussionson theAccessibility APIproposal

Allen Hoffman said: "I don't think we can say industry *must* use a
specific API, but maybe we can say that OS(s) have a requirement to include
such an API and make it available for use, and then require AT vendors to as
possible make use of available APIs)."

This is an interesting approach, and one that might be workable. We do,
however, have to be careful about specifying that ALL AT vendors must make
use of available APIs at all times - there are instances (particularly when
an API is inadequate to accomplish the end result, or as technology advances
and the APIs have not yet evolved to meet the needs) when the API will not
be usable for an AT vendor because of an end they are trying to accomplish.
We need to be careful that an AT vendor is not forced to use an API in a
circumstance that may not be adequate or appropriate - it should be
encouraged and a first choice to the extent it will be beneficial and
promote innovation, but there are times when that may not be the case.
Remember - AT is often the failsafe when mainstream or built-in access is
insufficient - thinking out of the box, and unconventional methods are often
necessary to reach the end result of actual access.

Jessica

From: Gregg Vanderheiden
Date: Thu, Jan 11 2007 12:50 AM
Subject: Re: Startingdiscussionson theAccessibilityAPIproposal

Good thoughts.

A couple more

- conformance to an API isn't sufficient if there is no AT or the users
can't get or can't use it. For example - conformance to an API for ATM
software will provide no access since they system is closed. So API
conformance.

- I actually don't think APIs should be required (since there are multiple
APIs and we don't want to freeze innovation. Also they aren't sufficient
by themselves.

- where I think APIs come in - is that the existence of APIs can greatly
reduce the work of both AT and IT vendors in making products work together.
But they still have to test them and make sure they work together - even if
they both build to an API. Anyone familiar with standards is also
familiar with plugfests and other similar interoperability events where
people who all built to the same specs get together to test and actually get
the 'compatible' products to work together. They are always highly
instructive - and the winners are people who worked together to get things
to work - and a few luck people. Building to a spec and not testing rarely
works in any industry much less one as complex as IT.

So APIs are indispensable in helping us to move forward. But they don't
guarantee interoperability and therefore access - without actually testing
to make sure things work.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
>From CES



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson, Norman B - Washington, DC
> Sent: Friday, January 05, 2007 3:58 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Startingdiscussionson
> theAccessibilityAPIproposal
>
>
> You'll see me commenting on the need for standards and
> the need for _references_ to current implementations in the
> Section 508 refresh.
> I don't mean that needs to be a part of law, but I do think
> it would help the development community (the ones sitting at
> a vendor's office creating software) if we point them in the
> right direction and inform them of the most common APIs somehow.
>
> I agree the definition of an API doesn't ensure accessibility.
> But if we are going to split hairs on semantics, I'd say you
> aren't compliant if you didn't _USE_ the API <grins>. If we
> have to debate semantics we are focusing on the wrong problem
> or need to rewrite the requirement (if it is clearly
> interpreted badly by most people). So I agree with you that
> vendor use of an API isn't a clear basis for measuring
> Section 508 compliance. I think the functional requirements
> (goals) Section 508 has outlined for determining compliance
> have been successful.
>
> However, do we need to address the issues when vendors
> use many different APIs to achieve accessibility? Does it
> move accessibility forward, make electronic information and
> electronic technology more accessible if we all,
> collectively, use the same APIs? Or is it better to have many
> different vendors implementing their own APIs?
>
> Is the defacto standard for an accessibility API on MS
> Windows MSAA? Is it AT-SPI for Gnome? KDE AT-API for KDE? UA
> for OSX? What about the Qt Accessibility Framework for MS
> Windows; it uses MSAA but has it's own API. I've got acronym
> overload! Perhaps, after looking at these things as the
> toolkits they are, we can agree there is a basic goodness in
> having developers develop to the appropriate API for their
> platform/operating system. Now, how could we, if so
> motivated, actually force/beat/make them use a particular
> API; even if that would be wrong of us? I don't think Section
> 508 would be the place to do that. I think it has to be tied
> to business requirements. Certainly requiring MSAA on the
> Linux platform won't get you anywhere - it doesn't exist!
>
> We approach this in our policy
> (http://www.usps.com/cpim/ftp/hand/as508a/508a_c5.html#508hdr8
> ) and I would say the short version is a prioritized list
> approach: 1. Support native operating system and activated
> accessibility features. 2. Use standard controls for
> particular operating systems where possible. 3. Be careful
> when using custom controls or enhancing standard controls. 4.
> Provide flexibility in using a variety of input methods. 5.
> Query accessibility aids in use by the operating system and
> configure the software applications automatically.
>
> So using a API doesn't equate to access, but we should:
> 1. Support native operating systems accessibility
> (e.g., the APIs for whatever development framework is being
> used should use the operating systems accessibility features
> and not _reinvent_ their own).
> - is there more than one native operating
> system API on any platform? Help point this out!
> 2. If the API provides standard controls (which is
> generally the purpose of a framework or development
> environment?) those standard controls should follow #1.
> - there are many developer toolkits or
> frameworks but do they all use the native API? (Java Access
> Bridge uses MSAA doesn't it?
> Qt?)
> 3. Developers should follow #1, via using standard
> controls (#2).
> 4. Developers should test their products in a variety
> of use-cases that include testing for users that might have a
> disability.
> 5. This is a repeat of #1 actually, as the operating
> system would provide this through a standard interface (#1).
>
> As we have developed our own policy, I can't help but
> think what we need is a central policy document that isn't a
> part of the law but the best practices that have been
> approved as acceptable. We need some agency (the Access
> Board? GSA?) to maintain this and harmonize it with any
> Section 508 updates. It would effectively replace an agencies
> individual policy when the agency didn't invent it.
> Guidelines, not Section 508 technical standards or
> regulations. Guidelines that meet the technical standards but
> can be legally ignored as not _required_.
>
> Wow. I think I just convinced myself that we shouldn't
> have API specifications in the revision at all.
>
> Have a great weekend,
>
>
> 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 Jessica M. Brodey
> Sent: Friday, January 05, 2007 12:17 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware]Startingdiscussionson
> theAccessibility APIproposal
>
>
> Peter:
>
> ATIA agrees that there are already aspects of an
> Accessibility API in 508.
> We are opposed to creating and labeling something an
> "Accessibility API,"
> enumerating it exactly in 508, and thus running the risk that
> companies can say "hey, I used the accessibility API so I am
> 508 compliant" without actual interoperability with AT. We
> want to be clear that while we think moving towards
> incorporating an accessibility API is a good thing, it may
> not be the lone solution to full interoperability, nor does
> an accessibility API alone equate to actual access, and it
> should therefore not be used as the measure for 508
> compliance. We are also not certain that an accessibility
> API expressed as such belongs in 508, which is a regulatory
> standard, as opposed to in an industry standard.
>
> ATIA would rather see enumerations written in broad brush
> strokes, not the specifics that would indicate "use this
> particular accessibility API."
> I
> apologize for not speaking to the specific language and
> sections as I am a policy person, not a techie, but if you
> equate this to the world of the Internet, we do not want to
> structure the regulations in a manner that would say the
> equivalent of "supports Java version x," or even spell out
> all the components or provisions in Java (without actually
> specifying it) that make it obvious which version of Java we
> are pushing to support. We would rather spell out
> characteristics that would allow a company to provide Java
> support in satisfaction of that provision, OR could allow a
> company to go another route and still satisfy the
> requirements of the regulation, or in three years switch to
> Java version x2 without violating the regulation. I
> understand that approach is sometimes frustrating for techies
> who often want it to be spelled out in black in white.
> Unfortunately, it is the same techies who also want the
> flexibility to innovate, and not be hemmed in when the law is
> so specific that it prevents them from diverging. We need to
> find a happy medium here . . . where we can include the
> elements of an accessibility API to get at some of the
> benefits without nailing down such specifics that we are
> locked into only one version of an accessibility API that is
> too rigid and cannot evolve.
>
> We need to focus on the end results - what we want to be able
> to achieve, not the means of getting there. The distinction
> you pointed out, Peter, is that while the descriptions in
> 1194.21(c) may comprise aspects of an accessibility API, it
> does not dictate the nature of the accessibility API - it is
> focused on the result of the access, not the means for
> providing the access. Perhaps we can determine what aspects
> you feel are missing from the existing provisions that are
> critical to an accessibility API, and write them in language
> consistent with 1194.21?
>
> Again . . . we think implementation of an accessibility API
> is a best practice, and perhaps can be used/publicized in
> other aspects of this process as a guide to understanding how
> to comply with the 508 requirements.
>
> Jessica
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Thursday, January 04, 2007 11:38 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware]Startingdiscussionson
> theAccessibility APIproposal
>
> Hi Jessica,
>
> > ATIA's position is that an accessibility API has a role,
> but it is in
> the
> > business venue, or in the standards venue, not the regulatory venue.
> If
> we
> > want to include aspects of the accessibility API into 508, it should
> be as
> > Sean Hayes from Microsoft has advocated. We are concerned about an
> exact
> > and precise list that is finite and unable to evolve without
> reconvening a
> > new panel and a new refresh. We see an accessibility API
> as more of a
> good
> > business practice that is the best way to meet some of the
> specifications
> of 508, but which accessibility API may change and evolve over time.
> >
>
> 508 already includes aspects of an accessibility API. The
> seven provisions enumerated in
> http://teitac.org/wiki/Web_and_Software:_Programmatic_exposure
> _of_inform
> atio
> n
> are existing places where 508 describes the programmatic
> information that IT shall provide to AT. The current
> language doesn't call this portions of an "accessibility
> API", but language like "focus shall be programmatically
> exposed so that assistive technology can track focus and
> focus changes" in 1194.21(c) aren't too far away from that.
>
> And I think ATIA would agree with me that the seven
> provisions in question constitute an insufficient set of
> information from which AT can
>
> accomplish their task. Yet these seven represent "a list
> that is finite
>
> and unable to evolve without reconvening a new panel and a
> new refresh." In fact, it is the very process of refreshing
> these seven provisions that gave rise to the accessibility
> API proposal - a much richer enumeration of things we know
> are needed, and in support of which
>
> the evolving, platform-specific accessibility APIs like UI
> Automation can be used by IT vendors to interopreate with AT.
>
> If ATIA is opposed to a finite list, then what does ATIA
> propose we do with finite list we currently have - the seven
> provisions enumerated above?
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
> > Jessica
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Lybarger,
> > Barbara (MOD)
> > Sent: Thursday, January 04, 2007 6:14 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware]Startingdiscussionson
> theAccessibility
> > APIproposal
> >
> > On this topic, I'm not nearly well enough informed on the content.
> > However, I question Jessica's reasoning, in that no set of
> standards
> > will help if they aren't followed by all the parties, here
> IT, AT and
> > all the players in between, and violators aren't chastised
> in some way
> > fair and reasonable way.
> >
> > At it's core, the API proposal is like the standards for our
> electrical
> > power grids. The government regulates how the power source
> comes out,
> > and all the other parties set up their stuff so all the
> customers can
> > get at the power to run their lights. Most of the parties conform
> > because the alternative is that people can't safely and cost
> effectively
> > share the power. If anyone in the chain doesn't conform with the
> > standard, end users either have dark houses because the light bulbs
> > can't get the power, or they have a very bright house while
> it burns
> > down. Either way the government is looking to punish the one who
> caused
> > the problem.
> >
> > People argued about innovation and standardization when the first
> power
> > grids were set up. Costs, safety and reliability won out over
> > unfettered innovation, but it didn't stifle innovation. Folks are
> still
> > inventing better, safer, cheaper ways of delivering power, and they
> are
> > being used to upgrade the power grid. The bottom line then
> and now is
> > that in a society we have to give up a little freedom to
> make sure we
> > all can get at shared resource cheaply, safely and reliable. The
> > technology equivalent may be this API or something like it. It is
> > needed so all of us can share, and conformance by all is
> essential for
> > it to work.
> >
> > If this API proposal isn't perfect in some ways, what would make it
> > better so everyone would want to follow it? And then, what type of
> > enforcement system is needed so the non-likeminded in society get
> > brought into line?
> >
> > Barbara Lybarger
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Jessica
> > M. Brodey
> > Sent: Thursday, January 04, 2007 4:21 PM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware]Startingdiscussionson
> theAccessibility
> > APIproposal
> >
> > Jim:
> >
> > Speaking as a policy wonk in lay terms, I think that the common
> > misunderstanding here is that use of an accessibility API equals
> > accessibility. Just because there is an accessibility API does not
> mean
> > that every piece of AT automatically works all of the time
> - it just
> > increases the odds of existing AT working with new products. But,
> > sometimes new technologies come with new features. If the
> AT did not
> > take into account those new features or capabilities, support for
> those
> > features still needs to be built in. An accessibility API makes it
> > easier to build in support for those features, and makes it less
> > burdensome for the AT vendors to do so (and means supporting those
> > features should be more standardized), but it is not always
> automatic.
> > Also, as I understand it, just because a company uses the
> accessibility
> > API does not mean it implements the API in exactly the same way as
> > another company, thus, it is possible a piece of AT may not work
> > perfectly with one product that uses the accessibility API but may
> work
> > perfectly with another, and thus it may not be fully
> compatible with
> > every product. So, the verdict is that an accessibility
> API could be
> > useful, could improve things, but does not mean that compliance with
> the
> > API will equal access.
> >
> > Another problem is that adopting an accessibility API that is the
> "gold
> > standard" today may quickly be old and out of date in 6 months or a
> > year.
> > While we are in danger of this for many aspects of 508, it is
> > particularly worrisome for how AT interfaces with IT,
> because it could
> > stifle the growth and expansion of new AT, particularly if the
> > accessibility API becomes the excuse or justification . . .
> "well, we
> > used the accessibility API, we don't have to be compatible
> with ACTUAL
> > AT." At some point not too far off, because the API won't
> be able to
> > grow and evolve once put into regulation, what started off
> as a means
> to
> > improve accessibility could actually become the one bar to
> providing
> > real access.
> >
> > Jessica Brodey
> >
> > -----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'
> > Subject: Re: [teitac-websoftware] Startingdiscussionson
> theAccessibility
> > APIproposal
> >
> > Your concerns are justified, but you have the concepts backwards.
> > Thinking in terms of an accessibility value chain guarantees that we
> are
> > thinking of all the steps required to give the end user access.
> > Separating the regs by narrow targets, one product or industry at a
> > time, ignores the need for both technical and informational
> > interoperation.
> >
> > There is no getting around the problem of assigning responsibilities
> to
> > the "proper"
> > parties. Luckily 508 burdens the purchaser, who has the
> best view of
> > the entire chain, from OEM-type product to developed product to
> > installed product to user and administrator. In theory.
> The problem
> > remains one of information flow rather than raw technological power,
> as
> > your example indicates -- Gregorian did not work closely enough with
> the
> > AT community.
> >
> > But that raises another troubling point: why is the
> Accessibility API
> > not sufficient? If Gregorian builds its software correctly, why is
> > additional action required by AT vendors?
> > If Gregorian cannot sell to the feds until one or more AT
> vendors acts
> > to make the new product accessible, isn't that an imbalance
> of market
> > power? I thought the whole idea of the Accessibility API was to
> > eliminate that problem.
> >
> > Maybe I'm misunderstanding something....
> >
> >
> >
> >> -----Original Message-----
> >> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> >> Sent: Thursday, January 04, 2007 1:52 AM
> >> To: 'TEITAC Web/Software Subcommittee'
> >> Subject: Re: [teitac-websoftware] Starting discussionson
> >> theAccessibility APIproposal
> >>
> >> Why value chain is good concept - but we need to be very careful
> about
> >>
> >
> >
> >> its use in regulatory standards.
> >>
> >> I really like the accessibility value chain concept as a way to
> >> understand this - and to point out the way things work together.
> >>
> >> But I worry about it in a discussion of how to structure our
> >> standards. And I don't think we should structure our standards
> around
> >>
> >
> >
> >> it. If we did then we would only require that software companies
> >> "enable" there software to be accessible - but they would have no
> >> responsibility to actually make sure that there was AT
> that did work
> >> with their software and did make it
> >> accessible. The result is that in fact it would be "meet
> >> accessibility
> >> standard" but be unusable by anyone with a disability.
> >>
> >> Take the following example.
> >>
> >>
> >> The Gregorian Software company creates a marvelous new media
> >> technology. It is new, different and extremely compelling web
> >> software for shopping and transactions using a simulated
> person and
> >> live environment over narrow
> >> bandwidth. They implement it with an accessibility API but
> >> no one uses the
> >> technology (of course) til its release in Sept 2007. At its
> >> announcement it
> >> is adopted by Amazon, a slew of banks, etc. AT vendors
> >> begin working with
> >> it but it will be a year or more before they can get up to speed
> (sort
> >>
> >
> >
> >> of like when dos went to windows) but this technology spreads at
> >> Internet speed because it is free downloadable plug in for most
> users.
> >>
> >> Suddenly these sites go black to AT users. But if we write out
> >> guidelines such that the sites and the Gregorian software
> company can
>
> >> say their software meets access standards, without
> actually requiring
>
> >> them to be supported by real live AT that is out there - and
> available
> >>
> >
> >
> >> to users.
> >>
> >> In fact AT vendors will remember the days before we
> required software
>
> >> to
> >> actually work with real AT. Software would come out with
> >> an accessibility
> >> API but AT vendors were not able get access to it and had
> very poor
> >> support
> >> from software vendors even after release. Only when the
> >> software was
> >> required to actually work with real AT did the vendors invite and
> >> support and even court AT vendors in the same way they invited,
> >> supported and courted other software and hardware vendors (for
> >> compatibility) when they released something new.
> >>
> >> So I think the "accessibility value chain" is a very important
> >> concept. But I don't think we should base our standards on it.
> >>
> >> I think that something is accessible if it can be used by
> real people
>
> >> who have disabilities, not just that it theoretically could be if
> only
> >>
> >
> >
> >> those other people had done their job.
> >>
> >> Accessible - means that it can be used by people with
> disabilities.
> >> That means it is either directly accessible. Or that it is
> accessible
> >>
> >
> >
> >> using the AT that the person with a disability has or can
> reasonably
> >> get (or in the case of the government - for its employees
> - AT they
> >> are given). For public websites, it would be the AT that
> the public
> >> at large has, can reasonably get, or is given.
> >>
> >> Any other definition of accessibility defeats the purpose the
> >> legislators laid out in creating 508. that is that people with
> >> disabilities could actually use the E&IT in the government
> alongside
> >> everyone else - and when it was purchased (not sometime in
> the future
>
> >> - if someone else does their job).
> >>
> >>
> >> Gregg
> >> -- ------------------------------
> >> Gregg C Vanderheiden Ph.D.
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: = EMAIL ADDRESS REMOVED =
> >>> [mailto: = EMAIL ADDRESS REMOVED = ] On
> >>>
> >> Behalf Of Jim
> >>
> >>> Tobias
> >>> Sent: Wednesday, January 03, 2007 9:35 AM
> >>> To: 'TEITAC Web/Software Subcommittee'
> >>> Subject: Re: [teitac-websoftware] Starting discussions on
> >>> theAccessibility APIproposal
> >>>
> >>> Sean Hayes wrote:
> >>>
> >>> "Firstly I agree that there is a problem that needs
> >>>
> >> adressing here,
> >>
> >>> which is the equitable division of reponsibility on
> accessibility
> >>> between each entity involved in delivering a software product.
> >>> However, as we are all aware, this is very difficult
> problem given
> >>> the manner in which modern software is produced, which in most
> >>> significant products involves cooperation across multiple
> >>> organisations, not only the software product developer, but OS
> >>> vendors, hardware vendors, AT vendors and middleware
> vendors among
> >>> others. In some cases standards or industry practice
> >>>
> >> already exists
> >>
> >>> around these interfaces, and in some cases it doesn't."
> >>>
> >>> I would like to take this opportunity to develop a little
> >>>
> >> further the
> >>
> >>> concept of an "accessibility value chain", which Sean refers to
> >>> indirectly. I believe that clarifying these
> responsibilities is at
> >>> the heart of "modern" accessibility, because, as Sean
> notes, modern
> >>> software requires cooperation across multiple
> >>>
> >> organizations, many of
> >>
> >>> whom have only indirect relationships.
> >>>
> >>> I would like to posit that the nature of this technical
> cooperation
> >>> has three distinct elements or phases:
> >>> capability, implementation, and preservation.
> >>> By
> >>> "capability" I mean that the software component contains all the
> >>> features necessary for accessible use or development.
> >>> Examples are the ability to add a text description to an
> image in a
> >>> web development tool, and the ability to record and play
> >>>
> >> back Baudot
> >>
> >>> files in a voice mail platform. By "implementation" I mean
> >>>
> >> that the
> >>
> >>> capability has actually been used by the next link in the
> >>>
> >> chain. That
> >>
> >>> is, the web developer has actually added a text description to an
> >>> image, and the telecom manager has actually set up a voice
> >>>
> >> mailbox so
> >>
> >>> a Baudot TTY user can receive messages. By "preservation"
> >>> I mean that
> >>> the next link in the chain is required not to interfere with the
> >>> accessibility feature already in place further up the chain. For
> >>> example, a digital cable system must not strip the captioning
> >>> information from a captioned video program during transmission.
> >>>
> >>> Most of the relationships in the chain are
> >>>
> >> capability-implementation
> >>
> >>> ones, especially for web and software. Thus the current
> >>>
> >> 508 requires
> >>
> >>> software to inherit system display settings, use standard OS text
> >>> presentation techniques, etc.
> >>>
> >>> I think this formulation may clarify for us where we want
> >>>
> >> to go. For
> >>
> >>> example, we have mentioned adding OS requirements.
> >>> That is, current 508 requires "downlink" software to honor OS
> >>> accessibility features, but it doesn't require OSs to have those
> >>> features. I think we may agree on adding such a requirement,
> >>> especially if we use today's common OSs as models rather
> >>>
> >> than dreaming
> >>
> >>> up new features OSs don't have yet.
> >>>
> >>> Another point that may meet more resistance, but seems
> >>>
> >> clear to me, is
> >>
> >>> the utter inseperability of content from software once we
> >>>
> >> agree that
> >>
> >>> there is an interlocking set of relationships in the web/software
> >>> arena. In the examples of the web page and voice mail
> >>>
> >> system I used
> >>
> >>> above, how can the tools be abstracted from the content?
> >>>
> >> My thinking
> >>
> >>> here is not very well developed, so I look forward to a dialogue.
> >>>
> >>>

From: Barrett, Don
Date: Thu, Jan 11 2007 8:45 AM
Subject: Re: Startingdiscussionson theAccessibilityAPIproposal

As I have stated before, it's hard to mandate the synergy between the IT
and the AT. The best you can hope for is to mandate as specifically as
possible what the IT must do, and then have the AT catch up to the same
spec.

One of the reasons the web standards have been so successful is that you
can literally look at code and say, "Yes, you have met the standard," or
"no, you haven't." You can check table headers, frame names, alt
attributes, etc. This gives the standards weight and teeth and
credibility.

For software, it's much harder, because everything is under the hood,
and the difficulties in achieving provability and testability lead to
less accountability overall.

Can the standards require that tools, if they exist, such as the Ferret
and the Monkey and Inspect Objects, etc. be utilized to show adherence
to a given set of specifications? I would love to see it if possible.
Greg is right that it is in the testing that the rubber really meets the
road, and anything we can do to build some level of testability or
accountability into the standards will move us further in that
direction.

From: Robinson, Norman B - Washington, DC
Date: Thu, Jan 18 2007 2:10 PM
Subject: Re: Startingdiscussionson theAccessibilityAPIproposal

Gregg,

I'll have to disagree with you about "or the users can't get or
can't use it (the API)." If there is a defined API or markup language
standard or file format specification and the content creators use that
then they should be in compliance.

At issue is the difference between compliance and accessibility
in specific instances. If the vendor provided the proper table headings
and row heading in an HTML table, per the W3C standards, and the screen
reader didn't read them properly, then the content should be considered
Section 508 compliant. This goes against your characterization when the
users can't get access. It may be true in some situations. Yes, testing
should let you know but if in the process of testing you find the
content, markup language, or document isn't accessible but they have
coded to the standards then the problem is the assistive technology -
not the content. Will the users suffer? They just might until the
assistive technology is fixed. I don't think it fair to say the
developers should find out what works with assistive technology (AT)
when that AT isn't following the standard instead of asking the AT to
follow the standards.

No, APIs don't guarantee interoperability but they provide the
best way to allow developers to make that happen. Therefore APIs
increase the chance for access. There are many instances where
developing against the well know API is sufficient to provide accessible
E&IT even without testing. We should encourage a development environment
where accessibility testing isn't required; this will move the industry
forward. Note I said where testing isn't _required_. It is highly
desirable but I mean that well defined interfaces enhance the ability
for developers to develop. I would imaging the screen reader
manufacturers and developers really appreciate having a Document Object
Model (DOM) standard for representation of HTML or XML. If you look at
the comparison of layout engines for DOM
(http://en.wikipedia.org/wiki/Comparison_of_layout_engines_dom you will
note "the industry" has various degrees of implementations against the
standard DOM recommendations yet it is clear this interface is the way
to go. I could imagine the Section 508 refresh making the _technical_
recommendation that vendors use the DOM model, as that is the way
industry is already heading. This is standards support. We simply need
to baseline what standards are industry wide and support accessibility
or identify those newer standards that offer significant benefits to
accessibility.

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: Thursday, January 11, 2007 2:46 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Startingdiscussionson
theAccessibilityAPIproposal


Good thoughts.

A couple more

- conformance to an API isn't sufficient if there is no AT or the users
can't get or can't use it. For example - conformance to an API for ATM
software will provide no access since they system is closed. So API
conformance.

- I actually don't think APIs should be required (since there are
multiple
APIs and we don't want to freeze innovation. Also they aren't
sufficient
by themselves.

- where I think APIs come in - is that the existence of APIs can greatly
reduce the work of both AT and IT vendors in making products work
together.
But they still have to test them and make sure they work together - even
if
they both build to an API. Anyone familiar with standards is also
familiar with plugfests and other similar interoperability events where
people who all built to the same specs get together to test and actually
get
the 'compatible' products to work together. They are always highly
instructive - and the winners are people who worked together to get
things
to work - and a few luck people. Building to a spec and not testing
rarely
works in any industry much less one as complex as IT.

So APIs are indispensable in helping us to move forward. But they don't
guarantee interoperability and therefore access - without actually
testing
to make sure things work.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
>From CES



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson, Norman B - Washington, DC
> Sent: Friday, January 05, 2007 3:58 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Startingdiscussionson
> theAccessibilityAPIproposal
>
>
> You'll see me commenting on the need for standards and
> the need for _references_ to current implementations in the
> Section 508 refresh.
> I don't mean that needs to be a part of law, but I do think
> it would help the development community (the ones sitting at
> a vendor's office creating software) if we point them in the
> right direction and inform them of the most common APIs somehow.
>
> I agree the definition of an API doesn't ensure accessibility.
> But if we are going to split hairs on semantics, I'd say you
> aren't compliant if you didn't _USE_ the API <grins>. If we
> have to debate semantics we are focusing on the wrong problem
> or need to rewrite the requirement (if it is clearly
> interpreted badly by most people). So I agree with you that
> vendor use of an API isn't a clear basis for measuring
> Section 508 compliance. I think the functional requirements
> (goals) Section 508 has outlined for determining compliance
> have been successful.
>
> However, do we need to address the issues when vendors
> use many different APIs to achieve accessibility? Does it
> move accessibility forward, make electronic information and
> electronic technology more accessible if we all,
> collectively, use the same APIs? Or is it better to have many
> different vendors implementing their own APIs?
>
> Is the defacto standard for an accessibility API on MS
> Windows MSAA? Is it AT-SPI for Gnome? KDE AT-API for KDE? UA
> for OSX? What about the Qt Accessibility Framework for MS
> Windows; it uses MSAA but has it's own API. I've got acronym
> overload! Perhaps, after looking at these things as the
> toolkits they are, we can agree there is a basic goodness in
> having developers develop to the appropriate API for their
> platform/operating system. Now, how could we, if so
> motivated, actually force/beat/make them use a particular
> API; even if that would be wrong of us? I don't think Section
> 508 would be the place to do that. I think it has to be tied
> to business requirements. Certainly requiring MSAA on the
> Linux platform won't get you anywhere - it doesn't exist!
>
> We approach this in our policy
> (http://www.usps.com/cpim/ftp/hand/as508a/508a_c5.html#508hdr8
> ) and I would say the short version is a prioritized list
> approach: 1. Support native operating system and activated
> accessibility features. 2. Use standard controls for
> particular operating systems where possible. 3. Be careful
> when using custom controls or enhancing standard controls. 4.
> Provide flexibility in using a variety of input methods. 5.
> Query accessibility aids in use by the operating system and
> configure the software applications automatically.
>
> So using a API doesn't equate to access, but we should:
> 1. Support native operating systems accessibility
> (e.g., the APIs for whatever development framework is being
> used should use the operating systems accessibility features
> and not _reinvent_ their own).
> - is there more than one native operating
> system API on any platform? Help point this out!
> 2. If the API provides standard controls (which is
> generally the purpose of a framework or development
> environment?) those standard controls should follow #1.
> - there are many developer toolkits or
> frameworks but do they all use the native API? (Java Access
> Bridge uses MSAA doesn't it?
> Qt?)
> 3. Developers should follow #1, via using standard
> controls (#2).
> 4. Developers should test their products in a variety
> of use-cases that include testing for users that might have a
> disability.
> 5. This is a repeat of #1 actually, as the operating
> system would provide this through a standard interface (#1).
>
> As we have developed our own policy, I can't help but
> think what we need is a central policy document that isn't a
> part of the law but the best practices that have been
> approved as acceptable. We need some agency (the Access
> Board? GSA?) to maintain this and harmonize it with any
> Section 508 updates. It would effectively replace an agencies
> individual policy when the agency didn't invent it.
> Guidelines, not Section 508 technical standards or
> regulations. Guidelines that meet the technical standards but
> can be legally ignored as not _required_.
>
> Wow. I think I just convinced myself that we shouldn't
> have API specifications in the revision at all.
>
> Have a great weekend,
>
>
> 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 Jessica M. Brodey
> Sent: Friday, January 05, 2007 12:17 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware]Startingdiscussionson
> theAccessibility APIproposal
>
>
> Peter:
>
> ATIA agrees that there are already aspects of an
> Accessibility API in 508.
> We are opposed to creating and labeling something an
> "Accessibility API,"
> enumerating it exactly in 508, and thus running the risk that
> companies can say "hey, I used the accessibility API so I am
> 508 compliant" without actual interoperability with AT. We
> want to be clear that while we think moving towards
> incorporating an accessibility API is a good thing, it may
> not be the lone solution to full interoperability, nor does
> an accessibility API alone equate to actual access, and it
> should therefore not be used as the measure for 508
> compliance. We are also not certain that an accessibility
> API expressed as such belongs in 508, which is a regulatory
> standard, as opposed to in an industry standard.
>
> ATIA would rather see enumerations written in broad brush
> strokes, not the specifics that would indicate "use this
> particular accessibility API."
> I
> apologize for not speaking to the specific language and
> sections as I am a policy person, not a techie, but if you
> equate this to the world of the Internet, we do not want to
> structure the regulations in a manner that would say the
> equivalent of "supports Java version x," or even spell out
> all the components or provisions in Java (without actually
> specifying it) that make it obvious which version of Java we
> are pushing to support. We would rather spell out
> characteristics that would allow a company to provide Java
> support in satisfaction of that provision, OR could allow a
> company to go another route and still satisfy the
> requirements of the regulation, or in three years switch to
> Java version x2 without violating the regulation. I
> understand that approach is sometimes frustrating for techies
> who often want it to be spelled out in black in white.
> Unfortunately, it is the same techies who also want the
> flexibility to innovate, and not be hemmed in when the law is
> so specific that it prevents them from diverging. We need to
> find a happy medium here . . . where we can include the
> elements of an accessibility API to get at some of the
> benefits without nailing down such specifics that we are
> locked into only one version of an accessibility API that is
> too rigid and cannot evolve.
>
> We need to focus on the end results - what we want to be able
> to achieve, not the means of getting there. The distinction
> you pointed out, Peter, is that while the descriptions in
> 1194.21(c) may comprise aspects of an accessibility API, it
> does not dictate the nature of the accessibility API - it is
> focused on the result of the access, not the means for
> providing the access. Perhaps we can determine what aspects
> you feel are missing from the existing provisions that are
> critical to an accessibility API, and write them in language
> consistent with 1194.21?
>
> Again . . . we think implementation of an accessibility API
> is a best practice, and perhaps can be used/publicized in
> other aspects of this process as a guide to understanding how
> to comply with the 508 requirements.
>
> Jessica
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Thursday, January 04, 2007 11:38 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware]Startingdiscussionson
> theAccessibility APIproposal
>
> Hi Jessica,
>
> > ATIA's position is that an accessibility API has a role,
> but it is in
> the
> > business venue, or in the standards venue, not the regulatory venue.
> If
> we
> > want to include aspects of the accessibility API into 508, it should
> be as
> > Sean Hayes from Microsoft has advocated. We are concerned about an
> exact
> > and precise list that is finite and unable to evolve without
> reconvening a
> > new panel and a new refresh. We see an accessibility API
> as more of a
> good
> > business practice that is the best way to meet some of the
> specifications
> of 508, but which accessibility API may change and evolve over time.
> >
>
> 508 already includes aspects of an accessibility API. The
> seven provisions enumerated in
> http://teitac.org/wiki/Web_and_Software:_Programmatic_exposure
> _of_inform
> atio
> n
> are existing places where 508 describes the programmatic
> information that IT shall provide to AT. The current
> language doesn't call this portions of an "accessibility
> API", but language like "focus shall be programmatically
> exposed so that assistive technology can track focus and
> focus changes" in 1194.21(c) aren't too far away from that.
>
> And I think ATIA would agree with me that the seven
> provisions in question constitute an insufficient set of
> information from which AT can
>
> accomplish their task. Yet these seven represent "a list
> that is finite
>
> and unable to evolve without reconvening a new panel and a
> new refresh." In fact, it is the very process of refreshing
> these seven provisions that gave rise to the accessibility
> API proposal - a much richer enumeration of things we know
> are needed, and in support of which
>
> the evolving, platform-specific accessibility APIs like UI
> Automation can be used by IT vendors to interopreate with AT.
>
> If ATIA is opposed to a finite list, then what does ATIA
> propose we do with finite list we currently have - the seven
> provisions enumerated above?
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
> > Jessica
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Lybarger,
> > Barbara (MOD)
> > Sent: Thursday, January 04, 2007 6:14 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware]Startingdiscussionson
> theAccessibility
> > APIproposal
> >
> > On this topic, I'm not nearly well enough informed on the content.
> > However, I question Jessica's reasoning, in that no set of
> standards
> > will help if they aren't followed by all the parties, here
> IT, AT and
> > all the players in between, and violators aren't chastised
> in some way
> > fair and reasonable way.
> >
> > At it's core, the API proposal is like the standards for our
> electrical
> > power grids. The government regulates how the power source
> comes out,
> > and all the other parties set up their stuff so all the
> customers can
> > get at the power to run their lights. Most of the parties conform
> > because the alternative is that people can't safely and cost
> effectively
> > share the power. If anyone in the chain doesn't conform with the
> > standard, end users either have dark houses because the light bulbs
> > can't get the power, or they have a very bright house while
> it burns
> > down. Either way the government is looking to punish the one who
> caused
> > the problem.
> >
> > People argued about innovation and standardization when the first
> power
> > grids were set up. Costs, safety and reliability won out over
> > unfettered innovation, but it didn't stifle innovation. Folks are
> still
> > inventing better, safer, cheaper ways of delivering power, and they
> are
> > being used to upgrade the power grid. The bottom line then
> and now is
> > that in a society we have to give up a little freedom to
> make sure we
> > all can get at shared resource cheaply, safely and reliable. The
> > technology equivalent may be this API or something like it. It is
> > needed so all of us can share, and conformance by all is
> essential for
> > it to work.
> >
> > If this API proposal isn't perfect in some ways, what would make it
> > better so everyone would want to follow it? And then, what type of
> > enforcement system is needed so the non-likeminded in society get
> > brought into line?
> >
> > Barbara Lybarger
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Jessica
> > M. Brodey
> > Sent: Thursday, January 04, 2007 4:21 PM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware]Startingdiscussionson
> theAccessibility
> > APIproposal
> >
> > Jim:
> >
> > Speaking as a policy wonk in lay terms, I think that the common
> > misunderstanding here is that use of an accessibility API equals
> > accessibility. Just because there is an accessibility API does not
> mean
> > that every piece of AT automatically works all of the time
> - it just
> > increases the odds of existing AT working with new products. But,
> > sometimes new technologies come with new features. If the
> AT did not
> > take into account those new features or capabilities, support for
> those
> > features still needs to be built in. An accessibility API makes it
> > easier to build in support for those features, and makes it less
> > burdensome for the AT vendors to do so (and means supporting those
> > features should be more standardized), but it is not always
> automatic.
> > Also, as I understand it, just because a company uses the
> accessibility
> > API does not mean it implements the API in exactly the same way as
> > another company, thus, it is possible a piece of AT may not work
> > perfectly with one product that uses the accessibility API but may
> work
> > perfectly with another, and thus it may not be fully
> compatible with
> > every product. So, the verdict is that an accessibility
> API could be
> > useful, could improve things, but does not mean that compliance with
> the
> > API will equal access.
> >
> > Another problem is that adopting an accessibility API that is the
> "gold
> > standard" today may quickly be old and out of date in 6 months or a
> > year.
> > While we are in danger of this for many aspects of 508, it is
> > particularly worrisome for how AT interfaces with IT,
> because it could
> > stifle the growth and expansion of new AT, particularly if the
> > accessibility API becomes the excuse or justification . . .
> "well, we
> > used the accessibility API, we don't have to be compatible
> with ACTUAL
> > AT." At some point not too far off, because the API won't
> be able to
> > grow and evolve once put into regulation, what started off
> as a means
> to
> > improve accessibility could actually become the one bar to
> providing
> > real access.
> >
> > Jessica Brodey
> >
> > -----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'
> > Subject: Re: [teitac-websoftware] Startingdiscussionson
> theAccessibility
> > APIproposal
> >
> > Your concerns are justified, but you have the concepts backwards.
> > Thinking in terms of an accessibility value chain guarantees that we
> are
> > thinking of all the steps required to give the end user access.
> > Separating the regs by narrow targets, one product or industry at a
> > time, ignores the need for both technical and informational
> > interoperation.
> >
> > There is no getting around the problem of assigning responsibilities
> to
> > the "proper"
> > parties. Luckily 508 burdens the purchaser, who has the
> best view of
> > the entire chain, from OEM-type product to developed product to
> > installed product to user and administrator. In theory.
> The problem
> > remains one of information flow rather than raw technological power,
> as
> > your example indicates -- Gregorian did not work closely enough with
> the
> > AT community.
> >
> > But that raises another troubling point: why is the
> Accessibility API
> > not sufficient? If Gregorian builds its software correctly, why is
> > additional action required by AT vendors?
> > If Gregorian cannot sell to the feds until one or more AT
> vendors acts
> > to make the new product accessible, isn't that an imbalance
> of market
> > power? I thought the whole idea of the Accessibility API was to
> > eliminate that problem.
> >
> > Maybe I'm misunderstanding something....
> >
> >
> >
> >> -----Original Message-----
> >> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> >> Sent: Thursday, January 04, 2007 1:52 AM
> >> To: 'TEITAC Web/Software Subcommittee'
> >> Subject: Re: [teitac-websoftware] Starting discussionson
> >> theAccessibility APIproposal
> >>
> >> Why value chain is good concept - but we need to be very careful
> about
> >>
> >
> >
> >> its use in regulatory standards.
> >>
> >> I really like the accessibility value chain concept as a way to
> >> understand this - and to point out the way things work together.
> >>
> >> But I worry about it in a discussion of how to structure our
> >> standards. And I don't think we should structure our standards
> around
> >>
> >
> >
> >> it. If we did then we would only require that software companies
> >> "enable" there software to be accessible - but they would have no
> >> responsibility to actually make sure that there was AT
> that did work
> >> with their software and did make it
> >> accessible. The result is that in fact it would be "meet
> >> accessibility
> >> standard" but be unusable by anyone with a disability.
> >>
> >> Take the following example.
> >>
> >>
> >> The Gregorian Software company creates a marvelous new media
> >> technology. It is new, different and extremely compelling web
> >> software for shopping and transactions using a simulated
> person and
> >> live environment over narrow
> >> bandwidth. They implement it with an accessibility API but
> >> no one uses the
> >> technology (of course) til its release in Sept 2007. At its
> >> announcement it
> >> is adopted by Amazon, a slew of banks, etc. AT vendors
> >> begin working with
> >> it but it will be a year or more before they can get up to speed
> (sort
> >>
> >
> >
> >> of like when dos went to windows) but this technology spreads at
> >> Internet speed because it is free downloadable plug in for most
> users.
> >>
> >> Suddenly these sites go black to AT users. But if we write out
> >> guidelines such that the sites and the Gregorian software
> company can
>
> >> say their software meets access standards, without
> actually requiring
>
> >> them to be supported by real live AT that is out there - and
> available
> >>
> >
> >
> >> to users.
> >>
> >> In fact AT vendors will remember the days before we
> required software
>
> >> to
> >> actually work with real AT. Software would come out with
> >> an accessibility
> >> API but AT vendors were not able get access to it and had
> very poor
> >> support
> >> from software vendors even after release. Only when the
> >> software was
> >> required to actually work with real AT did the vendors invite and
> >> support and even court AT vendors in the same way they invited,
> >> supported and courted other software and hardware vendors (for
> >> compatibility) when they released something new.
> >>
> >> So I think the "accessibility value chain" is a very important
> >> concept. But I don't think we should base our standards on it.
> >>
> >> I think that something is accessible if it can be used by
> real people
>
> >> who have disabilities, not just that it theoretically could be if
> only
> >>
> >
> >
> >> those other people had done their job.
> >>
> >> Accessible - means that it can be used by people with
> disabilities.
> >> That means it is either directly accessible. Or that it is
> accessible
> >>
> >
> >
> >> using the AT that the person with a disability has or can
> reasonably
> >> get (or in the case of the government - for its employees
> - AT they
> >> are given). For public websites, it would be the AT that
> the public
> >> at large has, can reasonably get, or is given.
> >>
> >> Any other definition of accessibility defeats the purpose the
> >> legislators laid out in creating 508. that is that people with
> >> disabilities could actually use the E&IT in the government
> alongside
> >> everyone else - and when it was purchased (not sometime in
> the future
>
> >> - if someone else does their job).
> >>
> >>
> >> Gregg
> >> -- ------------------------------
> >> Gregg C Vanderheiden Ph.D.
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: = EMAIL ADDRESS REMOVED =
> >>> [mailto: = EMAIL ADDRESS REMOVED = ] On
> >>>
> >> Behalf Of Jim
> >>
> >>> Tobias
> >>> Sent: Wednesday, January 03, 2007 9:35 AM
> >>> To: 'TEITAC Web/Software Subcommittee'
> >>> Subject: Re: [teitac-websoftware] Starting discussions on
> >>> theAccessibility APIproposal
> >>>
> >>> Sean Hayes wrote:
> >>>
> >>> "Firstly I agree that there is a problem that needs
> >>>
> >> adressing here,
> >>
> >>> which is the equitable division of reponsibility on
> accessibility
> >>> between each entity involved in delivering a software product.
> >>> However, as we are all aware, this is very difficult
> problem given
> >>> the manner in which modern software is produced, which in most
> >>> significant products involves cooperation across multiple
> >>> organisations, not only the software product developer, but OS
> >>> vendors, hardware vendors, AT vendors and middleware
> vendors among
> >>> others. In some cases standards or industry practice
> >>>
> >> already exists
> >>
> >>> around these interfaces, and in some cases it doesn't."
> >>>
> >>> I would like to take this opportunity to develop a little
> >>>
> >> further the
> >>
> >>> concept of an "accessibility value chain", which Sean refers to
> >>> indirectly. I believe that clarifying these
> responsibilities is at
> >>> the heart of "modern" accessibility, because, as Sean
> notes, modern
> >>> software requires cooperation across multiple
> >>>
> >> organizations, many of
> >>
> >>> whom have only indirect relationships.
> >>>
> >>> I would like to posit that the nature of this technical
> cooperation
> >>> has three distinct elements or phases:
> >>> capability, implementation, and preservation.
> >>> By
> >>> "capability" I mean that the software component contains all the
> >>> features necessary for accessible use or development.
> >>> Examples are the ability to add a text description to an
> image in a
> >>> web development tool, and the ability to record and play
> >>>
> >> back Baudot
> >>
> >>> files in a voice mail platform. By "implementation" I mean
> >>>
> >> that the
> >>
> >>> capability has actually been used by the next link in the
> >>>
> >> chain. That
> >>
> >>> is, the web developer has actually added a text description to an
> >>> image, and the telecom manager has actually set up a voice
> >>>
> >> mailbox so
> >>
> >>> a Baudot TTY user can receive messages. By "preservation"
> >>> I mean that
> >>> the next link in the chain is required not to interfere with the
> >>> accessibility feature already in place further up the chain. For
> >>> example, a digital cable system must not strip the captioning
> >>> information from a captioned video program during transmission.
> >>>
> >>> Most of the relationships in the chain are
> >>>
> >> capability-implementation
> >>
> >>> ones, especially for web and software. Thus the current
> >>>
> >> 508 requires
> >>
> >>> software to inherit system display settings, use standard OS text
> >>> presentation techniques, etc.
> >>>
> >>> I think this formulation may clarify for us where we want
> >>>
> >> to go. For
> >>
> >>> example, we have mentioned adding OS requirements.
> >>> That is, current 508 requires "downlink" software to honor OS
> >>> accessibility features, but it doesn't require OSs to have those
> >>> features. I think we may agree on adding such a requirement,
> >>> especially if we use today's common OSs as models rather
> >>>
> >> than dreaming
> >>
> >>> up new features OSs don't have yet.
> >>>
> >>> Another point that may meet more resistance, but seems
> >>>
> >> clear to me, is
> >>
> >>> the utter inseperability of content from software once we
> >>>
> >> agree that
> >>
> >>> there is an interlocking set of relationships in the web/software
> >>> arena. In the examples of the web page and voice mail
> >>>
> >> system I used
> >>
> >>> above, how can the tools be abstracted from the content?
> >>>
> >> My thinking
> >>
> >>> here is not very well developed, so I look forward to a dialogue.
> >>>
> >>>