Length units not discoverable by users

[Damian]

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.

[Jakub Ś]

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

This revision has also caused ticket #7947

[Garry Yao]

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.

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

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

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

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

[Garry Yao]

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.

[Frederico Caldeira Knabben]

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.

[Garry Yao]

Fixed with [7212].

[Anna Tomanek]

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.

[Anna Tomanek]

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