Thread Subject: Re: Starting discussionson theAccessibility APIproposal

Return to this mailing list's archives

From: Gregg Vanderheiden
Date: Thu, Jan 04 2007 12:15 AM
Subject: Re: 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 2:40 PM
Subject: Re: Starting discussionson theAccessibility APIproposal

Hi Jim,

> 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....
>

A key issue I think in Gregg's example is that Gregorian software has
implemented "an accessibility API" (maybe their own, invented out of
whole cloth and introduced for the very first time when the product was
released; maybe using someone someone else developed). Not that
Gregorian software implemented an accessibility API that was a
recognized "sufficient technique".

It cannot be fair - to the customer or to AT vendors - for any software
vendor to say "I expose information via an API, so my job is done".


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


>
>
>> -----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: Gregg Vanderheiden
Date: Sun, Jan 07 2007 7:40 PM
Subject: Re: Starting discussionson theAccessibilityAPIproposal

I don't think this is a market power question.

It is an accessibility question.

It isn't about AT vendors having more power or IT vendors having more power.
It is about the governments desire to have an E&IT environment that is
accessible. And that the government will use its purchasing power (as long
as it isn't an undo burden to the government) to make sure its E&IT
environment is accessible.

Companies spend money all the time to meet customer needs. It would be
expected that they would spend money to meet this need too. This isn't bad -
as long as it is fair and all companies face the same requirements.

The purpose of an accessibility API is not to avoid the problem (or need
for) AT to actually have accessibility. The purpose of the API is to make
it easier for AT to keep up with the ever changing IT. But without AT you
still do not have access.


I agree with your comments about not separating this by target products
except where functions clearly only apply to one technology. (like line 21
encoding of captions for NTSC). Even there I would like to see the
requirement be that "captioning be provided either in as 'open captions'
(permanenetly visible) or 'closed captions' using a method that is supported
by users equipment."

It could then be pointed out that the following were considered 'Sufficient"

For NTSC broadcast or video
- Line 21 encoding

For Digtal Broadcast
- xxxxx

Etc.

As will be discussed at the next TEITAC meeting, the sufficient approach is
very powerful but very easy to misuse if it is not done right. But done
right it could be very powerful and address a number of the issues under
discussion.

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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Tobias
> Sent: Thursday, January 04, 2007 10:01 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussionson
> theAccessibilityAPIproposal
>
> 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: Jim Tobias
Date: Mon, Jan 08 2007 6:30 AM
Subject: Re: Starting discussionson theAccessibilityAPIproposal

Gregg wrote, regarding the Accessibility API and the assignment of
responsibilities:

"I don't think this is a market power question. It is an accessibility
question. It isn't about AT vendors having more power or IT vendors having
more power."

I salute the optimism, but it just doesn't reflect reality. There are,
already on the table,
complaints in one direction that AT companies can hold the ICT industry
hostage by refusing
to develop AT compatible with a new mainstream technology unless "suitably
motivated"; and in
the other direction that mainstream ICT companies, with clearly deeper
pockets and self-defined
rollout schedules, are not cooperating sufficiently with AT companies. If
that's not a debate
over power relationships, I don't know what is.

Isn't the point of a regulatorily required Accessibility API that, in the
best case, it resolves both
technological and market power issues by safe-harboring both parties? If
both AT and mainstream
ICT companies build to the A-API in good faith, access, while not absolutely
guaranteed, is maximized
in a feasible framework.

The problem that remains is the process for rolling out a new technology
whose parameters are not
yet dealt with within the A-API. We can have ideas about how to address
that problem, but they, by
definition, cannot be contained within a set of technological standards.
Inputs for success are
enough time, enough willing cooperation, and a venue in which both trust and
decisiveness exist.

From: Jessica M. Brodey
Date: Mon, Jan 08 2007 9:00 AM
Subject: Re: Starting discussionson theAccessibilityAPIproposal

I do agree with Jim that this is, to some extent, about power relationships.
In an ideal world, an Accessibility API can help to minimize that struggle,
but I'm not sure that I would agree with Jim's optimism . . . I think,
perhaps, I am a bit more cynical. I am concerned about the scenario of
"what happens when the Accessibility API does not meet the expectations" -
what can we include in 508 to recognize that an Accessibility API is not the
cure all and does not equate with access. I am quite concerned about using
the Accessibility API as a proxy for actual compatibility . . . unlike some
of the other measures in 508, an end result of actual compatibility is not
necessarily guaranteed, unless we make sure it is written that way.

Jessica Brodey

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Monday, January 08, 2007 8:28 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware]Starting discussionson
theAccessibilityAPIproposal

Gregg wrote, regarding the Accessibility API and the assignment of
responsibilities:

"I don't think this is a market power question. It is an accessibility
question. It isn't about AT vendors having more power or IT vendors having
more power."

I salute the optimism, but it just doesn't reflect reality. There are,
already on the table,
complaints in one direction that AT companies can hold the ICT industry
hostage by refusing
to develop AT compatible with a new mainstream technology unless "suitably
motivated"; and in
the other direction that mainstream ICT companies, with clearly deeper
pockets and self-defined
rollout schedules, are not cooperating sufficiently with AT companies. If
that's not a debate
over power relationships, I don't know what is.

Isn't the point of a regulatorily required Accessibility API that, in the
best case, it resolves both
technological and market power issues by safe-harboring both parties? If
both AT and mainstream
ICT companies build to the A-API in good faith, access, while not absolutely
guaranteed, is maximized
in a feasible framework.

The problem that remains is the process for rolling out a new technology
whose parameters are not
yet dealt with within the A-API. We can have ideas about how to address
that problem, but they, by
definition, cannot be contained within a set of technological standards.
Inputs for success are
enough time, enough willing cooperation, and a venue in which both trust and
decisiveness exist.

From: Jim Tobias
Date: Mon, Jan 08 2007 9:10 AM
Subject: Re: Starting discussionson theAccessibilityAPIproposal

I agree with your concerns completely, Jessica. That's why
any A-API approach must include a consultative and evolutionary
process. We simply cannot wait 5 years between waltzes.

******
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1 732.441.0831 voice/tty
skype jimtobias
+1 908.907.2387 mobile

> -----Original Message-----
> From: Jessica M. Brodey [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, January 08, 2007 10:54 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware]Starting discussionson
> theAccessibilityAPIproposal
>
> I do agree with Jim that this is, to some extent, about power
> relationships.
> In an ideal world, an Accessibility API can help to minimize
> that struggle, but I'm not sure that I would agree with Jim's
> optimism . . . I think, perhaps, I am a bit more cynical. I
> am concerned about the scenario of "what happens when the
> Accessibility API does not meet the expectations" - what can
> we include in 508 to recognize that an Accessibility API is
> not the cure all and does not equate with access. I am quite
> concerned about using the Accessibility API as a proxy for
> actual compatibility . . . unlike some of the other measures
> in 508, an end result of actual compatibility is not
> necessarily guaranteed, unless we make sure it is written that way.
>
> Jessica Brodey
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Tobias
> Sent: Monday, January 08, 2007 8:28 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware]Starting discussionson
> theAccessibilityAPIproposal
>
> Gregg wrote, regarding the Accessibility API and the assignment of
> responsibilities:
>
> "I don't think this is a market power question. It is an
> accessibility question. It isn't about AT vendors having more
> power or IT vendors having more power."
>
> I salute the optimism, but it just doesn't reflect reality.
> There are, already on the table, complaints in one direction
> that AT companies can hold the ICT industry hostage by
> refusing to develop AT compatible with a new mainstream
> technology unless "suitably motivated"; and in the other
> direction that mainstream ICT companies, with clearly deeper
> pockets and self-defined rollout schedules, are not
> cooperating sufficiently with AT companies. If that's not a
> debate over power relationships, I don't know what is.
>
> Isn't the point of a regulatorily required Accessibility API
> that, in the best case, it resolves both technological and
> market power issues by safe-harboring both parties? If both
> AT and mainstream ICT companies build to the A-API in good
> faith, access, while not absolutely guaranteed, is maximized
> in a feasible framework.
>
> The problem that remains is the process for rolling out a new
> technology whose parameters are not yet dealt with within the
> A-API. We can have ideas about how to address that problem,
> but they, by definition, cannot be contained within a set of
> technological standards.
> Inputs for success are
> enough time, enough willing cooperation, and a venue in which
> both trust and decisiveness exist.
>
>