- From: John Foliot <john.foliot@deque.com>
- Date: Wed, 11 Jan 2017 19:50:31 -0600
- To: David MacDonald <david100@sympatico.ca>
- Cc: Laura Carlson <laura.lee.carlson@gmail.com>, Wayne Dick <wayneedick@gmail.com>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAKdCpxw09KQ1HAK+4nHs1ZwWBy31tSxPEVZR_SY=OYtxo1u-+w@mail.gmail.com>
Hi David, > There is an exception for mobile devices. (1) The user-agent provides no means of re-flowing content. Except, I've seen content re-flow on mobile devices, as long as the page is not locked down, so I don't think that would pass muster (IMHO). JF On Wed, Jan 11, 2017 at 4:49 PM, David MacDonald <david100@sympatico.ca> wrote: > >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 <(613)%20235-4902> > > LinkedIn > <http://www.linkedin.com/in/davidmacdonald100> > > twitter.com/davidmacd > > GitHub <https://github.com/DavidMacDonald> > > www.Can-Adapt.com <http://www.can-adapt.com/> > > > > * Adapting the web to all users* > * Including those with disabilities* > > If you are not the intended recipient, please review our privacy policy > <http://www.davidmacd.com/disclaimer.html> > > On Wed, Jan 11, 2017 at 5: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-tex >>> t/#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/Publ >>> ications_files/uais2015.pdf >>> >> >>>>>>>>> <http://www.luzrello.com/Publ >>> ications_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 >> > > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion
Received on Thursday, 12 January 2017 01:51:10 UTC