Thanks Patti! Eventually through enough prototyping and looking at accessibility inspector as you suggest, we were able to figure this out despite that fact that it’s not mentioned
anywhere in online documentation or the SDK headers – would be great if that could be fixed for anyone else that tries this in the future.
Having these objects live as children of the TextArea is kind of a pain for us, and it seems Pages is able to get away without doing that (or at least I don’t see these AXLink
objects in accessibility inspector)… I don’t suppose that’s an indication that there’s another way to approach this?
From: email@hidden [mailto:email@hidden]
On Behalf Of Patti Hoa
Sent: Wednesday, November 11, 2015 11:05 AM
To: Charlie Powell <email@hidden>
Cc: Alex Hall <email@hidden>; Apple Accessibility Developer List <email@hidden>
Subject: Re: Adding support for hyperlink and alignment text attributes
For Voiceover to be able to detect the hyperlinks in a text document, you need to wrap each hyperlink into a separate element with role:AXLink and subrole:AXTextLink and included this element as part of the textArea’s AXChildren.
As an example, type a sentence in TextEdit.app. Select a word, and press command-k (Edit—>Add Link).
Then use Accessibility Inspector to see how this hyperlink is presented in the accessibility hierarchy.
On Nov 6, 2015, at 9:46 AM, Charlie Powell <email@hidden> wrote:
Mail appears to use WebKit (or some kind of HTML view) – in Accessibility Inspector, I see AXWebArea towards the bottom of the accessibility hierarchy. Once HTML is involved,
it seems VoiceOver has all sorts of other behavior (same is true for web browsers too). Furthermore, while you can interact with the message text/links, you don’t need to in order to get VO-Space behavior during normal VO-Arrow actions.
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
_______________________________________________
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
|