Thread Subject: Re: Starting discussionsontheAccessibility APIproposal

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.

From: Randy Marsden
Date: Thu, Jan 04 2007 10:45 AM

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

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University