Thread Subject: Re: Startingdiscussions ontheAccessibilityAPIproposal
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
From: Gregg Vanderheiden
Date: Thu, Jan 04 2007 1:55 PM
Subject: Re: Startingdiscussions 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.
>
>
From: Randy Marsden
Date: Thu, Jan 04 2007 2:55 PM
Subject: Re: Startingdiscussions 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.
>>>>> >
>>>>> >
From: Gregg Vanderheiden
Date: Thu, Jan 04 2007 3:25 PM
Subject: Re: Startingdiscussions 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.
>
>
From: Lazzaro, Joe (ITD)
Date: Sun, Jan 07 2007 7:50 PM
Subject: Re: Startingdiscussions ontheAccessibilityAPIproposal
I agree with Gregg that the Access Board or another government entity is
most appropriate for regulating this. On an informal basis, a Bugzilla
style web site would be useful for consumers, vendors, and developers to
share info about bugs and for fixing them.
Joe
Joe Lazzaro
Manager: Assistive Technology Group
Information Technology Division
Commonwealth of Massachusetts
One Ashburton Place
Room 1601
Boston, MA 02108
Voice: 617-626-4410
Email: = EMAIL ADDRESS REMOVED =
Web: www.Mass.gov/ITD