Thread Subject: Re: Concerns about ourcurrent definition of a "platform"

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: Hoffman, Allen
Date: Wed, Aug 22 2007 6:30 AM

Can't the platform actually provide the services and use underlying,
both? I don't think this is mutually exclusive. I've been keeping out
of this one since I'm certain both of you are far more familiar with
layers of platforms than I, but lets look at this from a "not mutually
exclusive" perspective, since JNI tends to make me think this is not an
either or, but a a, b, or portions of A and B situation. But, lets not
put our a's and b's back in! Ha.

Peter and Sean i really want to say thanks for the work both you have
done on this item as I think this is a very critical piece of assembling
an end-to-end set of technical standards that may put usable boundaries
around the accessibility stack, and lead to a more standardized or in
Peter's term, "intentional" approach to accessibility in the software
arena as we move forward.





Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean
Hayes
Sent: Wednesday, August 22, 2007 5:54 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Concerns about ourcurrent definition
of a "platform"

Here is how I see it:

1 If a platform is completely isolating, then it must provide access
within the platform.
2 If not then there is a choice:
a it provides access within the platform (preferred for
"substantially complete platforms")
b it provides access to the underlying platform.

In no case is an app running on the platform 'hosed', as they can always
get at the required information, although it is perhaps easier if the
platform chooses 2a, rather than 2b.

So a platform that is "intended to create substantially complete
environments" *must* provide access - they just have a choice *how*.
If you don't think my proposed wording says this, then there is a
problem; but that's what I had in mind. I did not intend for any
platform to have an 'out' which leaves it inaccessible.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: 21 August 2007 23:45
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Concerns about our current definition
of a "platform"

Sean,

OK, looking at your draft language, you write:

> 3-W (a) Applications running on a platform that is also an
'application' running on another platform must have access to:
>
> 1 the underlying platform's color, contrast, and other individual
display settings, so that these applications can meet the User
Preferences provision.
> 2 the underlying platform's accessibility services information, so
that those applications can meet the AT Interoperability provision.

But if my platform is a "fully isolating platform", then applications
running on my platform *cannot* have access to the underlying platforms
accessibility services information. They rather have access to *my*
platform's accessibility services information, and it is my platform's
responsibility to play translator.

This is part of why I think your 3-W(a) is the wrong approach; we should
focus on what a platform that is "intended to create substantially
complete environments" *must* provide. If it isn't provided, then apps
above it are hosed. There is nothing they can do to be accessible. We
have essentially said "you can't meet the technical provisions if you
run on X". Now, that is a fine reality, but it should be clear from the
get go, and agencies should understand that what they are acquiring is
an inaccessible platform, upon which applications cannot be compatible
with underlying AT (essentially they have acquiring a closed platform
that runs on a potentially open OS), and so all apps on that platform
must behave as if they are on a closed system, and be completely
self-accessible.

On the other hand, if the platform supports an equivalent of JNI,
allowing direct access to the underlying platform/OS, then it should be
clear that the route for apps to take to be compatible with AT is via
that mechanism, and only that mechanism.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

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