XUL and Jaws

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

XUL and Jaws

mozilla accessibility
I believe the Jaws problems relating to XUL that Tom refers to have
something to do with whether browser chrome is showing or not. I've never
tried XUL Runner, but I have been playing with XUL in Firefox a bit.

Attached is a small test file ripped out of a little test app I've been
working on. I've removed most of the javascript behavior, leaving just the
main window and some typical elements.

Put it somewhere that has a chrome URL (say its chrome package name is
test). If you load it via a shortcut or with a browser command line, it
works fine:
firefox.exe -chrome chrome:test/content/elementTest.xul

If you load it from within firefox or without the -chrome option, Jaws gets
confused. I believe the problem is the dreaded "Jaws Virtual Buffer". It
attempts to interpret the resulting DOM as a web page and initializes and
uses its virtual buffer. From my limited testing so far, even pressing enter
on an interactive control (which is supposed to turn off virtual buffer mode
and allow you to interact directly with the browser) doesn't do the right
thing.

There is a good article on JuicyStudio about Jaws and AJAX which gives an
excellent explanation of exactly what this virtual buffer is and why it is
used. If folks need this, I can send the URL. Its worth reading by anyone
doing extensive XUL development or in fact any development/testing involving
a browser and screen reader combination.

-- Rich Caloggero, WGBH NCAM

Done -
https://bugzilla.mozilla.org/show_bug.cgi?id=376622

I tried to drop some other xulrunners in my app.  I don't get the broken
behavior, but I don't have everything wired up and there are other
failures, so I can't confidently say that it's not just working by
accident ;)

Hope you had a good break.

Tom

Aaron Leventhal wrote:
> The best thing right now, is to file a bug, with these questions. If
> there's nothing to fix, at least we can clarify whatever the technique
> is, in our MSAA/ATK docs.
>
> I just got back from vacation so it probably won't be touched right
> away. If you file a bug that helps ensure the problem doesn't get
> forgotten in this newsgroup thread.

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: XUL and Jaws

Tom Brunet
> I believe the Jaws problems relating to XUL that Tom refers to have
> something to do with whether browser chrome is showing or not. I've never
> tried XUL Runner, but I have been playing with XUL in Firefox a bit.

This sounds a little more like a different issue that I've been
tracking.  If memory serves, here's the issue there:

The default browser area in Firefox has a type attribute of 'content'.
When this is specified, Mozilla uses a more secure window class
(MozillaContentWindowClass), where content can't access the chrome.
When -chrome is specified, your containing window uses the
MozillaUIWindowClass.

I believe JAWS decides if it's looking at a webpage solely by looking at
the window class and isn't looking to see if it has a parent element
with role='application' vs role='document'.

A major drawback to this though is that if you want XUL in a browser,
it's impossible to correctly label some controls.  JAWS ignores the MSAA
information and applies HTML heuristics that are incorrect for XUL.  If
you're lucky enough to be able to get it into forms mode, then it
sometimes behaves a little better.

I believe that Freedom knows about it, but that's second hand knowledge.

Tom
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility