Opened 8 years ago

Closed 7 years ago

#16962 closed Bug (wontfix)

Paste notifications not read by screen reader

Reported by: Tomasz Jakut Owned by: kkrzton
Priority: Nice to have (we want to work on it) Milestone:
Component: General Version: 4.7.0
Keywords: Cc:

Description

Steps to reproduce

  1. Open http://nightly.ckeditor.com/17-04-11-06-09/standard/samples/
  2. Press "Paste" button.
  3. Check if screen reader is announcing notification correctly.

Expected result

Screen reader reads the notification.

Actual result

  • Firefox + VoiceOver: screen reader announces "Firefox has new window", but reads notification only after clicking it.
  • Firefox + JAWS: screen reader becomes muted when notification appears.
  • Chrome + VoiceOver: notification is read, however ⌘+V is read as plus v.

Change History (12)

comment:1 Changed 8 years ago by Tomasz Jakut

Status: newconfirmed

comment:2 Changed 8 years ago by Marek Lewandowski

Milestone: CKEditor 4.7.0

comment:3 Changed 8 years ago by Marek Lewandowski

Keep in mind that we support FF + JAWS. Anything other than that is just nice to have, but it's not our main focus here.

comment:4 Changed 8 years ago by Tomasz Jakut

I've created PoC branch:t/16962-focus, which shows that adding [aria-live=assertive] to the notification fixes the issues, however it's worsening the interaction with the editor (it's not focused as long as the notification is shown).

comment:5 Changed 8 years ago by Marek Lewandowski

Taking away focus is a no-go for us. We need either to troubleshot the issue on our end, or report a proper bug to product vendor if code is good.

comment:6 Changed 8 years ago by kkrzton

Owner: set to kkrzton
Status: confirmedassigned

comment:7 Changed 8 years ago by kkrzton

The issue with this case is the fact that after pressing Paste button, the notification is shown and editable gets focused.

It seems that the focused editable has preceding order over notification (not matter aria-live or the fact that notification was add/shown before or after focusing editable) and notification will be announced after the editable.

For now it seems the only way is to focus the notification to force JAWS to read it (for 1 - 2 seconds) and then focus editable. However, I am still investigating.

comment:8 Changed 8 years ago by kkrzton

The above (and this one) comment is based on tests with FF + JAWS.

Also I checked if focusing notification for some shorter amount of time ( < 500ms) before focusing editable (so toolbar -> notification -> editable) solves the issue but it does not help. The JAWS announces editable content first and then the notification.

comment:9 Changed 8 years ago by kkrzton

The one important finding is that if there is another notification visible, the new one is announced instantly no matter the editable focus. It means that the issue is related to notifications area adding/removing order (https://github.com/ckeditor/ckeditor-dev/blob/master/plugins/notification/plugin.js#L508). The whole area is attached/detached when notification is added/removed which may influence JAWS.

comment:10 Changed 8 years ago by kkrzton

Also it seems that even when the notification area is not detached but empty the JAWS still does not announce new notification when it appears (when other notification is there it works fine). We may need to look closer how exactly elements are added/removed here and how JAWS reacts on manipulating those elements.

comment:11 Changed 8 years ago by Marek Lewandowski

Milestone: CKEditor 4.7.0CKEditor 4.7.1

comment:12 Changed 7 years ago by Marek Lewandowski

Milestone: CKEditor 4.7.1
Resolution: wontfix
Status: assignedclosed

This issue has been closed here, see https://github.com/ckeditor/ckeditor-dev/issues/420#issuecomment-309416336 for more details.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy