Gutenberg: Inline boundaries improvements

I love the feature and I think it greatly helps understanding where you're typing.

However, quickly testing with Safari 10 + VoiceOver, the link boundary gets read out as:
link zero width no break space
or something like that, sorry not a native English speaker here 🙂

One option could be the one mentioned by @spocke on Slack:

might need to wrap it in a span with aria tags then

When navigating by characters or words, screen readers already announce link when entering a link, though they don't announce anything when exiting the link, so maybe just hiding the zwnbsp character from assistive technologies could work well.

@afercia Did some investigations into this one.

In order to keep the caret from normalizing into the anchor when being inside/outside we need to insert something that keeps the browser from doing it's default thing. We use zero width non breaking spaces for that it's basically an invisible character that is no longer used for anything except for BOM signatures in documents. These characters seems to be ignored by Jaws but spoken by VoiceOver and NVDA.

I tried to work around this in various ways:

1. Changing the character to spans with aria roles and attributes didn't work since the attributes where complacently ignored by most of the screen readers. I'm guessing since it's in the editor context it doesn't have any relevance. Tried role="presentation" aria-hidden="true" and aria-label="abc" nothing happened except on Jaws.
2. Tried the reserved unicode range \ue000 this is reserved for things like icons etc and shouldn't be spoken by the screen reader. It doesn't speak these however it's also ignored by the browsers selection normalization logic so it can't be used.
3. Added a role="status" element with aria-live="assertive" and pushed text to that basically what wp.a11y.speak does and that cancels out the queue on VoiceOver but not on NVDA and it seems a bit odd on Jaws. The spec says it might cancel out the queue so I guess it's random what happens. However this probably makes most sense to tell the user where the caret if it's at the start of the link, end, before or after since those are the locations we handle. However some screen readers will still speak that odd character code not sure we can do much about that.

So to sum this up it's complicated. :)

We fixed the items listed in this ticket. So I'm closing this one.