- From: John Foliot <john.foliot@deque.com>
- Date: Wed, 11 Jan 2017 08:59:49 -0600
- To: David MacDonald <david100@sympatico.ca>
- Cc: "Patrick H. Lauke" <redux@splintered.co.uk>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAKdCpxxN+=GP3z92D3k2L-c0-M4t+AacnrCRQFCK1wvgSAbyjw@mail.gmail.com>
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
Received on Wednesday, 11 January 2017 15:00:25 UTC