RE: Does text-overflow fail reflow and/or text-spacing

Thanks everyone for your input!

I’ll be looking at truncated text with suspicion now ??.

For this case I’ve decided to go with the paragraph of the resize text criterion<https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html> highlighted by Mitchell Evan, and fail all instances where it’s possible that the full text is never seen. If activation would allow the user to see the full text I will pass it with a strong recommendation to show all text on focus before activation (or with a button to fully show the text).

Many thanks,
Joppe


From: Mitchell Evan<mailto:mtchllvn@gmail.com>
Sent: Saturday, July 6, 2019 7:38 AM
To: Charles 'chaals' (McCathie) Nevile<mailto:chaals@yandex.ru>
Cc: WAI Interest Group<mailto:w3c-wai-ig@w3.org>
Subject: Re: Does text-overflow fail reflow and/or text-spacing

Understanding Success Criterion 1.4.4 Resize Text<https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html> offers an answer which I agree with. The truncated content should offer a control which enables the full content. I'll quote the full paragraph here because it's very relevant.

"Some user interface components that function as a label and require activation by the user to access content are not wide enough to accommodate the label's content. For example, in Web mail applications the subject column may not be wide enough to accommodate every possible subject header, but activating the subject header takes the user to the full message with the full subject header. In Web-based spreadsheets, cell content that is too long to be displayed in a column can be truncated, and the full content of the cell is available to the user when the cell receives focus. The content of a user interface component may also become too wide in user interfaces where the user can resize the column width. In this type of user interface component, line wrapping is not required; truncation is acceptable if the component's full content is available on focus or after user activation and an indication that this information can be accessed, is provided to the user in some way besides the fact that it is truncated."


On Fri, Jul 5, 2019 at 12:48 PM Charles 'chaals' (McCathie) Nevile <chaals@yandex.ru<mailto:chaals@yandex.ru>> wrote:
On Fri, 05 Jul 2019 15:13:12 +0200, Joppe Kroon <J.Kroon@topdesk.com<mailto:J.Kroon@topdesk.com>>
wrote:

> I am currently in the process of auditing our software and ran into some
> elements where _more_ of the text will be truncated >when zooming or
> changing text spacing.
>
> These elements display the first few words of (end-user provided) text
> truncated to the available width using the CSS ‘text->overflow’ property.
>
> The reflow and text-spacing criteria mention that a user should be able
> to zoom or increase text spacing without loss of >content, so, in a
> strict interpretation, these elements would fail.
>
> When I’m in a lenient mood, I feel that the truncated text was already
> not expected to be provided in it’s entirety, so the >additional loss of
> content would be acceptable.
>
> Would you fail or accept this situation?

Generally I would fail it, unless the purpose is really to get a sense of
what happens without the text itself being legible. (My assumption is that
most of the time that is unlikely to bne part of the use case. In any
event, even when it is it is usually pretty frustrating).

That's a hard line to take, I think. It is a case I think can be argued
reasonably easily against the written requirements, but I would prefer not
to spend a lot of time on it since it seems that it is first based on a
bad practice that should be fixed anyway, and second otherwise it is
probably not a very impactful problem.

> Would it be worth adding this situation to the reflow/text-spacing
> understanding documents?

Probably, if we can reach agreement on an answer...

cheers

Chaals

> Regards,
> Joppe Kroon

--
Using Opera's mail client: http://www.opera.com/mail/



--
Mitchell Evan
mtchllvn@gmail.com<mailto:mtchllvn@gmail.com>
(510) 375-6104 mobile