Thread Subject: Re: Starting discussions ontheAccessibilityAPIproposal

From: Peter Korn
Date: Thu, Jan 04 2007 3:15 PM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: terry.weaver@gsa.gov: "Re: Starting discussions ontheAccessibilityAPIproposal"
• Previous message in thread: None
• Messages sorted by: Author | Thread | Date

Hi Randy,

We encounter the situation you describe with ITWidgetsRUs all the time
at Sun, and I expect at most of the IT companies participating in
TEITAC. At Sun we have an internal checklist for these folks, and based
on the technology they are using (Web, Java, GNOME, other) we direct
them to the specific techniques they should follow to ensure that what
they produce is accessible.

This is very analogous to the "sufficient techniques" concept, and
putting such guidance into the 508-related materials that the Access
Board provides would I think be a significant service to all.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> My comments were centered on the specific technical implementation of
> interoperability between the IT and AT. I wasn’t considering any sort
> of regulatory or approval process.
>
> Example: ITWidgetsRUs is creating a new piece of IT technology and
> wants to be able to sell it to the Federal Government. They learn
> there’s this thing called Section 508 and that their widget must be
> accessible. So, they want to make it so. But where do they start? The
> 508 requirements seem daunting. They’ve never even heard of AT, much
> less know who to contact, what exists, what to do, etc.
>
> There ought to be a place where they can go to get started, get
> connected, sign NDA’s, and begin the journey of making their widget
> accessible to all. That’s the process I’m talking about. Still not
> sure how the Access Board would be involved.. But having consumers
> involved is always a good idea – that often happens naturally as part
> of the product development process (at least it should).
>
> -Randy
>
>
> *From: *"Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> *Reply-To: *TEITAC General Interface Accessibility Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> *Date: *Thu, 4 Jan 2007 14:52:55 -0600
> *To: *"'TEITAC Web/Software Subcommittee'"
> < = EMAIL ADDRESS REMOVED = >
> *Cc: *'TEITAC General Interface Accessibility Subcommittee'
> < = EMAIL ADDRESS REMOVED = >
> *Subject: *Re: [teitac-general] [teitac-websoftware] Starting
> discussions ontheAccessibilityAPIproposal
>
>
> I think it needs to be at the Access-board level.
>
>
>
> You can't have industry deciding what qualifies for ‘passing’ the
> government requirements and have it have any validity if a suit is
> brought.
>
>
>
> Also consumers need to be at the table –
>
>
>
> AND no matter what group of companies (IT and AT) you bring
> together, others will complain they were not represented.
>
>
>
> So AB is only one who could run such an operation I would think.
>
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf
> Of *Randy Marsden
> *Sent:* Thursday, January 04, 2007 11:44 AM
> *To:* TEITAC Web/Software Subcommittee
> *Subject:* Re: [teitac-websoftware] Starting discussions
> ontheAccessibilityAPIproposal
>
> I think there should be a consultative process put in place.
> Whether or not that has to involve the Access Board is not
> clear to me. I think it should be done at the industry level.
> I thought the suggestion of a bugzilla-like website was
> interesting. That could be part of it (although I don’t think
> that alone is enough). I believe the collaboration will happen
> naturally in most cases, given a process, but if there is some
> problem encountered in a specific interaction, perhaps a
> mediation procedure could be part of the picture.
>
> -Randy
>
>
> *From: *"Jim Tobias" < = EMAIL ADDRESS REMOVED = >
> *Reply-To: *TEITAC Web/Software Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> *Date: *Thu, 4 Jan 2007 11:01:14 -0500
> *To: *"'TEITAC Web/Software Subcommittee'"
> < = EMAIL ADDRESS REMOVED = >
> *Subject: *Re: [teitac-websoftware] Starting discussions
> ontheAccessibility APIproposal
>
>
>
>
> If I hear you correctly, Randy, you are proposing some
> sort of consultative process that would be mediated by, or
> at least
> would include participation by, regulators such as the
> Access Board. Is that correct? One of our recommendations
> might address this idea, as a way of providing continual
> refreshment.
>
> ------------------------------------------------------------------------
>
> *From:* Randy Marsden (Home) [mailto: = EMAIL ADDRESS REMOVED = ]
> *Sent:* Thursday, January 04, 2007 2:07 AM
> *To:* Gv@Trace. Edu; 'TEITAC Web/Software Subcommittee'
> *Subject:* Re: [teitac-websoftware] Starting discussions
> ontheAccessibility APIproposal
>
> Very well put, Gregg. You’ve managed to put into words
> something I was feeling but wasn’t sure how to express.
>
> My opinion is we should refresh Section 508 in such a way
> that it encourages the interaction even more between IT
> and AT vendors, and then at an industry level, set up a
> way for that to happen in a somewhat more formal way than
> we currently have.
>
> -Randy, ATIA
>
>
> *From: *"Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> *Date: *Thu, 4 Jan 2007 00:51:57 -0600
> *To: *"'TEITAC Web/Software Subcommittee'"
> < = EMAIL ADDRESS REMOVED = >
> *Cc: *"'Randy Marsden'" < = EMAIL ADDRESS REMOVED = >
> *Subject: *RE: [teitac-websoftware] Starting discussions
> on theAccessibility APIproposal
>
>
>
>
> Why value chain is good concept - but we need to be
> very careful about its
> use in regulatory standards.
>
> I really like the accessibility value chain concept as
> a way to understand
> this - and to point out the way things work together.
>
> But I worry about it in a discussion of how to
> structure our standards. And
> I don't think we should structure our standards around
> it. If we did then
> we would only require that software companies "enable"
> there software to be
> accessible - but they would have no responsibility to
> actually make sure
> that there was AT that did work with their software
> and did make it
> accessible. The result is that in fact it would be
> "meet accessibility
> standard" but be unusable by anyone with a disability.
>
> Take the following example.
>
>
> The Gregorian Software company creates a marvelous new
> media technology. It
> is new, different and extremely compelling web
> software for shopping and
> transactions using a simulated person and live
> environment over narrow
> bandwidth. They implement it with an accessibility API
> but no one uses the
> technology (of course) til its release in Sept 2007.
> At its announcement it
> is adopted by Amazon, a slew of banks, etc. AT vendors
> begin working with
> it but it will be a year or more before they can get
> up to speed (sort of
> like when dos went to windows) but this technology
> spreads at Internet speed
> because it is free downloadable plug in for most users.
>
> Suddenly these sites go black to AT users. But if we
> write out guidelines
> such that the sites and the Gregorian software company
> can say their
> software meets access standards, without actually
> requiring them to be
> supported by real live AT that is out there - and
> available to users.
>
> In fact AT vendors will remember the days before we
> required software to
> actually work with real AT. Software would come out
> with an accessibility
> API but AT vendors were not able get access to it and
> had very poor support
> from software vendors even after release. Only when
> the software was
> required to actually work with real AT did the vendors
> invite and support
> and even court AT vendors in the same way they
> invited, supported and
> courted other software and hardware vendors (for
> compatibility) when they
> released something new.
>
> So I think the "accessibility value chain" is a very
> important concept. But
> I don't think we should base our standards on it.
>
> I think that something is accessible if it can be used
> by real people who
> have disabilities, not just that it theoretically
> could be if only those
> other people had done their job.
>
> Accessible - means that it can be used by people with
> disabilities.
> That means it is either directly accessible. Or that
> it is accessible using
> the AT that the person with a disability has or can
> reasonably get (or in
> the case of the government - for its employees - AT
> they are given). For
> public websites, it would be the AT that the public at
> large has, can
> reasonably get, or is given.
>
> Any other definition of accessibility defeats the
> purpose the legislators
> laid out in creating 508. that is that people with
> disabilities could
> actually use the E&IT in the government alongside
> everyone else - and when
> it was purchased (not sometime in the future - if
> someone else does their
> job).
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ]
> On Behalf
> > Of Jim Tobias
> > Sent: Wednesday, January 03, 2007 9:35 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] Starting
> discussions on
> > theAccessibility APIproposal
> >
> > Sean Hayes wrote:
> >
> > "Firstly I agree that there is a problem that needs
> > adressing here, which is the equitable division of
> > reponsibility on accessibility between each entity
> involved
> > in delivering a software product. However, as we are
> all
> > aware, this is very difficult problem given the
> manner in
> > which modern software is produced, which in most
> significant
> > products involves cooperation across multiple
> organisations,
> > not only the software product developer, but OS
> vendors,
> > hardware vendors, AT vendors and middleware vendors
> among
> > others. In some cases standards or industry practice
> already
> > exists around these interfaces, and in some cases it
> doesn't."
> >
> > I would like to take this opportunity to develop a
> little
> > further the concept of an "accessibility value
> chain", which
> > Sean refers to indirectly. I believe that clarifying
> these
> > responsibilities is at the heart of "modern"
> accessibility,
> > because, as Sean notes, modern software requires
> cooperation
> > across multiple organizations, many of whom have only
> > indirect relationships.
> >
> > I would like to posit that the nature of this technical
> > cooperation has three distinct elements or phases:
> > capability, implementation, and preservation.
> > By
> > "capability" I mean that the software component
> contains all
> > the features necessary for accessible use or
> development.
> > Examples are the ability to add a text description
> to an
> > image in a web development tool, and the ability to
> record
> > and play back Baudot files in a voice mail platform. By
> > "implementation" I mean that the capability has
> actually been
> > used by the next link in the chain. That is, the web
> > developer has actually added a text description to
> an image,
> > and the telecom manager has actually set up a voice
> mailbox
> > so a Baudot TTY user can receive messages. By
> "preservation"
> > I mean that
> > the next link in the chain is required not to
> interfere with
> > the accessibility feature already in place further
> up the
> > chain. For example, a digital cable system must not
> strip
> > the captioning information from a captioned video
> program
> > during transmission.
> >
> > Most of the relationships in the chain are
> > capability-implementation ones, especially for web and
> > software. Thus the current 508 requires software to
> inherit
> > system display settings, use standard OS text
> presentation
> > techniques, etc.
> >
> > I think this formulation may clarify for us where we
> want to
> > go. For example, we have mentioned adding OS
> requirements.
> > That is, current 508 requires "downlink" software to
> honor OS
> > accessibility features, but it doesn't require OSs
> to have
> > those features. I think we may agree on adding such a
> > requirement, especially if we use today's common OSs as
> > models rather than dreaming up new features OSs
> don't have yet.
> >
> > Another point that may meet more resistance, but
> seems clear
> > to me, is the utter inseperability of content from
> software
> > once we agree that there is an interlocking set of
> > relationships in the web/software arena. In the
> examples of
> > the web page and voice mail system I used above, how
> can the
> > tools be abstracted from the content? My thinking
> here is
> > not very well developed, so I look forward to a
> dialogue.
> >
> >

• Next message in Thread: terry.weaver@gsa.gov: "Re: Starting discussions ontheAccessibilityAPIproposal"
• Previous message in Thread: None