- From: Wayne Dick <wayneedick@gmail.com>
- Date: Wed, 11 Jan 2017 11:33:10 -0800
- To: David MacDonald <david100@sympatico.ca>
- Cc: John Foliot <john.foliot@deque.com>, Makoto UEKI <ueki@infoaxia.com>, Shwetank Dixit <Shwetank@barrierbreak.com>, "Patrick H. Lauke" <redux@splintered.co.uk>, WCAG <w3c-wai-gl@w3.org>
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 > >
Received on Wednesday, 11 January 2017 19:34:25 UTC