- From: David MacDonald <david100@sympatico.ca>
- Date: Thu, 12 Jan 2017 14:34:41 -0500
- To: John Foliot <john.foliot@deque.com>
- Cc: Jim Allan <jimallan@tsbvi.edu>, Wayne Dick <wayneedick@gmail.com>, 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: <CAAdDpDashgyeRvGf_dMW0dKdAN-98TitR935+uyZAscZGqKhkA@mail.gmail.com>
#57 has been retired by the LVTF, Issue #58 will address the use case. 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 Thu, Jan 12, 2017 at 2:02 PM, John Foliot <john.foliot@deque.com> wrote: > @Jim - thanks for the tests. They further confirm what research I managed > to do that CSS hyphenation *IS* pretty well supported today, and so claims > to the contrary (which have surfaced on this thread) have been overcome by > time (for the most part). This is good! (While still wishing that Chrome > supported "auto") > > Alastair wrote: > > The intent is that the author allows for that (primarily ordering and > CSS methods used), not that they provide the mechanism. > > If that is the case, then a significant re-write is likely in order, as > that is not at all clear from the current draft text > , which states that (for the author) a mechanism be provided > (actually, "a mechanism is available") > - which suggests to me that it is the responsibility of the author to > provide that mechanism. If that is not the case, who's responsibility is > it? And if it is not the responsibility of the Web Content author, then is > this really a WCAG requirement (as opposed to an Accessibility support > requirement)? > > Cheers! > > JF > > On Thu, Jan 12, 2017 at 11:07 AM, Jim Allan <jimallan@tsbvi.edu> wrote: > >> John, >> did a bit of research on css hyphens >> see http://w3c.github.io/low-vision-a11y-tf/hyphenation-test.htm for >> some results. >> just declaring hyphens: auto - does a pretty good job (except for >> chrome). >> if you add ­ and hypens: manual they work always. Tho adding soft >> hypens is a bit of work for the author. >> >> On Wed, Jan 11, 2017 at 2:07 PM, 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-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/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-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 <(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 >>> >> >> >> >> -- >> Jim Allan, Accessibility Coordinator >> Texas School for the Blind and Visually Impaired >> 1100 W. 45th St., Austin, Texas 78756 >> voice 512.206.9315 <(512)%20206-9315> fax: 512.206.9264 >> <(512)%20206-9264> http://www.tsbvi.edu/ >> "We shape our tools and thereafter our tools shape us." McLuhan, 1964 >> > > > > -- > 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 19:35:19 UTC