- From: Hans Hillen <hhillen@paciellogroup.com>
- Date: Tue, 06 Nov 2007 13:33:29 -0800
- 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 UTC