Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#7948 closed Bug (fixed)

Length units not discoverable by users

Reported by: damo Owned by: Anna
Priority: Normal Milestone: CKEditor 3.6.2
Component: Accessibility Version: 3.6.1
Keywords: IBM NoTest Cc: tmonahan, satya

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 damo 6 years ago.
7948.patch (3.6 KB) - added by garry.yao 5 years ago.
7948_2.patch (1.6 KB) - added by garry.yao 5 years ago.
7948_3.patch (91.0 KB) - added by Anna 5 years ago.

Download all attachments as: .zip

Change History (21)

Changed 6 years ago by damo

comment:1 Changed 6 years ago by j.swiderski

  • Status changed from new to confirmed

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 changed from General to Accessibility

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 follow-up: Changed 6 years ago by damo

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 damo

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 follow-up: 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 wwalc

  • Keywords Discussion added

comment:7 in reply to: ↑ 5 Changed 5 years ago by damo

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 5 years ago by garry.yao

comment:8 Changed 5 years ago by garry.yao

  • Owner set to garry.yao
  • Status changed from confirmed to review

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 5 years ago by fredck

  • Keywords Discussion removed
  • Status changed from review to review_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 5 years ago by garry.yao

comment:10 Changed 5 years ago by garry.yao

  • Status changed from review_failed to review

comment:11 Changed 5 years ago by Saare

  • Status changed from review to review_passed

comment:12 Changed 5 years ago by garry.yao

  • Keywords NoTest added
  • Resolution set to fixed
  • Status changed from review_passed to closed

Fixed with [7212].

comment:13 Changed 5 years ago by Anna

  • Resolution fixed deleted
  • Status changed from closed to reopened

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 5 years ago by Anna

comment:14 Changed 5 years ago by Anna

  • Owner changed from garry.yao to Anna
  • Status changed from reopened to review

comment:15 Changed 5 years ago by garry.yao

  • Status changed from review to review_passed

comment:16 Changed 5 years ago by Anna

  • Resolution set to fixed
  • Status changed from review_passed to closed

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

comment:17 Changed 5 years ago by wwalc

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