W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2004

Re: Access Key alternative -in the wrong place?

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Tue, 13 Jul 2004 12:14:34 -0400
Message-Id: <p06110405bd19ae1f266e@[10.0.1.2]>
To: w3c-wai-gl@w3.org
Cc: Liddy Nevile <liddy.nevile@motile.net>

At 3:00 PM -0500 7/12/04, Richard Schwerdtfeger wrote:

>  it is becoming less likely that transcoding will be done in the 
>middleware to process it since more often than not the UI will be 
>constructed on the client.

For one thing, I see the opposite trend happening at the same time.

Compare with XRT2
http://64.233.161.104/search?q=cache:vbjWRFa6ZCQJ:www.intel.com/technology/upnp/download/Intel_UPnP-Based_Remote_IO_Developers_Guide_v0.4.pdf+XRT2+Intel&hl=en

It's not clear which trend is actually winning.

In any case, I don't see that we have the choice to try to guess the 
winner and only go with that.  We need
to be covering our bets so that where there is a role for RDF-reading 
AT, or for middleware, it can perform in that role.

Getting the necessary information in the W3C DOM and from there into 
an API near and dear to the AT does indeed appear to be our main 
chance at the moment to get the information to the AT where the AT 
gets its shot at meeting the user's needs.

Client-applied and middleware-or-server-applied transforms will 
coexist, don't you think?  I don't see people serving our new, 
improved HTML, whether it's XHTML 2.0 or XHTML 1.1+, without serving 
something compatible with HTML4 processors as well.

Al


>Jim,
>
>Browsers need to map RDF to an API to describe how to interact with 
>an object. This requires a good RDF parser.
>
>Furthermore, it is becoming less likely that transcoding will be 
>done in the middleware to process it since more often than not the 
>UI will be constructed on the client.
>
>
>Rich Schwerdtfeger
>STSM, Software Group Accessibility Strategist/Master Inventor
>Emerging Internet Technologies
>Chair, IBM Accessibility Architecture Review Board
>schwer@us.ibm.com, Phone: 512-838-4593,T/L: 678-4593
>
>"Two roads diverged in a wood, and I -
>I took the one less traveled by, and that has made all the difference.", Frost
>
>  Jim Ley <jim.ley@gmail.com>
>
>Jim Ley <jim.ley@gmail.com>
>Sent by: w3c-wai-pf-request@w3.org
>07/10/2004 06:17 AM
>
>
>To
>
>Richard Schwerdtfeger/Austin/IBM@IBMUS
>
>cc
>
>Lisa Seeman <lisa@ubaccess.com>, Becky Gibson/Westford/IBM@Iris, Jon 
>Gunderson <jongund@uiuc.edu>, Liddy Nevile 
><liddy.nevile@motile.net>, w3c-wai-gl@w3.org, w3c-wai-pf@w3.org, 
>wai-gl@w3c.org
>
>Subject
>
>Re: Access Key alternative -in the wrong place?
>
>
>
>Richard Schwerdtfeger <schwer@us.ibm.com>
>>Another concern that is growing for me is RDF. One of the problems we
>>are faced with on RDF is that NO browser supports it.
>
>I'm not exactly sure how you suggest browsers should or need to
>support RDF for this, it's not being served up to a user as bare RDF,
>but simply using RDF to provide useful additional metadata.
>
>The metadata need not be consumed by mainstream browsers, indeed I'm
>not sure what usefulness mozilla would have in doing so to the
>majority of its users, however it's easy to extend the browser with
>plugins to provide the functionality in an AT sense.
>
>Or do you propose inventing a new metadata format?
>
>Jim.
>
>
>The following document was sent as an embedded object but not 
>referenced by the email above:
>Attachment converted: Macintosh HD:pic20008.gif (GIFf/prvw) (0005CD6F)
Received on Tuesday, 13 July 2004 12:15:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:58 UTC