AVT: JAWS not reading media selected when embed media selected instead it reads selected Blank

[Satya Minnekanti]

Steps to reproduce

1. Open Media embed sample [​​http://sdk.ckeditor.com/samples/mediaembed.html]
2. Delete existing data & add few paragraphs of text
3. Embed a video using folowing URL [ ​https://vimeo.com/86541796]
4. Video embedded and focus is on video.
5. Press Right arrow key to focus back to content after video.
6. Press LEFT Arrow key again to select embedded media

Expected result

JAWS reads selected Media

Actual result

JAWS reads selected Blank. This is Accessibility Violation

[Jakub Ś]

I can see that video data gets read with Right Arrow + Tab but not with Right Arrow + Left Arrow.

[Marek Lewandowski]

I've been able to put initial code in ​branch:t/14539. It looks to do the trick, e.g. you can provide a custom label to be read when the fake selection is focused.

The only problem with widgets is that their fake selection is created in multiple places, and does not necessairly know that it's working with widgets - so fetching customized message might be a problem.

For instance, you do have a fake selection created on click in ​widget's plugin file - and it's great because you have access to widget instance. But then keyboard listener is ​in core selection module, and it doesn't know if it's a widget or not. The handling is generic, for all contenteditable=false elements.

We need to investigate what solutions are possible here, at this moment I see two possible:

• Providing labels on HTML elements inside the editable, and if present, fake selection would use them as for selection label (possibly adding " selected" word at the end).
• Exposing a handler for fake selection, so that widget plugin can take control over fake selection creation process.

[Marek Lewandowski]

All right I have a proposal for implementation, here's a brief idea, and let's discuss it.

General

The problem

If you select the widget (either with keybaord or a mouse), assistive technology will not announce focused content properly. It will say "blank" instead of actual focused content.

Reason

Currently widgets are using so called fake selection. This creates an invisible (thus fake) container within the editable and moves the real selection into this place.

For the time being this element is simply empty inside, that's why screen reader is reading "blank".

End goal

What we want to do here, is simply to allow setting a proper label, though API call. For instance, let's assume that we have a "Rocket launching" image widget. Our goal is to provide a description like: ""Rocked Launching" image widget selected".

This description should also be adjustable by a proper callback / event provided to the widget definition.

Proposed solution

The full featured solution would be a little complex, so for the time being I came up with a simplified one, that will not consider multiple ranges - since we're not supporting such with fake selection yet.

With this in mind we'll introduce CKEDITOR.dom.selection#setLabel method for setting the label.

• setLabel for fake selection - will set the innerHTML of fake selection container. Actually it might be wrapped in an element within the fake selection wrapper. This is because soon we might use fake selection for table selection enhancements, will require us to put partial table content into fake selection as well (but it's just a sidenote).
• setLabel for real selection - here it's going to simply act as a virtual method, because real selection does not need it for the time being. The defautl contenteditable support for screen reader does evertyhing for us.

To make it complementary, we should also include =getLabel, so that it's possible to append other selection strings in case when developer is working on a multirange fake selection.

To innerHTML or innerText?

Giving an ability to provide rich markup sounds reasonable, as it will allow to use semantic markup (emphasize some parts of the label), as well as add markup for aural "styling" of voice agent.

Widget API

​Widget's definition should get a new method - getLabel which would return a nice human readable label (string) for the end user.

It should provide a default implementation that would return following value: {definition.pathName || definition.name} widget selected. This method must be overridable, so that developer can provide as precise description as possible.

As for how widget plugin should achieve it, it's simply about listening to selectionchange event, and checking if:

1. it's a fake selection (because only such are created for widgets),
2. if element in range is any known widget, if so, call the getLabel method on a proper widget instance.

Related problems

This solution won't fix a case when widget sits in a middle of larger (non faked) selection, but that's a different case.

[Marek Lewandowski]

Our team had a discussion, we decided that we'll simplify it even further. The only way for setting the label is going to be direct setting it in fake method, just like it was done in ​t/14539.

There's a drawback though, in case of auto fake selection mechanism, which happened automatically when selecting a range containing only a content-non-editable element. Just because it doesn't have a proper context (it doesn't know what it's working on, and it should not have) we need to provide a mechanism for it to discover the label. So the idea is to provide proper aria markup (most likely aria-labelledby) and attempt fake selection to obtain it.

As for widgets, their label should be updated upon data event (since data properties might affect the label).

[Marek Lewandowski]

Interesting, we'll face some problems with JAWS, as it does not respect aria-hidden in contenteditable. It looks to be a JAWS bug. I've reached out for tips on workaround to JAWS folks, maybe we'll get something there.

​https://twitter.com/m_lewand/status/745645924999958529

Anyway, tested it with NVDA and works like a charm.

[Marek Lewandowski]

Pushed to ​t/14539 at dev.

[Tomasz Jakut]

LGTM.

[Tomasz Jakut]

Merged to master with ​git:d9873dd5c0bfbc9c25fe612a9a837ecebea70dfe.