RE: text 'truncation' at normal scaling

Darn junk folder ... sorry for the delayed response.

> that has a cognitive cost which is effectively a loss of content, although technically the content is still there.>

It is precisely the cognitive load and the tracing that Wayne mentions that I had in mind, particularly for extreme cases where, say, a database sets at 255 character limit, but the UI only provides the default user agent width or the author sets a width of x units because it matches all the other inputs on a form or the platform doesn't allow customisation etc. 

As a sometimes screen magnifier user, it does my head in. The phenomenon reminds me of the Official (paper) Forms we still see occasionally that provide inadequate space in which to write just so that everything can fit on one page. It's a pity that the limitations of print are still with us ... 

<I don't think so. There isn't content or functionality lost under zoom at 100% - it wasn't there>

So, what is the difference between text in a single line input not being visible in its entirety at 100% text resize and text in a similar single line text input that is not visible in its entirety at 200% (but is entirely visible at 100%) and given that the success criterion defines a continuum  and not a threshold?

< On the other hand it is unfriendly design that poses a barrier for users. To a certain extent whether this is acceptable depends on th actual content - it it's a long filename with lots of apparently random characters, there may be no real issue, if it is text you want the user to actually read, there is.>

I agree about the nature of the content to be read, but this presents a pretty blurry boundary from a conformance perspective. The 'understanding success criterion 1.4.4' counsels that " truncation is acceptable if the component's full content is available on focus or after user activation", and, while this is informative, it is instructive.  Does 'available' mean visible in its entirety?

Who knows? Maybe we'll have to wait for WCAG3.0 ... 

While I'm on the soapbox, one other related 'unfriendly design' in my thinking is the practice of re-presenting information to users in readonly inputs. Text is text. Inputs are for input. 

Cheers, 
Adam 



-----Original Message-----
From: chaals@yandex-team.ru [mailto:chaals@yandex-team.ru] 
Sent: Thursday, November 13, 2014 11:32 PM
To: James Nurthen; Adam Cooper
Cc: w3c-wai-ig@w3.org
Subject: Re: text 'truncation' at normal scaling

13.11.2014, 06:00, "James Nurthen" <james@nurthen.com>:
> There is no lost content here no matter the zoom. The user can
> activate the input component and scroll within it to reach all of the
> text.

As Wayne points out, that has a cognitive cost which is effectively a loss of content, although technically the content is still there.

I think we should be looking for some kind of requirement that means the user is only required to move in one dimension in order to get all the content.

> On Wed, Nov 12, 2014 at 12:30 PM, Adam Cooper <cooperad@bigpond.com> wrote:
[...]
>>  For example:
>>
>>  #css-width {width: 11em;}
>>  <input id="css-width" type="text" value="123456789012345678901234567890"
>>  /><br />
[...]
>>  Can ‘up to 200%’ be interpreted as ‘100% to 200%’ legitimately?  (an earlier
>>  draft of the guidelines had 50% to 200%)

The normal english meaning of "up to 200%" would be "from 0 to 200%"... but the key text here is "without loss of content or functionality".

>>  That is, are the examples above failures of success criterion 1.4.4?

I don't think so. There isn't content or functionality lost under zoom at 100% - it wasn't there.

On the other hand it is unfriendly design that poses a barrier for users. To a certain extent whether this is acceptable depends on th actual content - it it's a long filename with lots of apparently random characters, there may be no real issue, if it is text you want the user to actually read, there is.

Cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Monday, 17 November 2014 08:55:53 UTC