Open Bug 861681 Opened 12 years ago Updated 2 years ago

Links should not be treated as embedded objects.

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86_64
Linux
Type:
defect

Tracking

()

People

(Reporter: jdiggs, Unassigned)

References

(Blocks 3 open bugs)

Details

Consider the following html: <html> <head></head> <body><p>This is a <a href="foo">link</a> to something.</p></body> </html> Here are the results when attempting to get the current line via pyatspi: Epiphany/WebKitGtk: 'This is a link to something.', 0, 28 LibreOffice Writer: 'This is a link to something. ', 0, 29 Firefox/Gecko: 'This is a \xef\xbf\xbc to something.', 0, 25 Gecko's decision to expose links as embedded objects requires Assistive Technologies to piece together lines on a pretty frequent basis. This, in turn, increases the likelihood of bugs -- either in the AT piecing the lines together, or as a side effect of bugs in the toolkit's accessible text implementation. This is further complicated when a link wraps from one line to the next. The Orca end user experience would be greatly improved if the only embedded objects encountered were actual embedded objects (e.g. widgets). What WebKitGtk has done is make the links children of the parent text object so that events for the link (caret-moved, focused, etc.) can come from a known accessible. I would think/hope this would work for Gecko too. In order for Orca to present the presence of links as a user navigates in the parent text object, it queries the Hypertext interface to get the links in the text and looks at the start and end offset.
We certainly could do that (I personally think its probably a good idea). Note that Alex's proposal to not do embeded objects for things that are inline would subsume this. However Jamie is well know to point out the issues with this. For example consider <p>some <a href="whatever" aria-label="apples">text</a></p> apparently the wild has forced mvda to read that as "some apples" which this proposal would make more tricky.
Then maybe start with links which are not ARIA and leave ARIAified links as embedded objects. After all, most piecing together of lines happens because of links. And most links are not ARIA.
Blocks: orca
This is a specific case of bug 719047. What's so special about links? Why are they different to every other object? You say ARIA links can be excluded, but if that's the case, why are non-ARIA links special? You're still going to have to deal with the complexity you're trying to eliminate. Is this for performance alone or are there other reasons? I'm not entirely against the idea of flattening the tree. However, such a change needs to be considered not just for specific cases. There should be a thorough justification for the change. If we don't have explanation and consistency, things get very confusing, code gets ugly and edge cases become the norm. Alex's idea of doing it for all inline elements is at least consistent and can be explained.
(In reply to James Teh [:Jamie] from comment #3) > This is a specific case of bug 719047. > > What's so special about links? Why are they different to every other object? Most links are text; that cannot be said for every other object. When reading text with links, one reads the displayed text from the link as part of the text content of the parent. Consider the first sentence in your comment. It's just a sentence. My brain notes in passing that if I would like to know more about bug 719047, I could click on those words. But beyond that, I just read the text. > You say ARIA links can be excluded, but if that's the case, why are non-ARIA > links special? Non-ARIA links are not special; ARIA links are special. And the reason they are special is because ARIA is saying, "Don't treat this as it appears. Sure the text says 'bug 719047' but you should present it to the user who is blind as if it said 'apple.'" > Is this for performance alone or are there other reasons? While I have been saying what I have stated in the opening report for years now, what prompted me to file this bug is the recent discussion about accessible text interfaces and the subsequent decision to move forward on simplifying AtkText. Removing a couple of calls in Orca to getTextAfterOffset() should have been simple, but I kept running up against regressions. The source of the regressions is due to the fact that those calls were part of other hacks in Orca to deal with bugs and other inconsistencies seen in Gecko's text implementation. And those bugs and other inconsistencies are encountered specifically when Orca is trying to piece together lines of text. And Orca does much of that piecing together as a result of links. I would really, really like to remove those hacks from Orca. Doing so would make the Orca user experience more reliable. Furthermore, it would make it far less likely for a seemingly-harmless change or fix in Gecko to "break Orca" in the manner that Alex has recently blogged about. And when such breakage did occur, it would be far easier to get to the bottom of it -- which I think is important if we are about to embark on major changes in Gecko's accessible text support. > I'm not entirely against the idea of flattening the tree. However, such a > change needs to be considered not just for specific cases. There should be a > thorough justification for the change. If we don't have explanation and > consistency, things get very confusing, code gets ugly and edge cases > become the norm. I agree completely. Orca's support for Gecko is ugly. Edge cases are the norm. And if I had to do it all over again, I never would have put all these hacks into Orca. > Alex's idea of doing it for all inline elements is at least consistent and > can be explained. I'm not convinced that all inline elements are going to be the same.
By the way, about the apple link example: If the text on screen says "text" but ARIA says, expose it as "apple", what will happen when a caret-navigating user presses right arrow to move up to and then through that word?
(In reply to Joanmarie Diggs from comment #4) > Most links are text; that cannot be said for every other object. It can be said for a lot of them, though. > When reading text with links, one reads the displayed text from the link as > part of the text content of the parent. Consider the first sentence in your > comment. It's just a sentence. My brain notes in passing that if I would > like to know more about bug 719047, I could click on those words. But beyond > that, I just read the text. The same is true for clickables, which can be just about anything. > Removing a couple of calls in Orca to > getTextAfterOffset() should have been simple, but I kept running up against > regressions. The source of the regressions is due to the fact that those > calls were part of other hacks in Orca to deal with bugs and other > inconsistencies seen in Gecko's text implementation. And those bugs and > other inconsistencies are encountered specifically when Orca is trying to > piece together lines of text. My point is that you'll still have to do this piecing together for other embedded objects that occur in the middle of a line. Links are not unique in this respect. You'll also have to piece things together to handle selection which covers multiple lines or paragraphs.
(In reply to Joanmarie Diggs from comment #5) > By the way, about the apple link example: If the text on screen says "text" > but ARIA says, expose it as "apple", what will happen when a > caret-navigating user presses right arrow to move up to and then through > that word? In Windows, ATs don't rely on caret navigation due to hitherto deficient implementations and performance issues, so it's not relevant. I don't have a good answer for this. I'm not a big fan of this kind of content overriding nastiness with ARIA precisely because of this sort of problem, but the reality is that the spec allows for it and it is happening all over the web now. I finally accepted it as a battle i can't win.
If ARIA links and etc can change the text then I'd say it should happen on browser side so a screen reader don't need to go into children in flat text case. Caret navigation and navigation through the accessible text is not consistent of course. But I should notice that ATK and IA2 text interfaces operate on accessible tree and in general caret navigation and navigation through the accessible text may be not in sync in either case. So <p>text <a aria-label="hoho">oops</a></p> has accessible hierarchy and text paragraph (html:p): "text hoho" (accessible text) link (html:a): "oops" (accessible text) Would it be rather confusing? If we flat out the text for inlines except controls (like buttons and inputs) then would it be acceptable solution? (maybe as the first step of bug 719047)
(In reply to alexander :surkov from comment #8) > If ARIA links and etc can change the text then I'd say it should happen on > browser side so a screen reader don't need to go into children in flat text > case. That was one of the possibilities I suggested in bug 637568. :) > <p>text <a aria-label="hoho">oops</a></p> has accessible hierarchy and text > paragraph (html:p): "text hoho" (accessible text) > link (html:a): "oops" (accessible text) > Would it be rather confusing? It could be argued that the text of the link should also be "oops", but that opens up a very large and nasty can of worms. :) > If we flat out the text for inlines except controls (like buttons and > inputs) then would it be acceptable solution? (maybe as the first step of > bug 719047) It's acceptable, though imo, there's not much difference between links and buttons. Note that this will definitely break NVDA and probably some other Windows ATs as well.
(In reply to James Teh [:Jamie] from comment #9) > (In reply to alexander :surkov from comment #8) > > If ARIA links and etc can change the text then I'd say it should happen on > > browser side so a screen reader don't need to go into children in flat text > > case. > That was one of the possibilities I suggested in bug 637568. :) it must be a wrong bug number > > <p>text <a aria-label="hoho">oops</a></p> has accessible hierarchy and text > > paragraph (html:p): "text hoho" (accessible text) > > link (html:a): "oops" (accessible text) > > Would it be rather confusing? > It could be argued that the text of the link should also be "oops", but that > opens up a very large and nasty can of worms. :) it seems atk/ia2 text interface isn't suited well for this case. I believe that AT users should have an option to traverse the visible text. At least it sensible for screen magnifiers. So it seems the text interface should have modes to address it. > > If we flat out the text for inlines except controls (like buttons and > > inputs) then would it be acceptable solution? (maybe as the first step of > > bug 719047) > It's acceptable, though imo, there's not much difference between links and > buttons. If links are part of group of links then I'd say there's no any difference with buttons. If links are part of text then there's a difference because you don't go into buttons but you go into links when you traverse the text. Would you make a difference between links and text entries like html:input (which are also inlines and controls)? > Note that this will definitely break NVDA and probably some other > Windows ATs as well. I'd like to end up with something consummate here and then of course I will go to other screen ATs to check with them.
(In reply to Joanmarie Diggs from comment #4) > And those bugs and > other inconsistencies are encountered specifically when Orca is trying to > piece together lines of text. And Orca does much of that piecing together as > a result of links. Are you saying you don't ever treat buttons as being part of another line of text? If you do, won't you have the same issues with buttons?
(In reply to alexander :surkov from comment #10) > > That was one of the possibilities I suggested in bug 637568. :) > it must be a wrong bug number Typo, sorry: bug 637578. :) > If links are part of group of links then I'd say there's no any difference > with buttons. If links are part of text then there's a difference because > you don't go into buttons but you go into links when you traverse the text. I don't follow. We include buttons in our traversed text. Otherwise, the user wouldn't be able to see that the button was part of a line of text. > Would you make a difference between links and text entries like html:input > (which are also inlines and controls)? Probably, because the text of inputs is very much user mutable.
(In reply to James Teh [:Jamie] from comment #12) > (In reply to alexander :surkov from comment #10) > > > That was one of the possibilities I suggested in bug 637568. :) > > it must be a wrong bug number > Typo, sorry: bug 637578. :) > > > If links are part of group of links then I'd say there's no any difference > > with buttons. If links are part of text then there's a difference because > > you don't go into buttons but you go into links when you traverse the text. > I don't follow. We include buttons in our traversed text. Otherwise, the > user wouldn't be able to see that the button was part of a line of text. so if the user moves by words and a button is encountered that has 'a long and complex name' label then you won't announce 'a button' and its name but you will allow the user to traverse its label as ordinal text? In other words the unique difference between label and button is in role announcement? > > Would you make a difference between links and text entries like html:input > > (which are also inlines and controls)? > Probably, because the text of inputs is very much user mutable.
(In reply to alexander :surkov from comment #13) > so if the user moves by words and a button is encountered that has 'a long > and complex name' label then you won't announce 'a button' and its name but > you will allow the user to traverse its label as ordinal text? In other > words the unique difference between label and button is in role announcement? For NVDA browse mode (and most other Windows ATs), correct.
Joanie, what about you? Do you treat buttons differently from links?
The short answer: Yes, buttons are different from links. The long answer: We *try* and *want* to treat buttons as being different from links. In a typical GUI toolkit, buttons are NOT something you navigate *within*. In the context of this bug, a button SHOULD be a single "character" -- one that does NOT implement AtkText. However.... Orca currently does not have code to actively prevent users from navigating into things which permit navigating into (i.e. via AtkText).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.