Thread Subject: Re: Starting discussions ontheAccessibility 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 (Home)
Date: Thu, Jan 04 2007 12:20 AM

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