Re: Length of line

>you cannot have it all (i.e. at a fixed width of a device - say a cell
phone - if you enlarge your text to be very large (I'm seeing 400% being
tossed around a fair bit as a new normal), then even 25 characters will
very likely introduce horizontal scrolling,

There is an exception for mobile devices.
(1) The user-agent provides no means of re-flowing content.

> if you enlarge your text to be very large (I'm seeing 400% being tossed
around

The SC is to be tested without enlarging the text.
​ ​
"
​...
 a mechanism is available to adjust the line length
​...
 *without increasing the font in the user agent,*...

I think for the first draft we introduce the SCs separately " (1) line
length, (2) One column, (3) text zoom

I think this one stands on its own ok and meets the 8 requirements s for
acceptance ... I share your concerns about whether it's 25 or some larger
threshold, but besides that I think it holds together and is ready for
public scrutiny. I'm 25 hours into this SC, and hitting my limit of
bandwidth, unless someone else wants to take it over.

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 5:17 PM, John Foliot <john.foliot@deque.com> wrote:

> Hi Laura,
>
> Yes, and thanks for reminding me of that, although I am unsure whether
> Wayne is/was using Gmail to respond to this thread. Still, it is a useful
> metric to keep in mind.
>
> However, if I am to understand the proposed SC requirement here, I should
> be able to somehow shorten those line-lengths to nothing greater than 25
> characters, and how to do that consistently across multiple web-sites /
> web-pages is unclear as this time.
>
> What does the page author have to do (or not do) to ensure that users who
> have this requirement can meet success? I believe I understand the need
> that is driving this proposed SC, but have not seen any technique or
> example of how this could be achieved.
>
> I also continue to struggle with the intersection between line length,
> font-face and size, fixed view-port widths, and the issues around
> horizontal scrolling, as it seems you cannot have it all (i.e. at a fixed
> width of a device - say a cell phone - if you enlarge your text to be very
> large (I'm seeing 400% being tossed around a fair bit as a new normal),
> then even 25 characters will very likely introduce horizontal scrolling,
> due to the sheer size of each character.)
>
> JF
>
> On Wed, Jan 11, 2017 at 2:29 PM, Laura Carlson <
> laura.lee.carlson@gmail.com> wrote:
>
>> Hi John,
>>
>> You wrote to Wayne:
>>
>> > 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.
>>
>> Gmail's plain text mode foces hard breaks so no line is longer than 78
>> characters.
>>
>> Check:
>> https://mathiasbynens.be/notes/gmail-plain-text
>>
>> Kindest Regards,
>> Laura
>>
>> On 1/11/17, 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/
>> >> 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/20
>> 16/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 <(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
>> >
>>
>>
>> --
>> Laura L. Carlson
>>
>
>
>
> --
> 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 22:50:10 UTC