Re: Length of line

PS typo "Pluke" not "luke"

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://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
<http://www.davidmacd.com/disclaimer.html>

On Wed, Jan 11, 2017 at 7:39 AM, David MacDonald <david100@sympatico.ca>
wrote:

> That makes sense to me, except for Wayne's use case on yesterday's call of
> tunnel vision where the field is very narrow, and the LV user has a
> non-magnified font and narrow columns, so there is a lot of info in a
> narrow field.
>
> I think what is emerging is two amendments to the proposal
> (1) Line length can be narrowed to around 50-60 characters rather than 25
> (2) a baseline font size of 100% (no zoom) for the purposes of measuring
> whether the SC was met or not.
>
> So the new proposal, addressing some of Greg Lowney's, Mike luke's
> comments and others could be something like:
>
> =============
>
> For all visual presentation of text, a mechanism is available to adjust
> the line length to a maximum of 50 characters without increasing the font
> in the user agent, and without requiring two-dimensional scrolling, except
> where:
> (1) The user-agent provides no means of re-flowing content.
> (2) The spatial layout of text is essential to its use.
>
> ==========
>
> I also would not rule out integrating this (#57) into a 1.4.8 omnibus text
> SC (Issue #51 COGA), or merging with (#58) in future drafts, but I think
> for the first draft in 6 weeks this is sufficient.
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-4902>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://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
> <http://www.davidmacd.com/disclaimer.html>
>
> On Wed, Jan 11, 2017 at 5:58 AM, Michael Pluke <
> Mike.Pluke@castle-consult.com> wrote:
>
>> 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
>> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-visual-presentation.html>
>> 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/Publi
>> cations_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/us
>> erfiles/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
>>    <https://github.com/w3c/wcag21/issues/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 <https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/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
>> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-visual-presentation.html>)
>> 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
>>
>>
>>
>> *Can**Adapt* *Solutions Inc.*
>>
>> Tel:  613.235.4902 <(613)%20235-4902>
>>
>> LinkedIn
>> <http://www.linkedin.com/in/davidmacdonald100>
>>
>> twitter.com/davidmacd
>>
>> GitHub <https://github.com/DavidMacDonald>
>>
>> www.Can-Adapt.com <http://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
>> <http://www.davidmacd.com/disclaimer.html>
>>
>>
>>
>>
>>
>> --
>>
>> John Foliot
>>
>> Principal Accessibility Strategist
>>
>> Deque Systems Inc.
>>
>> john.foliot@deque.com
>>
>>
>>
>> Advancing the mission of digital accessibility and inclusion
>>
>
>