Re: Length of line

John,
did a bit of research on css hyphens
see http://w3c.github.io/low-vision-a11y-tf/hyphenation-test.htm for some
results.
just declaring hyphens: auto - does a pretty good job (except for chrome).
if you add ­ and hypens: manual they work always. Tho adding soft
hypens is a bit of work for the author.

On Wed, Jan 11, 2017 at 2:07 PM, John Foliot <john.foliot@deque.com> wrote:

> Hi Wayne,
>
> Thank you for weighing in here, as yes, there is a struggle to completely
> understand what you are asking for in the Success Criteria. I am looking
> forward to seeing your examples, while at the same time observing that your
> email's longest line is 72 characters in length.
>
> You wrote: "The point here is the user can choose" - which gets a 100%
> thumbs up from me, but what does that mean for the author (as opposed to
> the software/hardware tools being used by the user)?
>
> And when you speak of 25 characters as being "a little big" what do you
> mean by that (please)? 25 characters at 16 pt. is not very big; 25
> characters at 32pt. is big, and 25 characters at 32pt. X 400% magnification
> is enormous, so at a minimum I suspect we need to be also stating a unit
> measurement at a fixed magnification point for "testing" and compliance
> purposes. Do you have any thoughts there?
>
> One thing I want to address however is your claim "...because today
> hyphenation is not well supported." What is this assertion based upon? The
> research I've done shows that this is not the case, that currently support
> for CSS hyphenation, while not at 100%, is actually quite good today
> (source: http://caniuse.com/#search=hyphens)  I hate to sound like a
> broken record, but I've posted this source now 3 times - can you or
> somebody else either refute it or accept it as "true" today? If true, can
> we dispense with the "hyphenation is not well supported" claims on this
> list? Thanks!
>
> JF
>
> On Wed, Jan 11, 2017 at 1:33 PM, Wayne Dick <wayneedick@gmail.com> wrote:
>
>> Hi All,
>>
>> 50 characters is too much. 30 is too much. 25 is a little big but most
>> people with low vision can live with it. I know that you have a rough
>> time setting up examples right now, but they are not hard to do with
>> practice. I'll get to that tomorrow.
>>
>> The point here is the user can choose. Normal users probably won't
>> choose to shorten text because authors construct columns of text for
>> normal users. Users with dyslexia will probably choose moderate lines
>> 40-55. People who need enlargement and people who have medical field
>> loss will choose 25.
>>
>> >From the usability point of view character count is the item to
>> measure because it is based on lexical data (letters, digits,
>> punctuation, etc.). Word wrapping is a lexical operation and so is
>> reading. You don't write a 1-meter essay. You write 1000 words. if you
>> want to measure readable of language you must use linguistic measures.
>> EM like measures might do.
>>
>> The key her is user choice. Suppose a German has peripheral field
>> loss, a common enough occurrence. The overwhelming number of German
>> words are less than 15 characters. See
>> http://www.news-by-design.com/infographic/language-length/ .
>> 25-letter words occur, but not many. So you have a choice: You can
>> short lines and set your user style sheet to break words (because
>> today hyphenation is not well supported). Or, you can choose wider
>> lines. Your choice.
>>
>> it is not exact but 15em usually gives about 25 characters.
>>
>> To say authors aren't used to short columns is just silly. In four
>> column format 3 of four columns will be close to 25 characters or
>> less.
>>
>> This is not as hard as it seems. Also if you have normal vision your
>> conventional knowledge will not do you much good.
>>
>> i suggest finding a cardboard tube, like a toilet paper tube. Cut it
>> down to where you can only fit 25 characters inside and then try to
>> read one of these email string through the cardboard tube.
>>
>> if you have peripheral field loss or use a screen magnifier, lens or
>> CCTV that's what it's like. This problem can be solved, but not by
>> making lines too long.
>>
>> More to come.
>>
>> Wayne
>>
>>
>>
>>
>>
>> On Wed, Jan 11, 2017 at 10:21 AM, David MacDonald <david100@sympatico.ca>
>> wrote:
>> > CSS hyphenation (when it is supported) offers the author control, which
>> is
>> > fine...
>> >
>> > 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
>> >
>> > On Wed, Jan 11, 2017 at 12:28 PM, John Foliot <john.foliot@deque.com>
>> wrote:
>> >>
>> >> > most (all) bowsers don't add hyphens
>> >>
>> >> Sorry David, I have to disagree: most browsers today support the CSS
>> >> hyphens attribute (https://www.w3.org/TR/css-text/#hyphens-property),
>> >> confirmed by CanIUse here: http://caniuse.com/#search=hyphens
>> >>
>> >> See also:
>> >> http://blog.fontdeck.com/post/9037028497/hyphens
>> >> https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens
>> >> https://css-tricks.com/almanac/properties/h/hyphenate/
>> >>
>> >> JF
>> >>
>> >> On Wed, Jan 11, 2017 at 11:08 AM, David MacDonald <
>> david100@sympatico.ca>
>> >> wrote:
>> >>>
>> >>> > I would propose we look to Root EMS instead for at least part of
>> this
>> >>> > proposal, and that we also include a magnification point (200%?
>> 400%?) as
>> >>> > also part of the requirement:
>> >>>
>> >>> I think the latest proposal addresses the magnification issue by
>> >>> requiring that the SC be met without zooming text. The downside of
>> REMs are
>> >>> that it is harder to understand, it is a specific technology, and it
>> is a
>> >>> relative measurement. Patrick, Jon A., what are your thoughts?
>> >>>
>> >>> I would also like Makoto and Swetank to respond to the hyphenation
>> >>> situation that most (all) bowsers don't add hyphens, and that CSS can
>> be use
>> >>> to override any hyphenation.
>> >>>
>> >>> 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
>> >>>
>> >>> On Wed, Jan 11, 2017 at 11:24 AM, John Foliot <john.foliot@deque.com>
>> >>> wrote:
>> >>>>
>> >>>> David wrote:
>> >>>>
>> >>>> > We have an established precedent in 1.4.8 of using characters to
>> >>>> > measure line length.
>> >>>>
>> >>>> Hi David,
>> >>>>
>> >>>> While we may have precedent there, SC 1.4.8 is a AAA Success
>> Criteria,
>> >>>> and I am hard-pressed personally to recall a site that meets (and
>> reports
>> >>>> compliance to) that SC consistently. As we've seen, "character" is a
>> very
>> >>>> imprecise unit of measurement.
>> >>>>
>> >>>> I think we need to step back a bit; what is the real goal we are
>> trying
>> >>>> to achieve here? I don't think it has anything to do with actual
>> character
>> >>>> count (per-se), but rather that we need developers to not break text
>> re-flow
>> >>>> (perhaps to a minimum of 25 REMs - Root EMs). Level-set: LVTF, is
>> this the
>> >>>> real "goal" here?
>> >>>>
>> >>>> However, given fixed view-port sizes and magnification there will
>> >>>> necessitate a trade-off, or else I could envision developers will
>> create one
>> >>>> line in their document at font-size:40px - perhaps an h1 - and then
>> use that
>> >>>> as the 'measuring point': 25 X 40px = 1000px, which, as a "baseline,
>> would
>> >>>> then "allow" paragraph text at 16px. to far exceed the 25 character
>> count
>> >>>> being proposed (1000 / 16 = 62.5 "characters") It is for this reason
>> that I
>> >>>> would propose we look to Root EMS instead for at least part of this
>> >>>> proposal, and that we also include a magnification point (200%?
>> 400%?) as
>> >>>> also part of the requirement:
>> >>>>
>> >>>> <draft> For the visual presentation of all text, text should
>> naturally
>> >>>> re-flow to a minimum of 25 REMs at 200% magnification without
>> horizontal
>> >>>> scrolling, with the following exceptions. </draft>
>> >>>>
>> >>>> ...or something along those lines. By moving away from actual
>> characters
>> >>>> (and their "imperfect" unit of measurement), we will likely address
>> most
>> >>>> concerns around internationalization, and with a more precise unit of
>> >>>> measurement, we will be able to better test (mechanically)
>> compliance to the
>> >>>> new SC. (I'd also look to have this be an AA requirement, as opposed
>> to an
>> >>>> A, but that is a different discussion...)
>> >>>>
>> >>>> Thoughts?
>> >>>>
>> >>>> JF
>> >>>>
>> >>>> On Wed, Jan 11, 2017 at 8:59 AM, John Foliot <john.foliot@deque.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> David wrote:
>> >>>>>
>> >>>>> > No browser that I know would do this:
>> >>>>> >
>> >>>>> > "Now is the time for all good men to come to the aid of their
>> >>>>> > establish-
>> >>>>> > ment party for now and forever"
>> >>>>>
>> >>>>> Erm... https://www.w3.org/TR/css-text/#hyphens-property
>> >>>>> and http://caniuse.com/#search=hyphens
>> >>>>> (which suggests support in most browsers with the exception of
>> >>>>> Android's native browser)
>> >>>>>
>> >>>>> JF
>> >>>>>
>> >>>>> On Wed, Jan 11, 2017 at 8:52 AM, David MacDonald
>> >>>>> <david100@sympatico.ca> wrote:
>> >>>>>>
>> >>>>>> Perhaps I'm missing something. For example say there is the line
>> >>>>>>
>> >>>>>> "Now is the time for all good men to come to the aid of their
>> >>>>>> establishment party for now and forever"
>> >>>>>>
>> >>>>>> And lets say that at the end of the word "their" we have a count
>> of 45
>> >>>>>> characters (I didn't count). The browser window is narrowed to 50
>> >>>>>> characters. Then the line will wrap after "their" and it would
>> pass.
>> >>>>>>
>> >>>>>> "Now is the time for all good men to come to the aid of their  (45
>> >>>>>> characters)
>> >>>>>> establishment party for now and forever ..."
>> >>>>>>
>> >>>>>> This would pass because there are 50 or less characters on that
>> line.
>> >>>>>>
>> >>>>>> No browser that I know would do this:
>> >>>>>>
>> >>>>>> "Now is the time for all good men to come to the aid of their
>> >>>>>> establish-
>> >>>>>> ment party for now and forever"
>> >>>>>>
>> >>>>>> In other words.... most lines will be less than 50 characters if
>> 50 is
>> >>>>>> the threshold we decide on.
>> >>>>>>
>> >>>>>> We have an established precedent in 1.4.8 of using characters to
>> >>>>>> measure line length. I think in a dot release we should stick with
>> that,
>> >>>>>> unless I'm missing something.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Cheers,
>> >>>>>> David MacDonald
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> CanAdapt Solutions Inc.
>> >>>>>>
>> >>>>>> Tel:  613.235.4902 <(613)%20235-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
>> >>>>>>
>> >>>>>> On Wed, Jan 11, 2017 at 9:21 AM, Patrick H. Lauke
>> >>>>>> <redux@splintered.co.uk> wrote:
>> >>>>>>>
>> >>>>>>> On 11/01/2017 14:12, David MacDonald wrote:
>> >>>>>>>>
>> >>>>>>>> Hi Shwetank
>> >>>>>>>>
>> >>>>>>>> Can you help us understand how hyphenation works in those
>> languages?
>> >>>>>>>> In
>> >>>>>>>> English and French, (the languages I speak), the web the page
>> just
>> >>>>>>>> wraps
>> >>>>>>>> the entire word if it doesn't fit. So there is not generally
>> >>>>>>>> hyphenation
>> >>>>>>>> for web writing.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Regardless of language, hyphenation will be up to the browser to
>> do
>> >>>>>>> (support isn't fantastic / cross-browser just yet), or would
>> require
>> >>>>>>> additional JS solutions that forcibly break and hyphenate words
>> (which would
>> >>>>>>> likely lead to issues where AT would start to read word fragments
>> rather
>> >>>>>>> than full words). So there are potential technical limitations to
>> overcome
>> >>>>>>> here as well.
>> >>>>>>>
>> >>>>>>> P
>> >>>>>>>
>> >>>>>>>> Cheers,
>> >>>>>>>> David MacDonald
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> *Can**Adapt* *Solutions Inc.*
>> >>>>>>>>
>> >>>>>>>> Tel:  613.235.4902
>> >>>>>>>>
>> >>>>>>>> LinkedIn
>> >>>>>>>> <http://www.linkedin.com/in/davidmacdonald100>
>> >>>>>>>>
>> >>>>>>>> twitter.com/davidmacd <http://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 8:12 AM, Shwetank Dixit
>> >>>>>>>> <shwetank@barrierbreak.com <mailto:shwetank@barrierbreak.com>>
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>     FWIW, I agree with John that character length is not a good
>> >>>>>>>> criteria
>> >>>>>>>>     at all for this purpose, especially from the viewpoint of
>> >>>>>>>>     non-english languages. I believe the research and guidelines
>> >>>>>>>>     mentioned in this discussion have not included languages from
>> >>>>>>>>     scripts apart from the Latin script (please correct me if I’m
>> >>>>>>>> wrong)
>> >>>>>>>>     like Devnagari, Gurkumikhi, or any from the CJK ones for
>> >>>>>>>> example.
>> >>>>>>>>
>> >>>>>>>>     I am especially concerned about the possibility of
>> significantly
>> >>>>>>>>     increased ‘hyphenation’ that this could result in (which John
>> >>>>>>>> also
>> >>>>>>>>     mentioned) causing bigger problems from a cognitive
>> perspective.
>> >>>>>>>>     —
>> >>>>>>>>     Shwetank
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>     On Wednesday, Jan 11, 2017 at 4:32 PM, Michael Pluke
>> >>>>>>>>>     <Mike.Pluke@castle-consult.com
>> >>>>>>>>>     <mailto: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/Publications_files/uais2015.pdf
>> >>>>>>>>>     <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/us
>> erfiles/About_Us/policies/Dyslexia_Style_Guide.pdf
>> >>>>>>>>>
>> >>>>>>>>> <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 <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
>> >>>>>>>>>     <mailto:john.foliot@deque.com>]
>> >>>>>>>>>     *Sent:* 10 January 2017 23:56
>> >>>>>>>>>     *To:* David MacDonald <david100@sympatico.ca
>> >>>>>>>>>     <mailto:david100@sympatico.ca>>
>> >>>>>>>>>     *Cc:* WCAG <w3c-wai-gl@w3.org <mailto: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
>> >>>>>>>>>     <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_wo
>> rds.html
>> >>>>>>>>>
>> >>>>>>>>> <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/G2
>> 04>:
>> >>>>>>>>>     /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 <mailto:david100@sympatico.ca>>
>> >>>>>>>>> wrote:____
>> >>>>>>>>>
>> >>>>>>>>>         I'm the manager of Issue #57 line length.
>> >>>>>>>>>
>> >>>>>>>>>         https://github.com/w3c/wcag21/issues/57
>> >>>>>>>>>         <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>
>> <tel:(613)%20235-4902>____
>> >>>>>>>>>
>> >>>>>>>>>         LinkedIn
>> >>>>>>>>>         <http://www.linkedin.com/in/davidmacdonald100>____
>> >>>>>>>>>
>> >>>>>>>>>         twitter.com/davidmacd <http://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 <mailto:john.foliot@deque.com>____
>> >>>>>>>>>
>> >>>>>>>>>     __ __
>> >>>>>>>>>
>> >>>>>>>>>     Advancing the mission of digital accessibility and
>> >>>>>>>>> inclusion____
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Patrick H. Lauke
>> >>>>>>>
>> >>>>>>> www.splintered.co.uk | https://github.com/patrickhlauke
>> >>>>>>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> >>>>>>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> John Foliot
>> >>>>> Principal Accessibility Strategist
>> >>>>> Deque Systems Inc.
>> >>>>> john.foliot@deque.com
>> >>>>>
>> >>>>> Advancing the mission of digital accessibility and inclusion
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> John Foliot
>> >>>> Principal Accessibility Strategist
>> >>>> Deque Systems Inc.
>> >>>> john.foliot@deque.com
>> >>>>
>> >>>> Advancing the mission of digital accessibility and inclusion
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> John Foliot
>> >> Principal Accessibility Strategist
>> >> Deque Systems Inc.
>> >> john.foliot@deque.com
>> >>
>> >> Advancing the mission of digital accessibility and inclusion
>> >
>> >
>>
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>



-- 
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964