AVT: Title for all buttons in CK Editor Toolbar not displayed for Keyboard only User

[Satya Minnekanti]

Steps to reproduce

1. Open nightly build.
2. Navigate to toolbar by pressing Alt + F10
3. Navigate to each toolbar button using TAB key (keyboard only user).

Issue: Label for each button(ex: Source) not displayed for Keybaord only user. This is violation of AVT Checkpoint Checkpoint 2.1.1 Keyboard ​http://www-03.ibm.com/able/guidelines/ci162/keyboard.html

[Satya Minnekanti]

Replying to satya:

Steps to reproduce

1. Open nightly build.
2. Navigate to toolbar by pressing Alt + F10
3. Navigate to each toolbar button using TAB key (keyboard only user).

Issue: Label for each button(ex: Source) not displayed for Keybaord only user. This is violation of AVT Checkpoint Checkpoint 2.1.1 Keyboard ​http://www-03.ibm.com/able/guidelines/ci162/keyboard.html

Please look at this page ​http://pokgsa.ibm.com/gsa/pokgsa/projects/s/swf_design/design/Team-Folders/Randy-B/accessibility/aqg/tooltips.html for examples on how to fix this issue

[Marek Lewandowski]

Unfortunately we can't resolve ​http://pokgsa.ibm.com/gsa/pokgsa/projects/s/swf_design/design/Team-Folders/Randy-B/accessibility/aqg/tooltips.html host, it does look like a private one.

We're investigating the issue.

[Marek Lewandowski]

The ticket is valid, button tooltips would be a good a11y practice. Implementation would require some work and would put a notable footprint on the editor size so for sure it has to be contained within a plugin.

[Tade0]

Added a "Keyboard Tooltip" plugin that adds a tooltip when a button has focus.

Changes pushed to ​branch:t/14931.

[Marek Lewandowski]

1. Please put the styles inline, there's no reason to make another HTTP request just to get such a tiny file.
2. This CSS should be added in a onLoad method instead of init. The reason for it is that it will get executed multiple times for each editor, while it's enough to do it just once.

[Tade0]

Corrected the errors.

Tested in IE9, IE11, Chrome, Firefox.

[Tomasz Jakut]

There is one issue with the current solution: tooltips for the bottom line of buttons are cropped. In Chrome it's just unaesthetic, but in Firefox the issue is bigger, e.g. "g" looks like "o". Therefore tooltips are very hard to read and can be misleading.

The problem is caused by the fact that the container for all toolbars is floated and overflow: hidden is used to preserve its dimensions. However it also cause the cropping of tooltips. Perhaps the overflow: hidden could be replaced with ​clearfix hack by the plugin to properly display tooltips at the bottom?

[Tade0]

Destroyed layot

[Tade0]

Moved tooltip

[Tade0]

I tried that, but it broke the layout.

Then again moving the tooltip a little bit to the top and to the right for good measure seems to look better. What do you think?

[Tomasz Jakut]

Yep, the option with moved tooltip looks very good.

[Tade0]

Ok, so I'll be going with it.

Changes pushed to ​branch:t/14931.

[Tomasz Jakut]

LGTM.

[Marek Lewandowski]

Updated the tooltip - removed the opacity / because it lowers the accessibility (low contrast). Also moved the tooltip a little down.

[Tade0]

Replaced the native tooltip with this one, added a 1px white border for better visibility in high contrast mode, solved truncation problem.

Changes pushed to ​branch:t/14931.

[Marek Lewandowski]

The only thing I'm missing here is support for high contrast, and in fact we should not show tooltip in high contrast. The reason why is that in high contrast labels are visible so there's no need to duplicate this information and make UI more complex.

[Marek Lewandowski]

I've added a manual test for colorbutton integration. With title attribute removed from colors, those would not have any accessible label for screen readers. I have updated the existing logic to add aria-label for these cases. However still R fails because:

• label is not shown for "automatic" option nor for "more colors", see screen:

[Marek Lewandowski]

Related issue #16373.

[Tade0]

Fixed:

Works for moono-lisa as well.

[Marek Lewandowski]

LGTM, before closing the ticket, please publish plugin on a separate repository cksource/ckeditor-plugin-keyboardtooltip.

[kkrzton]

We have discovered one issue. As a tooltip is applied as :before element with relative positioning to the toolbar button (a) it works fine as long as all buttons have position: relative. That is the case for moono-lisa skin and normal buttons in moono skin. However, for dropdowns in moono skin, they have position: static so the tooltip is not rendered in a correct position (see attached screenshot).

If we are planning to deliver a generic plugin which will work with different skins I think it might be hard to achieve with the current approach. Probably we should consider global positioning of tooltips instead of positioning relatively to the buttons.

[Marek Lewandowski]

Pushed ​branch:t/14931 to review.

I've fixed a number of things, like:

• compatibility with inline editor (it was formerly broken)
• tooltips are no longer cropped within dropdown - element is now placed in the outer document
• plugin will no longer throw an exception if only one of color buttons is added to the toolbar

There's a know issue that the tooltip is not aligned correctly only for the first time you open color button palette using the keyboard. Any subsequent calls are fine.

[kkrzton]

I can see two issues:

1. The tooltips are not positioned correctly for moono-lisa skin (checked on Chrome and Firefox - see screenshot).
2. If you resize the viewport so that toolbar buttons positions changes the tooltip stays at it initial (and now invalid) position. This is the very rare edge case so I am not sure if it's worth fixing.

Overall, global positioning of tooltips is probably a way to go. Maybe you may consider using ​getBoundingClientRect instead of offsets as it might be more accurate?

[Marek Lewandowski]

Replying to k.krzton:

I can see two issues:

1. The tooltips are not positioned correctly for moono-lisa skin (checked on Chrome and Firefox - see screenshot).

That's right, the problem is fixed by replacing [CKEDITOR.addCss with document.appendStyleText](​https://github.com/cksource/ckeditor-dev/commit/a3a9112039e519e214724cbb5ca39c46e1f9ca84). Also I've added a manual test for Kama skin.

2. If you resize the viewport so that toolbar buttons positions changes the tooltip stays at it initial (and now invalid) position. This is the very rare edge case so I am not sure if it's worth fixing.

Yes it won't reposition itself on resize event, but it will do so on next button focus. We'll extract this into a separate issue.

Overall, global positioning of tooltips is probably a way to go. Maybe you may consider using ​getBoundingClientRect instead of offsets as it might be more accurate?

I was considering bounding rect, but it proved to be wrong in some cases, e.g. on our manual test pages. This way of computing offsets had correct results in this cases.

[kkrzton]

LGTM!

[Marek Lewandowski]

For the record - the tooltips are easily stylable, you could simply add following rule to your stylesheet:

div.cke_tooltip.cke_reset.cke_reset_all{ background: white; color: black; border: solid orange 1px; border-radius: 5px;}

And this will change the appearance of the tooltips.

[Marek Lewandowski]

This feature will be merged to major in issue #16373.