Thread Subject: StartingdiscussionsontheAccessibilityAPIproposal

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: Fri, Jan 19 2007 3:45 PM

Hi Norman,

I believe one of the provisions of the standard specifically requires that
the products be usable by people without vision or be compatible with AT.
Wouldn't a product that had an API but didn't work with AT fail that
criterion?

I think the power of the API isn't that you 'get our of jail free' if you
use one but rather that using a supported API and implementing your software
correctly can make it much easier to work with AT and therefore to conform.


No?


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 18, 2007 3:09 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware]
> StartingdiscussionsontheAccessibilityAPIproposal
>
> Gregg,
>
> I'll have to disagree with you about "or the users
> can't get or can't use it (the API)." If there is a defined
> API or markup language standard or file format specification
> and the content creators use that then they should be in compliance.
>
> At issue is the difference between compliance and
> accessibility in specific instances. If the vendor provided
> the proper table headings and row heading in an HTML table,
> per the W3C standards, and the screen reader didn't read them
> properly, then the content should be considered Section 508
> compliant. This goes against your characterization when the
> users can't get access. It may be true in some situations.
> Yes, testing should let you know but if in the process of
> testing you find the content, markup language, or document
> isn't accessible but they have coded to the standards then
> the problem is the assistive technology - not the content.
> Will the users suffer? They just might until the assistive
> technology is fixed. I don't think it fair to say the
> developers should find out what works with assistive
> technology (AT) when that AT isn't following the standard
> instead of asking the AT to follow the standards.
>
> No, APIs don't guarantee interoperability but they
> provide the best way to allow developers to make that happen.
> Therefore APIs increase the chance for access. There are many
> instances where developing against the well know API is
> sufficient to provide accessible E&IT even without testing.
> We should encourage a development environment where
> accessibility testing isn't required; this will move the
> industry forward. Note I said where testing isn't _required_.
> It is highly desirable but I mean that well defined
> interfaces enhance the ability for developers to develop. I
> would imaging the screen reader manufacturers and developers
> really appreciate having a Document Object Model (DOM)
> standard for representation of HTML or XML. If you look at
> the comparison of layout engines for DOM
> (http://en.wikipedia.org/wiki/Comparison_of_layout_engines_dom
> you will note "the industry" has various degrees of
> implementations against the standard DOM recommendations yet
> it is clear this interface is the way to go. I could imagine
> the Section 508 refresh making the _technical_ recommendation
> that vendors use the DOM model, as that is the way industry
> is already heading. This is standards support. We simply need
> to baseline what standards are industry wide and support
> accessibility or identify those newer standards that offer
> significant benefits to 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: Thursday, January 11, 2007 2:46 AM
> To: 'TEITAC Web/Software Subcommittee'
> 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
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Robinson, Norman B - Washington, DC
> > Sent: Friday, January 05, 2007 3:58 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] Startingdiscussionson
> > theAccessibilityAPIproposal
> >
> >
> > You'll see me commenting on the need for standards and
> the need for
> > _references_ to current implementations in the Section 508 refresh.
> > I don't mean that needs to be a part of law, but I do think
> it would
> > help the development community (the ones sitting at a
> vendor's office
> > creating software) if we point them in the right direction
> and inform
> > them of the most common APIs somehow.
> >
> > I agree the definition of an API doesn't ensure accessibility.
> > But if we are going to split hairs on semantics, I'd say you aren't
> > compliant if you didn't _USE_ the API <grins>. If we have to debate
> > semantics we are focusing on the wrong problem or need to
> rewrite the
> > requirement (if it is clearly interpreted badly by most
> people). So I
> > agree with you that vendor use of an API isn't a clear basis for
> > measuring Section 508 compliance. I think the functional
> requirements
> > (goals) Section 508 has outlined for determining compliance
> have been
> > successful.
> >
> > However, do we need to address the issues when vendors use many
> > different APIs to achieve accessibility? Does it move accessibility
> > forward, make electronic information and electronic technology more
> > accessible if we all, collectively, use the same APIs? Or
> is it better
> > to have many different vendors implementing their own APIs?
> >
> > Is the defacto standard for an accessibility API on MS
> Windows MSAA?
> > Is it AT-SPI for Gnome? KDE AT-API for KDE? UA for OSX?
> What about the
> > Qt Accessibility Framework for MS Windows; it uses MSAA but
> has it's
> > own API. I've got acronym overload! Perhaps, after looking at these
> > things as the toolkits they are, we can agree there is a basic
> > goodness in having developers develop to the appropriate
> API for their
> > platform/operating system. Now, how could we, if so motivated,
> > actually force/beat/make them use a particular API; even if
> that would
> > be wrong of us? I don't think Section
> > 508 would be the place to do that. I think it has to be tied to
> > business requirements. Certainly requiring MSAA on the
> Linux platform
> > won't get you anywhere - it doesn't exist!
> >
> > We approach this in our policy
> > (http://www.usps.com/cpim/ftp/hand/as508a/508a_c5.html#508hdr8
> > ) and I would say the short version is a prioritized list
> > approach: 1. Support native operating system and activated
> > accessibility features. 2. Use standard controls for particular
> > operating systems where possible. 3. Be careful when using custom
> > controls or enhancing standard controls. 4.
> > Provide flexibility in using a variety of input methods. 5.
> > Query accessibility aids in use by the operating system and
> configure
> > the software applications automatically.
> >
> > So using a API doesn't equate to access, but we should:
> > 1. Support native operating systems accessibility
> (e.g., the APIs for
> > whatever development framework is being used should use the
> operating
> > systems accessibility features and not _reinvent_ their own).
> > - is there more than one native operating
> system API on any
> > platform? Help point this out!
> > 2. If the API provides standard controls (which is
> generally the
> > purpose of a framework or development
> > environment?) those standard controls should follow #1.
> > - there are many developer toolkits or
> frameworks but do they all
> > use the native API? (Java Access Bridge uses MSAA doesn't it?
> > Qt?)
> > 3. Developers should follow #1, via using standard
> controls (#2).
> > 4. Developers should test their products in a variety
> of use-cases
> > that include testing for users that might have a disability.
> > 5. This is a repeat of #1 actually, as the operating
> system would
> > provide this through a standard interface (#1).
> >
> > As we have developed our own policy, I can't help but
> think what we
> > need is a central policy document that isn't a part of the
> law but the
> > best practices that have been approved as acceptable. We need some
> > agency (the Access Board? GSA?) to maintain this and
> harmonize it with
> > any Section 508 updates. It would effectively replace an agencies
> > individual policy when the agency didn't invent it.
> > Guidelines, not Section 508 technical standards or regulations.
> > Guidelines that meet the technical standards but can be legally
> > ignored as not _required_.
> >
> > Wow. I think I just convinced myself that we shouldn't have API
> > specifications in the revision at all.
> >
> > Have a great weekend,
> >
> >
> > 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
> > Jessica M. Brodey
> > Sent: Friday, January 05, 2007 12:17 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware]Startingdiscussionson
> > theAccessibility APIproposal
> >
> >
> > Peter:
> >
> > ATIA agrees that there are already aspects of an
> Accessibility API in
> > 508.
> > We are opposed to creating and labeling something an "Accessibility
> > API,"
> > enumerating it exactly in 508, and thus running the risk that
> > companies can say "hey, I used the accessibility API so I am
> > 508 compliant" without actual interoperability with AT. We
> want to be
> > clear that while we think moving towards incorporating an
> > accessibility API is a good thing, it may not be the lone
> solution to
> > full interoperability, nor does an accessibility API alone
> equate to
> > actual access, and it should therefore not be used as the
> measure for
> > 508 compliance. We are also not certain that an accessibility API
> > expressed as such belongs in 508, which is a regulatory
> standard, as
> > opposed to in an industry standard.
> >
> > ATIA would rather see enumerations written in broad brush
> strokes, not
> > the specifics that would indicate "use this particular
> accessibility
> > API."
> > I
> > apologize for not speaking to the specific language and
> sections as I
> > am a policy person, not a techie, but if you equate this to
> the world
> > of the Internet, we do not want to structure the regulations in a
> > manner that would say the equivalent of "supports Java
> version x," or
> > even spell out all the components or provisions in Java (without
> > actually specifying it) that make it obvious which version
> of Java we
> > are pushing to support. We would rather spell out characteristics
> > that would allow a company to provide Java support in
> satisfaction of
> > that provision, OR could allow a company to go another
> route and still
> > satisfy the requirements of the regulation, or in three
> years switch
> > to Java version x2 without violating the regulation. I understand
> > that approach is sometimes frustrating for techies who
> often want it
> > to be spelled out in black in white.
> > Unfortunately, it is the same techies who also want the
> flexibility to
> > innovate, and not be hemmed in when the law is so specific that it
> > prevents them from diverging. We need to find a happy
> medium here . .
> > . where we can include the elements of an accessibility API
> to get at
> > some of the benefits without nailing down such specifics
> that we are
> > locked into only one version of an accessibility API that
> is too rigid
> > and cannot evolve.
> >
> > We need to focus on the end results - what we want to be able to
> > achieve, not the means of getting there. The distinction
> you pointed
> > out, Peter, is that while the descriptions in
> > 1194.21(c) may comprise aspects of an accessibility API, it
> does not
> > dictate the nature of the accessibility API - it is focused on the
> > result of the access, not the means for providing the
> access. Perhaps
> > we can determine what aspects you feel are missing from the
> existing
> > provisions that are critical to an accessibility API, and
> write them
> > in language consistent with 1194.21?
> >
> > Again . . . we think implementation of an accessibility API
> is a best
> > practice, and perhaps can be used/publicized in other
> aspects of this
> > process as a guide to understanding how to comply with the 508
> > requirements.
> >
> > Jessica
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Peter
> > Korn
> > Sent: Thursday, January 04, 2007 11:38 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware]Startingdiscussionson
> > theAccessibility APIproposal
> >
> > Hi Jessica,
> >
> > > ATIA's position is that an accessibility API has a role,
> > but it is in
> > the
> > > business venue, or in the standards venue, not the
> regulatory venue.
> > If
> > we
> > > want to include aspects of the accessibility API into
> 508, it should
> > be as
> > > Sean Hayes from Microsoft has advocated. We are
> concerned about an
> > exact
> > > and precise list that is finite and unable to evolve without
> > reconvening a
> > > new panel and a new refresh. We see an accessibility API
> > as more of a
> > good
> > > business practice that is the best way to meet some of the
> > specifications
> > of 508, but which accessibility API may change and evolve over time.
> > >
> >
> > 508 already includes aspects of an accessibility API. The seven
> > provisions enumerated in
> > http://teitac.org/wiki/Web_and_Software:_Programmatic_exposure
> > _of_inform
> > atio
> > n
> > are existing places where 508 describes the programmatic
> information
> > that IT shall provide to AT. The current language doesn't
> call this
> > portions of an "accessibility API", but language like
> "focus shall be
> > programmatically exposed so that assistive technology can
> track focus
> > and focus changes" in 1194.21(c) aren't too far away from that.
> >
> > And I think ATIA would agree with me that the seven provisions in
> > question constitute an insufficient set of information from
> which AT
> > can
> >
> > accomplish their task. Yet these seven represent "a list that is
> > finite
> >
> > and unable to evolve without reconvening a new panel and a new
> > refresh." In fact, it is the very process of refreshing
> these seven
> > provisions that gave rise to the accessibility API proposal
> - a much
> > richer enumeration of things we know are needed, and in support of
> > which
> >
> > the evolving, platform-specific accessibility APIs like UI
> Automation
> > can be used by IT vendors to interopreate with AT.
> >
> > If ATIA is opposed to a finite list, then what does ATIA
> propose we do
> > with finite list we currently have - the seven provisions
> enumerated
> > above?
> >
> >
> > Regards,
> >
> > Peter Korn
> > Accessibility Architect,
> > Sun Microsystems, Inc.
> >
> >
> > > Jessica
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Lybarger,
> > > Barbara (MOD)
> > > Sent: Thursday, January 04, 2007 6:14 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware]Startingdiscussionson
> > theAccessibility
> > > APIproposal
> > >
> > > On this topic, I'm not nearly well enough informed on the content.
> > > However, I question Jessica's reasoning, in that no set of
> > standards
> > > will help if they aren't followed by all the parties, here
> > IT, AT and
> > > all the players in between, and violators aren't chastised
> > in some way
> > > fair and reasonable way.
> > >
> > > At it's core, the API proposal is like the standards for our
> > electrical
> > > power grids. The government regulates how the power source
> > comes out,
> > > and all the other parties set up their stuff so all the
> > customers can
> > > get at the power to run their lights. Most of the
> parties conform
> > > because the alternative is that people can't safely and cost
> > effectively
> > > share the power. If anyone in the chain doesn't conform with the
> > > standard, end users either have dark houses because the
> light bulbs
> > > can't get the power, or they have a very bright house while
> > it burns
> > > down. Either way the government is looking to punish the one who
> > caused
> > > the problem.
> > >
> > > People argued about innovation and standardization when the first
> > power
> > > grids were set up. Costs, safety and reliability won out over
> > > unfettered innovation, but it didn't stifle innovation. Folks are
> > still
> > > inventing better, safer, cheaper ways of delivering
> power, and they
> > are
> > > being used to upgrade the power grid. The bottom line then
> > and now is
> > > that in a society we have to give up a little freedom to
> > make sure we
> > > all can get at shared resource cheaply, safely and reliable. The
> > > technology equivalent may be this API or something like
> it. It is
> > > needed so all of us can share, and conformance by all is
> > essential for
> > > it to work.
> > >
> > > If this API proposal isn't perfect in some ways, what
> would make it
> > > better so everyone would want to follow it? And then,
> what type of
> > > enforcement system is needed so the non-likeminded in society get
> > > brought into line?
> > >
> > > Barbara Lybarger
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Jessica
> > > M. Brodey
> > > Sent: Thursday, January 04, 2007 4:21 PM
> > > To: 'TEITAC Web/Software Subcommittee'
> > > Subject: Re: [teitac-websoftware]Startingdiscussionson
> > theAccessibility
> > > APIproposal
> > >
> > > Jim:
> > >
> > > Speaking as a policy wonk in lay terms, I think that the common
> > > misunderstanding here is that use of an accessibility API equals
> > > accessibility. Just because there is an accessibility
> API does not
> > mean
> > > that every piece of AT automatically works all of the time
> > - it just
> > > increases the odds of existing AT working with new
> products. But,
> > > sometimes new technologies come with new features. If the
> > AT did not
> > > take into account those new features or capabilities, support for
> > those
> > > features still needs to be built in. An accessibility
> API makes it
> > > easier to build in support for those features, and makes it less
> > > burdensome for the AT vendors to do so (and means
> supporting those
> > > features should be more standardized), but it is not always
> > automatic.
> > > Also, as I understand it, just because a company uses the
> > accessibility
> > > API does not mean it implements the API in exactly the
> same way as
> > > another company, thus, it is possible a piece of AT may not work
> > > perfectly with one product that uses the accessibility API but may
> > work
> > > perfectly with another, and thus it may not be fully
> > compatible with
> > > every product. So, the verdict is that an accessibility
> > API could be
> > > useful, could improve things, but does not mean that
> compliance with
> > the
> > > API will equal access.
> > >
> > > Another problem is that adopting an accessibility API that is the
> > "gold
> > > standard" today may quickly be old and out of date in 6
> months or a
> > > year.
> > > While we are in danger of this for many aspects of 508, it is
> > > particularly worrisome for how AT interfaces with IT,
> > because it could
> > > stifle the growth and expansion of new AT, particularly if the
> > > accessibility API becomes the excuse or justification . . .
> > "well, we
> > > used the accessibility API, we don't have to be compatible
> > with ACTUAL
> > > AT." At some point not too far off, because the API won't
> > be able to
> > > grow and evolve once put into regulation, what started off
> > as a means
> > to
> > > improve accessibility could actually become the one bar to
> > providing
> > > real access.
> > >
> > > Jessica Brodey
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of Jim
> > > Tobias
> > > Sent: Thursday, January 04, 2007 11:01 AM
> > > To: 'TEITAC Web/Software Subcommittee'
> > > Subject: Re: [teitac-websoftware] Startingdiscussionson
> > theAccessibility
> > > APIproposal
> > >
> > > Your concerns are justified, but you have the concepts backwards.
> > > Thinking in terms of an accessibility value chain
> guarantees that we
> > are
> > > thinking of all the steps required to give the end user access.
> > > Separating the regs by narrow targets, one product or
> industry at a
> > > time, ignores the need for both technical and informational
> > > interoperation.
> > >
> > > There is no getting around the problem of assigning
> responsibilities
> > to
> > > the "proper"
> > > parties. Luckily 508 burdens the purchaser, who has the
> > best view of
> > > the entire chain, from OEM-type product to developed product to
> > > installed product to user and administrator. In theory.
> > The problem
> > > remains one of information flow rather than raw
> technological power,
> > as
> > > your example indicates -- Gregorian did not work closely
> enough with
> > the
> > > AT community.
> > >
> > > But that raises another troubling point: why is the
> > Accessibility API
> > > not sufficient? If Gregorian builds its software
> correctly, why is
> > > additional action required by AT vendors?
> > > If Gregorian cannot sell to the feds until one or more AT
> > vendors acts
> > > to make the new product accessible, isn't that an imbalance
> > of market
> > > power? I thought the whole idea of the Accessibility API was to
> > > eliminate that problem.
> > >
> > > Maybe I'm misunderstanding something....
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> > >> Sent: Thursday, January 04, 2007 1:52 AM
> > >> To: 'TEITAC Web/Software Subcommittee'
> > >> Subject: Re: [teitac-websoftware] Starting discussionson
> > >> 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