Thread Subject: Re: 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: Wed, Jan 24 2007 9:40 PM

Thanks Norman,

Looks good. If I can summarize.

Basically, if 'building to an API' would guarantee that screen readers and
IT would work together, and then if users have or can get AT that works with
the API, this would solve the problem. Bugs in AT would be AT
responsibility and IT that had bugs would fail til they did their part and
fixed them.

This assumes

1) that AT can get all the information they need from the API
2) that the API is clear and unambiguous (i.e. building to the API will
reliably give full access by itself)
3) that AT exits for the API and
4) that the users can get that AT or it is provided for them.

OR

5) the product has full access built in.


If #1 thru 4 or #5 is true for each user, the users can access the
product. It is accessible to people with disabilities.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: Robinson, Norman B - Washington, DC
> [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Wednesday, January 24, 2007 4:55 PM
> To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
> Subject: RE:
> [teitac-websoftware]StartingdiscussionsontheAccessibilityAPIproposal
>
> Gregg,
>
> Let me take chance and try to explain my point of view.
> I apologize in advance for the length of my post.
>
> You asked if a product (electronic information & technology or
> E&IT) had used an (assumed accessibility related API) API but
> didn't work with assistive technology, would it fail to meet
> the Section 508 standards. Clearly the answer is NO.
>
> 1. The Section 508 technical standards do not _require_
> testing or use with assistive technology.
> 1a. I can test against the standards in many ways
> without ever using assistive technology. Examples:
> - I can self-voice or build in audible clues to meet
> 1194.31(a) & (b).
> - I can provide enlarge text or visual
> prompting to meet 1194.31(c).
> - I can test keyboard access to meet 1194.31(f)
> by using a keyboard.
>
> 2. It is important to address your assertion that the
> standards required that products be usable by people with
> disabilities or be compatible with assistive technology. I
> believe the exact wording in
> 1194.1 is "...have access to and use of information and data
> that is comparable to the access and use by (those) who are
> not individuals with disabilities..." and 1194.31 "at least
> one mode of operation and information retrieval that does not
> require user vision shall be provided, or support for
> assistive technology used by people who are blind or visually
> impaired shall be provided". This IS about semantics; the
> language is important to making legal determinations.
>
> So let us focus on "OR support for assistive technology
> used by people...shall be provided". The intent is that we
> can demonstrate access as proof of accessibility and Section
> 508 compliance by showing access using (in this instance) a
> screen reader.
>
> The important part to think about is that there is more
> than one screen reader. There are many. It is also important
> to think about the fact that each and every vendor could,
> technically, provide their own screen reader with their own
> controls specific to their application and meet the
> requirements of this provision. The built-in Adobe Reader's
> Read OutLoud may be a real example you can consider. There
> are other readers built into eLearning applications. I assume
> there are others.
>
> How does this fail? I can demonstrate accessibility by
> using my custom screen reader. Imagine I built my own custom
> screen reader that only works with my line of enterprise
> applications and it costs ten thousand dollars a seat. That
> would be legal. I guess if you don't buy my screen reader you
> don't want it enough; but I can _prove_ accessibility and
> Section 508 compliance. I can also demonstrate that built-in
> screen readers, although they some times work, don't provide
> consistent controls, don't provide comparable access (speed,
> control), don't work WITH my existing dedicated screen
> reader, and sometimes interfere with operation of my
> assistive technology.
>
> Furthermore, if I reverse your logic and ask you "How
> do you provide software that doesn't use an API?" and suggest
> you can't answer.
> There is an API if you have software. Typically on a
> Microsoft platform a majority is using the Microsoft
> Foundation Classes (MFC) and you have therefore used the
> Microsoft development APIs. On new operating system that
> system interface or API is sometimes not mature, but most
> operating systems provide some sort of standard system
> interface and API so programmers can design and create
> software. If you speak to device drivers, the hardware itself
> has an interface which I would refer to as the API, even if
> the device doesn't offer the operating system a direct data
> connection.
>
> The point is we want to encourage software developers
> to use the well-defined operating system functions for
> accessibility where they exist. We would be better off if the
> same interface used in the Adobe Read Out Loud function was
> provided to the system for use with my own screen reader. Now
> the question is - does it? If it does, it does so by using
> the same Microsoft Accessibility API. If not, they use their
> own proprietary API internal to the Adobe Acrobat Reader
> itself. Would you expect my screen reader to be able to work
> with the operating systems accessibility API to obtain the
> information in the PDF or would you expect my screen reader
> to be able to work with the vendor's internal proprietary
> API? I'd say the proprietary API wouldn't be a good approach
> as the screen reader manufacturer would have the same
> potential problem for each and every piece of software on
> that platform. I'd say the well-defined operating system API
> would be the way to go, and increase the likelihood vendors
> making software would be able to provide accessibility, buy
> developing to the operating system's API instead of inventing
> their own methods.
>
> So given these scenarios, I'd also say that I can show
> you inspection tools that take the code used in the software
> events and allow you to inspect them and review the same data
> the screen reader _must_ be using to provide access. I have
> done and do this today. This information is available to the
> programmer or developers via the API and therefore you can
> inspect the code and determine what should be passed via the
> API for use by a screen reader.
>
> A screen reader is software and as potentially
> imperfect as any other software. I'm sure many of the people
> using screen readers can tell you how they fail. If the
> SCREEN READER MANUFACTURER, in developing their screen
> reader, builds their software to read the APIs and access
> isn't provided because the screen reader is defective, then
> who is to blame? Why is it not accessible? Should the
> software vendor be _required_ to test with a screen reader to
> determine if it is Section
> 508 compliant? In this instance they might be able to report
> to the screen reader manufacturer the screen reader is
> defective. Also consider should software vendors have to test
> with each and every screen reader out there? Some screen
> readers might work with specific programs via knowledge of
> proprietary APIs used. Does that mean the users that require
> assistive technology need one of every version? One only has
> to consider accessing the same document content via Microsoft
> Windows, OS X, and Linux to realize as you abstract these
> issues the standard operating system API is most important.
>
> Assistive technology is a great functional test _if the
> vendor uses the operating system standard APIs_. Assistive
> technologies should be tested to see how they rate against
> standard (API) implementations for quality (e.g., as in how
> they render the content from the web ACID2 test).
>
> And yes, if during testing it is found software uses
> the defined APIs and the screen reader is defective _the
> software or content in question_ is Section 508 compliant.
> The fix is to update the screen reader, not make the software
> in question work with defective software.
> Testing with assistive technology is important for
> verification if that is the specific use-case in your user's
> environment. It doesn't mean squat to me on Linux using Orca
> if you tested your application or content on MS Windows using JAWS.
>
> I hope that better explained my point of view and was
> useful to this discussion.
>
> 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: Friday, January 19, 2007 5:41 PM
> To: 'TEITAC Web/Software Subcommittee'
> Subject:
> [teitac-websoftware]StartingdiscussionsontheAccessibilityAPIproposal
>
>
> 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