Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#7948 closed Bug (fixed)

Length units not discoverable by users

Reported by: Damian Owned by: Anna Tomanek
Priority: Normal Milestone: CKEditor 3.6.2
Component: Accessibility Version: 3.6.1
Keywords: IBM NoTest Cc: Teresa Monahan, Satya Minnekanti

Description

Ticket #6462 has introduced a change to the table properties dialog, removing the width unit selector. By removing the unit selector, users now have no way to discover what possible values they could choose, nor do they know what the default unit length is.

Based on experience and what MS Word exposes, the two most common length values a user is likely to want to use are pixels and percentages. The other valid types of CSS units are likely to only be used by advanced users.

The editor should make it easy for both novice and advanced users to work with table (and other elements') sizes. Bringing back the combo selector would meet this objective.

Attachments (4)

word-table-width.png (6.0 KB) - added by Damian 6 years ago.
7948.patch (3.6 KB) - added by Garry Yao 6 years ago.
7948_2.patch (1.6 KB) - added by Garry Yao 6 years ago.
7948_3.patch (91.0 KB) - added by Anna Tomanek 6 years ago.

Download all attachments as: .zip

Change History (21)

Changed 6 years ago by Damian

Attachment: word-table-width.png added

comment:1 Changed 6 years ago by Jakub Ś

Status: newconfirmed

The unit combo hasn't been visible from rev [6979]

This revision has also caused ticket #7947

comment:2 Changed 6 years ago by Garry Yao

Component: GeneralAccessibility

The right way to achieve this is to utilize a field title attribute to provide supplementary information to a particular field label which could consist of:

  1. a more descriptive variant of an existing label, like supported length unit types;
  2. a reminder if the field is mandatory;

The simplified markup would be the following, which would be read by JAWS correctly.

<div class="cke_dialog_ui_text" role="presentation">
	<label for="cke_117_textInput" id="cke_118_label">Width</label>
	<input title="Width of the table specified in CSS length, in form of either absolute unit, relative unit or percentage." type="text" aria-labelledby="cke_118_label" id="cke_117_textInput" />
</div>

Considering it's an a11y enhancement and wouldn't be a small change, as we need to keep consistency across all existing dialog fields, v4 looks like the appropriate time for it.

comment:3 Changed 6 years ago by Damian

This is not just an a11y enhancement request, it is both an a11y problem and a general usability one. The problem is that sighted (and blind) users cannot discover what the valid formats are for width.

I think setting a label and a title attribute goes only a certain way to help. The only benefit of the title is that it provides a tooltip for the sighted user. A screen reader user won't normally hear the title because the aria label will be the calculated label for the input. For this reason, the additional descriptions of the field should also be placed in an aria-describedby.

Is there a reason why you don't want to reintroduce the unit selector option? It seems much more usable than expecting correct formats to be applied in the edit field.

comment:4 in reply to:  3 Changed 6 years ago by Damian

Replying to damo:

I think setting a label and a title attribute goes only a certain way to help. The only benefit of the title is that it provides a tooltip for the sighted user. A screen reader user won't normally hear the title because the aria label will be the calculated label for the input. For this reason, the additional descriptions of the field should also be placed in an aria-describedby.

I can see that in FF, IE and Safari, when a title is provided, the browser will use it to populate the accessible description value.

I can't find a definitive specification saying that the title attribute should be exposed as the accessible description of the input field. Although, the working draft "HTML to Platform Accessibility APIs Implementation Guide" http://www.w3.org/TR/2011/WD-html-aapi-20110414/ seems to support using title for the accessible description.

comment:5 Changed 6 years ago by Garry Yao

A screen reader user won't normally hear the title because the aria label will be the calculated label for the input

Sorry I don't get it, got this works perfect for both IE and FF.

Is there a reason why you don't want to reintroduce the unit selector option?

Well if we don't have other good options we could still consider bringing it back, which adds some good level of complication to the dialog.

comment:6 Changed 6 years ago by Wiktor Walc

Keywords: Discussion added

comment:7 in reply to:  5 Changed 6 years ago by Damian

Replying to garry.yao:

A screen reader user won't normally hear the title because the aria label will be the calculated label for the input

Sorry I don't get it, got this works perfect for both IE and FF.

Yes, as I mentioned in my later post, this seems to function ok right now and will likely be in the HTML5 standard, so I'm ok with the approach for now.


Is there a reason why you don't want to reintroduce the unit selector option?

Well if we don't have other good options we could still consider bringing it back, which adds some good level of complication to the dialog.

I have some further feedback from UX:

"The proposed dialog certainly violates the generally accepted dictum that an interface should avoid, where possible, allowing the user to make a mistake (i.e., don't let them make a mistake then correct them afterwards). And it violates the guideline emphasizing user recognition rather than user recall (show the user what units are valid, don't make the user remember them)."

Changed 6 years ago by Garry Yao

Attachment: 7948.patch added

comment:8 Changed 6 years ago by Garry Yao

Owner: set to Garry Yao
Status: confirmedreview

We'd provide the title accessibility solution as the first step fix (which requires some new translations), then when considering v4, a generic UI component that handles choose-able length unit could be enlarged into the dialog API to eventually resolve the usability requirement you raised here.

comment:9 Changed 6 years ago by Frederico Caldeira Knabben

Keywords: Discussion removed
Status: reviewreview_failed

KISS:

  1. Using text parts that need to fit on different contexts is a bad practice on localization.
  2. It's not a big issue to repeat that same text on several language entries. This is supposed to compress well.
  3. Based on "2", the added processing code, other than adding execution overhead, enlarges the core code unnecessarily.

Changed 6 years ago by Garry Yao

Attachment: 7948_2.patch added

comment:10 Changed 6 years ago by Garry Yao

Status: review_failedreview

comment:11 Changed 6 years ago by Sa'ar Zac Elias

Status: reviewreview_passed

comment:12 Changed 6 years ago by Garry Yao

Keywords: NoTest added
Resolution: fixed
Status: review_passedclosed

Fixed with [7212].

comment:13 Changed 6 years ago by Anna Tomanek

Resolution: fixed
Status: closedreopened

Reopening as discussed with Wiktor and Garry.

I suggest replacing two different tooltips with just a single common message. The text should also clearly state that a value without a unit denotes pixels.

Changed 6 years ago by Anna Tomanek

Attachment: 7948_3.patch added

comment:14 Changed 6 years ago by Anna Tomanek

Owner: changed from Garry Yao to Anna Tomanek
Status: reopenedreview

comment:15 Changed 6 years ago by Garry Yao

Status: reviewreview_passed

comment:16 Changed 6 years ago by Anna Tomanek

Resolution: fixed
Status: review_passedclosed

Fixed with [7215]. Polish and Dutch (thanks Niek!) translations included.

comment:17 Changed 6 years ago by Wiktor Walc

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