Focus with caret browsing in Firefox

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

Focus with caret browsing in Firefox

Michael Curran
Hi all,

Now that IAccessible2 has been introduced in to Gecko, I have been
implementing caret navigation of its edit fields in NVDA.

So far things are looking really good, I can now arrow around in Thunderbird
documents, and edit fields in Firefox. Some really good work has been done,
thanks To Aaron and Alexander for that.

However, I do have a question about caret browsing in Firefox. I was playing
around with it just before, and it actually works quite well, now that NVDA
now treets any object with an IAccessibleEditableText interface as possibly
responding to cursor actions like up down left and right arrows etc.

However, from what I can tell, when arrowing to objects such as paragraphs
etc, although the caret may move with in them, focus does not actually get
given to the object in question.

I understand that in theory focus shouldn't go to them when pressing tab
etc, but I was wondering if it would be possible for them to get focus if in
caret browsing mode, and the caret is moved in to one of them.

Currently, NVDA only manages a caret with in the object with focus, so if
the caret moves out of this object, and the focus doesn't change, NVDA gets
rather confused.

If there is a very good reason why paragraphs etc can't be given focus that
is fine, and we will continue to look in to other ways of doing our own
caret emulation (with virtual buffers and the like) but just out of interest
I would like to know if this way is in fact possible.

It would be rather nice if we could use the Firefox caret if its possible.

Thanks
Mick



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

Re: Focus with caret browsing in Firefox

bhawkeslewis
By spec, not all HTML elements can receive "content focus" by default.
I'm using content focus in the sense defined by UAAG:

http://www.w3.org/TR/UAAG10/glossary.html#def-current-focus

For more background on focus in HTML and Mozilla, please see:

http://www.w3.org/TR/html4/interact/forms.html#h-17.11

http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets

http://www.mozilla.org/access/keyboard/proposal

By default, there's no such thing as content focus for <p> in HTML, and
it would be a bug if they did receive content focus with the caret. But
as the caret moves over elements that can receive focus, such as links,
they receive content focus. And as the caret moves off such elements,
they lose content focus. (At least, they do in Firefox on Mac.)

<p> elements may not receive content focus, but you can still manipulate
their contents via the context menu (Shift + F10 on Windows).

Arrow keys cannot select form widgets. For that you need to tab into a
form widget, at which point caret browsing goes into widget mode. The
caret now becomes a caret local to edit boxes that does not move content
focus, until you tab out of the form.

But I don't understand why the distinction between caret and content
focus is a problem for NVDA. Can you explain what would be the
difference between a paragraph with focus in your terms and a paragraph
without such focus? I'm not at all clear about how you'd like Firefox to
change its current behaviour, and for what.

If there was no distinction between the text caret in edit boxes and the
content focus on surrounding buttons, buttons could not manipulate the
content of edit boxes in relation to the caret or selection. Caret
emulation could presumably break this too; I'm not sure. I suspect NVDA
needs to implement UAAG's distinction between content focus and text caret.

--
Benjamin Hawkes-Lewis

Michael Curran wrote:

> Hi all,
>
> Now that IAccessible2 has been introduced in to Gecko, I have been
> implementing caret navigation of its edit fields in NVDA.
>
> So far things are looking really good, I can now arrow around in Thunderbird
> documents, and edit fields in Firefox. Some really good work has been done,
> thanks To Aaron and Alexander for that.
>
> However, I do have a question about caret browsing in Firefox. I was playing
> around with it just before, and it actually works quite well, now that NVDA
> now treets any object with an IAccessibleEditableText interface as possibly
> responding to cursor actions like up down left and right arrows etc.
>
> However, from what I can tell, when arrowing to objects such as paragraphs
> etc, although the caret may move with in them, focus does not actually get
> given to the object in question.
>
> I understand that in theory focus shouldn't go to them when pressing tab
> etc, but I was wondering if it would be possible for them to get focus if in
> caret browsing mode, and the caret is moved in to one of them.
>
> Currently, NVDA only manages a caret with in the object with focus, so if
> the caret moves out of this object, and the focus doesn't change, NVDA gets
> rather confused.
>
> If there is a very good reason why paragraphs etc can't be given focus that
> is fine, and we will continue to look in to other ways of doing our own
> caret emulation (with virtual buffers and the like) but just out of interest
> I would like to know if this way is in fact possible.
>
> It would be rather nice if we could use the Firefox caret if its possible.
>
> Thanks
> Mick
>
>
>
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>

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

Re: Focus with caret browsing in Firefox

Aaron Leventhal-3
In reply to this post by Michael Curran
I'm glad things are going well. BTW, if everything is showing up as
IAccessibleEditableText that's a bug -- a normal paragraph should only be
IAccessibleText. The IAccessibleEditableText interface should only show up when
copy/paste etc. is possible.

I think it's probably best if we keep the concept of focus basically the same as
what the browser thinks it is, otherwise I'm afraid of the confusion that will
result on Mozilla's code. Also, a paragraph actually could receive focus if it
gets tabindex="0" placed on it and the user tabs to it. So how would we know the
difference?

It seems like the main thing you want is to be be able to find the current
object with the caret quickly. I'm not sure why that's can't be done by
following caret move events.

In any case, I need to caution against using Firefox's caret navigation. It's
very buggy, brittle code, and no one is signed up to fix those bugs. The bugs
are in core layout, and require deep review from the top few layout peers. The
code is complex and written by long-gone developers, although it seems to be
undergoing some significant rearchitecture. I'm not sure if that will impact
caret navigation or not. In any case, it's not a priority to fix those bugs for
any indvidual developer right now. No one with the right skills has signed up to
do it.

At least for now I think you will get the best results of you manage the caret
in NVDA. This will give you the opportunity to deal consistently with the page
even if there embedded Flash or PDF components, and you can iterate your code
out-of-cycle with the rest of Mozilla's code. In other words, when you want to
improve something you won't have to wait 12-24 months.

- Aaron

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

Re: Focus with caret browsing in Firefox

bhawkeslewis
With regards to your practical suggestion of continuing to manage the
caret within NVDA, what's the best way for such a screen reader caret to
relate to the content focus, the caret within edit controls, and the
context menu? It would help accessibility-friendly web developers and I
assume screen reader developers if we could nail that interrelationship
down a bit.

Re caret navigation within Firefox, is the buglist at
http://www.mozilla.org/access/keyboard/proposal complete?

--
Benjamin Hawkes-Lewis

Aaron Leventhal wrote:

> I'm glad things are going well. BTW, if everything is showing up as
> IAccessibleEditableText that's a bug -- a normal paragraph should only be
> IAccessibleText. The IAccessibleEditableText interface should only show up when
> copy/paste etc. is possible.
>
> I think it's probably best if we keep the concept of focus basically the same as
> what the browser thinks it is, otherwise I'm afraid of the confusion that will
> result on Mozilla's code. Also, a paragraph actually could receive focus if it
> gets tabindex="0" placed on it and the user tabs to it. So how would we know the
> difference?
>
> It seems like the main thing you want is to be be able to find the current
> object with the caret quickly. I'm not sure why that's can't be done by
> following caret move events.
>
> In any case, I need to caution against using Firefox's caret navigation. It's
> very buggy, brittle code, and no one is signed up to fix those bugs. The bugs
> are in core layout, and require deep review from the top few layout peers. The
> code is complex and written by long-gone developers, although it seems to be
> undergoing some significant rearchitecture. I'm not sure if that will impact
> caret navigation or not. In any case, it's not a priority to fix those bugs for
> any indvidual developer right now. No one with the right skills has signed up to
> do it.
>
> At least for now I think you will get the best results of you manage the caret
> in NVDA. This will give you the opportunity to deal consistently with the page
> even if there embedded Flash or PDF components, and you can iterate your code
> out-of-cycle with the rest of Mozilla's code. In other words, when you want to
> improve something you won't have to wait 12-24 months.
>
> - Aaron
>
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>

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

Re: Focus with caret browsing in Firefox

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
Here's what we have for our Linux API support docs:
http://developer.mozilla.org/en/docs/Accessibility/AT-SPI_Support

Our MSAA docs are here: http://www.mozilla.org/access/windows/at-apis

For Firefox 3 we'll need to evolved that into IAccessible2 docs, but it will
look very, very close to the Linux API support docs.

Generally focus in the accessibility APIs is not the same as caret/selection.
Focus events are fired for the widget that is currently receiving keyboard
events. In the case of caret navigation, that is the entire document when a
focusable widget within it (such as a link or form control) is not focused. It's
all normal behavior as far as accessibility APIs are concerned.

I'm not sure what the status of that keyboard proposal is, except that as I
mentioned before, it's best of the AT's support the kind of navigation they
need. We're providing the API's they need to in order to do that.

If someone from the community steps forward to fix the caret nav bugs it could
be gret. Here is the meta bug for caret navigation issues:
http://bugzilla.mozilla.org/show_bug.cgi?id=caretnav

- Aaron

Benjamin Hawkes-Lewis wrote:

> With regards to your practical suggestion of continuing to manage the
> caret within NVDA, what's the best way for such a screen reader caret to
> relate to the content focus, the caret within edit controls, and the
> context menu? It would help accessibility-friendly web developers and I
> assume screen reader developers if we could nail that interrelationship
> down a bit.
>
> Re caret navigation within Firefox, is the buglist at
> http://www.mozilla.org/access/keyboard/proposal complete?
>
> --
> Benjamin Hawkes-Lewis
>
> Aaron Leventhal wrote:
>> I'm glad things are going well. BTW, if everything is showing up as
>> IAccessibleEditableText that's a bug -- a normal paragraph should only
>> be IAccessibleText. The IAccessibleEditableText interface should only
>> show up when copy/paste etc. is possible.
>>
>> I think it's probably best if we keep the concept of focus basically
>> the same as what the browser thinks it is, otherwise I'm afraid of the
>> confusion that will result on Mozilla's code. Also, a paragraph
>> actually could receive focus if it gets tabindex="0" placed on it and
>> the user tabs to it. So how would we know the difference?
>>
>> It seems like the main thing you want is to be be able to find the
>> current object with the caret quickly. I'm not sure why that's can't
>> be done by following caret move events.
>>
>> In any case, I need to caution against using Firefox's caret
>> navigation. It's very buggy, brittle code, and no one is signed up to
>> fix those bugs. The bugs are in core layout, and require deep review
>> from the top few layout peers. The code is complex and written by
>> long-gone developers, although it seems to be undergoing some
>> significant rearchitecture. I'm not sure if that will impact caret
>> navigation or not. In any case, it's not a priority to fix those bugs
>> for any indvidual developer right now. No one with the right skills
>> has signed up to do it.
>>
>> At least for now I think you will get the best results of you manage
>> the caret in NVDA. This will give you the opportunity to deal
>> consistently with the page even if there embedded Flash or PDF
>> components, and you can iterate your code out-of-cycle with the rest
>> of Mozilla's code. In other words, when you want to improve something
>> you won't have to wait 12-24 months.
>>
>> - Aaron
>>
>> _______________________________________________
>> dev-accessibility mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-accessibility
>>
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Focus with caret browsing in Firefox

Michael Curran
In reply to this post by Aaron Leventhal-3
Hi Aaron,

Faire enough about the caret browsing in Firefox, if its not that usable
then we'll concentrate on other things then.

However, to explain a little better how NVDA works with a caret:

Some screen readers build up a representation of the screen in a flat model
(off-screen model). In the past, as far as I am aware, these screen readers
have used the caret location (point on the screen), and identified the text
in the off-screen model at that point.

Because of this, they are able to think of the caret as simply a point on a
flat screen.

However, NVDA does not have an off-screen model, nore will it probably ever
have one, at least, not to depend upon that much anyway.

For NVDA to allow the user to interact with the caret, and have the screen
reader give appropriate feed back (such as speaking the line when pressing
down arrow and the like) there is a few things that must be.

NVDA must track key presses (in this case down arrow). When a down arrow is
pressed, NVDA must send this key press through to the application, and then
find out where the caret is, and speak the line the caret is on.

For minimal interuption to applications, NVDA only handles speaking a line
for down arrow etc, when the object with focus is believed to actually have
a caret that moves because of a key press.

We don't really use the MSAA caret event since we need to do different
things based on what key is pressed, rather than just if the caret moves or
not.

So this is why it becomes troublesom if when pressing a key, the caret
actually moves in an object that doesn't have the focus.

I have no problem lying to NVDA, and making NVDA be tricked in to thinking
that there is a focus event when there is a caret event. As in, NVDA can
correct itself to say, ok, I saw a caret event on this object, so apparently
this is the object that should be classed as having focus now, as far as
caret movement is concerned.

However, having had a play with the MSAA caret event today in both Firefox 3
and Thunderbird 3, I notice that accessibleObjectFromEvent with
window,objectID,childID, of the caret event gives me a "caret" object, not
the actual object where the     caret moved (as in the IAccessible 2 object
who's caret offset changed).

I thought then, well, perhaps I can use accessibleObjectFromPoint, using x
and y coordinates, calculated from the accLocation property of the caret
object.  This works ok for objects that that are the deepist in the tree at
that point, but if for instance there is another object in front of the
object with the caret movement, and its deeper in the MSAA tree, then
accessibleObjectFromPoint will give me the deeper object, not the one with
the caret offset.
I guess then I could search back with accParent, until I do find an
IAccessible2 object with a caret offset, but surely there could be a less
costly way.

The biggest problem this is causing is in Thunderbird 3, where when
composing a reply email (in html compersition mode), I can navigate around
any text I have written at the top of the message, but I can not accurately
get text in the original quoted message. This is because although my writing
is actually occuring on the document object, the text that is quoted is in
its own "blockquote" role object (this is also where the IAccessible 2 caret
offset is changing as I arrow around the quoted message). But, of course
because the focus doesn't move to this blockquote, NVDA doesn't know. And if
NVDA listens to the caret events, it can only retreave the actual text node
object  (which is a child of the blockquote). Although this text object
contains the text, it doesn't seem as though it contains a caret offset.

I hope this all makes sence?

In short, how should NVDA correctly find out the object where the caret move
occured?

Thanks
Mick


----- Original Message -----
From: "Aaron Leventhal" <[hidden email]>
Newsgroups: mozilla.dev.accessibility
To: "Michael Curran" <[hidden email]>
Sent: Monday, May 28, 2007 1:23 AM
Subject: Re: Focus with caret browsing in Firefox


> I'm glad things are going well. BTW, if everything is showing up as
> IAccessibleEditableText that's a bug -- a normal paragraph should only be
> IAccessibleText. The IAccessibleEditableText interface should only show up
> when copy/paste etc. is possible.
>
> I think it's probably best if we keep the concept of focus basically the
> same as what the browser thinks it is, otherwise I'm afraid of the
> confusion that will result on Mozilla's code. Also, a paragraph actually
> could receive focus if it gets tabindex="0" placed on it and the user tabs
> to it. So how would we know the difference?
>
> It seems like the main thing you want is to be be able to find the current
> object with the caret quickly. I'm not sure why that's can't be done by
> following caret move events.
>
> In any case, I need to caution against using Firefox's caret navigation.
> It's very buggy, brittle code, and no one is signed up to fix those bugs.
> The bugs are in core layout, and require deep review from the top few
> layout peers. The code is complex and written by long-gone developers,
> although it seems to be undergoing some significant rearchitecture. I'm
> not sure if that will impact caret navigation or not. In any case, it's
> not a priority to fix those bugs for any indvidual developer right now. No
> one with the right skills has signed up to do it.
>
> At least for now I think you will get the best results of you manage the
> caret in NVDA. This will give you the opportunity to deal consistently
> with the page even if there embedded Flash or PDF components, and you can
> iterate your code out-of-cycle with the rest of Mozilla's code. In other
> words, when you want to improve something you won't have to wait 12-24
> months.
>
> - Aaron
>
>

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

Re: Focus with caret browsing in Firefox

bhawkeslewis
A relationship between the AT or Firefox caret and individual
non-focusable elements (paragraphs, quotations, abbreviations, etc) that
is exposed to the Firefox DOM is also important if screen reader users
or keyboard/switch users are to be able to trigger the context menu for
a given element (for example, in order to view its properties, inspect
it, or access custom functionality in Firefox extensions).

--
Benjamin Hawkes-Lewis

Michael Curran wrote:

> Hi Aaron,
>
> Faire enough about the caret browsing in Firefox, if its not that usable
> then we'll concentrate on other things then.
>
> However, to explain a little better how NVDA works with a caret:
>
> Some screen readers build up a representation of the screen in a flat model
> (off-screen model). In the past, as far as I am aware, these screen readers
> have used the caret location (point on the screen), and identified the text
> in the off-screen model at that point.
>
> Because of this, they are able to think of the caret as simply a point on a
> flat screen.
>
> However, NVDA does not have an off-screen model, nore will it probably ever
> have one, at least, not to depend upon that much anyway.
>
> For NVDA to allow the user to interact with the caret, and have the screen
> reader give appropriate feed back (such as speaking the line when pressing
> down arrow and the like) there is a few things that must be.
>
> NVDA must track key presses (in this case down arrow). When a down arrow is
> pressed, NVDA must send this key press through to the application, and then
> find out where the caret is, and speak the line the caret is on.
>
> For minimal interuption to applications, NVDA only handles speaking a line
> for down arrow etc, when the object with focus is believed to actually have
> a caret that moves because of a key press.
>
> We don't really use the MSAA caret event since we need to do different
> things based on what key is pressed, rather than just if the caret moves or
> not.
>
> So this is why it becomes troublesom if when pressing a key, the caret
> actually moves in an object that doesn't have the focus.
>
> I have no problem lying to NVDA, and making NVDA be tricked in to thinking
> that there is a focus event when there is a caret event. As in, NVDA can
> correct itself to say, ok, I saw a caret event on this object, so apparently
> this is the object that should be classed as having focus now, as far as
> caret movement is concerned.
>
> However, having had a play with the MSAA caret event today in both Firefox 3
> and Thunderbird 3, I notice that accessibleObjectFromEvent with
> window,objectID,childID, of the caret event gives me a "caret" object, not
> the actual object where the     caret moved (as in the IAccessible 2 object
> who's caret offset changed).
>
> I thought then, well, perhaps I can use accessibleObjectFromPoint, using x
> and y coordinates, calculated from the accLocation property of the caret
> object.  This works ok for objects that that are the deepist in the tree at
> that point, but if for instance there is another object in front of the
> object with the caret movement, and its deeper in the MSAA tree, then
> accessibleObjectFromPoint will give me the deeper object, not the one with
> the caret offset.
> I guess then I could search back with accParent, until I do find an
> IAccessible2 object with a caret offset, but surely there could be a less
> costly way.
>
> The biggest problem this is causing is in Thunderbird 3, where when
> composing a reply email (in html compersition mode), I can navigate around
> any text I have written at the top of the message, but I can not accurately
> get text in the original quoted message. This is because although my writing
> is actually occuring on the document object, the text that is quoted is in
> its own "blockquote" role object (this is also where the IAccessible 2 caret
> offset is changing as I arrow around the quoted message). But, of course
> because the focus doesn't move to this blockquote, NVDA doesn't know. And if
> NVDA listens to the caret events, it can only retreave the actual text node
> object  (which is a child of the blockquote). Although this text object
> contains the text, it doesn't seem as though it contains a caret offset.
>
> I hope this all makes sence?
>
> In short, how should NVDA correctly find out the object where the caret move
> occured?
>
> Thanks
> Mick
>
>
> ----- Original Message -----
> From: "Aaron Leventhal" <[hidden email]>
> Newsgroups: mozilla.dev.accessibility
> To: "Michael Curran" <[hidden email]>
> Sent: Monday, May 28, 2007 1:23 AM
> Subject: Re: Focus with caret browsing in Firefox
>
>
>> I'm glad things are going well. BTW, if everything is showing up as
>> IAccessibleEditableText that's a bug -- a normal paragraph should only be
>> IAccessibleText. The IAccessibleEditableText interface should only show up
>> when copy/paste etc. is possible.
>>
>> I think it's probably best if we keep the concept of focus basically the
>> same as what the browser thinks it is, otherwise I'm afraid of the
>> confusion that will result on Mozilla's code. Also, a paragraph actually
>> could receive focus if it gets tabindex="0" placed on it and the user tabs
>> to it. So how would we know the difference?
>>
>> It seems like the main thing you want is to be be able to find the current
>> object with the caret quickly. I'm not sure why that's can't be done by
>> following caret move events.
>>
>> In any case, I need to caution against using Firefox's caret navigation.
>> It's very buggy, brittle code, and no one is signed up to fix those bugs.
>> The bugs are in core layout, and require deep review from the top few
>> layout peers. The code is complex and written by long-gone developers,
>> although it seems to be undergoing some significant rearchitecture. I'm
>> not sure if that will impact caret navigation or not. In any case, it's
>> not a priority to fix those bugs for any indvidual developer right now. No
>> one with the right skills has signed up to do it.
>>
>> At least for now I think you will get the best results of you manage the
>> caret in NVDA. This will give you the opportunity to deal consistently
>> with the page even if there embedded Flash or PDF components, and you can
>> iterate your code out-of-cycle with the rest of Mozilla's code. In other
>> words, when you want to improve something you won't have to wait 12-24
>> months.
>>
>> - Aaron
>>
>>
>
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>

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

Re: Focus with caret browsing in Firefox

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
Mick,

Don't use the old-fashioned MSAA caret events, which are simply based on the
location on the screen. Take a look at all the new IA2 events, but in particular
IA2_EVENT_TEXT_CARET_MOVED and IA2_EVENT_TEXT_SELECTION_CHANGED. You can also
get text change events such as what has been inserted or deleted.

The new events will tell you what object the caret moved in. Focus will be in an
ancestor.

- Aaron

Michael Curran wrote:

> Hi Aaron,
>
> Faire enough about the caret browsing in Firefox, if its not that usable
> then we'll concentrate on other things then.
>
> However, to explain a little better how NVDA works with a caret:
>
> Some screen readers build up a representation of the screen in a flat
> model (off-screen model). In the past, as far as I am aware, these
> screen readers have used the caret location (point on the screen), and
> identified the text in the off-screen model at that point.
>
> Because of this, they are able to think of the caret as simply a point
> on a flat screen.
>
> However, NVDA does not have an off-screen model, nore will it probably
> ever have one, at least, not to depend upon that much anyway.
>
> For NVDA to allow the user to interact with the caret, and have the
> screen reader give appropriate feed back (such as speaking the line when
> pressing down arrow and the like) there is a few things that must be.
>
> NVDA must track key presses (in this case down arrow). When a down arrow
> is pressed, NVDA must send this key press through to the application,
> and then find out where the caret is, and speak the line the caret is on.
>
> For minimal interuption to applications, NVDA only handles speaking a
> line for down arrow etc, when the object with focus is believed to
> actually have a caret that moves because of a key press.
>
> We don't really use the MSAA caret event since we need to do different
> things based on what key is pressed, rather than just if the caret moves
> or not.
>
> So this is why it becomes troublesom if when pressing a key, the caret
> actually moves in an object that doesn't have the focus.
>
> I have no problem lying to NVDA, and making NVDA be tricked in to
> thinking that there is a focus event when there is a caret event. As in,
> NVDA can correct itself to say, ok, I saw a caret event on this object,
> so apparently this is the object that should be classed as having focus
> now, as far as caret movement is concerned.
>
> However, having had a play with the MSAA caret event today in both
> Firefox 3 and Thunderbird 3, I notice that accessibleObjectFromEvent
> with window,objectID,childID, of the caret event gives me a "caret"
> object, not the actual object where the     caret moved (as in the
> IAccessible 2 object who's caret offset changed).
>
> I thought then, well, perhaps I can use accessibleObjectFromPoint, using
> x and y coordinates, calculated from the accLocation property of the
> caret object.  This works ok for objects that that are the deepist in
> the tree at that point, but if for instance there is another object in
> front of the object with the caret movement, and its deeper in the MSAA
> tree, then accessibleObjectFromPoint will give me the deeper object, not
> the one with the caret offset.
> I guess then I could search back with accParent, until I do find an
> IAccessible2 object with a caret offset, but surely there could be a
> less costly way.
>
> The biggest problem this is causing is in Thunderbird 3, where when
> composing a reply email (in html compersition mode), I can navigate
> around any text I have written at the top of the message, but I can not
> accurately get text in the original quoted message. This is because
> although my writing is actually occuring on the document object, the
> text that is quoted is in its own "blockquote" role object (this is also
> where the IAccessible 2 caret offset is changing as I arrow around the
> quoted message). But, of course because the focus doesn't move to this
> blockquote, NVDA doesn't know. And if NVDA listens to the caret events,
> it can only retreave the actual text node object  (which is a child of
> the blockquote). Although this text object contains the text, it doesn't
> seem as though it contains a caret offset.
>
> I hope this all makes sence?
>
> In short, how should NVDA correctly find out the object where the caret
> move occured?
>
> Thanks
> Mick
>
>
> ----- Original Message ----- From: "Aaron Leventhal"
> <[hidden email]>
> Newsgroups: mozilla.dev.accessibility
> To: "Michael Curran" <[hidden email]>
> Sent: Monday, May 28, 2007 1:23 AM
> Subject: Re: Focus with caret browsing in Firefox
>
>
>> I'm glad things are going well. BTW, if everything is showing up as
>> IAccessibleEditableText that's a bug -- a normal paragraph should only
>> be IAccessibleText. The IAccessibleEditableText interface should only
>> show up when copy/paste etc. is possible.
>>
>> I think it's probably best if we keep the concept of focus basically
>> the same as what the browser thinks it is, otherwise I'm afraid of the
>> confusion that will result on Mozilla's code. Also, a paragraph
>> actually could receive focus if it gets tabindex="0" placed on it and
>> the user tabs to it. So how would we know the difference?
>>
>> It seems like the main thing you want is to be be able to find the
>> current object with the caret quickly. I'm not sure why that's can't
>> be done by following caret move events.
>>
>> In any case, I need to caution against using Firefox's caret
>> navigation. It's very buggy, brittle code, and no one is signed up to
>> fix those bugs. The bugs are in core layout, and require deep review
>> from the top few layout peers. The code is complex and written by
>> long-gone developers, although it seems to be undergoing some
>> significant rearchitecture. I'm not sure if that will impact caret
>> navigation or not. In any case, it's not a priority to fix those bugs
>> for any indvidual developer right now. No one with the right skills
>> has signed up to do it.
>>
>> At least for now I think you will get the best results of you manage
>> the caret in NVDA. This will give you the opportunity to deal
>> consistently with the page even if there embedded Flash or PDF
>> components, and you can iterate your code out-of-cycle with the rest
>> of Mozilla's code. In other words, when you want to improve something
>> you won't have to wait 12-24 months.
>>
>> - Aaron
>>
>>
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Focus with caret browsing in Firefox

Aaron Leventhal-3
One more thing, after you get the caret/selection event, you can use
IAccessibleText to find out where the caret or selection is within that object.

Are you sure that having focus on that object matters?

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