- From: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Date: Wed, 11 Jan 2017 17:25:12 +0000
- To: WCAG <w3c-wai-gl@w3.org>
- Message-ID: <DM5PR03MB2780CCA47C6B9D89F89AA4289B660@DM5PR03MB2780.namprd03.prod.outlook.com>
Ø 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?
My concern is with REM as a relative measure. You could squeeze more in 25rem with a smaller default font-size – say font-size:50%. And sites with larger default font size (font-size:125%” would get less text 25rem. Am I missing something?
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)
Vis Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | LinkedIn<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
See you at CSUN in March!<http://info.ssbbartgroup.com/CSUN-2017_Sessions.html>
From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Wednesday, January 11, 2017 12:08 PM
To: John Foliot; Makoto UEKI; Shwetank@barrierbreak.com
Cc: Patrick H. Lauke; WCAG
Subject: Re: Length of line
> 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
<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 11:24 AM, John Foliot <john.foliot@deque.com<mailto: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<mailto: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<mailto: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<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>
On Wed, Jan 11, 2017 at 9:21 AM, Patrick H. Lauke <redux@splintered.co.uk<mailto: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<tel:613.235.4902>
LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>
twitter.com/davidmacd<http://twitter.com/davidmacd> <http://twitter.com/davidmacd>
GitHub <https://github.com/DavidMacDonald>
www.Can-Adapt.com<http://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> <mailto: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>
<mailto: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
<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
<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 #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>
<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>
<mailto:david100@sympatico.ca<mailto:david100@sympatico.ca>>>
*Cc:* WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org> <mailto: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_words.html
<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> <mailto: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.235.4902> <tel:(613)%20235-4902>____
LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>____
twitter.com/davidmacd<http://twitter.com/davidmacd> <http://twitter.com/davidmacd>____
GitHub <https://github.com/DavidMacDonald>____
www.Can-Adapt.com<http://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> <mailto:john.foliot@deque.com<mailto:john.foliot@deque.com>>____
__ __
Advancing the mission of digital accessibility and inclusion____
--
Patrick H. Lauke
www.splintered.co.uk<http://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<mailto:john.foliot@deque.com>
Advancing the mission of digital accessibility and inclusion
--
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
Received on Wednesday, 11 January 2017 17:25:50 UTC