- From: David MacDonald <david100@sympatico.ca>
- Date: Wed, 11 Jan 2017 13:34:30 -0500
- To: John Foliot <john.foliot@deque.com>
- Cc: Makoto UEKI <ueki@infoaxia.com>, Shwetank Dixit <Shwetank@barrierbreak.com>, "Patrick H. Lauke" <redux@splintered.co.uk>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAAdDpDYXiZBb_mgu=uuSJOLsB2BEsEanomQJRBcxzVC3H0t8AQ@mail.gmail.com>
I think I've addressed the comments the best I can. I'd like to propose that we go with the current language for our first draft (unless Makoto, or Shwetank offer significantly new information). We can add "At Risk" if there are still those who feel it does not address their concerns. We have 62 more SCs to edit and I'd like to move on to the next one. ============ For all visual presentation of text, a mechanism is available to adjust the line length to a maximum of 50 characters without increasing the font in the user agent, and without requiring two-dimensional scrolling, except where: (1) The user-agent provides no means of re-flowing content. (2) The spatial layout of text is essential to its use. (3) A line has a word that is longer than 50 characters. ============ 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 1:21 PM, David MacDonald <david100@sympatico.ca> wrote: > CSS hyphenation (when it is supported) offers the author control, which is > fine... > > 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 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 >>> >>> >>> >>> *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 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 >>>> <https://snook.ca/archives/html_and_css/font-size-with-rem>). >>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> *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 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-con >>>>>>>>> trast-visual-presentation.html> >>>>>>>>> will cause significant difficulties for many people with >>>>>>>>> dyslexia.____ >>>>>>>>> >>>>>>>>> __ __ >>>>>>>>> >>>>>>>>> EA has quoted several research-based sources that offer >>>>>>>>> realistic >>>>>>>>> line-length proposals. From reading the extract from 'Dyslexia >>>>>>>>> in >>>>>>>>> the Digital Age' that EA linked-to (http://tinyurl.com/jra7hk3) >>>>>>>>> I >>>>>>>>> don’t think that it gives very strong evidence that 55 >>>>>>>>> characters >>>>>>>>> is the only choice. I’m a great fan of the realistic proposals >>>>>>>>> that Luz Rello makes (based on her research >>>>>>>>> (http://www.luzrello.com/Publications_files/uais2015.pdf >>>>>>>>> <http://www.luzrello.com/Publications_files/uais2015.pdf>)) >>>>>>>>> so I >>>>>>>>> have confidence for specifying line lengths in the 44-66 range >>>>>>>>> (although it was non-dyslexic people who benefitted most from >>>>>>>>> 44 >>>>>>>>> character columns). The British Dyslexia Style Guide >>>>>>>>> http://www.bdadyslexia.org.uk/common/ckeditor/filemanager/us >>>>>>>>> erfiles/About_Us/policies/Dyslexia_Style_Guide.pdf >>>>>>>>> <http://www.bdadyslexia.org.uk/common/ckeditor/filemanager/u >>>>>>>>> serfiles/About_Us/policies/Dyslexia_Style_Guide.pdf> >>>>>>>>> recommends that “Lines should not be too long: 60 to70 >>>>>>>>> characters.”____ >>>>>>>>> >>>>>>>>> __ __ >>>>>>>>> >>>>>>>>> *Conclusion*: Based on all of the above I think that:____ >>>>>>>>> >>>>>>>>> * To benefit LV users we should avoid having SCs that give a >>>>>>>>> line length based on the number of characters;____ >>>>>>>>> * To benefit people with dyslexia (and also the general >>>>>>>>> population) the 1.4.8-based 80 character maximum in >>>>>>>>> proposal #51 <https://github.com/w3c/wcag21/issues/51> >>>>>>>>> should >>>>>>>>> be reduced to a figure no greater than 70 characters (and >>>>>>>>> probably no less than 60).____ >>>>>>>>> >>>>>>>>> __ __ >>>>>>>>> >>>>>>>>> Mike____ >>>>>>>>> >>>>>>>>> __ __ >>>>>>>>> >>>>>>>>> *From:*John Foliot [mailto:john.foliot@deque.com >>>>>>>>> <mailto:john.foliot@deque.com>] >>>>>>>>> *Sent:* 10 January 2017 23:56 >>>>>>>>> *To:* David MacDonald <david100@sympatico.ca >>>>>>>>> <mailto:david100@sympatico.ca>> >>>>>>>>> *Cc:* WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>> >>>>>>>>> *Subject:* Re: Length of line____ >>>>>>>>> >>>>>>>>> __ __ >>>>>>>>> >>>>>>>>> TL;DR - Using 'character' as a unit of measurement is extremely >>>>>>>>> problematic, and I do not support it's use here. ____ >>>>>>>>> >>>>>>>>> __ __ >>>>>>>>> >>>>>>>>> **************____ >>>>>>>>> >>>>>>>>> __ __ >>>>>>>>> >>>>>>>>> Some thoughts after today's call.____ >>>>>>>>> >>>>>>>>> __ __ >>>>>>>>> >>>>>>>>> I personally have significant concerns over prescribing a fixed >>>>>>>>> number of characters, especially such a low number, as a unit >>>>>>>>> of >>>>>>>>> measurement. ____ >>>>>>>>> >>>>>>>>> __ __ >>>>>>>>> >>>>>>>>> *Internationalization:*____ >>>>>>>>> >>>>>>>>> When we factor in both Internationalization and languages other >>>>>>>>> than English, we will quickly arrive at a point where the >>>>>>>>> number >>>>>>>>> 25 is smaller than numerous words in different languages >>>>>>>>> (https://en.wikipedia.org/wiki/Longest_words >>>>>>>>> <https://en.wikipedia.org/wiki/Longest_words>), which will >>>>>>>>> then >>>>>>>>> require word hyphenization (most probably supplied by the >>>>>>>>> content >>>>>>>>> author, until such time as AI can do that job seamlessly). This >>>>>>>>> then suggests to me that we will start to see 'forced' >>>>>>>>> line-breaks >>>>>>>>> again (using the presentational <br>), which could have a >>>>>>>>> significant impact on screen flow in RWD (Responsive) layouts >>>>>>>>> (i.e. the cure being worse the the symptom).____ >>>>>>>>> >>>>>>>>> __ __ >>>>>>>>> >>>>>>>>> __ __ >>>>>>>>> >>>>>>>>> *Font-size and font-face choices:*____ >>>>>>>>> >>>>>>>>> Equally, as mentioned on the call, another factor in measuring >>>>>>>>> this, related to horizontal scrolling, is font-size. For those >>>>>>>>> of >>>>>>>>> you using HTML-rich mail clients, and using a 25 >>>>>>>>> character-count >>>>>>>>> example taken from >>>>>>>>> http://www.litscape.com/words/length/25_letters/25_letter_wo >>>>>>>>> rds.html >>>>>>>>> <http://www.litscape.com/words/length/25_letters/25_letter_w >>>>>>>>> ords.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-con >>>>>>>>> trast-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/disc >>>>>>>>> laimer.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 18:35:06 UTC