More text issues. :( Str: 1. Open this URL: data:text/html,<a name="foo"></a>b 2. Get the accessible for the document. 3. Get the line offsets at offset 0. Expected: (0, 2) Actual: (0, 0)
Jamie, maybe we should push harder on new text interface rather than putting effort here?
We could consider that, but with respect, the reality is that we discussed the new text interface over 6 months ago and there has been no further progress. Even if we moved forward on it now, it would still be quite some time before we have anything remotely workable. Meanwhile, it's 2015 and we still can't get decent rich text editing support. :) Also, while I don't presume to understand Gecko's text accessibility code, I'm not convinced the new interface would solve problems like this. There are still going to be nodes with no text that have to be taken into account, so the underlying problem will still need to be solved. In fact, the problem might even be worse. If inline nodes just become part of the text, how will a node with no text be represented? The node is still important because it might have a label, be interactive, etc.
I'm with Jamie on this one regarding the time-frame on having something workable. And Orca is trying to use the accessible text interface for non-editable text too. So it would be super if these issues could be fixed.
Joanie, the fact that WebKit doesn't use embedded objects much aside, can you please tell me what it does for the following? (Yes, it's insane, but so is the world...) <p>a<a href="foo" style="padding: 1px;"></a>b</p> (Normally, that padding would be a background image or something.) The point is that a user might need to get at that link, but it has no text, which makes it difficult to expose in our rather text-centric APIs.
Jamie! I've so missed our <strike>arguments</strike> happy chats about embedded objects. ;) Jokes aside, here's what I'm seeing: 1. For the accessible paragraph: a. text interface, line at offset 0: ('ab', 0, 2) b. hypertext interface, link count: 1, getting link 0 returns a valid hyperlink iface object c. hyperlink iface object returned by 1b: startIndex: 1, endIndex: 1, getObject: the accessible link 2. For the accessible link: a. text interface, line at offset 0: ('', 0, 0) b. hyperlink interface, same results as in 1c
Hmm. Do you have a hyperlinkIndex method on your Hypertext interface; i.e. get the index of the hyperlink at character offset o? What happens if you call that for offsets 0, 1 and 2? I'm guessing it returns index 0 for offset 1. The reason I asked is that I was wondering whether the text alternatives we discussed last year would actually solve this problem. I guess the way WebKit exposes this could work, though it still seems weird that the hyperlink range is collapsed even though it reports as having an offset (not that there's any other way you could do it).
Yes, I have a getLinkIndex() method on the hypertext interface which takes a character offset as its argument. If there's no associated hyperlink for the specified offset, it returns -1. For your particular edge case, getLinkIndex() returns -1 for offset 0 and offset 1. One could make a case for that return value being correct. The character at offset 0 is "a". Is it a link? No. The character at offset 1 is "b". Is it a link? No. Of course, one could also make a case for that return value being incorrect, with index 0 being the expected return value for the link at offset 1 as you guessed would be the case. And with a 0-sized range, the engine wouldn't be lying to us. <insert shrug here>
Whether it's strictly correct is probably irrelevant, but the point is that an AT needs to get at this and walking through all the hyperlinks even when hyperlinkIndex doesn't return it (on the off chance that there *might* be a 0-length hyperlink) is horrible. It's certainly an edge case, but unfortunately, I've seen stuff like this on a few occasions. Long story short: we don't have a good solution for this yet; even the proposed new text interface doesn't account for this. Gecko's embedded object stuff would work if it exposed the correct offsets, but as we all know, embedded objects are horrible (arguments about whether they're necessary aside).
This is actually worse than i had originally anticipated, though I guess it's logical. Expanding on my example, if you do: data:text/html,<div><div><div><a name="foo"></a>b</div></div></div> getting the line offsets at offset 0 for the document and all of the divs returns (0, 0). So it's broken for all ancestors, not just the embedding object.
(In reply to James Teh [:Jamie] from comment #2) > We could consider that, but with respect, the reality is that we discussed > the new text interface over 6 months ago and there has been no further > progress. there's lack of focus from all of us, that's a primary reason I think why we keep stumbling > Even if we moved forward on it now, it would still be quite some > time before we have anything remotely workable. Meanwhile, it's 2015 and we > still can't get decent rich text editing support. :) that's much true for non AT users as well :) and that's the root problem I'd said. > Also, while I don't presume to understand Gecko's text accessibility code, > I'm not convinced the new interface would solve problems like this. There > are still going to be nodes with no text that have to be taken into account, > so the underlying problem will still need to be solved. This certainly is true: the base of our text problems is broken Gecko's layout navigation. If we do the proposed approach then it will have all Gecko's bugs. There's implementation difference between current approach and proposed one though. Currently we do several movements in text to detect text lexems and chances to hit a problem are just higher. If we have fixed those Gecko's layout bugs then the current approach worked pretty much correctly and we would probably lived ok with it longer, but that's a whole thing to fix them and much out of scope of sole accessibility. > In fact, the problem > might even be worse. If inline nodes just become part of the text, how will > a node with no text be represented? The node is still important because it > might have a label, be interactive, etc. maybe we should have something like content traversal API that would allow you move through text and content both.
As per duplicate bug 1493824, the embedded object just has to be empty; whether it's inline is irrelevant.
Summary: Inline embedded object with no text breaks line offsets → Empty embedded object (HyperTextAccessible child) breaks line offsets
You need to log in before you can comment on or make changes to this bug.