Thread Subject: Re: Platform issues
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: Peter Wallack
Date: Fri, Jun 08 2007 11:40 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Sean Hayes: "Re: Platform issues"
- Previous message in thread: Sean Hayes: "Re: Platform issues"
- Messages sorted by: Author | Thread | Date
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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*.<br>
<br>
<pre class="moz-signature" cols="72">Peter Wallack
Accessibility Program Director
Oracle Corporation</pre>
<br>
<br>
Sean Hayes wrote:
<blockquote
cite="mid: = EMAIL ADDRESS REMOVED = "
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.moz-txt-citetags
{mso-style-name:moz-txt-citetags;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="Section1">
<p class="MsoNormal"><a moz-do-not-send="true" name="_MailEndCompose"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">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.<o:p></o:p></span></a></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span
style="font-size: 10pt; color: rgb(31, 73, 125);" lang="EN-US">Sean
Hayes<br>
Standards and Policy Team<br>
<b>Corporate Accessibility Group<br>
Microsoft<br>
</b>Phone: <br>
mob +44 7977 455002<br>
office +44 117 9719730</span><span style="color: rgb(31, 73, 125);"
lang="EN-US"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<div>
<div
style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
<p class="MsoNormal"><b><span
style="font-size: 10pt; font-family: "Tahoma","sans-serif"; color: windowtext;"
lang="EN-US">From:</span></b><span
style="font-size: 10pt; font-family: "Tahoma","sans-serif"; color: windowtext;"
lang="EN-US"> <a class="moz-txt-link-abbreviated" href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a>
[<a class="moz-txt-link-freetext" href="mailto: = EMAIL ADDRESS REMOVED = ">mailto: = EMAIL ADDRESS REMOVED = </a>] <b>On Behalf Of </b>Peter
Wallack<br>
<b>Sent:</b> 08 June 2007 18:23<br>
<b>To:</b> TEITAC Web/Software Subcommittee<br>
<b>Subject:</b> Re: [teitac-websoftware] Platform issues<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I'm not grokking this. With the inclusion of the
Note:<br>
<br>
<o:p></o:p></p>
<pre>For example, a program which hosts plug-in's is not a platform if the<span
class="moz-txt-citetags"> </span>plug-in could directly access the underlying layer.<o:p></o:p></pre>
<p class="MsoNormal">doesn't that mean that a browser is not a
platform? I
thought snagging a browser was the primary intent of this.<br>
<br>
<o:p></o:p></p>
<pre>Peter Wallack<o:p></o:p></pre>
<pre>Accessibility Program Director<o:p></o:p></pre>
<pre>Oracle Corporation<o:p></o:p></pre>
<p class="MsoNormal"><br>
<br>
Peter Korn wrote: <o:p></o:p></p>
<pre>Hi Sean, Allen,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I think these are good starts. "In the wild", one of the key aspects of <o:p></o:p></pre>
<pre>a "platform" is that the isolation from the the underlying OS/platform <o:p></o:p></pre>
<pre>allows developers to deploy "cross-platform" applications. E.g. a web <o:p></o:p></pre>
<pre>application, or Java application, or Flash application - they all run <o:p></o:p></pre>
<pre>*unchanged* on Windows and Mac and UNIX (and other places); no "porting" <o:p></o:p></pre>
<pre>is involved. <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I don't know if that concept is critical to our definition of a <o:p></o:p></pre>
<pre>platform, but it is certainly common to all of the commercial examples <o:p></o:p></pre>
<pre>I'm aware of that we need to apply the "platform on a platform" <o:p></o:p></pre>
<pre>accessibility provision(s) to.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Regards,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Peter Korn<o:p></o:p></pre>
<pre>Accessibility Architect,<o:p></o:p></pre>
<pre>Sun Microsystems, Inc.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<pre>Sean wrote:<o:p></o:p></pre>
<pre>"A platform is a collection of software components (B) that runs on an<o:p></o:p></pre>
<pre>underlying software or hardware layer (A), such that B creates a virtual<o:p></o:p></pre>
<pre>environment in which to run third party applications (C) in a manner<o:p></o:p></pre>
<pre>which isolates the applications C from the underlying layer A.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Note 1: B is not a platform if there is a direct route from C to A. For<o:p></o:p></pre>
<pre>example, a program which hosts plug-in's is not a platform if the<o:p></o:p></pre>
<pre>plug-in could directly access the underlying layer A.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Note 2: B is not a platform if it's an application offering a compute<o:p></o:p></pre>
<pre>service, such as a 3d rendering engine where a requesting application<o:p></o:p></pre>
<pre>could directly access the underlying layer A."<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>If this can be written to leave out the A, B, and C it would read more<o:p></o:p></pre>
<pre>clearly. (maybe?) I'll take a stab. I think this is a good start.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>A platform is a collection of software components that runs on an<o:p></o:p></pre>
<pre>underlying software or hardware layer, such that the platform creates a<o:p></o:p></pre>
<pre>virtual environment in which to run applications in a manner which<o:p></o:p></pre>
<pre>isolates the applications from the underlying layer. <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Note 1: if there is a direct route from the application to the<o:p></o:p></pre>
<pre>underlying layer then the software components in the middle are not<o:p></o:p></pre>
<pre>considered to be a "platform". <o:p></o:p></pre>
<pre>For example, a program which hosts plug-in's is not a platform if the<o:p></o:p></pre>
<pre>plug-in could directly access the underlying layer.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Note 2: Ann application offering a compute service, such as a 3d<o:p></o:p></pre>
<pre>rendering engine where a requesting application could directly access<o:p></o:p></pre>
<pre>the underlying layer would also not be considered a "platform".<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Note 3: Platforms can include such things as Internet browsers,<o:p></o:p></pre>
<pre>operating systems, plug-ins to internet browsers or other software<o:p></o:p></pre>
<pre>applications, and under some situations, byte-code interpreted virtual<o:p></o:p></pre>
<pre>environments, and other "programming within another programming"<o:p></o:p></pre>
<pre>environment.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>somewhere the word dependent needs to be inserted to get the concept<o:p></o:p></pre>
<pre>that while platforms act as isolating "layers", they also provide<o:p></o:p></pre>
<pre>services between layers.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Anyone else?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Allen Hoffman -- <a moz-do-not-send="true"
href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a>; v: 202-447-0303<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>-----Original Message-----<o:p></o:p></pre>
<pre>From: <a moz-do-not-send="true"
href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a><o:p></o:p></pre>
<pre>[<a moz-do-not-send="true"
href="mailto: = EMAIL ADDRESS REMOVED = ">mailto: = EMAIL ADDRESS REMOVED = </a>] On Behalf Of Sean<o:p></o:p></pre>
<pre>Hayes<o:p></o:p></pre>
<pre>Sent: Thursday, June 07, 2007 1:19 PM<o:p></o:p></pre>
<pre>To: TEITAC Web/Software Subcommittee<o:p></o:p></pre>
<pre>Subject: Re: [teitac-websoftware] Platform issues<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Based on our discussion at the last call, here is a straw man definition<o:p></o:p></pre>
<pre>of platform, the wording here probably needs work, but I think the ideas<o:p></o:p></pre>
<pre>are valid.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>"A platform is a collection of software components (B) that runs on an<o:p></o:p></pre>
<pre>underlying software or hardware layer (A), such that B creates a virtual<o:p></o:p></pre>
<pre>environment in which to run third party applications (C) in a manner<o:p></o:p></pre>
<pre>which isolates the applications C from the underlying layer A.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Note 1: B is not a platform if there is a direct route from C to A. For<o:p></o:p></pre>
<pre>example, a program which hosts plug-in's is not a platform if the<o:p></o:p></pre>
<pre>plug-in could directly access the underlying layer A.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Note 2: B is not a platform if it's an application offering a compute<o:p></o:p></pre>
<pre>service, such as a 3d rendering engine where a requesting application<o:p></o:p></pre>
<pre>could directly access the underlying layer A."<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Thoughts?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Sean Hayes<o:p></o:p></pre>
<pre>Standards and Policy Team<o:p></o:p></pre>
<pre>Corporate Accessibility Group<o:p></o:p></pre>
<pre>Microsoft<o:p></o:p></pre>
<pre>Phone:<o:p></o:p></pre>
<pre> mob +44 7977 455002<o:p></o:p></pre>
<pre> office +44 117 9719730<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>-----Original Message-----<o:p></o:p></pre>
<pre>From: <a moz-do-not-send="true"
href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a><o:p></o:p></pre>
<pre>[<a moz-do-not-send="true"
href="mailto: = EMAIL ADDRESS REMOVED = ">mailto: = EMAIL ADDRESS REMOVED = </a>] On Behalf Of Peter<o:p></o:p></pre>
<pre>Korn<o:p></o:p></pre>
<pre>Sent: 31 May 2007 23:41<o:p></o:p></pre>
<pre>To: TEITAC Web/Software Subcommittee<o:p></o:p></pre>
<pre>Subject: Re: [teitac-websoftware] Platform issues<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>A little while ago Andi started a discussion of the platform issues (or<o:p></o:p></pre>
<pre>"platform-on-platform" issues). We have some definitions from HFES 200<o:p></o:p></pre>
<pre>to use as a starting point (see<o:p></o:p></pre>
<pre><a moz-do-not-send="true"
href="http://teitac.org/wiki/Web_and_Software:_Platform_Issues">http://teitac.org/wiki/Web_and_Software:_Platform_Issues</a>). But as a<o:p></o:p></pre>
<pre>subcommittee, we haven't yet figured out whether there should be any<o:p></o:p></pre>
<pre>specific accessibility standards for a "platform running on another<o:p></o:p></pre>
<pre>platform" - e.g. a web browser, or a Flash player, or the Java runtime.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Looking over our software standards - and specifically in the new format<o:p></o:p></pre>
<pre>from yesterday (see <a moz-do-not-send="true"
href="http://teitac.org/wiki/EWG:Draft_May_30">http://teitac.org/wiki/EWG:Draft_May_30</a>) items<o:p></o:p></pre>
<pre>3.1.A, 3.2.E, 3.4.A, and even 3.4.C, it is clear that an application<o:p></o:p></pre>
<pre>that running on a platform that is itself running on another platform<o:p></o:p></pre>
<pre>(e.g. a dynamic HTML app in a browser, a Java applet in Java runtime in<o:p></o:p></pre>
<pre>a browser) will have a very hard time meeting those standards unless the<o:p></o:p></pre>
<pre>"immediate platform" conveys critical information to it from the<o:p></o:p></pre>
<pre>"underlying platform", and likewise conveys back object information to<o:p></o:p></pre>
<pre>AT that may be running on the underlying platform.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>In essence, this "immediate platform" needs to act as something of a<o:p></o:p></pre>
<pre>broker/translator/conveyer of accessibility information between its<o:p></o:p></pre>
<pre>applications and the underlying platform. How can a screen reader know<o:p></o:p></pre>
<pre>that this dynamic HTML object is a checkbox that just got checked unless<o:p></o:p></pre>
<pre>the browser (immediate platform) conveys that from the dynamic HTML<o:p></o:p></pre>
<pre>application to the AT running on the underlying platform? How can the<o:p></o:p></pre>
<pre>Java applet know what the user's desktop color and contrast settings are<o:p></o:p></pre>
<pre>unless the Java runtime picks that information up from the underlying<o:p></o:p></pre>
<pre>platform and conveys it to the Java applet?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>To that end, I've taken a stab at some language for us to consider:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> Software that is both a 'platform', and an 'application' running<o:p></o:p></pre>
<pre> on another platform shall:<o:p></o:p></pre>
<pre> a. expose the underlying platform's color, contrast, and other<o:p></o:p></pre>
<pre> individual display settings to applications running within<o:p></o:p></pre>
<pre> its platform, so that these applications can respect the<o:p></o:p></pre>
<pre> color, contrast, and other individual displays settings of<o:p></o:p></pre>
<pre> the underlying platform - so that those applications can<o:p></o:p></pre>
<pre> meet 1194.21(g) / 3.2.E.<o:p></o:p></pre>
<pre> b. define, expose, and translate accessibility service information<o:p></o:p></pre>
<pre> between applications running within its platform and the<o:p></o:p></pre>
<pre> underlying platform - so that those applications can meet<o:p></o:p></pre>
<pre> 1194.21(d) / 3.4.A.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I also think we need a (c) that addresses keyboard navigation (e.g. the<o:p></o:p></pre>
<pre>problem of whether and how to TAB into a Java applet or Flash<o:p></o:p></pre>
<pre>application in a browser, and then back out of that to other elements on<o:p></o:p></pre>
<pre>the web page). But I'm not at all satisfied with my attempts so far at<o:p></o:p></pre>
<pre>that language:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> c. mediate any keyboard control and navigation between the<o:p></o:p></pre>
<pre> applications and the underlying platform, to provide for a<o:p></o:p></pre>
<pre> consistent navigation mechanism between user interface elements<o:p></o:p></pre>
<pre> inside the application and those outside of it.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Also, we don't say anything about keyboard operation consistency. We've<o:p></o:p></pre>
<pre>gone to great lengths in Java/Swing to use the keyboard mnemonics and<o:p></o:p></pre>
<pre>gestures of the underlying platform (e.g. using + and - for<o:p></o:p></pre>
<pre>expanding/closing a Swing tree node in a tree control on UNIX, while<o:p></o:p></pre>
<pre>using left and right arrow for expanding/closing a Swing tree node in a<o:p></o:p></pre>
<pre>tree control on Windows). This sort of consistency is a usability<o:p></o:p></pre>
<pre>issue; it isn't as clearly an accessibility issue (if we didn't do this,<o:p></o:p></pre>
<pre>you would simply have to learn a different keyboard gesture, but<o:p></o:p></pre>
<pre>certainly the keyboard operability requirements of 1194.21(a) / 3.3.A<o:p></o:p></pre>
<pre>are met without that consistency.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Thinking further about 1194.21(c) / 3.4.C., graphical UNIX today<o:p></o:p></pre>
<pre>provides some definition of the visual focus indicator as part of the<o:p></o:p></pre>
<pre>desktop theme (perhaps Windows does as well). I would consider this as<o:p></o:p></pre>
<pre>simple another "individual display setting". But this has an impact in<o:p></o:p></pre>
<pre>the "platform-on-platform" situation because we would want the visual<o:p></o:p></pre>
<pre>focus indication of user interface elements of say a web app or a Java<o:p></o:p></pre>
<pre>applet to be consistent with those of the underlying platform/desktop.<o:p></o:p></pre>
<pre>So that in the UNIX case, a high-contrast-large-print theme with its<o:p></o:p></pre>
<pre>definition of a heavy thick dotted-line border focus indicator could be<o:p></o:p></pre>
<pre>carried over to that web app or Java applet.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Regards,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Peter Korn<o:p></o:p></pre>
<pre>Accessibility Architect,<o:p></o:p></pre>
<pre>Sun Microsystems, Inc.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre> <o:p></o:p></pre>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<pre>We have had a bit of discussion about platform issues but we have not <o:p></o:p></pre>
<pre>really developed any proposals or decisions in this area.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I created a page for this on the wiki. It contains a link to the<o:p></o:p></pre>
<pre> <o:p></o:p></pre>
<pre> <o:p></o:p></pre>
</blockquote>
<pre>mailing list thread on this topic and some definitions. [1] We won't<o:p></o:p></pre>
<pre>have this on the agenda for the subcommittee meeting until at least<o:p></o:p></pre>
<pre>mid-April, but please think about what we ought to do in this area, and<o:p></o:p></pre>
<pre>discuss it on the mailing list, or on the "discuss this article" page on<o:p></o:p></pre>
<pre>the wiki.<o:p></o:p></pre>
<pre> <o:p></o:p></pre>
<pre> <o:p></o:p></pre>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<pre>[1] <a moz-do-not-send="true"
href="http://teitac.org/wiki/Web_and_Software:_Platform_Issues">http://teitac.org/wiki/Web_and_Software:_Platform_Issues</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Andi<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>
- Next message in Thread: Sean Hayes: "Re: Platform issues"
- Previous message in Thread: Sean Hayes: "Re: Platform issues"
WebAIM is an initiative of:
