accessible and rich-interactive i-together clients

I have been giving some more thought to the thorny issue of how to deploy a server/client solution that offers the benefits of RIA functionality (drag and drop, contextual menus etc.) while still being fully accessible to screen readers (for the sight-impaired) and web crawlers (programs that index the web) from search engines, and embodying a granular system of URLs (so that users can bookmark and link to any page or sub-section of a page).

The diagram above outlines my provisional ideas. The starting point is to mirror the XML-structured data for each page and page sub-section held in the database in equivalent actual XML pages (intended for machines) stored at unique URLs. These XML pages would not be intended for surfing by sighted users, as they would appear in a browser much like this XML summary of my weblog (intended for machines, e.g. newsreaders etc.). These XML pages, then, would make i-together content accessible to screen readers and web crawlers (and hence Google searches etc.).

Sighted users, on the other hand, would access i-together through the i-together RIA UI. The two UI options (accessible and RIA) could be linked to from an (HTML) i-together homepage. The RIA client would exchange XML-formatted data—equivalent to the XML pages for the machines, but in "variable" format—with the Data Processing layer (server). Data sent from the server would be interpreted by the client to present the user with the appropriate content, layout and interactive options for any given page or sub-section. Conversely, information about the user's interactions within i-together, made via the client's visually-rich UI, would be transmitted back to the Data Processing layer, which in turn would evaluate what new data needed to be sent back to the client based on those interactions (for example, a information about a whole new page if the user had clicked a link, but just an extra text box if the user had requested an inline preview of another page via RSS).

Is it technically feasible to have the URL of the RIA track the pages and sub-sections the user surfs, or it is necessary to have a single, static root URL for the RIA and just to display the changing URLs within the UI to allow bookmarking and linking (surfing to one of these URLs would result in a redirect to the static root URL whilst passing data about the required page/subsection to the app)? The second option is less elegant, but I have a feeling that, given the way our likely RIA client-side technology of choice, Flash, operates, it may be the only possible one of the two.

Going back to the overall issue of the dual clients, one drawback to this arrangement is that sighted people may stumble on the plain XML pages, through a Google search, for instance. The best work around for this might be to append a redirect link to each XML page along the lines of "this page is for machines to read. would you like to view a version of this page for people?". A cookie could then be set for subsequent automatic redirects to the RIA versions of content. Not ideal, but are there better solutions this side of Microsoft releasing Longhorn in 2006? Then there's the issue of search engine optimisation: the RIA effectively hides content from search engines on the server side, so Google et al would possibly not be able to spider i-together content at the RIA URLs, even if they were linked to from other pages. What a headache!