ChromeVox: button names are not announced

[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.

[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?

[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

[Wim Leers]

Also tracked at ​http://drupal.org/node/1879430.

[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)

[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

[Frederico Caldeira Knabben]

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

[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.

[Jesse Beach]

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

[Mike Gifford]

Changing Component & adding keywords.

[Jakub Ś]

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

[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.

[Jakub Ś]

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.

[Jakub Ś]

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

[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.

[Jakub Ś]

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 :)

[Frederico Caldeira Knabben]

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.

[Olek Nowodziński]

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

[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

[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!

[Jesse Beach]

Noted and updated: ​https://drupal.org/node/2079129#comment-7826367

[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!