Re: [orca-list] Does Orca not respect role="application" on anything other than body elements?



A way for you to test in the meantime is to enable Orca's sticky focus
mode. Because that mode is Orca's "let the web app handle it all" mode.

--joanie

On 07/25/2016 12:35 PM, Nolan Darilek wrote:
Right, I'll be using role="document" in most places and implementing my
own handling where necessary. I just need to keep users from arrowing
down from a menu and landing at the beginning of a document area
containing text, thus moving their cursor position and triggering my
tracking code to trash their original place. :) Not sure if that will
work as I think it might, but in order to know I need role="application"
to work as described in the spec--or, at least, how I've seen it work in
NVDA.


That said, it might be nice to have some way of disabling that behavior.
I've seen a few sites that use it because hey, it's ARIA, they need to
use ARIA, and they're applications so... :) It'd be nice to have an
ejection seat from someone else's idea of a good experience.


Thanks!



On 07/25/2016 11:30 AM, Joanmarie Diggs wrote:
Hey Nolan.

Understood. And I've put addressing this on my to-do list.

I trust that your application is going to handle the key events, right?
Because if Orca's focus mode kicks in, that just means it won't
reposition the caret; it won't prevent Firefox's native caret navigation
from doing so.

--joanie

On 07/25/2016 11:51 AM, Nolan Darilek wrote:
Got it. My understanding is that role="application" should override text
navigability, which is why I'm using it in this instance.


Thanks for the explanation.



On 07/25/2016 10:04 AM, Joanmarie Diggs wrote:
Hi Nolan.

I just took a quick glance (as I'm in the middle of something else).
But
as a general rule, Orca respects role="application" on page elements
when there is not something that looks like caret-navigable text. And
your paragraph child looks like caret-navigable text.

--joanie

On 07/25/2016 10:48 AM, Nolan Darilek wrote:
Working on an HTML-based ebook reader and am experimenting with using
role="application" so someone can't arrow down from a menu into ebook
text and trash their current position. But it doesn't seem like Orca
respects role="application" on non-body elements. Take, for instance,
this attached document. If I put role="application" on the body,
everything works as expected and I can't arrow around. But with it on
the <main/> element, nothing changes.

Am I missing something either in the spec, or in some Orca/Firefox
setup, that still permits this interaction? Thanks.


_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide:
https://help.gnome.org/users/gnome-help/stable/a11y.html
Log bugs and feature requests at http://bugzilla.gnome.org

_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide:
https://help.gnome.org/users/gnome-help/stable/a11y.html
Log bugs and feature requests at http://bugzilla.gnome.org



_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide:
https://help.gnome.org/users/gnome-help/stable/a11y.html
Log bugs and feature requests at http://bugzilla.gnome.org




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]