Re: Length of line

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
> >>>>>>
> >>>>>> 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/
> userfiles/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_
> words.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/
> 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 <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 <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