- From: Katie Haritos-Shea GMAIL <ryladog@gmail.com>
- Date: Wed, 11 Jan 2017 11:14:15 -0500
- To: "'Jonathan Avila'" <jon.avila@ssbbartgroup.com>, "'WCAG'" <w3c-wai-gl@w3.org>
- Message-ID: <2afa01d26c25$c1a65960$44f30c20$@gmail.com>
+1 to Jon Avila
* katie *
Katie Haritos-Shea
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)
Cell: 703-371-5545 | <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA | <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 | <https://twitter.com/Ryladog> @ryladog
NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.
From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
Sent: Wednesday, January 11, 2017 11:06 AM
To: WCAG <w3c-wai-gl@w3.org>
Subject: RE: Length of line
* 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.
We have precedent to have different requirements for different languages in SC 1.4.8. I’d encourage the team to scope the SC in a way that it can be met with exceptions rather than throwing out an SC just because as it’s currently written won’t work everywhere. We have a large-scale text exception for SC 1.4.3 and SC 4.1.1 Parsing is only applicable to markup languages.
* I am especially concerned about the possibility of significantly increased ‘hyphenation’ that this could result in (which
I certainly don’t want a lot of hyphenation but wrapping words without hyphenation is a CSS option. So perhaps that could be enabled when the content is reflowed. I use several different browsers and I don’t generally see a lot of hyphenation on responsive sites with lines that have less characters.
Jonathan
From: Shwetank Dixit [mailto:shwetank@barrierbreak.com]
Sent: Wednesday, January 11, 2017 8:13 AM
To: David MacDonald; John Foliot; Michael Pluke
Cc: WCAG
Subject: Re: Length of line
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-contrast-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)) 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/userfiles/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 <https://github.com/w3c/wcag21/issues/51> #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]
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), 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_words.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-contrast-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
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
CanAdapt Solutions Inc.
Tel: 613.235.4902 <tel:(613)%20235-4902>
LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
twitter.com/davidmacd <http://twitter.com/davidmacd>
<https://github.com/DavidMacDonald> GitHub
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.
<mailto:john.foliot@deque.com> john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
<http://pixels.canarymail.io/tracking/A97B6B32-3BC8-432B-A2DF-8FDAF8788CEC.png>
Received on Wednesday, 11 January 2017 16:15:03 UTC