Thread Subject: Re: Platform issues

From: Sean Hayes
Date: Fri, Jun 08 2007 11:45 AM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: None
• Previous message in thread: Peter Wallack: "Re: Platform issues"
• Messages sorted by: Author | Thread | Date

No, the intent is that if the plug in can access the OS directly, then in that situation the browser does not need to be responsible for reflecting all of the OS settings to the plug in.

But you bring up a good point, and I think the wording will need to be amended to make it clear that being a platform is a role; and that same piece of software may play the role of a platform in some situations, but not in others.

Sean Hayes
Standards and Policy Team
Corporate Accessibility Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730

From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Wallack
Sent: 08 June 2007 18:38
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Platform issues

Understood. But as currently worded, the standard leads me to believe that, for example, because ACME browser supports a plug-in that can be used to access to the OS directly, ACME browser itself is not a platform. I believe the intent is to exclude that *plug-in* from the platform definition, not the *browser*.



Peter Wallack

Accessibility Program Director

Oracle Corporation


Sean Hayes wrote:
It depends. A browser might be a 'platform' to Javascript/HTML as it does indeed isolate them from the OS. It might not be a platform to a toolbar plug in written in C++ which can utilise the OS API's.

Sean Hayes
Standards and Policy Team
Corporate Accessibility Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730

From: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Wallack
Sent: 08 June 2007 18:23
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Platform issues

I'm not grokking this. With the inclusion of the Note:



For example, a program which hosts plug-in's is not a platform if the plug-in could directly access the underlying layer.
doesn't that mean that a browser is not a platform? I thought snagging a browser was the primary intent of this.



Peter Wallack

Accessibility Program Director

Oracle Corporation


Peter Korn wrote:

Hi Sean, Allen,



I think these are good starts. "In the wild", one of the key aspects of

a "platform" is that the isolation from the the underlying OS/platform

allows developers to deploy "cross-platform" applications. E.g. a web

application, or Java application, or Flash application - they all run

*unchanged* on Windows and Mac and UNIX (and other places); no "porting"

is involved.



I don't know if that concept is critical to our definition of a

platform, but it is certainly common to all of the commercial examples

I'm aware of that we need to apply the "platform on a platform"

accessibility provision(s) to.





Regards,



Peter Korn

Accessibility Architect,

Sun Microsystems, Inc.





Sean wrote:

"A platform is a collection of software components (B) that runs on an

underlying software or hardware layer (A), such that B creates a virtual

environment in which to run third party applications (C) in a manner

which isolates the applications C from the underlying layer A.



Note 1: B is not a platform if there is a direct route from C to A. For

example, a program which hosts plug-in's is not a platform if the

plug-in could directly access the underlying layer A.



Note 2: B is not a platform if it's an application offering a compute

service, such as a 3d rendering engine where a requesting application

could directly access the underlying layer A."



If this can be written to leave out the A, B, and C it would read more

clearly. (maybe?) I'll take a stab. I think this is a good start.





A platform is a collection of software components that runs on an

underlying software or hardware layer, such that the platform creates a

virtual environment in which to run applications in a manner which

isolates the applications from the underlying layer.



Note 1: if there is a direct route from the application to the

underlying layer then the software components in the middle are not

considered to be a "platform".

For example, a program which hosts plug-in's is not a platform if the

plug-in could directly access the underlying layer.



Note 2: Ann application offering a compute service, such as a 3d

rendering engine where a requesting application could directly access

the underlying layer would also not be considered a "platform".



Note 3: Platforms can include such things as Internet browsers,

operating systems, plug-ins to internet browsers or other software

applications, and under some situations, byte-code interpreted virtual

environments, and other "programming within another programming"

environment.



somewhere the word dependent needs to be inserted to get the concept

that while platforms act as isolating "layers", they also provide

services between layers.



Anyone else?











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



-----Original Message-----

From: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean

Hayes

Sent: Thursday, June 07, 2007 1:19 PM

To: TEITAC Web/Software Subcommittee

Subject: Re: [teitac-websoftware] Platform issues



Based on our discussion at the last call, here is a straw man definition

of platform, the wording here probably needs work, but I think the ideas

are valid.



"A platform is a collection of software components (B) that runs on an

underlying software or hardware layer (A), such that B creates a virtual

environment in which to run third party applications (C) in a manner

which isolates the applications C from the underlying layer A.



Note 1: B is not a platform if there is a direct route from C to A. For

example, a program which hosts plug-in's is not a platform if the

plug-in could directly access the underlying layer A.



Note 2: B is not a platform if it's an application offering a compute

service, such as a 3d rendering engine where a requesting application

could directly access the underlying layer A."



Thoughts?



Sean Hayes

Standards and Policy Team

Corporate Accessibility Group

Microsoft

Phone:

mob +44 7977 455002

office +44 117 9719730





-----Original Message-----

From: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter

Korn

Sent: 31 May 2007 23:41

To: TEITAC Web/Software Subcommittee

Subject: Re: [teitac-websoftware] Platform issues



A little while ago Andi started a discussion of the platform issues (or

"platform-on-platform" issues). We have some definitions from HFES 200

to use as a starting point (see

http://teitac.org/wiki/Web_and_Software:_Platform_Issues). But as a

subcommittee, we haven't yet figured out whether there should be any

specific accessibility standards for a "platform running on another

platform" - e.g. a web browser, or a Flash player, or the Java runtime.



Looking over our software standards - and specifically in the new format

from yesterday (see http://teitac.org/wiki/EWG:Draft_May_30) items

3.1.A, 3.2.E, 3.4.A, and even 3.4.C, it is clear that an application

that running on a platform that is itself running on another platform

(e.g. a dynamic HTML app in a browser, a Java applet in Java runtime in

a browser) will have a very hard time meeting those standards unless the

"immediate platform" conveys critical information to it from the

"underlying platform", and likewise conveys back object information to

AT that may be running on the underlying platform.



In essence, this "immediate platform" needs to act as something of a

broker/translator/conveyer of accessibility information between its

applications and the underlying platform. How can a screen reader know

that this dynamic HTML object is a checkbox that just got checked unless

the browser (immediate platform) conveys that from the dynamic HTML

application to the AT running on the underlying platform? How can the

Java applet know what the user's desktop color and contrast settings are

unless the Java runtime picks that information up from the underlying

platform and conveys it to the Java applet?



To that end, I've taken a stab at some language for us to consider:



Software that is both a 'platform', and an 'application' running

on another platform shall:

a. expose the underlying platform's color, contrast, and other

individual display settings to applications running within

its platform, so that these applications can respect the

color, contrast, and other individual displays settings of

the underlying platform - so that those applications can

meet 1194.21(g) / 3.2.E.

b. define, expose, and translate accessibility service information

between applications running within its platform and the

underlying platform - so that those applications can meet

1194.21(d) / 3.4.A.



I also think we need a (c) that addresses keyboard navigation (e.g. the

problem of whether and how to TAB into a Java applet or Flash

application in a browser, and then back out of that to other elements on

the web page). But I'm not at all satisfied with my attempts so far at

that language:



c. mediate any keyboard control and navigation between the

applications and the underlying platform, to provide for a

consistent navigation mechanism between user interface elements

inside the application and those outside of it.



Also, we don't say anything about keyboard operation consistency. We've

gone to great lengths in Java/Swing to use the keyboard mnemonics and

gestures of the underlying platform (e.g. using + and - for

expanding/closing a Swing tree node in a tree control on UNIX, while

using left and right arrow for expanding/closing a Swing tree node in a

tree control on Windows). This sort of consistency is a usability

issue; it isn't as clearly an accessibility issue (if we didn't do this,

you would simply have to learn a different keyboard gesture, but

certainly the keyboard operability requirements of 1194.21(a) / 3.3.A

are met without that consistency.





Thinking further about 1194.21(c) / 3.4.C., graphical UNIX today

provides some definition of the visual focus indicator as part of the

desktop theme (perhaps Windows does as well). I would consider this as

simple another "individual display setting". But this has an impact in

the "platform-on-platform" situation because we would want the visual

focus indication of user interface elements of say a web app or a Java

applet to be consistent with those of the underlying platform/desktop.

So that in the UNIX case, a high-contrast-large-print theme with its

definition of a heavy thick dotted-line border focus indicator could be

carried over to that web app or Java applet.





Regards,



Peter Korn

Accessibility Architect,

Sun Microsystems, Inc.







We have had a bit of discussion about platform issues but we have not

really developed any proposals or decisions in this area.



I created a page for this on the wiki. It contains a link to the





mailing list thread on this topic and some definitions. [1] We won't

have this on the agenda for the subcommittee meeting until at least

mid-April, but please think about what we ought to do in this area, and

discuss it on the mailing list, or on the "discuss this article" page on

the wiki.





[1] http://teitac.org/wiki/Web_and_Software:_Platform_Issues



Andi

• Next message in Thread: None
• Previous message in Thread: Peter Wallack: "Re: Platform issues"