That I'm not sure of. In Mail messages, though, I can interact with the message text, then vo-arrow to a link and interact with it. Depending on the format, I can even interact with the text inside that embedded link, which is two levels below the text of the message. I can't say how Pages does this, but in Mail, it's quite possible.
On Nov 5, 2015, at 17:30, Charlie Powell < email@hidden> wrote:
But there’s no concept of actually “interacting with text” using VoiceOver, right? In other words, I didn’t think VO-Shift-Down arrow was supposed to have any effect when you’re
already interacting with a text area because what accessibility elements should exist as a child of a text area? I guess we’re saying link elements should? But using Accessibility Inspector on an app like Pages, I don’t actually see any child elements like
this and the experience works just find there. And even if it does, how does VO know to look for child elements of a text area when the text with focus is a hyperlink? This brings me back to the notion that Apple must be doing something related to intersection
of rectangles of various elements, but I’d prefer to know that before we go spend time with just this assumption…
I don't know about the APIs here at all, so I could be way off base. That said, have you interacted with the link text? Ideally that wouldn't be necessary, but some people have major problems opening links in emails, just like you're describing,
and report that interacting with the link before pressing vo-space does the trick.
On Nov 5, 2015, at 17:03, Charlie Powell <email@hidden> wrote:
Just to circle back on things here – we’ve successfully been able to add a new accessibility object for hyperlinks, such that when the user does VO-Cmd-L, it jumps to the hyperlink
and doing VO-Space will open the hyperlink. However, VO-Space does not work when you use VO-Left/Right Arrow to move focus to the text that is linked. Does anyone know why this might be the case? Essentially, it’s entirely unclear how VoiceOver knows to send the AXPress command to the hyperlink object instead of the text area when using VO-Arrow to navigate text. The
only thing I can come up with is that Apple is relying on the focus rectangles, i.e. if the rectangle provided by accessibilityFrameForRange for text containing a hyperlink is entirely contained in the rectangle of the hyperlink object provided, it’ll send
the command to the hyperlink object. I don’t suppose anyone can confirm that’s how to get all this to work? Otherwise the only thing that would make this work is if VO focus moved to the hyperlink object using VO-Arrow, which certainly does not happen. In
fact, in apps like Pages, I don’t even _see_ a hyperlink object as a child of the text area, so I’m completely baffled how we’re supposed to know what we need to do to get this to work.
From: Boris Dusek [mailto:email@hidden]
Sent: Thursday, October 15, 2015 11:32 PM
To: Charlie Powell <email@hidden>
Cc: Apple Accessibility Developer List <email@hidden>
Subject: Re: Adding support for hyperlink and alignment text attributes
I’ll start with a basic NSURL object as the value and see how far that takes things.
From my not so fresh memory, I think the limit you will hit there will be that the link in a NSURL/NSString form cannot be activated using VO-Space, for that I think you would need a custom link accessibility object with AXPress action.
As mentioned, VO-Space had trouble to determine based on cursor position which link object to AXPress (e.g. when I last tried, it might not AXPress the link object at which cursor is - either fail or AXPress a different link object), but that might have changed
in the meantime (e.g. in El Capitan), so as I suggested earlier you should do your own experiments here :-)
I don’t suppose there’s been any discussion on here about getting Apple to document these things?
I probably did not get to report it to rdar (no time for it at the moment), which you should, as there is the known truth of “what does not exists in rdar does not exist”. I think there might be at least 3 reasons for Apple not documenting
these attributes:
1. Intentional - Apple wants to still have the leeway of changing the attribute semantics/names etc. in future OS releases and break things, before committing to a public API
2. Apple knows about the fact that the attributes have not been documented, but just did not get to documenting them yet.
3. Apple does not know about it.
Filing a rdar definitely helps for 3., could quite help for 2., and might theoretically speed things a little bit with 1.
Maybe someone else already filed the rdar, but it still helps to have your own rdar reported nevertheless (more rdars for the same issue could mean more priority given to them, you might formulate the rdar more clearly than someone else,
etc.).
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|