Opened 3 months ago

Closed 10 days ago

#16962 closed Bug (wontfix)

Paste notifications not read by screen reader

Reported by: t.jakut Owned by: k.krzton
Priority: Nice to have (we want to work on it) Milestone:
Component: General Version: 4.7.0 (GitHub - major)
Keywords: Cc:


Steps to reproduce

  1. Open
  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 3 months ago by t.jakut

  • Status changed from new to confirmed

comment:2 Changed 2 months ago by m.lewandowski

  • Milestone set to CKEditor 4.7.0

comment:3 Changed 2 months ago by m.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 2 months ago by t.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 2 months ago by m.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 2 months ago by k.krzton

  • Owner set to k.krzton
  • Status changed from confirmed to assigned

comment:7 Changed 2 months ago by k.krzton

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 weeks ago by k.krzton

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 weeks ago by k.krzton

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 ( The whole area is attached/detached when notification is added/removed which may influence JAWS.

comment:10 Changed 8 weeks ago by k.krzton

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 7 weeks ago by m.lewandowski

  • Milestone changed from CKEditor 4.7.0 to CKEditor 4.7.1

comment:12 Changed 10 days ago by m.lewandowski

  • Milestone CKEditor 4.7.1 deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

This issue has been closed here, see for more details.

Note: See TracTickets for help on using tickets.
© 2003 – 2017 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy