RE: Length of line

> Surely when you say “character length is not a good criteria at all for this purpose”, in the email that you sent 2 minutes after replying to my thoughts, you are saying exactly the same?

I certainly did not say that – I was quoting from another member who said that.  I used a greater than to communicate that I was quoting from the thread.  Perhaps the greater than did not come through.

Jonathan



From: Michael Pluke [mailto:Mike.Pluke@castle-consult.com] 
Sent: Wednesday, January 11, 2017 12:41 PM
To: Jonathan Avila; WCAG
Subject: RE: Length of line

I didn’t say that that line length was not important – I said not to have an SC that specified “line length based on the number of characters”. Surely when you say “character length is not a good criteria at all for this purpose”, in the email that you sent 2 minutes after replying to my thoughts, you are saying exactly the same?

Mike

From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com] 
Sent: 11 January 2017 16:08
To: WCAG <w3c-wai-gl@w3.org>
Subject: RE: Length of line

• Conclusion: Based on all of the above I think that:
• To benefit LV users we should avoid having SCs that give a line length based on the number of characters;

Mike, I don’t understand – how does this benefit users with low vision if the LV task force is the one who suggested we have maximum line length?

Jonathan 
From: Michael Pluke [mailto:Mike.Pluke@castle-consult.com] 
Sent: Wednesday, January 11, 2017 5:59 AM
To: John Foliot; David MacDonald
Cc: WCAG
Subject: RE: Length of line

I can see that the choice of characters as the unit of measurement can result in very different end-results that you get depending on the chosen font-size and font-face. This may make this unit less useful from an LV perspective. 

However I still think that, from a cognitive perspective, it is relevant and important to set a maximum line length in characters. Long lines with many words/characters are demonstrably hard to read for everyone but, most particularly for people with dyslexia.  The 80 characters in SC 1.4.8 will cause significant difficulties for many people with dyslexia.

EA has quoted several research-based sources that offer realistic line-length proposals. From reading the extract from 'Dyslexia in the Digital Age' that EA linked-to (http://tinyurl.com/jra7hk3) I don’t think that it gives very strong evidence that 55 characters is the only choice. I’m a great fan of the realistic proposals that Luz Rello makes (based on her research (http://www.luzrello.com/Publications_files/uais2015.pdf)) so I have confidence for specifying line lengths in the 44-66 range (although it was non-dyslexic people who benefitted most from 44 character columns). The British Dyslexia Style Guide http://www.bdadyslexia.org.uk/common/ckeditor/filemanager/userfiles/About_Us/policies/Dyslexia_Style_Guide.pdf recommends that “Lines should not be too long: 60 to70 characters.”

Conclusion: Based on all of the above I think that:
• To benefit LV users we should avoid having SCs that give a line length based on the number of characters;
• To benefit people with dyslexia (and also the general population) the 1.4.8-based 80 character maximum in proposal #51 should be reduced to a figure no greater than 70 characters (and probably no less than 60).

Mike

From: John Foliot [mailto:john.foliot@deque.com] 
Sent: 10 January 2017 23:56
To: David MacDonald <david100@sympatico.ca>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: Re: Length of line

TL;DR - Using 'character' as a unit of measurement is extremely problematic, and I do not support it's use here. 

**************

Some thoughts after today's call.

I personally have significant concerns over prescribing a fixed number of characters, especially such a low number, as a unit of measurement. 

Internationalization:
When we factor in both Internationalization and languages other than English, we will quickly arrive at a point where the number 25 is smaller than numerous words in different languages (https://en.wikipedia.org/wiki/Longest_words), which will then require word hyphenization (most probably supplied by the content author, until such time as AI can do that job seamlessly). This then suggests to me that we will start to see 'forced' line-breaks again (using the presentational <br>), which could have a significant impact on screen flow in RWD (Responsive) layouts (i.e. the cure being worse the the symptom).


Font-size and font-face choices:
Equally, as mentioned on the call, another factor in measuring this, related to horizontal scrolling, is font-size. For those of you using HTML-rich mail clients, and using a 25 character-count example taken from http://www.litscape.com/words/length/25_letters/25_letter_words.html:


​​
electroencephalographical
​      
(Gmail's
​ 
'
​
S
mall' sizing)​
​
electroencephalographical      (Gmail's
​ 
'Normal' sizing)​
​
electroencephalographical      (Gmail's
​ 
'Large' sizing)​
​
electroencephalographical      (Gmail's
​ 
'Huge' sizing)​

Q: How do we test for "success" here? Even the final line above (Gmail's "Huge" font-size) could introduce horizontal scrolling at some level of magnification on some devices, yet at 25 characters "meets" the current wording of the proposed SC.  

Additionally, different font-faces will have different font-width characteristics, depending on the font-face chosen. For example:

​
electroencephalographical      (Gmail 'sans-serif', size 'normal')
​
electroencephalographical    (Gmail 'Verdana', size 'normal')  
​
electroencephalographical     (Gmail 'Wide', size 'normal')

...once again, depending on the font-face choice we have 3 different line-lengths, and so I question the overall choice of "character" as a unit of measurement here.


How to 'Succeed'/Author push-back:
The current proposed language for this SC reads:
For the visual presentation of all text, a mechanism is available such that line length is user adjustable, to 25 characters, with no two-dimensional scrolling required, and with the following exceptions.

However, it is unclear what a page author can or should do to meet this requirement
​, as it very much feels like a User-Agent requirement as much as anything else. For SC 1.4.8, one technique is 
G204: Not interfering with the user agent's reflow of text as the viewing window is narrowed
​, which​ seems to me to at least address the larger issue (avoid horizontal scrolling) without prescribing a specific line-length.

Finally, the current Success Criteria that requires an 80 character line-length (
SC 1.4.8) is a AAA Success Criteria requirement, and yet this new proposed SC is at level A, at roughly 1/3 the 80-char limit. 
​Sadly (but not totally unreasonably) ​
I suspect that we will get significant push-back at level A
​.

JF​
 

On Tue, Jan 10, 2017 at 3:31 PM, David MacDonald <david100@sympatico.ca> wrote:
I'm the manager of Issue #57 line length.

https://github.com/w3c/wcag21/issues/57


I was asked to explain why 25 characters was chosen as the threshold. I deferred to the LVTF
​ since I did not write that requirement​
. One point that was mentioned was that 25 characters is about the width of most news article columns. 

I did a survey of several top news sites on the web and measured the length of characters when text size is 100% (no zoom)

-CNN 74
​ ​
characters without counting spaces 87 with spaces. could narrow to 35 (w/ spaces) in Responsive
-NBC 61 no spaces 73 with spaces, could narrow to 39 (w/ spaces)
-ABC NEWS 81 no spaces 92 Spaces, could narrow to 43 in responsive
-FoxNews 67 no space 79 spaces could narrow to 45 in responsive
-Le Droit french 74 no space, 86 with spaces, no responsive
-Google News 73 No Spaces 87 with spaces could narrow to 44 in responsive
- Huff post French 67 no spaces 79 with spaces no responsive
​N
one of these sites passed the new SC proposal of 25 characters. They all went to horizontal scroll when window was narrowed less than those 
​minimum character ​
widths shown above.
​Do we
 want to make the minimum a little wider, say 45 or 50 characters.

For reference, the following is about 25 characters:

"This test assesses basic"


Cheers,
David MacDonald
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 

twitter.com/davidmacd
GitHub
www.Can-Adapt.com
  
  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy




-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

Received on Wednesday, 11 January 2017 18:12:51 UTC