- From: John Foliot <john.foliot@deque.com>
- Date: Wed, 11 Jan 2017 10:24:41 -0600
- To: David MacDonald <david100@sympatico.ca>
- Cc: "Patrick H. Lauke" <redux@splintered.co.uk>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAKdCpxwJaV9xXF9rsxYjb1iQHVGXpiUNBSVksZRAfk4osb8rSg@mail.gmail.com>
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
Received on Wednesday, 11 January 2017 16:25:17 UTC