- From: John Foliot <john.foliot@deque.com>
- Date: Wed, 11 Jan 2017 11:28:15 -0600
- To: David MacDonald <david100@sympatico.ca>
- 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: <CAKdCpxxKWZfoJqaGjhtm9kXrEzKh-85+1Z505BdftcE8ZuJKTQ@mail.gmail.com>
> 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/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 17:28:52 UTC