Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#10004 closed Bug (fixed)

ChromeVox: button names are not announced

Reported by: Wiktor Walc Owned by: Jakub Ś
Priority: Normal Milestone: CKEditor 4.2.1
Component: Accessibility Version: 4.0
Keywords: Drupal ChromeVox Cc: wim.leers@…

Description (last modified by Wiktor Walc)

When using CKEditor with ChromeVox (confirmed at least in framed mode), button names are not recognized. See the following screencast:

http://screencast.com/t/iK369LOczoKa

It looks like ChromeVox is buggy, we're using aria-labelledby to point reader to the label (works with JAWS and VoiceOver).

Note: issue was originally reported for VoiceOver, but the problem has been in fact in ChromeVox.

Change History (23)

comment:1 Changed 6 years ago by Wim Leers

Cc: wim.leers@… added
Description: modified (diff)

comment:2 Changed 6 years ago by Wiktor Walc

I did not try this directly in Drupal, but I checked http://nightly.ckeditor.com/13-01-31-08-51/standard/samples/replacebyclass.html @ OSX 10.7.5 and in both Safari (6.0.2) and Chrome (24.0.1312.57) VoiceOver read properly button names.

@Wim - can you check if the standard/replacebyclass sample works properly?

comment:3 Changed 6 years ago by Jesse Beach

I made the original screencast on Mac 10.7, on Chrome 24 with ChromeVox.

This is a screencast of the same setup on the replacebyclass example:

http://screencast.com/t/QMX7fWFsf

comment:4 Changed 6 years ago by Wim Leers

comment:5 Changed 6 years ago by Wiktor Walc

I never used VoiceOver so far, but this is what I got: http://www.screencast.com/t/YshiMiOXEm8 (make sure to turn the sound a bit louder while watching)

comment:6 Changed 6 years ago by Wiktor Walc

@jessebeach - I do not have a lot of experience with VoiceOver, but is it possible that the differences between results on my and your side come from using different keys or VoiceOver configuration (default in my case)?

I'm using the editor this way:

  • tab key to get into editing area
  • Alt + F10 to get into the toolbar
  • right/left arrow key to move between buttons in a single toolbar group
  • Tab to move between toolbar groups

comment:7 Changed 6 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 4.0.2

This one seems to be related to ChromeVox, not VoiceOver.

comment:8 Changed 6 years ago by Wiktor Walc

Yep, I was able to confirm it in ChromeVox and it looked just like on the screencast created by jessebeach. Looks like a bug in ChromeVox itself, it has nothing to do with VoiceOver.

comment:9 Changed 6 years ago by Wiktor Walc

Description: modified (diff)
Summary: VoiceOver: button names are not announcedChromeVox: button names are not announced

comment:10 Changed 6 years ago by Jesse Beach

Sorry, I had thought that ChromeVox was leveraging VoiceOver on a Mac.

comment:11 Changed 6 years ago by Mike Gifford

Component: GeneralAccessibility
Keywords: accessibility ChromeVox added

Changing Component & adding keywords.

comment:12 Changed 6 years ago by Jakub Ś

Keywords: accessibility removed

Please don't add keywords we don't use.

comment:13 Changed 6 years ago by Mike Gifford

Well, there are other issues that have used it - http://dev.ckeditor.com/ticket/10239

Not sure why you don't use the keyword "Accessibility". Marking it as a component makes it isolated from the other issues (like tables).

Anyways, the thing I'm mostly worried about is seeing movement in these issues. I haven't seen a lot on the threads that are in the Accessibility component.

comment:14 Changed 6 years ago by Jakub Ś

Status: newconfirmed

I think I may have found what is wrong.

ChromVox reads only Source button and not any other. It turns out that all other buttons have something like below:

<span id="cke_117_label" class="cke_button_label cke_button__preview_label">Preview</span>

.cke_button_label {
display: none;
...
}

As you can see for every of these other buttons label is set to display : none. If you remove display property from this class all buttons are now read. The problem is that editor looks really terrible then.

I have made some search and found this article: http://blog.paciellogroup.com/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/. Author claims that

Use of aria-hidden=false had no effect in any of the screen reader/browser

I have also checked http://www.w3.org/WAI/PF/aria-implementation/#include_elements and http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements2. All of this made perfect sense that display:none elements are not included in the accessibility tree.

Nevertheless I have tried using aria-hidden=false as it kind of made sense to me - you can hide something from screen but you may not want to hide it from screen reader and to my surprise it has worked. Labels are now read.

Perhaps this is because there is aria-labelledby attribute used which makes this element included in accessibility tree after all.

comment:15 Changed 6 years ago by Jakub Ś

I have made some further tests - seems this possible solution doesn't break JAWS or VoiceOver.

comment:16 in reply to:  14 Changed 6 years ago by Wim Leers

Replying to j.swiderski:

I have made some search and found this article: http://blog.paciellogroup.com/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/. Author claims that

Use of aria-hidden=false had no effect in any of the screen reader/browser

I have also checked http://www.w3.org/WAI/PF/aria-implementation/#include_elements and http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements2. All of this made perfect sense that display:none elements are not included in the accessibility tree.

Nevertheless I have tried using aria-hidden=false as it kind of made sense to me - you can hide something from screen but you may not want to hide it from screen reader and to my surprise it has worked. Labels are now read.

Perhaps this is because there is aria-labelledby attribute used which makes this element included in accessibility tree after all.

I'm not sure I follow. The article you cite says this:

Use of aria-hidden=false had no effect in any of the screen reader/browser combinations tested. In other words if content is hidden from all users using HTML5 hidden or display:none applying aria-hidden=false to the content does not make it visible to screen reader users.

(Emphasis mine.)

So why not just use the off screen technique? That's guaranteed to work; we've all used that for many, many years without any problems.

comment:17 Changed 6 years ago by Jakub Ś

Owner: set to Jakub Ś
Status: confirmedreview

Hmm... I must have been drunk when writing this.

@WimLeers what I have meant is that elements with display:none (or with aria-hidden="true") are not included in accessibility tree. These links confirm it: http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements2 and http://www.w3.org/WAI/PF/aria-implementation/#include_elements.

What I also understand from doc above is that you can prevent excluding element from accessibility tree by setting aria-hidden="false" on display:none element. It isn't stated directly here but this is how I understand it. I have found link that confirms this but more of this later.

Author of this blog-post http://blog.paciellogroup.com/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/ claimed that aria-hidden="false" has no effect, that it does nothing. I didn't agree with that opinion and decided to test this. I have set aria-hidden="false" on label element and it has worked.


I have tried it in ChromeVox, Jaws and VoiceOver. This solution has fixed problem in chromeVox and didn't break JAWS or VoiceOver.

It seems that aria-hidden="false" prevents element being removed from accessibility tree and docs seem to confirm it (contrary to blog-post). This is the link I was talking about http://www.w3.org/WAI/PF/aria/states_and_properties#aria-hidden. I should have looked at it in the first place.
Please have a look at first sentence.

Indicates that the element and all of its descendants are not visible or perceivable to any user as implemented by the author ...

Please also have a look at http://www.w3.org/WAI/PF/aria/terms#def_perceivable. Perceivable means discoverable.

It looks like Chrome Vox understands it the same way. IMHO such solution is better and much simpler.

Having said all that, I have made fix in branch t/10004 (https://github.com/cksource/ckeditor-dev/tree/t/10004).

@Wim Leers try it before you deny it :)

comment:18 Changed 6 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 4.2.1
Status: reviewreview_passed

The specs for aria-hidden are clearly saying that this attributed can be used in any context when it's intended to "improve the experience for users of assistive technologies". This is clearly an acceptable case. Here, even if we're hidding the button labels with CSS, we want them to be considered for a11y purposes and therefore "unhidding" them is certainly a good way for it.

comment:19 Changed 6 years ago by Olek Nowodziński

Resolution: fixed
Status: review_passedclosed

Merged fix into master (​git:882760cf14da).

comment:20 Changed 6 years ago by Jesse Beach

@fredck, awesome detective work!

I noted this solution in a similar issue we're having with Dragon Naturally Speaking. I'm hoping it will help us solve that issue as well.

https://drupal.org/node/2079129#comment-7826367

comment:21 in reply to:  20 Changed 6 years ago by Frederico Caldeira Knabben

Replying to jessebeach:

@jessebeach, thanks! But you pointed to the wrong person :)

I just reviewed the final solution but j.swiderski is the one who spent hours on research, testing and coding here, coming with a simple and effective solution.

So, if you don't mind, I'm transferring the kudos to j.swiderski. Great job Kuba!

comment:23 Changed 6 years ago by Wim Leers

@j.swiderski: Thanks for the thorough, clear response you provided in comment:17. And I totally agree with jessebeach that this is most impressive detective work. Thank you :) Great job indeed!

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