W3C home > Mailing lists > Public > wai-xtech@w3.org > November 2007

Making role="document" work

From: Hans Hillen <hhillen@paciellogroup.com>
Date: Tue, 06 Nov 2007 13:33:29 -0800
Message-ID: <4730DDA9.2080408@paciellogroup.com>
To: wai-xtech@w3.org

Hi everyone,

I was wondering if anybody has any practical experience with the use of 
the 'document'  ARIA role.

I'm working on an email client web application which has a role of 
'application', and within the interface there is an iframe that is used 
to display an email's content. From what I understand, a role of 
'document' would be applicable here, so that screen readers that support 
it to will switch from non virtual mode (which is used for the rest of 
the interface)  to virtual mode. This would then allow the user to read 
the non-focusable email content using standard screen reader navigation. 
So far I haven't been able to put this into practice however. I've tried 
applying the role to the iframe itself , its contentDocument and body 
node, but also (as a test case) to just a basic focusable div with text 
in it. According to the ARIA MDC page the role should be supported by 
WindowEeyes 5.5 or higher, but I can't seem to get WE6.1 to see or use 
the role. JAWS doesn't work either, but at least JAWS users can switch 
back to virtual mode themselves and then read the message manually. If 
you switch back to browse mode in WindowEyes, focus is placed back to 
the beginning of the page, away from the email message. So currently 
it's more or less impossible for WindowEyes users to read the messages, 
which is of course the main feature of an email client.

Is there anyone who has gotten the document role to work in real life? 
To which node should the role be applied? Where should the focus be 
placed for the screen reader to recognize it? What is the screen 
reader's expected behavior?


Thanks,
Hans Hillen
Received on Tuesday, 6 November 2007 21:34:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:44 GMT