Expanding the web's potential for people with disabilities

Getting Started

Introduction to web accessibility

WebAIM Training

May 21-22
Training Details

From the Blog

Community

You are here: Home > TEITAC Archives > Mailing List Archives

Thread Subject: Re: Starting discussions ontheAccessibility API proposal

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

Return to this mailing list's archives

Next message

From: Jim Tobias
Date: Wed, Jan 03 2007 8:55 AM
Subject: Re: Starting discussions ontheAccessibility API proposal

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.

Previous message | Next message

From: Randy Marsden (Home)
Date: Thu, Jan 04 2007 12:20 AM
Subject: Re: Starting discussions ontheAccessibility APIproposal

Very well put, Gregg. YouÂ¹ve managed to put into words something I was
feeling but wasnÂ¹t sure how to express.

My opinion is we should refresh Section 508 in such a way that it encourages
the interaction even more between IT and AT vendors, and then at an industry
level, set up a way for that to happen in a somewhat more formal way than we
currently have.

-Randy, ATIA
>
> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> Date: Thu, 4 Jan 2007 00:51:57 -0600
> To: "'TEITAC Web/Software Subcommittee'" < = EMAIL ADDRESS REMOVED = >
> Cc: "'Randy Marsden'" < = EMAIL ADDRESS REMOVED = >
> Subject: RE: [teitac-websoftware] Starting discussions on 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.
>> >
>> >

Previous message | Next message

From: Gregg Vanderheiden
Date: Thu, Jan 04 2007 12:25 AM
Subject: Starting discussions ontheAccessibilityAPIproposal

A challenge for us.

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

-----Original Message-----
From: Randy Marsden (Home) [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, January 04, 2007 1:07 AM
To: Gv@Trace. Edu; 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Starting discussions on
theAccessibilityAPIproposal

Very well put, Gregg. You've managed to put into words something I was
feeling but wasn't sure how to express.

My opinion is we should refresh Section 508 in such a way that it encourages
the interaction even more between IT and AT vendors, and then at an industry
level, set up a way for that to happen in a somewhat more formal way than we
currently have.

-Randy, ATIA

From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
Date: Thu, 4 Jan 2007 00:51:57 -0600
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Cc: "'Randy Marsden'" < = EMAIL ADDRESS REMOVED = >
Subject: RE: [teitac-websoftware] Starting discussions on
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.
>
>

Previous message | Next message

From: Gregg Vanderheiden
Date: Thu, Jan 04 2007 7:25 AM
Subject: Re: Starting discussions ontheAccessibilityAPIproposal

Not sure what you mean by 'excuse' the example.

If the reader had built in accessibility then the documents/content would be
accessible the day it shipped. People with disabilities could use it.

I do believe however that if we are talking about productivity related
material then it should still also have AT compatibility to allow people to
use AT that best fits them so they can have productivity.

Did I answer your question?

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> David Poehlman
> Sent: Thursday, January 04, 2007 5:25 AM
> To: TEITAC General Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] FW: [teitac-websoftware]
> Starting discussions ontheAccessibilityAPIproposal
>
> would you excuse your example case if they put AT in the
> package so that it was not necessary to use external at?
>
> On Jan 4, 2007, at 2:07 AM, Gregg Vanderheiden wrote:
>
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Gregg Vanderheiden
> Sent: Thursday, January 04, 2007 12:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussions on
> theAccessibilityAPIproposal
>
> 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.
> >
> >

Previous message | Next message

From: David Poehlman
Date: Thu, Jan 04 2007 2:00 PM
Subject: Re: Starting discussions ontheAccessibilityAPIproposal

Hi Greg,

I'm not certain, I think part of this answers my question. If my
product is fully accessible, I've done my part. I don't know what
you meant by the second part of the answer.

On Jan 4, 2007, at 9:20 AM, Gregg Vanderheiden wrote:

Not sure what you mean by 'excuse' the example.

If the reader had built in accessibility then the documents/content
would be
accessible the day it shipped. People with disabilities could use it.

I do believe however that if we are talking about productivity related
material then it should still also have AT compatibility to allow
people to
use AT that best fits them so they can have productivity.

Did I answer your question?

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> David Poehlman
> Sent: Thursday, January 04, 2007 5:25 AM
> To: TEITAC General Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] FW: [teitac-websoftware]
> Starting discussions ontheAccessibilityAPIproposal
>
> would you excuse your example case if they put AT in the
> package so that it was not necessary to use external at?
>
> On Jan 4, 2007, at 2:07 AM, Gregg Vanderheiden wrote:
>
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Gregg Vanderheiden
> Sent: Thursday, January 04, 2007 12:52 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Starting discussions on
> theAccessibilityAPIproposal
>
> 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.
>>
>>

Previous message | Next message

From: Peter Korn
Date: Thu, Jan 04 2007 3:10 PM
Subject: Re: Starting discussions ontheAccessibilityAPIproposal

Hi Randy,

We encounter the situation you describe with ITWidgetsRUs all the time
at Sun, and I expect at most of the IT companies participating in
TEITAC. At Sun we have an internal checklist for these folks, and based
on the technology they are using (Web, Java, GNOME, other) we direct
them to the specific techniques they should follow to ensure that what
they produce is accessible.

This is very analogous to the "sufficient techniques" concept, and
putting such guidance into the 508-related materials that the Access
Board provides would I think be a significant service to all.

Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> My comments were centered on the specific technical implementation of
> interoperability between the IT and AT. I wasnâ��t considering any sort
> of regulatory or approval process.
>
> Example: ITWidgetsRUs is creating a new piece of IT technology and
> wants to be able to sell it to the Federal Government. They learn
> thereâ��s this thing called Section 508 and that their widget must be
> accessible. So, they want to make it so. But where do they start? The
> 508 requirements seem daunting. Theyâ��ve never even heard of AT, much
> less know who to contact, what exists, what to do, etc.
>
> There ought to be a place where they can go to get started, get
> connected, sign NDAâ��s, and begin the journey of making their widget
> accessible to all. Thatâ��s the process Iâ��m talking about. Still not
> sure how the Access Board would be involved.. But having consumers
> involved is always a good idea â�� that often happens naturally as part
> of the product development process (at least it should).
>
> -Randy
>
>
> *From: *"Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> *Reply-To: *TEITAC General Interface Accessibility Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> *Date: *Thu, 4 Jan 2007 14:52:55 -0600
> *To: *"'TEITAC Web/Software Subcommittee'"
> < = EMAIL ADDRESS REMOVED = >
> *Cc: *'TEITAC General Interface Accessibility Subcommittee'
> < = EMAIL ADDRESS REMOVED = >
> *Subject: *Re: [teitac-general] [teitac-websoftware] Starting
> discussions ontheAccessibilityAPIproposal
>
>
> I think it needs to be at the Access-board level.
>
>
>
> You can't have industry deciding what qualifies for â��passingâ�� the
> government requirements and have it have any validity if a suit is
> brought.
>
>
>
> Also consumers need to be at the table â��
>
>
>
> AND no matter what group of companies (IT and AT) you bring
> together, others will complain they were not represented.
>
>
>
> So AB is only one who could run such an operation I would think.
>
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf
> Of *Randy Marsden
> *Sent:* Thursday, January 04, 2007 11:44 AM
> *To:* TEITAC Web/Software Subcommittee
> *Subject:* Re: [teitac-websoftware] Starting discussions
> ontheAccessibilityAPIproposal
>
> I think there should be a consultative process put in place.
> Whether or not that has to involve the Access Board is not
> clear to me. I think it should be done at the industry level.
> I thought the suggestion of a bugzilla-like website was
> interesting. That could be part of it (although I donâ��t think
> that alone is enough). I believe the collaboration will happen
> naturally in most cases, given a process, but if there is some
> problem encountered in a specific interaction, perhaps a
> mediation procedure could be part of the picture.
>
> -Randy
>
>
> *From: *"Jim Tobias" < = EMAIL ADDRESS REMOVED = >
> *Reply-To: *TEITAC Web/Software Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> *Date: *Thu, 4 Jan 2007 11:01:14 -0500
> *To: *"'TEITAC Web/Software Subcommittee'"
> < = EMAIL ADDRESS REMOVED = >
> *Subject: *Re: [teitac-websoftware] Starting discussions
> ontheAccessibility APIproposal
>
>
>
>
> If I hear you correctly, Randy, you are proposing some
> sort of consultative process that would be mediated by, or
> at least
> would include participation by, regulators such as the
> Access Board. Is that correct? One of our recommendations
> might address this idea, as a way of providing continual
> refreshment.
>
> ------------------------------------------------------------------------
>
> *From:* Randy Marsden (Home) [mailto: = EMAIL ADDRESS REMOVED = ]
> *Sent:* Thursday, January 04, 2007 2:07 AM
> *To:* Gv@Trace. Edu; 'TEITAC Web/Software Subcommittee'
> *Subject:* Re: [teitac-websoftware] Starting discussions
> ontheAccessibility APIproposal
>
> Very well put, Gregg. Youâ��ve managed to put into words
> something I was feeling but wasnâ��t sure how to express.
>
> My opinion is we should refresh Section 508 in such a way
> that it encourages the interaction even more between IT
> and AT vendors, and then at an industry level, set up a
> way for that to happen in a somewhat more formal way than
> we currently have.
>
> -Randy, ATIA
>
>
> *From: *"Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> *Date: *Thu, 4 Jan 2007 00:51:57 -0600
> *To: *"'TEITAC Web/Software Subcommittee'"
> < = EMAIL ADDRESS REMOVED = >
> *Cc: *"'Randy Marsden'" < = EMAIL ADDRESS REMOVED = >
> *Subject: *RE: [teitac-websoftware] Starting discussions
> on 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.
> >
> >

Previous message | Next message

From: terry.weaver@gsa.gov
Date: Thu, Jan 04 2007 4:05 PM
Subject: Re: Starting discussions ontheAccessibilityAPIproposal

I have gotten a lot of calls from companies like ITWidgetsRUs. My
response is to sell them on 508 and then point them to my Buy Accessible
Data Center, which feeds the Wizard's market research activity. I have
also pointed to the Data Center as an excellent resource on AT companies
that might be interested in partnerships. It is in my work plans this
year to get a lot more out of the data Center by using it as a proactive
recruiting/educating tool and enlist more E&IT providers.

"Randy Marsden" < = EMAIL ADDRESS REMOVED = >
Sent by: = EMAIL ADDRESS REMOVED =
01/04/2007 04:40 PM
Please respond to
"TEITAC General Interface Accessibility Subcommittee"
< = EMAIL ADDRESS REMOVED = >

To
"TEITAC General Interface Accessibility Subcommittee"
< = EMAIL ADDRESS REMOVED = >, "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
cc

Subject
Re: [teitac-general] [teitac-websoftware] Starting discussions
ontheAccessibilityAPIproposal

My comments were centered on the specific technical implementation of
interoperability between the IT and AT. I wasnâ��t considering any sort of
regulatory or approval process.

Example: ITWidgetsRUs is creating a new piece of IT technology and wants
to be able to sell it to the Federal Government. They learn thereâ��s this
thing called Section 508 and that their widget must be accessible. So,
they want to make it so. But where do they start? The 508 requirements
seem daunting. Theyâ��ve never even heard of AT, much less know who to
contact, what exists, what to do, etc.

There ought to be a place where they can go to get started, get connected,
sign NDAâ��s, and begin the journey of making their widget accessible to
all. Thatâ��s the process Iâ��m talking about. Still not sure how the Access
Board would be involved.. But having consumers involved is always a good
idea â�� that often happens naturally as part of the product development
process (at least it should).

-Randy

From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
Reply-To: TEITAC General Interface Accessibility Subcommittee
< = EMAIL ADDRESS REMOVED = >
Date: Thu, 4 Jan 2007 14:52:55 -0600
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Cc: 'TEITAC General Interface Accessibility Subcommittee'
< = EMAIL ADDRESS REMOVED = >
Subject: Re: [teitac-general] [teitac-websoftware] Starting discussions
ontheAccessibilityAPIproposal

I think it needs to be at the Access-board level.

You can't have industry deciding what qualifies for â��passingâ�� the
government requirements and have it have any validity if a suit is
brought.

Also consumers need to be at the table â��

AND no matter what group of companies (IT and AT) you bring together,
others will complain they were not represented.

So AB is only one who could run such an operation I would think.

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

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy
Marsden
Sent: Thursday, January 04, 2007 11:44 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Starting discussions
ontheAccessibilityAPIproposal

I think there should be a consultative process put in place. Whether or
not that has to involve the Access Board is not clear to me. I think it
should be done at the industry level. I thought the suggestion of a
bugzilla-like website was interesting. That could be part of it (although
I donâ��t think that alone is enough). I believe the collaboration will
happen naturally in most cases, given a process, but if there is some
problem encountered in a specific interaction, perhaps a mediation
procedure could be part of the picture.

-Randy

From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
Reply-To: TEITAC Web/Software Subcommittee
< = EMAIL ADDRESS REMOVED = >
Date: Thu, 4 Jan 2007 11:01:14 -0500
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Subject: Re: [teitac-websoftware] Starting discussions ontheAccessibility
APIproposal

If I hear you correctly, Randy, you are proposing some sort of
consultative process that would be mediated by, or at least
would include participation by, regulators such as the Access Board. Is
that correct? One of our recommendations
might address this idea, as a way of providing continual refreshment.

From: Randy Marsden (Home) [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, January 04, 2007 2:07 AM
To: Gv@Trace. Edu; 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Starting discussions ontheAccessibility
APIproposal

Very well put, Gregg. Youâ��ve managed to put into words something I was
feeling but wasnâ��t sure how to express.

My opinion is we should refresh Section 508 in such a way that it
encourages the interaction even more between IT and AT vendors, and then
at an industry level, set up a way for that to happen in a somewhat more
formal way than we currently have.

-Randy, ATIA

From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
Date: Thu, 4 Jan 2007 00:51:57 -0600
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Cc: "'Randy Marsden'" < = EMAIL ADDRESS REMOVED = >
Subject: RE: [teitac-websoftware] Starting discussions on 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.
>
>

Previous message | Next message

From: terry.weaver@gsa.gov
Date: Thu, Jan 04 2007 4:25 PM
Subject: Re: Starting discussions ontheAccessibilityAPIproposal

But is insuring that AT companies can be competitive truly a government
function? Isn't our role one more of education - we let vendors know how
requirements and companies decide whether they have a product or service
they want to offer?

I don't see how we can create a government entity that has this role,
unless there is something I've missed.

"Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
Sent by: = EMAIL ADDRESS REMOVED =
01/04/2007 03:52 PM
Please respond to
"TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >

To
"'TEITAC Web/Software Subcommittee'" < = EMAIL ADDRESS REMOVED = >
cc
"'TEITAC General Interface Accessibility Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Subject
Re: [teitac-websoftware] Starting discussions
ontheAccessibilityAPIproposal

I think it needs to be at the Access-board level.

You can't have industry deciding what qualifies for â��passingâ�� the
government requirements and have it have any validity if a suit is
brought.

Also consumers need to be at the table â��

AND no matter what group of companies (IT and AT) you bring together,
others will complain they were not represented.

So AB is only one who could run such an operation I would think.

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

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy
Marsden
Sent: Thursday, January 04, 2007 11:44 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Starting discussions
ontheAccessibilityAPIproposal
I think there should be a consultative process put in place. Whether or
not that has to involve the Access Board is not clear to me. I think it
should be done at the industry level. I thought the suggestion of a
bugzilla-like website was interesting. That could be part of it (although
I donâ��t think that alone is enough). I believe the collaboration will
happen naturally in most cases, given a process, but if there is some
problem encountered in a specific interaction, perhaps a mediation
procedure could be part of the picture.

-Randy

From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
Reply-To: TEITAC Web/Software Subcommittee
< = EMAIL ADDRESS REMOVED = >
Date: Thu, 4 Jan 2007 11:01:14 -0500
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Subject: Re: [teitac-websoftware] Starting discussions ontheAccessibility
APIproposal

If I hear you correctly, Randy, you are proposing some sort of
consultative process that would be mediated by, or at least
would include participation by, regulators such as the Access Board. Is
that correct? One of our recommendations
might address this idea, as a way of providing continual refreshment.

From: Randy Marsden (Home) [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, January 04, 2007 2:07 AM
To: Gv@Trace. Edu; 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Starting discussions ontheAccessibility
APIproposal

Very well put, Gregg. Youâ��ve managed to put into words something I was
feeling but wasnâ��t sure how to express.

My opinion is we should refresh Section 508 in such a way that it
encourages the interaction even more between IT and AT vendors, and then
at an industry level, set up a way for that to happen in a somewhat more
formal way than we currently have.

-Randy, ATIA

From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
Date: Thu, 4 Jan 2007 00:51:57 -0600
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Cc: "'Randy Marsden'" < = EMAIL ADDRESS REMOVED = >
Subject: RE: [teitac-websoftware] Starting discussions on 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.
>
>

Previous message | Next message

From: terry.weaver@gsa.gov
Date: Thu, Jan 04 2007 4:30 PM
Subject: Re: Starting discussions ontheAccessibilityAPIproposal

Previous message | Next message

From: Randy Marsden (Home)
Date: Thu, Jan 11 2007 9:35 AM
Subject: Re: Accessibility API proposal

I think itÂ¹s time for us to weigh in on this subject. First, I agree with
what Gregg says below. Here are our additional thoughts from the
perspective of an AT manufacturer:

> * We like Accessibility APIÂ¹s (but not necessarily in 508). In fact, we have
> been advocating for them for years, and have worked extensively with the OS
> manufacturers to put them in. So, they are not something we are afraid of Â
> in fact, we helped design them and are a large part of why they exist! Our
> concern is that if we define a minimum set in 508, then that may become all
> that people work toward or support. That wouldnÂ¹t be a good thing. But there
> may be ways we can word things such that there is room for changes and/or
> growth to address that concern. WeÂ¹d like to explore that, because we do
> indeed see value in defining a set of standard APIÂ¹s.
>
> * We like cooperation. Defining a minimum set of APIÂ¹s potentially sets up a
> circumstance where an IT vendor can say Â³hey, we met the minimum Â so weÂ¹ve
> done our part. It must be the ATÂ¹s fault itÂ¹s not workingÂ². AT could answer
> Â³hey, we did tooÂ². Then the finger pointing begins. The reality is even with
> APIÂ¹s, there is usually technical tweaking and cooperation required between
> the IT and AT to make it all work. Speaking on a technical level, APIÂ¹s are
> very helpful, but not necessary a magic cure for all compatibility issues.
> WeÂ¹d prefer to see 508 create an environment that encourages cooperation to
> help guarantee interoperability. Some companies (HP, Microsoft, Apple, etc)
> actually have special developer programs for AT vendors that are very helpful.
> ThatÂ¹s an example of what weÂ¹d like to see 508 encourage.
>
> * We understand the issue of market power. We know there are times when
> procurement of an IT product can be inadvertently held up by AT, and that
> thatÂ¹s not good. ThatÂ¹s not in anyoneÂ¹s best interest Â certainly not the AT
> companiesÂ¹. We would much rather generate revenue from the sale of product
> than spend time customizing things. But there is not always a business case
> for AT companies to make their products work on all platforms Â even with an
> API set in place. Surely we canÂ¹t tell an AT company they must make a product
> that they arenÂ¹t going to sell any of, simply so an IT company can win a
> federal contract. So, there are valid concerns on both sides. We need to
> talk about it and figure out the best solution. APIÂ¹s may be part of that
> solution Â but we donÂ¹t believe they are the single magic answer.
>
> * We donÂ¹t mind accountability, but it needs to make sense. In many cases,
> the provisions of 508 would defeat the purpose for which the AT is developed.
> Often, AT is intended to serve a specific disability group, and is not
> supposed to be accessible for all. Take, for example, an eye-tracker ... if
> that was subject to 508, it would technically need to be accessible to someone
> who is blind. Makes no sense, right? Every time an AT company tried to sell
> this piece of equipment to the federal government, an argument and
> justification would need to be made explaining why it should be exempt from
> 508. ThatÂ¹s a lot of red tape for both the procurement officers and the
> vendors for something that is obviously not applicable.
>
> * We are motivated by compatibility. ItÂ¹s important to understand that the
> primary motivation for AT that is derived from Section 508 is the potential
> for enhanced compatibility with IT. Theoretically, that means our products
> work better and weÂ¹ll sell more of them. For many AT companies, federal
> government purchases represent only a small percentage of their business, so
> even if there were requirements for AT put in 508, they may not have the
> desired effect. Rather, if 508 sets up an environment that encourages
> interaction and collaboration between AT and IT, weÂ¹ll be all over it.

Randy & Jessica
ATIA

>
> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC Web/Software Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Wed, 10 Jan 2007 23:45:59 -0800
> To: "'TEITAC Web/Software Subcommittee'" < = EMAIL ADDRESS REMOVED = >
> 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
>
>
>
>

Previous message | Next message

From: David Poehlman
Date: Sat, Jan 20 2007 3:15 AM
Subject: Re: Accessibility API proposal

A couple of thoughts.

I think working this in such a way as to promote innovation and
continued evolution is a good thing. I agree that APIs alone are not
sufficient.. Perhaps the standard should contain the api with
additional language supporting future work and bee made a living
document not subject to the normal chanels of change but on a faster
track so as to keep up with developments.

As I see it, there are three possible positive outcomes.

1> software works on its own and can comply.
2> software works with existing apis et al.
and:
3> aT is developped with our API in mind so that when products are
built, they can more rreadily be made to fit the requirements of AT
and It which is not AT to work together. Oh, Is there ever a time
when IT is AT?

AS far as AT its self is concerned, the only way we can avoid
confusion as to whether it meets 508 is to special case it and for
that we'd probably need a base line approach. I don't see an
equitable way to exempt a class of product based on its stated
function. If we do that, AT for the blind suddenly becomes
acceptable if it cannot be operated with one hand or if it blacks the
screen... I'm not saying that we need to go to extremes here, but we
need to be careful of our approach.

Thanks!

On Jan 11, 2007, at 11:21 AM, Randy Marsden (Home) wrote:

I think itâ��s time for us to weigh in on this subject. First, I agree
with
what Gregg says below. Here are our additional thoughts from the
perspective of an AT manufacturer:

> * We like Accessibility APIâ��s (but not necessarily in 508). In
> fact, we have
> been advocating for them for years, and have worked extensively
> with the OS
> manufacturers to put them in. So, they are not something we are
> afraid of â��
> in fact, we helped design them and are a large part of why they
> exist! Our
> concern is that if we define a minimum set in 508, then that may
> become all
> that people work toward or support. That wouldnâ��t be a good
> thing. But there
> may be ways we can word things such that there is room for changes
> and/or
> growth to address that concern. Weâ��d like to explore that, because
> we do
> indeed see value in defining a set of standard APIâ��s.
>
> * We like cooperation. Defining a minimum set of APIâ��s potentially
> sets up a
> circumstance where an IT vendor can say â��hey, we met the minimum â��
> so weâ��ve
> done our part. It must be the ATâ��s fault itâ��s not workingâ��. AT
> could answer
> â��hey, we did tooâ��. Then the finger pointing begins. The reality is
> even with
> APIâ��s, there is usually technical tweaking and cooperation required
> between
> the IT and AT to make it all work. Speaking on a technical level,
> APIâ��s are
> very helpful, but not necessary a magic cure for all compatibility
> issues.
> Weâ��d prefer to see 508 create an environment that encourages
> cooperation to
> help guarantee interoperability. Some companies (HP, Microsoft,
> Apple, etc)
> actually have special developer programs for AT vendors that are
> very helpful.
> Thatâ��s an example of what weâ��d like to see 508 encourage.
>
> * We understand the issue of market power. We know there are times
> when
> procurement of an IT product can be inadvertently held up by AT,
> and that
> thatâ��s not good. Thatâ��s not in anyoneâ��s best interest â�� certainly
> not the AT
> companiesâ��. We would much rather generate revenue from the sale of
> product
> than spend time customizing things. But there is not always a
> business case
> for AT companies to make their products work on all platforms â��
> even with an
> API set in place. Surely we canâ��t tell an AT company they must
> make a product
> that they arenâ��t going to sell any of, simply so an IT company can
> win a
> federal contract. So, there are valid concerns on both sides. We
> need to
> talk about it and figure out the best solution. APIâ��s may be part
> of that
> solution â�� but we donâ��t believe they are the single magic answer.
>
> * We donâ��t mind accountability, but it needs to make sense. In
> many cases,
> the provisions of 508 would defeat the purpose for which the AT is
> developed.
> Often, AT is intended to serve a specific disability group, and is not
> supposed to be accessible for all. Take, for example, an eye-
> tracker ... if
> that was subject to 508, it would technically need to be accessible
> to someone
> who is blind. Makes no sense, right? Every time an AT company
> tried to sell
> this piece of equipment to the federal government, an argument and
> justification would need to be made explaining why it should be
> exempt from
> 508. Thatâ��s a lot of red tape for both the procurement officers
> and the
> vendors for something that is obviously not applicable.
>
> * We are motivated by compatibility. Itâ��s important to understand
> that the
> primary motivation for AT that is derived from Section 508 is the
> potential
> for enhanced compatibility with IT. Theoretically, that means our
> products
> work better and weâ��ll sell more of them. For many AT companies,
> federal
> government purchases represent only a small percentage of their
> business, so
> even if there were requirements for AT put in 508, they may not
> have the
> desired effect. Rather, if 508 sets up an environment that encourages
> interaction and collaboration between AT and IT, weâ��ll be all over it.

Randy & Jessica
ATIA

>
> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC Web/Software Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Wed, 10 Jan 2007 23:45:59 -0800
> To: "'TEITAC Web/Software Subcommittee'" <teitac-
> = EMAIL ADDRESS REMOVED = >
> 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
>
>
>
>

Previous message | Next message

From: Robinson, Norman B - Washington, DC
Date: Wed, Jan 24 2007 4:05 PM
Subject: Re: Accessibility API proposal

I'd say the real issue is that the _operating system_ itself
must be capable of supporting accessibility. The real test for an
operating system is if it provides APIs that support use by software in
ALL of the functional performance criteria of 1194.31. If it doesn't,
then the operating system isn't accessible and no software running on
that operating system will be accessible.

It is a chain. The operating system must support accessibility
and provide a standard way for software (an API) to provide
accessibility. The software can then be developed to meet the technical
standards for accessibility (software standards) and in specific content
issues (web content) that content can meet the specific standards
because the software (web browser) provides those features inherited
from the operating system.

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 David
Poehlman
Sent: Saturday, January 20, 2007 5:09 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Accessibility API proposal

A couple of thoughts.

I think working this in such a way as to promote innovation and
continued evolution is a good thing. I agree that APIs alone are not
sufficient.. Perhaps the standard should contain the api with
additional language supporting future work and bee made a living
document not subject to the normal chanels of change but on a faster
track so as to keep up with developments.

As I see it, there are three possible positive outcomes.

1> software works on its own and can comply.
2> software works with existing apis et al.
and:
3> aT is developped with our API in mind so that when products are
built, they can more rreadily be made to fit the requirements of AT
and It which is not AT to work together. Oh, Is there ever a time
when IT is AT?

AS far as AT its self is concerned, the only way we can avoid
confusion as to whether it meets 508 is to special case it and for
that we'd probably need a base line approach. I don't see an
equitable way to exempt a class of product based on its stated
function. If we do that, AT for the blind suddenly becomes
acceptable if it cannot be operated with one hand or if it blacks the
screen... I'm not saying that we need to go to extremes here, but we
need to be careful of our approach.

Thanks!

On Jan 11, 2007, at 11:21 AM, Randy Marsden (Home) wrote:

I think it's time for us to weigh in on this subject. First, I agree
with
what Gregg says below. Here are our additional thoughts from the
perspective of an AT manufacturer:

> * We like Accessibility API's (but not necessarily in 508). In
> fact, we have
> been advocating for them for years, and have worked extensively
> with the OS
> manufacturers to put them in. So, they are not something we are
> afraid of -
> in fact, we helped design them and are a large part of why they
> exist! Our
> concern is that if we define a minimum set in 508, then that may
> become all
> that people work toward or support. That wouldn't be a good
> thing. But there
> may be ways we can word things such that there is room for changes
> and/or
> growth to address that concern. We'd like to explore that, because
> we do
> indeed see value in defining a set of standard API's.
>
> * We like cooperation. Defining a minimum set of API's potentially
> sets up a
> circumstance where an IT vendor can say "hey, we met the minimum -
> so we've
> done our part. It must be the AT's fault it's not working". AT
> could answer
> "hey, we did too". Then the finger pointing begins. The reality is
> even with
> API's, there is usually technical tweaking and cooperation required
> between
> the IT and AT to make it all work. Speaking on a technical level,
> API's are
> very helpful, but not necessary a magic cure for all compatibility
> issues.
> We'd prefer to see 508 create an environment that encourages
> cooperation to
> help guarantee interoperability. Some companies (HP, Microsoft,
> Apple, etc)
> actually have special developer programs for AT vendors that are
> very helpful.
> That's an example of what we'd like to see 508 encourage.
>
> * We understand the issue of market power. We know there are times
> when
> procurement of an IT product can be inadvertently held up by AT,
> and that
> that's not good. That's not in anyone's best interest - certainly
> not the AT
> companies'. We would much rather generate revenue from the sale of
> product
> than spend time customizing things. But there is not always a
> business case
> for AT companies to make their products work on all platforms -
> even with an
> API set in place. Surely we can't tell an AT company they must
> make a product
> that they aren't going to sell any of, simply so an IT company can
> win a
> federal contract. So, there are valid concerns on both sides. We
> need to
> talk about it and figure out the best solution. API's may be part
> of that
> solution - but we don't believe they are the single magic answer.
>
> * We don't mind accountability, but it needs to make sense. In
> many cases,
> the provisions of 508 would defeat the purpose for which the AT is
> developed.
> Often, AT is intended to serve a specific disability group, and is not
> supposed to be accessible for all. Take, for example, an eye-
> tracker ... if
> that was subject to 508, it would technically need to be accessible
> to someone
> who is blind. Makes no sense, right? Every time an AT company
> tried to sell
> this piece of equipment to the federal government, an argument and
> justification would need to be made explaining why it should be
> exempt from
> 508. That's a lot of red tape for both the procurement officers
> and the
> vendors for something that is obviously not applicable.
>
> * We are motivated by compatibility. It's important to understand
> that the
> primary motivation for AT that is derived from Section 508 is the
> potential
> for enhanced compatibility with IT. Theoretically, that means our
> products
> work better and we'll sell more of them. For many AT companies,
> federal
> government purchases represent only a small percentage of their
> business, so
> even if there were requirements for AT put in 508, they may not
> have the
> desired effect. Rather, if 508 sets up an environment that encourages
> interaction and collaboration between AT and IT, we'll be all over it.

Randy & Jessica
ATIA

>
> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC Web/Software Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Wed, 10 Jan 2007 23:45:59 -0800
> To: "'TEITAC Web/Software Subcommittee'" <teitac-
> = EMAIL ADDRESS REMOVED = >
> 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
>
>
>
>

Previous message | Next message

From: Gregg Vanderheiden
Date: Wed, Jan 24 2007 9:50 PM
Subject: Re: Accessibility API proposal

The application could of course provide direct access, as you mentioned in
another email. Then the OS would not be relevant. On Kiosks for example,
accessibility of the OS is not that relevant. But built in accessibility
would be.

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson, Norman B - Washington, DC
> Sent: Wednesday, January 24, 2007 5:01 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> I'd say the real issue is that the _operating system_
> itself must be capable of supporting accessibility. The real
> test for an operating system is if it provides APIs that
> support use by software in ALL of the functional performance
> criteria of 1194.31. If it doesn't, then the operating system
> isn't accessible and no software running on that operating
> system will be accessible.
>
> It is a chain. The operating system must support
> accessibility and provide a standard way for software (an
> API) to provide accessibility. The software can then be
> developed to meet the technical standards for accessibility
> (software standards) and in specific content issues (web
> content) that content can meet the specific standards because
> the software (web browser) provides those features inherited
> from the operating system.
>
> 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 David Poehlman
> Sent: Saturday, January 20, 2007 5:09 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> A couple of thoughts.
>
> I think working this in such a way as to promote innovation
> and continued evolution is a good thing. I agree that APIs
> alone are not sufficient.. Perhaps the standard should
> contain the api with additional language supporting future
> work and bee made a living document not subject to the normal
> chanels of change but on a faster track so as to keep up with
> developments.
>
> As I see it, there are three possible positive outcomes.
>
> 1> software works on its own and can comply.
> 2> software works with existing apis et al.
> and:
> 3> aT is developped with our API in mind so that when products are
> built, they can more rreadily be made to fit the requirements
> of AT and It which is not AT to work together. Oh, Is there
> ever a time when IT is AT?
>
> AS far as AT its self is concerned, the only way we can avoid
> confusion as to whether it meets 508 is to special case it
> and for that we'd probably need a base line approach. I
> don't see an equitable way to exempt a class of product based
> on its stated function. If we do that, AT for the blind
> suddenly becomes acceptable if it cannot be operated with one
> hand or if it blacks the screen... I'm not saying that we
> need to go to extremes here, but we need to be careful of our
> approach.
>
> Thanks!
>
> On Jan 11, 2007, at 11:21 AM, Randy Marsden (Home) wrote:
>
> I think it's time for us to weigh in on this subject. First,
> I agree with what Gregg says below. Here are our additional
> thoughts from the perspective of an AT manufacturer:
>
> > * We like Accessibility API's (but not necessarily in 508).
> In fact,
> > we have been advocating for them for years, and have worked
> > extensively with the OS manufacturers to put them in. So, they are
> > not something we are afraid of - in fact, we helped design them and
> > are a large part of why they exist! Our concern is that if
> we define a
> > minimum set in 508, then that may become all that people
> work toward
> > or support. That wouldn't be a good thing. But there may
> be ways we
> > can word things such that there is room for changes and/or
> growth to
> > address that concern. We'd like to explore that, because
> we do indeed
> > see value in defining a set of standard API's.
> >
> > * We like cooperation. Defining a minimum set of API's potentially
> > sets up a circumstance where an IT vendor can say "hey, we met the
> > minimum - so we've done our part. It must be the AT's
> fault it's not
> > working". AT could answer "hey, we did too". Then the finger
> > pointing begins. The reality is even with API's, there is usually
> > technical tweaking and cooperation required between the IT
> and AT to
> > make it all work. Speaking on a technical level, API's are very
> > helpful, but not necessary a magic cure for all
> compatibility issues.
> > We'd prefer to see 508 create an environment that encourages
> > cooperation to help guarantee interoperability. Some companies (HP,
> > Microsoft, Apple, etc) actually have special developer
> programs for AT
> > vendors that are very helpful.
> > That's an example of what we'd like to see 508 encourage.
> >
> > * We understand the issue of market power. We know there are times
> > when procurement of an IT product can be inadvertently held
> up by AT,
> > and that that's not good. That's not in anyone's best interest -
> > certainly not the AT companies'. We would much rather generate
> > revenue from the sale of product than spend time
> customizing things.
> > But there is not always a business case for AT companies to
> make their
> > products work on all platforms - even with an API set in place.
> > Surely we can't tell an AT company they must make a product
> that they
> > aren't going to sell any of, simply so an IT company can
> win a federal
> > contract. So, there are valid concerns on both sides. We need to
> > talk about it and figure out the best solution. API's may
> be part of
> > that solution - but we don't believe they are the single
> magic answer.
> >
> > * We don't mind accountability, but it needs to make sense.
> In many
> > cases, the provisions of 508 would defeat the purpose for
> which the AT
> > is developed.
> > Often, AT is intended to serve a specific disability group,
> and is not
> > supposed to be accessible for all. Take, for example, an eye-
> > tracker ... if that was subject to 508, it would
> technically need to
> > be accessible to someone who is blind. Makes no sense,
> right? Every
> > time an AT company tried to sell this piece of equipment to the
> > federal government, an argument and justification would need to be
> > made explaining why it should be exempt from 508. That's a
> lot of red
> > tape for both the procurement officers and the vendors for
> something
> > that is obviously not applicable.
> >
> > * We are motivated by compatibility. It's important to understand
> > that the primary motivation for AT that is derived from
> Section 508 is
> > the potential for enhanced compatibility with IT.
> Theoretically, that
> > means our products work better and we'll sell more of them.
> For many
> > AT companies, federal government purchases represent only a small
> > percentage of their business, so even if there were
> requirements for
> > AT put in 508, they may not have the desired effect.
> Rather, if 508
> > sets up an environment that encourages interaction and
> collaboration
> > between AT and IT, we'll be all over it.
>
> Randy & Jessica
> ATIA
>
> >
> > From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> > Reply-To: TEITAC Web/Software Subcommittee
> > < = EMAIL ADDRESS REMOVED = >
> > Date: Wed, 10 Jan 2007 23:45:59 -0800
> > To: "'TEITAC Web/Software Subcommittee'" <teitac-
> > = EMAIL ADDRESS REMOVED = >
> > 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
> >
> >
> >
> >
>
>
>

Previous message | Next message

From: Robinson, Norman B - Washington, DC
Date: Thu, Jan 25 2007 12:40 PM
Subject: Re: Accessibility API proposal

Gregg,

Could you please give me an example of direct access? For all
our kiosk implementations the accessibility is provided via the
operating system functions or software that relies on the operating
system functions.

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: Wednesday, January 24, 2007 11:49 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Accessibility API proposal

The application could of course provide direct access, as you mentioned
in
another email. Then the OS would not be relevant. On Kiosks for
example,
accessibility of the OS is not that relevant. But built in
accessibility
would be.

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson, Norman B - Washington, DC
> Sent: Wednesday, January 24, 2007 5:01 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> I'd say the real issue is that the _operating system_
> itself must be capable of supporting accessibility. The real
> test for an operating system is if it provides APIs that
> support use by software in ALL of the functional performance
> criteria of 1194.31. If it doesn't, then the operating system
> isn't accessible and no software running on that operating
> system will be accessible.
>
> It is a chain. The operating system must support
> accessibility and provide a standard way for software (an
> API) to provide accessibility. The software can then be
> developed to meet the technical standards for accessibility
> (software standards) and in specific content issues (web
> content) that content can meet the specific standards because
> the software (web browser) provides those features inherited
> from the operating system.
>
> 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 David Poehlman
> Sent: Saturday, January 20, 2007 5:09 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> A couple of thoughts.
>
> I think working this in such a way as to promote innovation
> and continued evolution is a good thing. I agree that APIs
> alone are not sufficient.. Perhaps the standard should
> contain the api with additional language supporting future
> work and bee made a living document not subject to the normal
> chanels of change but on a faster track so as to keep up with
> developments.
>
> As I see it, there are three possible positive outcomes.
>
> 1> software works on its own and can comply.
> 2> software works with existing apis et al.
> and:
> 3> aT is developped with our API in mind so that when products are
> built, they can more rreadily be made to fit the requirements
> of AT and It which is not AT to work together. Oh, Is there
> ever a time when IT is AT?
>
> AS far as AT its self is concerned, the only way we can avoid
> confusion as to whether it meets 508 is to special case it
> and for that we'd probably need a base line approach. I
> don't see an equitable way to exempt a class of product based
> on its stated function. If we do that, AT for the blind
> suddenly becomes acceptable if it cannot be operated with one
> hand or if it blacks the screen... I'm not saying that we
> need to go to extremes here, but we need to be careful of our
> approach.
>
> Thanks!
>
> On Jan 11, 2007, at 11:21 AM, Randy Marsden (Home) wrote:
>
> I think it's time for us to weigh in on this subject. First,
> I agree with what Gregg says below. Here are our additional
> thoughts from the perspective of an AT manufacturer:
>
> > * We like Accessibility API's (but not necessarily in 508).
> In fact,
> > we have been advocating for them for years, and have worked
> > extensively with the OS manufacturers to put them in. So, they are
> > not something we are afraid of - in fact, we helped design them and
> > are a large part of why they exist! Our concern is that if
> we define a
> > minimum set in 508, then that may become all that people
> work toward
> > or support. That wouldn't be a good thing. But there may
> be ways we
> > can word things such that there is room for changes and/or
> growth to
> > address that concern. We'd like to explore that, because
> we do indeed
> > see value in defining a set of standard API's.
> >
> > * We like cooperation. Defining a minimum set of API's potentially
> > sets up a circumstance where an IT vendor can say "hey, we met the
> > minimum - so we've done our part. It must be the AT's
> fault it's not
> > working". AT could answer "hey, we did too". Then the finger
> > pointing begins. The reality is even with API's, there is usually
> > technical tweaking and cooperation required between the IT
> and AT to
> > make it all work. Speaking on a technical level, API's are very
> > helpful, but not necessary a magic cure for all
> compatibility issues.
> > We'd prefer to see 508 create an environment that encourages
> > cooperation to help guarantee interoperability. Some companies (HP,
> > Microsoft, Apple, etc) actually have special developer
> programs for AT
> > vendors that are very helpful.
> > That's an example of what we'd like to see 508 encourage.
> >
> > * We understand the issue of market power. We know there are times
> > when procurement of an IT product can be inadvertently held
> up by AT,
> > and that that's not good. That's not in anyone's best interest -
> > certainly not the AT companies'. We would much rather generate
> > revenue from the sale of product than spend time
> customizing things.
> > But there is not always a business case for AT companies to
> make their
> > products work on all platforms - even with an API set in place.
> > Surely we can't tell an AT company they must make a product
> that they
> > aren't going to sell any of, simply so an IT company can
> win a federal
> > contract. So, there are valid concerns on both sides. We need to
> > talk about it and figure out the best solution. API's may
> be part of
> > that solution - but we don't believe they are the single
> magic answer.
> >
> > * We don't mind accountability, but it needs to make sense.
> In many
> > cases, the provisions of 508 would defeat the purpose for
> which the AT
> > is developed.
> > Often, AT is intended to serve a specific disability group,
> and is not
> > supposed to be accessible for all. Take, for example, an eye-
> > tracker ... if that was subject to 508, it would
> technically need to
> > be accessible to someone who is blind. Makes no sense,
> right? Every
> > time an AT company tried to sell this piece of equipment to the
> > federal government, an argument and justification would need to be
> > made explaining why it should be exempt from 508. That's a
> lot of red
> > tape for both the procurement officers and the vendors for
> something
> > that is obviously not applicable.
> >
> > * We are motivated by compatibility. It's important to understand
> > that the primary motivation for AT that is derived from
> Section 508 is
> > the potential for enhanced compatibility with IT.
> Theoretically, that
> > means our products work better and we'll sell more of them.
> For many
> > AT companies, federal government purchases represent only a small
> > percentage of their business, so even if there were
> requirements for
> > AT put in 508, they may not have the desired effect.
> Rather, if 508
> > sets up an environment that encourages interaction and
> collaboration
> > between AT and IT, we'll be all over it.
>
> Randy & Jessica
> ATIA
>
> >
> > From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> > Reply-To: TEITAC Web/Software Subcommittee
> > < = EMAIL ADDRESS REMOVED = >
> > Date: Wed, 10 Jan 2007 23:45:59 -0800
> > To: "'TEITAC Web/Software Subcommittee'" <teitac-
> > = EMAIL ADDRESS REMOVED = >
> > 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
> >
> >
> >
> >
>
>
>

Previous message | Next message

From: Gregg Vanderheiden
Date: Thu, Jan 25 2007 10:10 PM
Subject: Re: Accessibility API proposal

Example? - How about the post offices automated postal stations. They
have touch screens but also tactile controls and voice output that allow you
to access all functions from the tactile controls. (you can also use the
same controls near the front of the system to control the APS visually
(without audio) and without using the touch screen).

Question: Could you explain what you mean by providing access via OS
functions? For example , how do you provide access for blind people to
touch screen kiosks using built in OS features?

Thanks

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson, Norman B - Washington, DC
> Sent: Thursday, January 25, 2007 1:38 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> Gregg,
>
> Could you please give me an example of direct access?
> For all our kiosk implementations the accessibility is
> provided via the operating system functions or software that
> relies on the operating system functions.
>
> 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: Wednesday, January 24, 2007 11:49 PM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> The application could of course provide direct access, as you
> mentioned in
> another email. Then the OS would not be relevant. On Kiosks for
> example,
> accessibility of the OS is not that relevant. But built in
> accessibility would be.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Robinson, Norman B - Washington, DC
> > Sent: Wednesday, January 24, 2007 5:01 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] Accessibility API proposal
> >
> >
> > I'd say the real issue is that the _operating system_
> itself must be
> > capable of supporting accessibility. The real test for an operating
> > system is if it provides APIs that support use by software
> in ALL of
> > the functional performance criteria of 1194.31. If it doesn't, then
> > the operating system isn't accessible and no software
> running on that
> > operating system will be accessible.
> >
> > It is a chain. The operating system must support
> accessibility and
> > provide a standard way for software (an
> > API) to provide accessibility. The software can then be
> developed to
> > meet the technical standards for accessibility (software standards)
> > and in specific content issues (web
> > content) that content can meet the specific standards because the
> > software (web browser) provides those features inherited from the
> > operating system.
> >
> > 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 David
> > Poehlman
> > Sent: Saturday, January 20, 2007 5:09 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] Accessibility API proposal
> >
> >
> > A couple of thoughts.
> >
> > I think working this in such a way as to promote innovation and
> > continued evolution is a good thing. I agree that APIs
> alone are not
> > sufficient.. Perhaps the standard should contain the api with
> > additional language supporting future work and bee made a living
> > document not subject to the normal chanels of change but on
> a faster
> > track so as to keep up with developments.
> >
> > As I see it, there are three possible positive outcomes.
> >
> > 1> software works on its own and can comply.
> > 2> software works with existing apis et al.
> > and:
> > 3> aT is developped with our API in mind so that when products are
> > built, they can more rreadily be made to fit the requirements of AT
> > and It which is not AT to work together. Oh, Is there ever a time
> > when IT is AT?
> >
> > AS far as AT its self is concerned, the only way we can avoid
> > confusion as to whether it meets 508 is to special case it and for
> > that we'd probably need a base line approach. I don't see an
> > equitable way to exempt a class of product based on its stated
> > function. If we do that, AT for the blind suddenly becomes
> acceptable
> > if it cannot be operated with one hand or if it blacks the
> screen...
> > I'm not saying that we need to go to extremes here, but we
> need to be
> > careful of our approach.
> >
> > Thanks!
> >
> > On Jan 11, 2007, at 11:21 AM, Randy Marsden (Home) wrote:
> >
> > I think it's time for us to weigh in on this subject.
> First, I agree
> > with what Gregg says below. Here are our additional
> thoughts from the
> > perspective of an AT manufacturer:
> >
> > > * We like Accessibility API's (but not necessarily in 508).
> > In fact,
> > > we have been advocating for them for years, and have worked
> > > extensively with the OS manufacturers to put them in.
> So, they are
> > > not something we are afraid of - in fact, we helped
> design them and
> > > are a large part of why they exist! Our concern is that if
> > we define a
> > > minimum set in 508, then that may become all that people
> > work toward
> > > or support. That wouldn't be a good thing. But there may
> > be ways we
> > > can word things such that there is room for changes and/or
> > growth to
> > > address that concern. We'd like to explore that, because
> > we do indeed
> > > see value in defining a set of standard API's.
> > >
> > > * We like cooperation. Defining a minimum set of API's
> potentially
> > > sets up a circumstance where an IT vendor can say "hey,
> we met the
> > > minimum - so we've done our part. It must be the AT's
> > fault it's not
> > > working". AT could answer "hey, we did too". Then the finger
> > > pointing begins. The reality is even with API's, there is usually
> > > technical tweaking and cooperation required between the IT
> > and AT to
> > > make it all work. Speaking on a technical level, API's are very
> > > helpful, but not necessary a magic cure for all
> > compatibility issues.
> > > We'd prefer to see 508 create an environment that encourages
> > > cooperation to help guarantee interoperability. Some
> companies (HP,
> > > Microsoft, Apple, etc) actually have special developer
> > programs for AT
> > > vendors that are very helpful.
> > > That's an example of what we'd like to see 508 encourage.
> > >
> > > * We understand the issue of market power. We know there
> are times
> > > when procurement of an IT product can be inadvertently held
> > up by AT,
> > > and that that's not good. That's not in anyone's best interest -
> > > certainly not the AT companies'. We would much rather generate
> > > revenue from the sale of product than spend time
> > customizing things.
> > > But there is not always a business case for AT companies to
> > make their
> > > products work on all platforms - even with an API set in place.
> > > Surely we can't tell an AT company they must make a product
> > that they
> > > aren't going to sell any of, simply so an IT company can
> > win a federal
> > > contract. So, there are valid concerns on both sides.
> We need to
> > > talk about it and figure out the best solution. API's may
> > be part of
> > > that solution - but we don't believe they are the single
> > magic answer.
> > >
> > > * We don't mind accountability, but it needs to make sense.
> > In many
> > > cases, the provisions of 508 would defeat the purpose for
> > which the AT
> > > is developed.
> > > Often, AT is intended to serve a specific disability group,
> > and is not
> > > supposed to be accessible for all. Take, for example, an eye-
> > > tracker ... if that was subject to 508, it would
> > technically need to
> > > be accessible to someone who is blind. Makes no sense,
> > right? Every
> > > time an AT company tried to sell this piece of equipment to the
> > > federal government, an argument and justification would
> need to be
> > > made explaining why it should be exempt from 508. That's a
> > lot of red
> > > tape for both the procurement officers and the vendors for
> > something
> > > that is obviously not applicable.
> > >
> > > * We are motivated by compatibility. It's important to
> understand
> > > that the primary motivation for AT that is derived from
> > Section 508 is
> > > the potential for enhanced compatibility with IT.
> > Theoretically, that
> > > means our products work better and we'll sell more of them.
> > For many
> > > AT companies, federal government purchases represent only a small
> > > percentage of their business, so even if there were
> > requirements for
> > > AT put in 508, they may not have the desired effect.
> > Rather, if 508
> > > sets up an environment that encourages interaction and
> > collaboration
> > > between AT and IT, we'll be all over it.
> >
> > Randy & Jessica
> > ATIA
> >
> > >
> > > From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> > > Reply-To: TEITAC Web/Software Subcommittee
> > > < = EMAIL ADDRESS REMOVED = >
> > > Date: Wed, 10 Jan 2007 23:45:59 -0800
> > > To: "'TEITAC Web/Software Subcommittee'" <teitac-
> > > = EMAIL ADDRESS REMOVED = >
> > > 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
> > >
> > >
> > >
> > >
> >
> >
> >

Previous message | Next message

From: Jim Tobias
Date: Fri, Jan 26 2007 7:10 AM
Subject: Re: Accessibility API proposal

I think we are using two different meanings for "direct". Gregg means it to
refer to accessibility features built into the product, therefore not
requiring
the user to load any AT. Norman means it as somehow skipping the OS, or in
products that don't have an OS. In Gregg's example, the touchscreen,
tactile
controls, and voice output either rely or don't rely on underlying OS
features,
utilities that enable the very presence of such input and output
capabilities.
I think Gregg would agree that they do rely on an OS, leaving aside for the
moment how we define "OS".

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias

-----Original Message-----
From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, January 26, 2007 12:08 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Accessibility API proposal

Example? - How about the post offices automated postal stations. They
have touch screens but also tactile controls and voice output that allow you
to access all functions from the tactile controls. (you can also use the
same controls near the front of the system to control the APS visually
(without audio) and without using the touch screen).

Question: Could you explain what you mean by providing access via OS
functions? For example , how do you provide access for blind people to
touch screen kiosks using built in OS features?

Thanks

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Robinson, Norman B - Washington, DC
> Sent: Thursday, January 25, 2007 1:38 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> Gregg,
>
> Could you please give me an example of direct access?
> For all our kiosk implementations the accessibility is provided via
> the operating system functions or software that relies on the
> operating system functions.
>
> 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: Wednesday, January 24, 2007 11:49 PM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> The application could of course provide direct access, as you
> mentioned in
> another email. Then the OS would not be relevant. On Kiosks for
> example,
> accessibility of the OS is not that relevant. But built in
> accessibility would be.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Robinson, Norman B - Washington, DC
> > Sent: Wednesday, January 24, 2007 5:01 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] Accessibility API proposal
> >
> >
> > I'd say the real issue is that the _operating system_
> itself must be
> > capable of supporting accessibility. The real test for an operating
> > system is if it provides APIs that support use by software
> in ALL of
> > the functional performance criteria of 1194.31. If it doesn't, then
> > the operating system isn't accessible and no software
> running on that
> > operating system will be accessible.
> >
> > It is a chain. The operating system must support
> accessibility and
> > provide a standard way for software (an
> > API) to provide accessibility. The software can then be
> developed to
> > meet the technical standards for accessibility (software standards)
> > and in specific content issues (web
> > content) that content can meet the specific standards because the
> > software (web browser) provides those features inherited from the
> > operating system.
> >
> > 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 David
> > Poehlman
> > Sent: Saturday, January 20, 2007 5:09 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] Accessibility API proposal
> >
> >
> > A couple of thoughts.
> >
> > I think working this in such a way as to promote innovation and
> > continued evolution is a good thing. I agree that APIs
> alone are not
> > sufficient.. Perhaps the standard should contain the api with
> > additional language supporting future work and bee made a living
> > document not subject to the normal chanels of change but on
> a faster
> > track so as to keep up with developments.
> >
> > As I see it, there are three possible positive outcomes.
> >
> > 1> software works on its own and can comply.
> > 2> software works with existing apis et al.
> > and:
> > 3> aT is developped with our API in mind so that when products are
> > built, they can more rreadily be made to fit the requirements of AT
> > and It which is not AT to work together. Oh, Is there ever a time
> > when IT is AT?
> >
> > AS far as AT its self is concerned, the only way we can avoid
> > confusion as to whether it meets 508 is to special case it and for
> > that we'd probably need a base line approach. I don't see an
> > equitable way to exempt a class of product based on its stated
> > function. If we do that, AT for the blind suddenly becomes
> acceptable
> > if it cannot be operated with one hand or if it blacks the
> screen...
> > I'm not saying that we need to go to extremes here, but we
> need to be
> > careful of our approach.
> >
> > Thanks!
> >
> > On Jan 11, 2007, at 11:21 AM, Randy Marsden (Home) wrote:
> >
> > I think it's time for us to weigh in on this subject.
> First, I agree
> > with what Gregg says below. Here are our additional
> thoughts from the
> > perspective of an AT manufacturer:
> >
> > > * We like Accessibility API's (but not necessarily in 508).
> > In fact,
> > > we have been advocating for them for years, and have worked
> > > extensively with the OS manufacturers to put them in.
> So, they are
> > > not something we are afraid of - in fact, we helped
> design them and
> > > are a large part of why they exist! Our concern is that if
> > we define a
> > > minimum set in 508, then that may become all that people
> > work toward
> > > or support. That wouldn't be a good thing. But there may
> > be ways we
> > > can word things such that there is room for changes and/or
> > growth to
> > > address that concern. We'd like to explore that, because
> > we do indeed
> > > see value in defining a set of standard API's.
> > >
> > > * We like cooperation. Defining a minimum set of API's
> potentially
> > > sets up a circumstance where an IT vendor can say "hey,
> we met the
> > > minimum - so we've done our part. It must be the AT's
> > fault it's not
> > > working". AT could answer "hey, we did too". Then the finger
> > > pointing begins. The reality is even with API's, there is usually
> > > technical tweaking and cooperation required between the IT
> > and AT to
> > > make it all work. Speaking on a technical level, API's are very
> > > helpful, but not necessary a magic cure for all
> > compatibility issues.
> > > We'd prefer to see 508 create an environment that encourages
> > > cooperation to help guarantee interoperability. Some
> companies (HP,
> > > Microsoft, Apple, etc) actually have special developer
> > programs for AT
> > > vendors that are very helpful.
> > > That's an example of what we'd like to see 508 encourage.
> > >
> > > * We understand the issue of market power. We know there
> are times
> > > when procurement of an IT product can be inadvertently held
> > up by AT,
> > > and that that's not good. That's not in anyone's best interest -
> > > certainly not the AT companies'. We would much rather generate
> > > revenue from the sale of product than spend time
> > customizing things.
> > > But there is not always a business case for AT companies to
> > make their
> > > products work on all platforms - even with an API set in place.
> > > Surely we can't tell an AT company they must make a product
> > that they
> > > aren't going to sell any of, simply so an IT company can
> > win a federal
> > > contract. So, there are valid concerns on both sides.
> We need to
> > > talk about it and figure out the best solution. API's may
> > be part of
> > > that solution - but we don't believe they are the single
> > magic answer.
> > >
> > > * We don't mind accountability, but it needs to make sense.
> > In many
> > > cases, the provisions of 508 would defeat the purpose for
> > which the AT
> > > is developed.
> > > Often, AT is intended to serve a specific disability group,
> > and is not
> > > supposed to be accessible for all. Take, for example, an eye-
> > > tracker ... if that was subject to 508, it would
> > technically need to
> > > be accessible to someone who is blind. Makes no sense,
> > right? Every
> > > time an AT company tried to sell this piece of equipment to the
> > > federal government, an argument and justification would
> need to be
> > > made explaining why it should be exempt from 508. That's a
> > lot of red
> > > tape for both the procurement officers and the vendors for
> > something
> > > that is obviously not applicable.
> > >
> > > * We are motivated by compatibility. It's important to
> understand
> > > that the primary motivation for AT that is derived from
> > Section 508 is
> > > the potential for enhanced compatibility with IT.
> > Theoretically, that
> > > means our products work better and we'll sell more of them.
> > For many
> > > AT companies, federal government purchases represent only a small
> > > percentage of their business, so even if there were
> > requirements for
> > > AT put in 508, they may not have the desired effect.
> > Rather, if 508
> > > sets up an environment that encourages interaction and
> > collaboration
> > > between AT and IT, we'll be all over it.
> >
> > Randy & Jessica
> > ATIA
> >
> > >
> > > From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> > > Reply-To: TEITAC Web/Software Subcommittee
> > > < = EMAIL ADDRESS REMOVED = >
> > > Date: Wed, 10 Jan 2007 23:45:59 -0800
> > > To: "'TEITAC Web/Software Subcommittee'" <teitac-
> > > = EMAIL ADDRESS REMOVED = >
> > > 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
> > >
> > >
> > >
> > >
> >
> >
> >

Previous message | Next message

From: Robinson, Norman B - Washington, DC
Date: Fri, Jan 26 2007 11:50 AM
Subject: Re: Accessibility API proposal

Gregg,

Thanks!

I'm trying to constrain my response to the subject, that being
Accessibility Application Programming Interface (API) (specifically
software and not hardware), however your example is worth interpreting
as I think I have the responsibility to be clear in my posts.

1. Automated postal stations have touch screens (hardware) that
interface with the driver software running on the operating system.
2. Tactile controls running on the same system are keys or in
effect a keyboard (hardware) that interface with the operating system.
3. Voice output is actually designed into the software
application itself and directed to the earplug or speaker (hardware) via
the operating system.

My point is that those are _hardware_ or physical requirements
that should be in the refresh, but I don't like the term "closed, self
contained" as the category or labeling of such doesn't help us as we get
to many integrated devices. The concepts fail and people reading and
interpreting the technical standards when creating devices with physical
interfaces (e.g., touch screens, keys and keyboards, connectors) are
better served by being told about the functional requirements for
physical hardware and not having to ask "Is this closed? Is this
self-contained?" So I suggest the refresh simply consolidate all the
technical requirements for hardware in one section and do away with
"closed, self-contained".

Back to concepts of an accessibility API. I won't ever use API
to refer to hardware, as I think it is purely a term related to
software. We could use the term "interfaces" but then we could fit
hardware back into the discussion (e.g., hardware interfaces as a term)
so perhaps "software interfaces" is most clear and I should use that
from now on.

What I mean by providing access via operating system functions
is that when manufacturers design software to work with hardware they
choose the appropriate operating system for their application. The
operating system provides a level of accessibility and abstraction to
the software so the vendor doesn't have to create their own operating
system functions. Most operating systems provide abstractions for
accessibility functions through the specific software interfaces to
enable functions such as on-screen keyboards, visual alerts, captioning,
and event updates (e.g., interface windows opening, windows or software
views being refreshed such as a web page reloading) via accessibility
APIs.

From a programming perspective, if I create window for my new
web browser, you may see a web browser, but it is a window, created by
the operating system. It usually has the expected "Close Window",
"Maximize Window", "Minimize Window" widgets. The API that allows this
also has information such as the window name (e.g., Mozilla Firefox)
obtained from the same API used that a screen reader would use to voice
the name of the window. And when the first window is opened (the program
starts) the screen reader gets the event, through the API, thus knows to
read the event. What I'm saying, relevant to the Section 508 refresh, is
that we can consider well-known accessibility interfaces as functional
specifications for the refresh. We might find value in requiring
operating systems to meet all the functional specifications to be
considered Section 508 compliant. In terms of suggesting we should
require this in the refresh, I don't see how we can do anything else,
other than to say the existing technical standards for software and
operating systems already describe functional requirements, but we don't
have a clearly defined statement that says "Yes, the operating system
has to support accessibility or else your software would have to
(re)create all these basic functions".

Finally to answer your question "How do you provide access for
blind people to touch screen kiosks using built in OS features?" I say
that I design my software (in our example the interface running on the
automate postal stations) using the frameworks provided by the operating
systems accessibility interfaces. When I expect the physical buttons to
provide an enter-key event I could also state "press any key or touch
the screen to continue". For that physical function I have the software
provide interaction using the standard interface events, so that if I
enabled visual alerts I could get flashing and the error beep. I could
get the vendor to show us which software development framework they
used. Otherwise I'd have to code both of those into each and every
screen myself (as a programmer). Also, by using things like the
operating system accessibility software interface I can do things *I*
didn't program in such as later enabling an on-screen keyboard (since my
program only expected key entry, who cares how it gets the key
information) or perhaps enabling bluetooth keyboard access so I can use
my own keyboard. This includes enhancing and adding on to the system
which is where I see failure and risk; most systems I've evaluated as
Section 508 compliance have sometimes fallen out of compliance because
of updates, not due to entropy.

It is also important to know in our hypothetical versus
real-world examples the automated postal station are self-voicing but
there is not a screen reader. The vendor has to record voice events and
voice descriptions for each and every screen. It is laborious, tedious,
error-prone, doesn't dynamically update with content changes, and
probably isn't the best way to go about implementing the system. But
that is how it is done today and I've taking this into consideration in
speaking to the concepts of an accessibility software interface or
accessibility API.

In terms of actionable events I'd like to see something that
states operating systems must provide accessibility APIs that meet the
Section 508 functional performance criteria (currently Subpart C). I'd
argue that is already required today as an operating systems are
software thus 1194.21 applies, however no where does it require that the
OS software provide accessibility information to _other_ software. It is
simply the best practice, has been implemented as such on multiple
operating systems, but I think the refresh could make this relationship
clear without adversely impacting industry and doing so would further
the cause of 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: Friday, January 26, 2007 12:08 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Accessibility API proposal

Example? - How about the post offices automated postal stations.
They
have touch screens but also tactile controls and voice output that allow
you
to access all functions from the tactile controls. (you can also use
the
same controls near the front of the system to control the APS visually
(without audio) and without using the touch screen).

Question: Could you explain what you mean by providing access via OS
functions? For example , how do you provide access for blind people to
touch screen kiosks using built in OS features?

Thanks

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson, Norman B - Washington, DC
> Sent: Thursday, January 25, 2007 1:38 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> Gregg,
>
> Could you please give me an example of direct access?
> For all our kiosk implementations the accessibility is
> provided via the operating system functions or software that
> relies on the operating system functions.
>
> 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: Wednesday, January 24, 2007 11:49 PM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> The application could of course provide direct access, as you
> mentioned in
> another email. Then the OS would not be relevant. On Kiosks for
> example,
> accessibility of the OS is not that relevant. But built in
> accessibility would be.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Robinson, Norman B - Washington, DC
> > Sent: Wednesday, January 24, 2007 5:01 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] Accessibility API proposal
> >
> >
> > I'd say the real issue is that the _operating system_
> itself must be
> > capable of supporting accessibility. The real test for an operating
> > system is if it provides APIs that support use by software
> in ALL of
> > the functional performance criteria of 1194.31. If it doesn't, then
> > the operating system isn't accessible and no software
> running on that
> > operating system will be accessible.
> >
> > It is a chain. The operating system must support
> accessibility and
> > provide a standard way for software (an
> > API) to provide accessibility. The software can then be
> developed to
> > meet the technical standards for accessibility (software standards)
> > and in specific content issues (web
> > content) that content can meet the specific standards because the
> > software (web browser) provides those features inherited from the
> > operating system.
> >
> > 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 David
> > Poehlman
> > Sent: Saturday, January 20, 2007 5:09 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] Accessibility API proposal
> >
> >
> > A couple of thoughts.
> >
> > I think working this in such a way as to promote innovation and
> > continued evolution is a good thing. I agree that APIs
> alone are not
> > sufficient.. Perhaps the standard should contain the api with
> > additional language supporting future work and bee made a living
> > document not subject to the normal chanels of change but on
> a faster
> > track so as to keep up with developments.
> >
> > As I see it, there are three possible positive outcomes.
> >
> > 1> software works on its own and can comply.
> > 2> software works with existing apis et al.
> > and:
> > 3> aT is developped with our API in mind so that when products are
> > built, they can more rreadily be made to fit the requirements of AT
> > and It which is not AT to work together. Oh, Is there ever a time
> > when IT is AT?
> >
> > AS far as AT its self is concerned, the only way we can avoid
> > confusion as to whether it meets 508 is to special case it and for
> > that we'd probably need a base line approach. I don't see an
> > equitable way to exempt a class of product based on its stated
> > function. If we do that, AT for the blind suddenly becomes
> acceptable
> > if it cannot be operated with one hand or if it blacks the
> screen...
> > I'm not saying that we need to go to extremes here, but we
> need to be
> > careful of our approach.
> >
> > Thanks!
> >
> > On Jan 11, 2007, at 11:21 AM, Randy Marsden (Home) wrote:
> >
> > I think it's time for us to weigh in on this subject.
> First, I agree
> > with what Gregg says below. Here are our additional
> thoughts from the
> > perspective of an AT manufacturer:
> >
> > > * We like Accessibility API's (but not necessarily in 508).
> > In fact,
> > > we have been advocating for them for years, and have worked
> > > extensively with the OS manufacturers to put them in.
> So, they are
> > > not something we are afraid of - in fact, we helped
> design them and
> > > are a large part of why they exist! Our concern is that if
> > we define a
> > > minimum set in 508, then that may become all that people
> > work toward
> > > or support. That wouldn't be a good thing. But there may
> > be ways we
> > > can word things such that there is room for changes and/or
> > growth to
> > > address that concern. We'd like to explore that, because
> > we do indeed
> > > see value in defining a set of standard API's.
> > >
> > > * We like cooperation. Defining a minimum set of API's
> potentially
> > > sets up a circumstance where an IT vendor can say "hey,
> we met the
> > > minimum - so we've done our part. It must be the AT's
> > fault it's not
> > > working". AT could answer "hey, we did too". Then the finger
> > > pointing begins. The reality is even with API's, there is usually
> > > technical tweaking and cooperation required between the IT
> > and AT to
> > > make it all work. Speaking on a technical level, API's are very
> > > helpful, but not necessary a magic cure for all
> > compatibility issues.
> > > We'd prefer to see 508 create an environment that encourages
> > > cooperation to help guarantee interoperability. Some
> companies (HP,
> > > Microsoft, Apple, etc) actually have special developer
> > programs for AT
> > > vendors that are very helpful.
> > > That's an example of what we'd like to see 508 encourage.
> > >
> > > * We understand the issue of market power. We know there
> are times
> > > when procurement of an IT product can be inadvertently held
> > up by AT,
> > > and that that's not good. That's not in anyone's best interest -
> > > certainly not the AT companies'. We would much rather generate
> > > revenue from the sale of product than spend time
> > customizing things.
> > > But there is not always a business case for AT companies to
> > make their
> > > products work on all platforms - even with an API set in place.
> > > Surely we can't tell an AT company they must make a product
> > that they
> > > aren't going to sell any of, simply so an IT company can
> > win a federal
> > > contract. So, there are valid concerns on both sides.
> We need to
> > > talk about it and figure out the best solution. API's may
> > be part of
> > > that solution - but we don't believe they are the single
> > magic answer.
> > >
> > > * We don't mind accountability, but it needs to make sense.
> > In many
> > > cases, the provisions of 508 would defeat the purpose for
> > which the AT
> > > is developed.
> > > Often, AT is intended to serve a specific disability group,
> > and is not
> > > supposed to be accessible for all. Take, for example, an eye-
> > > tracker ... if that was subject to 508, it would
> > technically need to
> > > be accessible to someone who is blind. Makes no sense,
> > right? Every
> > > time an AT company tried to sell this piece of equipment to the
> > > federal government, an argument and justification would
> need to be
> > > made explaining why it should be exempt from 508. That's a
> > lot of red
> > > tape for both the procurement officers and the vendors for
> > something
> > > that is obviously not applicable.
> > >
> > > * We are motivated by compatibility. It's important to
> understand
> > > that the primary motivation for AT that is derived from
> > Section 508 is
> > > the potential for enhanced compatibility with IT.
> > Theoretically, that
> > > means our products work better and we'll sell more of them.
> > For many
> > > AT companies, federal government purchases represent only a small
> > > percentage of their business, so even if there were
> > requirements for
> > > AT put in 508, they may not have the desired effect.
> > Rather, if 508
> > > sets up an environment that encourages interaction and
> > collaboration
> > > between AT and IT, we'll be all over it.
> >
> > Randy & Jessica
> > ATIA
> >
> > >
> > > From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> > > Reply-To: TEITAC Web/Software Subcommittee
> > > < = EMAIL ADDRESS REMOVED = >
> > > Date: Wed, 10 Jan 2007 23:45:59 -0800
> > > To: "'TEITAC Web/Software Subcommittee'" <teitac-
> > > = EMAIL ADDRESS REMOVED = >
> > > 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
> > >
> > >
> > >
> > >
> >
> >
> >

Previous message |

From: Gregg Vanderheiden
Date: Fri, Jan 26 2007 1:00 PM
Subject: Re: Accessibility API proposal

Yes
They certainly do use the OS. They may not use the OS Accessibility
Features, since many may be tuned to AT but they may build their access even
on those.

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Tobias
> Sent: Friday, January 26, 2007 8:05 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
> I think we are using two different meanings for "direct".
> Gregg means it to refer to accessibility features built into
> the product, therefore not requiring the user to load any AT.
> Norman means it as somehow skipping the OS, or in products
> that don't have an OS. In Gregg's example, the touchscreen,
> tactile controls, and voice output either rely or don't rely
> on underlying OS features, utilities that enable the very
> presence of such input and output capabilities.
> I think Gregg would agree that they do rely on an OS, leaving
> aside for the moment how we define "OS".
>
>
>
> ***
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Friday, January 26, 2007 12:08 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Accessibility API proposal
>
>
> Example? - How about the post offices automated postal
> stations. They
> have touch screens but also tactile controls and voice output
> that allow you
> to access all functions from the tactile controls. (you can
> also use the
> same controls near the front of the system to control the APS visually
> (without audio) and without using the touch screen).
>
>
> Question: Could you explain what you mean by providing access via OS
> functions? For example , how do you provide access for
> blind people to
> touch screen kiosks using built in OS features?
>
> Thanks
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Robinson, Norman B - Washington, DC
> > Sent: Thursday, January 25, 2007 1:38 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] Accessibility API proposal
> >
> >
> > Gregg,
> >
> > Could you please give me an example of direct access?
> > For all our kiosk implementations the accessibility is provided via
> > the operating system functions or software that relies on the
> > operating system functions.
> >
> > 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: Wednesday, January 24, 2007 11:49 PM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Accessibility API proposal
> >
> >
> > The application could of course provide direct access, as you
> > mentioned in
> > another email. Then the OS would not be relevant. On Kiosks for
> > example,
> > accessibility of the OS is not that relevant. But built in
> > accessibility would be.
> >
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Robinson, Norman B - Washington, DC
> > > Sent: Wednesday, January 24, 2007 5:01 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] Accessibility API proposal
> > >
> > >
> > > I'd say the real issue is that the _operating system_
> > itself must be
> > > capable of supporting accessibility. The real test for an
> operating
> > > system is if it provides APIs that support use by software
> > in ALL of
> > > the functional performance criteria of 1194.31. If it
> doesn't, then
> > > the operating system isn't accessible and no software
> > running on that
> > > operating system will be accessible.
> > >
> > > It is a chain. The operating system must support
> > accessibility and
> > > provide a standard way for software (an
> > > API) to provide accessibility. The software can then be
> > developed to
> > > meet the technical standards for accessibility (software
> standards)
> > > and in specific content issues (web
> > > content) that content can meet the specific standards because the
> > > software (web browser) provides those features inherited from the
> > > operating system.
> > >
> > > 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 David
> > > Poehlman
> > > Sent: Saturday, January 20, 2007 5:09 AM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] Accessibility API proposal
> > >
> > >
> > > A couple of thoughts.
> > >
> > > I think working this in such a way as to promote innovation and
> > > continued evolution is a good thing. I agree that APIs
> > alone are not
> > > sufficient.. Perhaps the standard should contain the api with
> > > additional language supporting future work and bee made a living
> > > document not subject to the normal chanels of change but on
> > a faster
> > > track so as to keep up with developments.
> > >
> > > As I see it, there are three possible positive outcomes.
> > >
> > > 1> software works on its own and can comply.
> > > 2> software works with existing apis et al.
> > > and:
> > > 3> aT is developped with our API in mind so that when products are
> > > built, they can more rreadily be made to fit the
> requirements of AT
> > > and It which is not AT to work together. Oh, Is there
> ever a time
> > > when IT is AT?
> > >
> > > AS far as AT its self is concerned, the only way we can avoid
> > > confusion as to whether it meets 508 is to special case
> it and for
> > > that we'd probably need a base line approach. I don't see an
> > > equitable way to exempt a class of product based on its stated
> > > function. If we do that, AT for the blind suddenly becomes
> > acceptable
> > > if it cannot be operated with one hand or if it blacks the
> > screen...
> > > I'm not saying that we need to go to extremes here, but we
> > need to be
> > > careful of our approach.
> > >
> > > Thanks!
> > >
> > > On Jan 11, 2007, at 11:21 AM, Randy Marsden (Home) wrote:
> > >
> > > I think it's time for us to weigh in on this subject.
> > First, I agree
> > > with what Gregg says below. Here are our additional
> > thoughts from the
> > > perspective of an AT manufacturer:
> > >
> > > > * We like Accessibility API's (but not necessarily in 508).
> > > In fact,
> > > > we have been advocating for them for years, and have worked
> > > > extensively with the OS manufacturers to put them in.
> > So, they are
> > > > not something we are afraid of - in fact, we helped
> > design them and
> > > > are a large part of why they exist! Our concern is that if
> > > we define a
> > > > minimum set in 508, then that may become all that people
> > > work toward
> > > > or support. That wouldn't be a good thing. But there may
> > > be ways we
> > > > can word things such that there is room for changes and/or
> > > growth to
> > > > address that concern. We'd like to explore that, because
> > > we do indeed
> > > > see value in defining a set of standard API's.
> > > >
> > > > * We like cooperation. Defining a minimum set of API's
> > potentially
> > > > sets up a circumstance where an IT vendor can say "hey,
> > we met the
> > > > minimum - so we've done our part. It must be the AT's
> > > fault it's not
> > > > working". AT could answer "hey, we did too". Then the finger
> > > > pointing begins. The reality is even with API's, there
> is usually
> > > > technical tweaking and cooperation required between the IT
> > > and AT to
> > > > make it all work. Speaking on a technical level, API's
> are very
> > > > helpful, but not necessary a magic cure for all
> > > compatibility issues.
> > > > We'd prefer to see 508 create an environment that encourages
> > > > cooperation to help guarantee interoperability. Some
> > companies (HP,
> > > > Microsoft, Apple, etc) actually have special developer
> > > programs for AT
> > > > vendors that are very helpful.
> > > > That's an example of what we'd like to see 508 encourage.
> > > >
> > > > * We understand the issue of market power. We know there
> > are times
> > > > when procurement of an IT product can be inadvertently held
> > > up by AT,
> > > > and that that's not good. That's not in anyone's best
> interest -
> > > > certainly not the AT companies'. We would much rather generate
> > > > revenue from the sale of product than spend time
> > > customizing things.
> > > > But there is not always a business case for AT companies to
> > > make their
> > > > products work on all platforms - even with an API set in place.
> > > > Surely we can't tell an AT company they must make a product
> > > that they
> > > > aren't going to sell any of, simply so an IT company can
> > > win a federal
> > > > contract. So, there are valid concerns on both sides.
> > We need to
> > > > talk about it and figure out the best solution. API's may
> > > be part of
> > > > that solution - but we don't believe they are the single
> > > magic answer.
> > > >
> > > > * We don't mind accountability, but it needs to make sense.
> > > In many
> > > > cases, the provisions of 508 would defeat the purpose for
> > > which the AT
> > > > is developed.
> > > > Often, AT is intended to serve a specific disability group,
> > > and is not
> > > > supposed to be accessible for all. Take, for example, an eye-
> > > > tracker ... if that was subject to 508, it would
> > > technically need to
> > > > be accessible to someone who is blind. Makes no sense,
> > > right? Every
> > > > time an AT company tried to sell this piece of equipment to the
> > > > federal government, an argument and justification would
> > need to be
> > > > made explaining why it should be exempt from 508. That's a
> > > lot of red
> > > > tape for both the procurement officers and the vendors for
> > > something
> > > > that is obviously not applicable.
> > > >
> > > > * We are motivated by compatibility. It's important to
> > understand
> > > > that the primary motivation for AT that is derived from
> > > Section 508 is
> > > > the potential for enhanced compatibility with IT.
> > > Theoretically, that
> > > > means our products work better and we'll sell more of them.
> > > For many
> > > > AT companies, federal government purchases represent
> only a small
> > > > percentage of their business, so even if there were
> > > requirements for
> > > > AT put in 508, they may not have the desired effect.
> > > Rather, if 508
> > > > sets up an environment that encourages interaction and
> > > collaboration
> > > > between AT and IT, we'll be all over it.
> > >
> > > Randy & Jessica
> > > ATIA
> > >
> > > >
> > > > From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> > > > Reply-To: TEITAC Web/Software Subcommittee
> > > > < = EMAIL ADDRESS REMOVED = >
> > > > Date: Wed, 10 Jan 2007 23:45:59 -0800
> > > > To: "'TEITAC Web/Software Subcommittee'" <teitac-
> > > > = EMAIL ADDRESS REMOVED = >
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >

WebAIM is an initiative of: