Thread Subject: Re: Starting discussions 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.

From: Gregg Vanderheiden
Date: Thu, Jan 04 2007 7:25 AM

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

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