<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>DOM Scripting comments: Ajax and screenreaders</title>
        <link>http://domscripting.com/blog/display/64</link>
        <description>Finally we&#8217;re starting to see some solid research on this subject.</description>
        <language>en</language>
        <item>
            <title>Victor Tsaran</title>
            <link>http://domscripting.com/blog/display.php/64#comment392</link>
            <content:encoded><![CDATA[<p>It&#8217;s a two fold problem: on the one hand, DHTML developers do not always take programmatic considerations seriously, e.g. setting focus to an element versus emulating visual focus with CSS. No matter how smart a screen reader is, no feedback will be provided when an element claims to be in focus (visually), but not programmatically. The problem is similar to the one we have with desktop applications.
On the other han, screen readers have been relying on system events exclusively for a long while and DOM events is something very new in the screen reader land.
Unobtrusive scripting does resolve some of the accessibility problems, but far not all of them. Just a quick example: set of radiobuttons may be presented as set of hyperlinks which, when clicked on, reflect their selection status visually. Because there is no more information about the widget (its type, name etc), screen reader does not know whether the set of hyperlinks is a set of radiobuttons, list of options or simply bunch of links.
Two solutions here:
1. Use standard HTML elements and CSS them; or, better yet,
2. <a href="http://www.mozilla.org/access/dhtml">http://www.mozilla.org/access/dhtml</a>.</p>
]]></content:encoded>
            <pubDate>Mon, 08 May 2006 18:08:47 GMT</pubDate>
        </item>
        <item>
            <title>Jeremy Keith</title>
            <link>http://domscripting.com/blog/display.php/64#comment391</link>
            <content:encoded><![CDATA[<p>There’s definitely some promise in the Flash/JavaScript bridge. Flash is able to detect the presence of a screenreader — something that can’t be done directly with JavaScript. Once that presence is detected, then perhaps scripts could fork to send alert messages when the page is updated.</p>

<p>Of course, then the Flash player becomes a requirement. But, certainly in the short-term, some sort of Flash/JavaScript hybrid could work.</p>
]]></content:encoded>
            <pubDate>Mon, 08 May 2006 12:16:40 GMT</pubDate>
        </item>
        <item>
            <title>Kev</title>
            <link>http://domscripting.com/blog/display.php/64#comment390</link>
            <content:encoded><![CDATA[<p>In terms of notification, would a very small SWF movie containing a single sound be a good work around? It could operate a similar conceptual way to the Yellow Fade Technique, except obviously in an aural way rather than a visual way.</p>

<p>On a practical level, defining and subsequently calling a JS function which passes a variable into Flash would be child&#8217;s play. Actionscript picks up the incoming name/value pair and initiates the movieclip containing the sound.</p>

<p>You could even supply a number of differing sounds to indicate what part of the page had been updated. Further you could tailor the page to ask a user if they want sounds or not and thus those who desire aural notifications get them and those that don&#8217;t, won&#8217;t.</p>
]]></content:encoded>
            <pubDate>Mon, 08 May 2006 11:14:40 GMT</pubDate>
        </item>
   </channel>
</rss>