DOMI and accessibility events
Alexander Surkov
able to reflects accessibility events. Step by step DOM Inspector
makes closer to be a valuable accessibility tool (now it can be used
already to investigate accessbile tree and properties of accessible
objects, see bugs 337674 and 347791) . But it still not able to show
accessibility events. I talked with Shawn Wilsher and he is not
against this idea but he suggested to get some public feedback to
approve the idea from the accessibility team. Do you think it's useful
feature for futher DOMi evolution as valuable accessibility tool?
Thank you,
Alexander.
Steve Lee
> Do you think it's useful
> feature for futher DOMi evolution as valuable accessibility tool?
Do you mean showing event declaration in markup? Dynamic event capture
would change the nature from a simple browser but sounds useful.
I can think of 2 reasons to say yes.
1) Accessibility so often means interacting with the DOM (rather than
just getting content correct). This is vital now Ajax and ARIA are on
the rise. These are effectively DOM extensions so DOMi (or any tool)
really needs to have complete support, including events.
2) Accessibility should be part of any application usability design,
so putting it in the tool that gets used most will hopefully get more
authors/developers thinking about it. We need to be mainstream not an
after thought.
I guess these boil down to not having a second accessibility-only tool
when it could and should be in the main tool everyone uses. Firebug is
another one to think about.
--
Steve Lee
--
Open Source Assistive Technology Software
PowerTalk - your presentations can speak for themselves
www.fullmeasure.co.uk
Alexander Surkov
> On 11/07/07, Alexander Surkov <surkov.alexan...@gmail.com> wrote:
>
> > Do you think it's useful
> > feature for futher DOMi evolution as valuable accessibility tool?
>
> Do you mean showing event declaration in markup? Dynamic event capture
> would change the nature from a simple browser but sounds useful.
I'm not sure I get right you about event declaration in markup. But I
think we can listen to accessibility events and show list of events
that are occurred on selected element or on entirely tree. If you
click on some event in the list then it shows it properties. For
example, for general event it will show accessible object, for state
change event it shows state that is changed additionally. Also, we
should be able to choose event types we want to listen.
David Bolter
I like the idea of getting this kind of functionality into the more
popular extensions.
Selfishly though... Aaron has talked about, and I'd like to see, a great
unified accessibility developer extension that shows the a11y events,
and the a11y node tree (which, as you know, is not 1:1 with the DOM
tree). I'd like the tool to offer me logging of MSAA, ATK, and Apple
a11y events as exposed by FF. As for filtering events... I'd like to see
all the options currently available in Accerciser. That's probably just
a matter of furthering Jon Gunderson's work.
I'm on the fence though... because I use both extensions and combining
them would be neat. I'm just uncomfortable with the idea of bloating
the DOMI tool.
cheers,
D
> _______________________________________________
> dev-accessibility mailing list
> dev-acce...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-accessibility
>
Tom Brunet
> them would be neat. I'm just uncomfortable with the idea of bloating
> the DOMI tool.
I'm personally a very big fan of FireBug:
https://addons.mozilla.org/en-US/firefox/addon/1843
Although I don't think it can be used for investigating chrome at the
moment, it might be a useful target for this sort of 'bloat'?
Tom
Alexander Surkov
On 11 , 17:22, David Bolter <david.bol...@utoronto.ca> wrote:
> Hi Alexander,
>
> I like the idea of getting this kind of functionality into the more
> popular extensions.
>
> Selfishly though... Aaron has talked about, and I'd like to see, a great
> unified accessibility developer extension that shows the a11y events,
> and the a11y node tree (which, as you know, is not 1:1 with the DOM
> tree).
Sure and we have DOMi bug for this.
> I'd like the tool to offer me logging of MSAA, ATK, and Apple
> a11y events as exposed by FF.
That is good idea to reflect not only cross platform events.
> I'm on the fence though... because I use both extensions and combining
> them would be neat. I'm just uncomfortable with the idea of bloating
> the DOMI tool.
It would be hard to create ally tool from the beginning. I'm not very
well familar with Firebug but DOMi is a good platform to bring
accessibility inspection there easy enough. Also it's very usefull to
have all in one tool because navigation through ally tree is very
close related to navigation through the DOM like Steve mentioned
already. Otherwise we will have two tools for the the same target.
DOMi has partial support of ally navigation already and I use it often
enough therefore I'd vote to procceed ally expansion into DOMi.
David Bolter
OK I'm convinced :) You have my vote.
D
Alexander Surkov
> OK I'm convinced :) You have my vote.
Thank you :) DOMi has one advantage is Timeless and Shawn don't deny
us to bring ally into DOMi. Possibly we should have someone who will
investigate the question and if DOMi will be choosed as a best
platform then he will polish ally support there so that we will have
very nice tool to inspect ally in mozilla.
T.V Raman
1+
--
Best Regards,
--raman
Title: Research Scientist
Email: ra...@google.com
WWW: http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk: ra...@google.com, tv.ra...@gmail.com
PGP: http://emacspeak.sf.net/raman/raman-almaden.asc