Forum Moderators: open
I have a second path for browsers that can't handle AJAX or have scripting disabled. This path offers an experience almost as good as the fancy one, but without things like Google Maps and the all-important throbber.
What I want to know is if there is a way to ensure that screen readers always get sent down the non-AJAX path. From the various discussions here, it looks like screen readers bravely try to render AJAX, and fall down.
As I said, I've tested without any bells and whistles, scripting disabled, old browsers, etc. They all get sent down the non-AJAX primrose path.
However, I would be crushed if my disabled users tried to go down the fancy (non-accessible) path.
Is there some capability or UA flag that I can use to detect screen readers as a general category?
I also have the capability of generating RSS and WML pages (I use XSLT), so it may even be better to send them that ways.
Is there an accept-type or something I can use?
However, that won't solve my dilemma. I need to send the reader to a different rendering of the page. I could show you how it works, but we can't do that here (No links TOS).
Basically, if you hit the page with a JavaScript-AJAX capable browser, you get a dynamic page with in-place content display. If you hit it without, the page needs to reload each time, but the content looks very similar. CSS won't give me that.
I still need to work on making the AJAX a bit more accessible, but, even then, it won't be that good.
The non-AJAX version will be fine. I just need to make sure that screen readers get that, as opposed to the dynamic version.
Can you provide both sets of content, the accessible one first, and use your alternative CSS versions to hide one or the other entirely?
Not without serious cost. It's an event search that uses PHP to XSLT an XML feed from another server. It can be pretty time-consuming. The lists can get very long, and it can take ten seconds or more to finish a request.
I need to commit to a path before sending the request to the other server. The AJAX path renders the page, then fills in the list after being fetched. The non-AJAX path delays rendering the page until it gets the rendered XSLT, so that means I can't redesign the delivery without incurring serious usability costs to the 90% of users that have AJAX-aware browsers.
That's why I want to make sure the proper path is executed.
I just measured the Brooklyn dump, and it's 370K. I don't want to give everyone 700K, just so a few of them can see it. I just want to make sure that the correct 370K gets sent to the browser.
First link on the page 'go to accessible version'... follow the link see the accessible version. If you want to keep the same URL, then just send a get argument on the end.
That's something to consider. I think maybe Marshall's <link /> idea may be the best way to do this (the site framework is WordPress, so I only have limited interaction between the list -which is a WP plugin- and the theme header.php, which is where either of these solutions would be implemented.)
However, I also seem to remember reading on this forum somewhere that links like that are considered rude.
The most polite way would be to handle it in exactly the same manner as I do non-AJAX browsers: Just send them static XHTML. The entire structure is already there. I just need to figure out how to send the browser to the correct code.
Thinking back on the CSS solution, I'm wondering if there is a way to implement a screen reader class, then check it in JavaScript. If the class is active, then I send the browser to the non-AJAX path. From what I understand, all screen readers can execute JavaScript. I remember a discussion along these lines for printer styles, and they concluded it couldn't be done. However, we have different rules here...
Links that require an extra action on the part of the visitor (skipnav, for example). The page should just plain render they way it's supposed to, with no intercession by the user.
This was why I like your idea, because these head tags are usually executed by the browser automatically. I'm just not sure if the reader would be able to use it.
I wonder if there is a WURFL [wurfl.sourceforge.net] for screen readers?