"at least" should be "at most" in WCAG 2.1 SC 1.4.12

jrpool commented 5 years ago

"at least" occurs 30 times on https://www.w3.org/TR/WCAG21/. It means what it says in 26 of those cases, but it means the opposite in the 4 cases where it occurs in SC 1.4.12.

For example, if the user sets line spacing to 1.3 times the font size, no loss of content or functionality should occur, but 1.3 is not at least 1.5. Conversely, if the user sets line spacing to 50 times the font size, content creators should not be required to protect against loss of content or functionality, although 50 is at least 1.5.

More colloquially, "at least" in these cases could be changed to "up to", rather than "at most".

awkawk commented 5 years ago

I see your point, but from a testing perspective, setting the line spacing to 1.3 wouldn't allow you to make a conformance claim because you need to verify that the content isn't lost when you set it to 1.5 or greater. If you set the paragraph spacing to at least 1.5, including 2, 9 or 40 and no loss occurs then you can.

patrickhlauke commented 5 years ago

changing it to "up to" could work, however. for testing, you'd test the extreme (1.5) - or, if you've got the time/inclination, all values leading up to 1.5 (to really verify there's no quirky thing happening).

having said that, the reading here (which is, i believe, the one that was intended) is more along the lines of "you can at least increase the line spacing to 1.5. it can break apart after that, but at least you got to 1.5..."

jrpool commented 5 years ago

Thanks for your thinking about this. It is not felicitous that we are in doubt about whether a word in a success criterion means what it says or means the opposite of that; or whether it modifies one or another word in a sentence. Clarity calls for a reformulation. @awkawk is correct that a test of 1.3 line spacing wouldn't permit a conformance claim. But a test of 40 line spacing wouldn't either. Neither test proves what the SC intends (at least I believe it intends) to require, namely that every line spacing from 1 to 1.5 is lossless and fully functional. The SC could be reformulated to say that, so we all understand it.

mraccess77 commented 5 years ago

On a related note SC 1.4.4 resize text says "up to 200%". Many of us read that SC to require increments between the default size and 200% of the default size although practically speaking that would be cumbersome to test.

jrpool commented 5 years ago

Yes, that's a good indication of the intent. While testing every increment might be expensive, testing all possible conditions is usually expensive, so we sample. But the SC serves as notice of what a legitimate complaint could report. Here I think we want the public to understand that a user who sets a line height of 1.4 and loses content has a basis for complaint, and a user who sets a line height of 1.6 and loses content has no basis for complaint. I'd say the SC as formulated does not make that clear.

alastc commented 5 years ago

I think using "at least" is important and correct, the intent is similar to the contrast ones: "a contrast ratio of at least 3:1 against adjacent color".

Anything over 3:1 is good (passing), under that fails.

For the text-size one that is intended to work up to 200%, including the increments between default and 200%.

I disagree that this SC should use 'up to', the intent is that people test the 'min' value and allow for more if they can.

patrickhlauke commented 5 years ago

For the text-size one that is intended to work up to 200%, including the increments between default and 200%.

for the spacing one, i assume it's intended to work up to the normative sizes at least, including all the increments in between? or are you honestly saying that a site that completely breaks apart in anything other than the default and the spacing values defined normatively (the increments in between) would be fine?

expanding this with some actual examples...say a site defines a layout that uses a line-height of 1. normatively, it needs to allow "at least 1.5". say the site completely breaks if the value is set to anything between >1 and <1.5, but then at 1.5 it works again. surely that's not the intent here?

(and the answer to that would determine if "up to" is or isn't appropriate)

patrickhlauke commented 5 years ago

and to clarify, in the case of text size, it's "up to 200%" because it rightly posits that some users will want to increment the text size by 110%, 120% or similar (user agent allowing). similarly, not all users will immediately want to change, say, line-height to 1.5, but perhaps just inch it up a bit (assuming the default is too low) to 1.3, 1.4, etc. [edit: and that's also due to the fact that not all fonts are the same, and with some fonts - depending on their actual x-height etc - a line-height of less than 1.5 will have the same visual spacing as 1.5 on other fonts; it's "subjective" or rather highly dependent on the font, rather than something like contrast ratio which is fairly cut and dry either you hit the lowest limit or you don't)

alastc commented 5 years ago

say the site completely breaks if the value is set to anything between >1 and <1.5

How would that work? I'm struggling to see a way you could create something that would work at 1 & 1.5, but not in between.

patrickhlauke commented 5 years ago

How would that work?

the how is not important i'd say. there's a variety of ways in which (either on purpose, or by accident) things may break apart except when you're hitting just the right values (e.g. could be some stupid JavaScript that detects if the user has set just that particular value of 1.5 and adapts the layout to work, but no other value triggers it...would be a nice "let's pass the normative wording, and not the spirit, of this SC"). And regardless, the intent surely is that users can increase spacing from defaults up to those values, no? And if so, isn't that expressed better with "up to"?

jrpool commented 5 years ago

The formulation of the SC seems to encourage confusion as to whether it specifies tests or functionalities. The "by setting" clause is responsible for this confusion, and it isn't even grammatical, because per standard English parsing rules the implied subject of "setting" is "loss". To make it grammatical and clear, it would be possible to change "by setting all of the following and by changing" to "if the user sets some or all of the following and changes", together with the replacement of "at least" with "up to" (or "at most"). Even that would leave some ambiguity, because of the failure to specify the lower bounds of the ranges. An even better formulation would do that, for example changing "Line height (line spacing) to at least 1.5 times the font size" to "Line height (line spacing) to any value from 1 to 1.5 times the font size".

jake-abma commented 5 years ago

Is there a conclusions for this one?

seems a critical part to say we demand a bandwidth of (example) "between 0.5 and 1.5" OR "from 1.5 and higher"

lauracarlson commented 5 years ago

@alastc commented on Mar 19

I think using "at least" is important and correct, the intent is similar to the contrast ones: "a contrast ratio of at least 3:1 against adjacent color".

Anything over 3:1 is good (passing), under that fails.

For the text-size one that is intended to work up to 200%, including the increments between default and 200%.

I disagree that this SC should use 'up to', the intent is that people test the 'min' value and allow for more if they can.

I agree with Alastair. Anything over the metrics pass, anything under fails. The phrase "at least" is important and correct. This is what the LVTF meant when we wrote the SC.

alastc commented 5 years ago

To me this is essentially about the English interpretation. From looking at how "at least" is used elsewhere in WCAG 2.1:

Most cases are "at least one of the following is true", and then has a specific list of items. The meaning is that one of those things must be true to pass. Not equivalent to 1.4.12.
In time based media it is used as "then text alternatives at least provide descriptive identification", not equivalent to 1.4.12.
Contrast is "text and images of text has a contrast ratio of at least 4.5:1". Directly equivalent as we are looking for it to have that as a minimum level, anything that meets "at least" that level is enough.
1.4.8 Visual Presentation has "Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing", which is equivalent to 1.4.12.
2.2.1 Timing Adjustable has "The user is warned before time expires and given at least 20 seconds to extend the time limit", directly equivalent here.
2.5.5 Target Size has "The size of the target for pointer inputs is at least 44 by 44 CSS pixels", directly equivalent.

I get that there is a logical issue with it not technically having to work between the authored value and the test value.

However, the idea was that those values are a baseline we want to encourage authors to surpass, not a ceiling to build to.

If we made a normative change I'd rather adjust the text to cover the change, e.g.

no loss of content or functionality occurs by increasing the values of the following settings (only):

However, that has it's own logical problems if the authored value is greater than the guideline value!

WayneEDick commented 5 years ago

We have 2.2 to change some of the normative wording. I would propose "at most". In 1.4.12, the inline spacing (Letter and Word) is generous. When we were formulating 1.4.12 Alastair proposed a 20% cap on inline increase of space. I agree with that. That is text length can increase at most 1.2 times text length. That really seems reasonable.

I think language like ... letter-spacing at most 0.12 times font-size, ... word spacing at most 0.16 times... with the total increase in text width being at most 1.2 times the width of the original text would be good.

This is a hard target that testers and users can measure. In the research we cited by A study of the effect of letter spacing on the reading speed of young readers with low vision (PDF) http://journals.sagepub.com/doi/pdf/10.1177/0264619607075995 - Eve Mcleish, her response curve increased until the values we used, 0.12, where it flattened. That means that most users benefit for values less than 0.12.

All users can still benefit with less inline spacing. Ciel of 1.2 times the text length enables the user to vary many parameters such as letter spacing, word spacing. Since font enlargement is primarily achieved by zoom, a person who needs 300% enlargement could zoom to 400% and reduce font size to 80%. That would be a little larger than 300%. This would allow more space for inline spacing. Suppose your inline spacing increased the space of text by 1.5 times the original. At 80% of font size, we get a total of 1.2 increase over the original.

So that is my 2 cents: use at most and don't let the total exceed 1.2 times the original width.

The line and paragraph spacing should be "at most", but there should be no leeway. This is the place most sites break down because of old coding techniques. Flex and grids fix all of this problem.

Best Wayne

On Fri, Jul 19, 2019 at 7:02 AM Alastair Campbell notifications@github.com wrote:

To me this is essentially about the English interpretation. From looking at how "at least" is used elsewhere in WCAG 2.1:

Most cases are "at least one of the following is true", and then has a specific list of items. The meaning is that one of those things must be true to pass. Not equivalent to 1.4.12.

In time based media it is used as "then text alternatives at least provide descriptive identification", not equivalent to 1.4.12.

Contrast is "text and images of text has a contrast ratio of at least 4.5:1". Directly equivalent as we are looking for it to have that as a minimum level, anything that meets "at least" that level is enough.

1.4.8 Visual Presentation has "Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing", which is equivalent to 1.4.12.

2.2.1 Timing Adjustable has "The user is warned before time expires and given at least 20 seconds to extend the time limit", directly equivalent here.

2.5.5 Target Size has "The size of the target for pointer inputs is at least 44 by 44 CSS pixels", directly equivalent.

I get that there is a logical issue with it not technically having to work between the authored value and the test value.

However, the idea was that those values are a baseline we want to encourage authors to surpass, not a ceiling to build to.

If we made a normative change I'd rather adjust the text to cover the change, e.g.

no loss of content or functionality occurs by increasing the values of the following settings (only):

However, that has it's own logical problems if the authored value is greater than the guideline value!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/635?email_source=notifications&email_token=AB6Q4F3BDLZ7JZYNUBS7IC3QAHCOVA5CNFSM4GY7OLA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2LWYRY#issuecomment-513240135, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6Q4F6JVQBFTHVSQ7GKSBLQAHCOVANCNFSM4GY7OLAQ .

patrickhlauke commented 5 years ago

From looking at how "at least" is used elsewhere in WCAG 2.1

in those examples, i'd argue that "at least" is probably correct because it defines an absolute minimum below which content can be unusable/problematic. Whereas for line spacing and such, it's much more of a sliding scale, and users may need to nudge things from, say, 1 to 1.5 times the line spacing / leading.

However, I understand the concern that "up to" may give the impression that it's a hard ceiling value.

So really, we have the tension where ideally we'd want to say that authors should simply allow any arbitrary value of line height, but need to provide some reasonable and easily testable value while indicating that authors are strongly encouraged to exceed it, but also to ensure that in-between values between 1 / the starting value and 1.5 work. Can this be resolved purely in understanding perhaps, with a paragraph that kind of sums this up? Or, abusing the English language a bit, "up to at least 1.5" or similar (again, complemented with some understanding explanation)? That then makes the 1-1.5 range normatively required to be working, but retains the "at least" soft nudge to go beyond...

Myndex commented 5 years ago

@alastc Hi Alastair, I was responding to your email but thought it more useful to post here.

I had to read the SC 1.4.12 a couple times before realizing what it was getting at. (In fact was about to send an email that discussed the visual perception of letter-spacing and why it isn’t robustly testable, before I read the understanding doc and realized this is just about user agent overrides!!)

The SC is unclear in this regard. Nowhere in the SC does it state that this is about the author making a provision for the user to override these CSS properties, and I think mentioning that in the SC would go a long way toward clarity.

As an Aside:

One thing worth mentioning is that the importance of letter-spacing on reading speed is directly affected by font-size, contrast, and the use context (i.e. headline vs body text). And there are certainly cases where the author may be using a larger spacing than those indicated below, which may be needed for a particular font or other design consideration — is it a fail if the author uses !important and defines one of these properties at, or larger than, what the SC specifies?

Also, does this SC apply to all text including headlines, subheads, and “non-content” text (i.e. copyrights, disclaimers, etc.)? Or just body/block text?

Mention Overrides in SC?

As a matter of clarity, may I suggest making the user-override aspect more clear, and clarifying that any given setting is not also a “maximum limit” ? (Something like this, changes in bold):

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by user overrides of all of the following and by changing no other style property:

Line height (line spacing) user override up to 1.5 times the font size and optionally more;
Paragraph spacing user override up to 2 times the font size and optionally more;
Letter spacing (tracking) user override up to 0.12 times the font size and optionally more;
Word spacing user override up to 0.16 times the font size and optionally more.

I think this clarifies purpose, and also does not create an artificial ceiling which can be inappropriate in a number of use cases.

Tangential Thoughts on `letter-spacing`

Not directly related to this issue, but as this thread has some related discussion on spacing:

As a generalization, smaller text (such as a column of body text) benefits from greater letter spacing, whereas headlines and other large text often benefit from smaller letter spacing. As such, optimum and/or aesthetically desirable letter spacing varies depending on the font size, context, and contrast.

Part of this has to do with the visual-span, which is the number of characters than can be viewed without moving the eye. Along with this is the perception of crowding.

One thing with current CSS "letter-spacing” is it takes a length unit which can be specified as 0.12em (good only when it is relative to the current font element) or 2px (BAD!) or 2vw (EVEN WORSE)! YIKES!

Setting letter-spacing based on a length that is not directly tied to the font size should avoided as a design fail IMO. On the CSS spec, while this might not be our “department” IMO letter-spacing should have been specified as a unit-less measure the way line-height is. That’s how tracking is defined in every design or typesetting application I can think of. Perhaps in the future, a CSS "tracking:" parameter that is unit-less, inherited, and relative to the current font could solve some of this.

Padding

Also as I've mentioned before, PADDING can in many cases have a substantial effect on readability due to surround effects and local adaptation. If a user overrides to add padding, they could cause content/function problems just as font size or spacing can (a consideration for the future).

References:

Recent research specifically regarding letter spacing: https://jov.arvojournals.org/article.aspx?articleid=2122052

On font SIZE: https://jov.arvojournals.org/article.aspx?articleid=2191906

WayneEDick commented 5 years ago

"up to" is really best. The adjustment has no effect for larger spacing inline. In fact, if it gets much bigger increased letter spacing has a negative effect.

Best, Wayne

On Wed, Jul 24, 2019 at 11:47 AM Andrew Somers notifications@github.com wrote:

@alastc https://github.com/alastc Hi Alastair, I was responding to your email but thought it more useful to post here.

I had to read the SC 1.4.12 a couple times before realizing what it was getting at. (In fact was about to send an email that discussed the visual perception of letter-spacing and why it isn’t robustly testable, before I read the understanding doc and realized this is just about user agent overrides!!)

The SC is unclear in this regard. Nowhere in the SC does it state that this is about the author making a provision for the user to override these CSS properties, and I think mentioning that in the SC would go a long way toward clarity. As an Aside:

One thing worth mentioning is that the importance of letter-spacing on reading speed is directly affected by font-size, contrast, and the use context (i.e. headline vs body text). And there are certainly cases where the author may be using a larger spacing than those indicated below, which may be needed for a particular font or other design consideration — is it a fail if the author uses !important and defines one of these properties at, or larger than, what the SC specifies?

Also, does this SC apply to all text including headlines, subheads, and “non-content” text (i.e. copyrights, disclaimers, etc.)? Or just body/block text? Mention Overrides in SC?

As a matter of clarity, may I suggest making the user-override aspect more clear, and clarifying that any given setting is not also a “maximum limit” ? (Something like this, changes in bold):

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by user overrides of all of the following and by changing no other style property:

Line height (line spacing) user override up to 1.5 times the font size and optionally more;

Paragraph spacing user override up to 2 times the font size and optionally more;

Letter spacing (tracking) user override up to 0.12 times the font size and optionally more;

Word spacing user override up to 0.16 times the font size and optionally more.

I think this clarifies purpose, and also does not create an artificial ceiling which can be inappropriate in a number of use cases. Tangential Thoughts on letter-spacing

Not directly related to this issue, but as this thread has some related discussion on spacing:

As a generalization, smaller text (such as a column of body text) benefits from greater letter spacing, whereas headlines and other large text often benefit from smaller letter spacing. As such, optimum and/or aesthetically desirable letter spacing varies depending on the font size, context, and contrast.

Part of this has to do with the visual-span, which is the number of characters than can be viewed without moving the eye. Along with this is the perception of crowding.

One thing with current CSS "letter-spacing” is it takes a length unit which can be specified as 0.12em (good only when it is relative to the current font element) or 2px (BAD!) or 2vw (EVEN WORSE)! YIKES!

Setting letter-spacing based on a length that is not directly tied to the font size should avoided as a design fail IMO. On the CSS spec, while this might not be our “department” IMO letter-spacing should have been specified as a unit-less measure the way line-height is. That’s how tracking is defined in every design or typesetting application I can think of. Perhaps in the future, a CSS "tracking:" parameter that is unit-less, inherited, and relative to the current font could solve some of this. Padding

Also as I've mentioned before, PADDING can in many cases have a substantial effect on readability due to surround effects and local adaptation. If a user overrides to add padding, they could cause content/function problems just as font size or spacing can (a consideration for the future). References:

Recent research specifically regarding letter spacing: https://jov.arvojournals.org/article.aspx?articleid=2122052

On font SIZE: https://jov.arvojournals.org/article.aspx?articleid=2191906

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/635?email_source=notifications&email_token=AB6Q4F3CMWACQB5QRLCEAC3QBCPVJA5CNFSM4GY7OLA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2XIKXA#issuecomment-514753884, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6Q4F2SIHCJ3A5BU2LWWCDQBCPVJANCNFSM4GY7OLAQ .

mraccess77 commented 5 years ago

I agree with Wayne that too much space is a negative for people with low vision -- I can't speak for other disaibilities. So I would not want to add the phrase ""optimal more"".

Myndex commented 5 years ago

"up to" is really best. The adjustment has no effect for larger spacing inline. In fact, if it gets much bigger increased letter spacing has a negative effect. Best, Wayne …

I agree with Wayne that too much space is a negative for people with low vision -- I can't speak for other disaibilities. So I would not want to add the phrase ""optimal more"".

Hi @WayneEDick Hi @mraccess77

Since this is not a spec of what a designer/author should be using, but rather a spec of how much flexibility a USER has in overriding, the "optionally more" tells a designer that they don't need to crimp or lock at a particular size/spacing. It also tells a designer that they don't need to keep their own non-overridden design within that arbitrary defined range, and such a restriction is inappropriate in the general sense for reasons I detailed in the above post.

It is important to point out that the CSS letter-spacing property does not set letter-spacing. It only adjusts whatever letter spacing is built into the font. This is true of all four parameters in this SC.

"Best" letter, word, and line spacing are dependent on font size, font design (aspect, weight, serif, etc), contrast, and context of use (headline or block text, etc).

The driving factors are visual-span and spatial frequency. Increasing letter-spacing on very small text is helpful because it decreases spatial frequency thus improving contrast and reducing perceived crowding within the visual-span. Decreasing tracking on very large text can be helpful because it can in some cases increase contrast, but also helps keep the visual-span at a range of most letters visible.

To illustrate this, the well known plot of Michelson Contrast Modulation, spatial frequency vs perceived contrast:

As the spacial frequency increases toward the right, perceived contrast decreases rapidly. Interestingly, as spacial frequency decreases below the peak, contrast also decreases!

To the right, we see gratings that approximate block/body text with a small font. Toward the center, the gratings more approximate a large bold headline. It should be clear then that a particular optimum spacing relative to font size and weight is not consistent but vary considerably depending on the relationship to other factors.

This is also discussed in this paper.

And yes, "too much" space can cause a decrease in reading speed — but again, it is codependent and interrelated to other properties. Like everything in human perception, it's nonlinear and affected by multiple factors.

It is trivial to find use cases where a letter-spacing more than 0.12em is not only acceptable but helpful. Within THIS SC, it is inappropriate to state that 0.12em should be a maximum letter-spacing. Among other things, because the CSS letter-spacing property only modifies the font's default spacing, any "standard" using such an arbitrary value is technically meaningless. CSS letter-spacing does not specify spacing, only how much spacing is to be changed.

WayneEDick commented 5 years ago

If you read the vision science on crowding most will claim that there is none or a negative effect resulting from increases in letter spacing. A careful reading of this literature reveals that all of these studies start with spacing greater than the 0.12 we suggest*. If you look at, A study of the effect of letter spacing on the reading speed of young readers with low vision Eve McLeish https://journals.sagepub.com/doi/abs/10.1177/0264619607075995, her graphs the flatten at around this point 0.12em. (Note: She uses a different scale. We converted.) So I think "up to" is pretty well grounded in vision science.

There is a gap. I don't know of another study that started with anything less than 0.5. Mc Leash is the only one below 0.5.

On Wed, Jul 24, 2019 at 3:12 PM Andrew Somers notifications@github.com wrote:

"up to" is really best. The adjustment has no effect for larger spacing inline. In fact, if it gets much bigger increased letter spacing has a negative effect. Best, Wayne … <#m2239106345731555159>

I agree with Wayne that too much space is a negative for people with low vision -- I can't speak for other disaibilities. So I would not want to add the phrase ""optimal more"".

Hi @WayneEDick https://github.com/WayneEDick Hi @mraccess77 https://github.com/mraccess77

Since this is not a spec of what a designer/author should be using, but rather a spec of how much flexibility a USER has in overriding, the "optionally more" tells a designer that they don't need to crimp or lock at a particular size/spacing. It also tells a designer that they don't need to keep their own non-overridden design within that arbitrary defined range, and such a restriction is inappropriate in the general sense for reasons I detailed in the above post.

It is important to point out that the CSS letter-spacing property does not set letter-spacing. It only adjusts whatever letter spacing is built into the font. This is true of all four parameters in this SC.

"Best" letter, word, and line spacing are dependent on font size, font design (aspect, weight, serif, etc), contrast, and context of use (headline or block text, etc).

The driving factors are visual-span and spatial frequency. Increasing letter-spacing on very small text is helpful because it decreases spatial frequency thus improving contrast and reducing perceived crowding within the visual-span. Decreasing tracking on very large text can be helpful because it can in some cases increase contrast, but also helps keep the visual-span at a range of most letters visible.

To illustrate this, the well known plot of Michelson Contrast Modulation, spatial frequency vs perceived contrast:

[image: image] https://user-images.githubusercontent.com/42009457/61828305-33ec8780-ae1b-11e9-9134-94fd41da1d3c.png [image: image] https://user-images.githubusercontent.com/42009457/61829019-dfe2a280-ae1c-11e9-9937-e780f53d1931.png

As the spacial frequency increases toward the right, perceived contrast decreases rapidly. Interestingly, as spacial frequency decreases below the peak, contrast also decreases!

To the right, we see gratings that approximate block/body text with a small font. Toward the center, the gratings more approximate a large bold headline. It should be clear then that a particular optimum spacing relative to font size and weight is not consistent but vary considerably depending on the relationship to other factors.

This is also discussed in this paper. https://jov.arvojournals.org/article.aspx?articleid=2122052

And yes, "too much" space can cause a decrease in reading speed — but again, it is codependent and interrelated to other properties. Like everything in human perception, it's nonlinear and affected by multiple factors.

It is trivial to find use cases where a letter-spacing more than 0.12em is not only acceptable but helpful. Within THIS SC, it is inappropriate to state that 0.12em should be a maximum letter-spacing. Among other things, because the CSS letter-spacing property only modifies the font's default spacing, any "standard" using such an arbitrary value is technically meaningless. CSS letter-spacing does not specify spacing, only how much spacing is to be changed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/635?email_source=notifications&email_token=AB6Q4FYMCIQ6PPAENGJ3ZS3QBDHVTA5CNFSM4GY7OLA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2XYHUQ#issuecomment-514819026, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6Q4F4JUGPOC2POD6I5AF3QBDHVTANCNFSM4GY7OLAQ .

alastc commented 5 years ago

Hi @Myndex,

I read the understanding doc and realized this is just about user agent overrides!!

Yep, there is a balance in the spec between length and moving things to other places, e.g. the understanding doc. For WCAG 2.0 it was decided that the spec should be as concise as possible, and the explanations go in the understanding docs. (At least, that's my assumption based on the current setup!)

Nowhere in the SC does it state that this is about the author making a provision for the user to override these CSS properties, and I think mentioning that in the SC would go a long way toward clarity.

Possibly, but in the current framework the object of the SC text is the content. It is the content that passes/fails, not via a user-agent. (Even if that is the best or only way of testing it.)

Another option would be to add a note to that effect, e.g. "The SC does not require authors use these values, but that users can override the authored styles with these values."

does this SC apply to all text including headlines, subheads, and “non-content” text (i.e. copyrights, disclaimers, etc.)? Or just body/block text?

Unless specified in the SC it defaults to everything that takes those settings in the content, i.e. all text.

It is also worth noting that the values were intended to set a reasonable expansion of text for several possible purposes. E.g. changing font to something wider, and/or spacing. So the discussion about letter spacing and reading speed is interesting, but not going to change this SC.

Myndex commented 5 years ago

Hi @alastc

Yep, there is a balance in the spec between length and moving things to other places, e.g. the understanding doc. For WCAG 2.0 it was decided that the spec should be as concise as possible..

Understood - in this case IMO it's a bit too concise as the purpose is non-intuitive as specified.

Possibly, but in the current framework the object of the SC text is the content. It is the content that passes/fails, not via a user-agent. (Even if that is the best or only way of testing it.)

Okay, well the first reading before I read the understanding doc, was more along the lines of the author hitting these values which was a bit confusing (and concerning from a designer's point of view).

Another option would be to add a note to that effect, e.g. "The SC does not require authors use these values, but that users can override the authored styles with these values."

Yes, that's also clarifying.

Unless specified in the SC it defaults to everything that takes those settings in the content, i.e. all text.

SVG has letter-spacing and word-spacing but not the other two, so does that make SVG exempt?

It is also worth noting that the values were intended to set a reasonable expansion of text for several possible purposes. E.g. changing font to something wider, and/or spacing. So the discussion about letter spacing and reading speed is interesting, but not going to change this SC.

AH, I added that in response to some earlier comments by Wayne et al, and I was not suggesting a change to the spec so much as indicating that an arbitrary spec on spacing for authors to follow is more complicated than a spec (like this one or reflow) that specifies that a user change in size/space/etc does not break the page.

The concern I was intending to raise is one of misunderstanding intent and application ("authors to provide that certain user changes don't break the page" and not "authors are restricted to these values") because the latter was actually my first impression.

Thank you!

Andy

WayneEDick commented 5 years ago

We definitely do not want authors changing letter spacing. There is no situation like contrast minimum with spacing. Normal spacing works for most people including many with low vision. The user is the only person qualified to choose the letter spacing that works for them.

The need for a contrast minimum is well grounded in vision science research. How we measure it appears to be an open question, but it's need has been carefully documented repeatedly.

On Wed, Jul 24, 2019 at 4:32 PM Andrew Somers notifications@github.com wrote:

Hi @alastc https://github.com/alastc

Yep, there is a balance in the spec between length and moving things to other places, e.g. the understanding doc. For WCAG 2.0 it was decided that the spec should be as concise as possible..

Understood - in this case IMO it's a bit too concise as the purpose is non-intuitive as specified.

Possibly, but in the current framework the object of the SC text is the content. It is the content that passes/fails, not via a user-agent. (Even if that is the best or only way of testing it.)

Okay, well the first reading before I read the understanding doc, was more along the lines of the author hitting these values which was a bit confusing (and concerning from a designer's point of view).

Another option would be to add a note to that effect, e.g. "The SC does not require authors use these values, but that users can override the authored styles with these values."

Yes, that's also clarifying.

Unless specified in the SC it defaults to everything that takes those settings in the content, i.e. all text.

SVG has letter-spacing and word-spacing but not the other two, so does that make SVG exempt?

It is also worth noting that the values were intended to set a reasonable expansion of text for several possible purposes. E.g. changing font to something wider, and/or spacing. So the discussion about letter spacing and reading speed is interesting, but not going to change this SC.

AH, I added that in response to some earlier comments by Wayne et al, and I was not suggesting a change to the spec so much as indicating that an arbitrary spec on spacing for authors to follow is more complicated than a spec (like this one or reflow) that specifies that a user change in size/space/etc does not break the page.

The concern I was intending to raise is one of misunderstanding intent and application ("authors to provide that certain user changes don't break the page" and not "authors are restricted to these values") because the latter was actually my first impression.

Thank you!

Andy

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/635?email_source=notifications&email_token=AB6Q4FY2F5VHVR64HKHU3VTQBDQ7JA5CNFSM4GY7OLA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2X4S3Q#issuecomment-514836846, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6Q4F7BLIE7WI7PD2ABTJTQBDQ7JANCNFSM4GY7OLAQ .

mraccess77 commented 5 years ago

I'd also guess that spacing is more important in different situations. For whole word readers spacing is likely less important with some exceptions such as between certain combinations like r and n. But for math or science spacing is likely to have an enhanced effect where users with low vision have to read each character separately. Too much space could break the association between adjacent operands, etc.

Myndex commented 5 years ago

Hi @WayneEDick

We definitely do not want authors changing letter spacing. There is no situation like contrast minimum with spacing. Normal spacing works for most people including many with low vision. The user is the only person qualified to choose the letter spacing that works for them.

No I can not agree, Wayne, the author has every right to use letter-spacing for aesthetic or design reasons, including but not limited to adjusting poorly kerned fonts, reducing letter spacing when the font is used large for a headline, or increasing letter spacing when the font is used small in a block of text, for instance. There are many design reasons for adjusting spacing, it is not just for accessibility, and the user is not the "only person qualified" for setting the property.

However, I am a STRONG believer that the user should have the ability to override properties and zoom causing reflow that does not break the page (i.e. the page design needs to be robust enough to accommodate user agent modifications such as zoom in and spacing increases.

What I'd really like to see:

I'd really like to see an initiative for a "relative style sheet" wherein a user could set not absolute values for properties, but relative values, so for instance, all letter spacing increases by x%, all sizes by y%, all contrast by z% etc. This way the designer's original intent would be better maintained while improving accessibility.

The need for a contrast minimum is well grounded in vision science research. How we measure it appears to be an open question, but it's need has been carefully documented repeatedly.

Yes, but again (and I've posted many cites supporting this) minimum critical contrast is affected by font size, font weight, total luminance, luminance relative to light adaptation, surround effect/simultaneous contrast, etc. etc.

Hi @mraccess77

I'd also guess that spacing is more important in different situations. For whole word readers spacing is likely less important with some exceptions such as between certain combinations like r and n. But for math or science spacing is likely to have an enhanced effect where users with low vision have to read each character separately. Too much space could break the association between adjacent operands, etc.

Yes, indeed. Spacing requirements vary considerably with stimuli size (as I showed in the above post with reference to Michelson Contrast Modulation). And as I mentioned to Wayne above, I'd really like to see fine-grained control over relative element adjustments by the user. But as far as I can tell, that's going to take an elaborate extension, if not a full on browser modification.

And definitely some things, such as a LaTeX equation or SVG element, should probably be left alone (at least not arbitrarily modified blindly with a new CSS sheet.)

alastc commented 5 years ago

I'd really like to see fine-grained control over relative element adjustments by the user.

That would indeed require something new. I'm not aware of any standard CSS that would allow for that.

I suspect you could create a user-side script that analyzed the current letter spacing and then calculated the over-ride value to apply on a per-element basis. That would be the first step.

However, the main question for the LVTF is: would those values being a (perceived) ceiling be ok?

The choices are basically:

Keep the SC text as-is and use the understanding doc to say that values between default and the SC values should also work. Or
Change the SC text to use "up to", and then use the understanding doc to say it should allow for more.

If the area between the authored values and the SC values is most important I'd choose 2 (e.g. 0 to 0.12em letter spacing). If it is more important that people consider going above those values I'd choose 1.

lauracarlson commented 5 years ago

@alastc wrote:

If the area between the authored values and the SC values is most important I'd choose 2 (e.g. 0 to 0.12em letter spacing).

Before the Working Group changes normative SC text, it would be good to have information on how an author could create something that would work at the SC's metrics and fail in between. The originator of this issue didn't provide a site in the wild or example code that does this. At the AG's July 23, 2019 meeting, @patrickhlauke said he thought it was possible and kindly offered to put together an example. Before making a decision, can we see it?

Thanks.

lauracarlson commented 5 years ago

LVTF Resolution from July 25, 2019 meeting:

RESOLUTION: leave current 1.4.12 SC test as "at least" ... Change the understanding document for 1.4.12 and LVTF will update the doc.

patrickhlauke commented 5 years ago

At the AG's July 23, 2019 meeting, @patrickhlauke said he thought it was possible and kindly offered to put together an example. Before making a decision, can we see it?

Admittedly contrived, but I've seen similar/worse things in the wild when authors try to "game" criteria to pass them....

https://codepen.io/patrickhlauke/pen/jgVGOp (editable codepen) https://s.codepen.io/patrickhlauke/debug/acdfbbb5b1ec1d1476e1679030e6acd2 (debug/live view)

this demo cuts off text with overflow:hidden, unless it detects that line-height was set to at least 1.5 times the font-size.

can be seen in action by using something like the text spacing bookmarklet (once the page is loaded) to force those minimum line-height, spacing, etc values https://codepen.io/stevef/full/YLMqbo

lauracarlson commented 5 years ago

Hi @patrickhlauke ,

Thank you very much for creating the demo.

I tested the debug/live view in Safari with custom stylesheets set.

line-height set to 1.1 passes. Content is moved down into the available space below the "Exception" paragraph.

line-height set to 1.2 (barely) passes. Content is moved down into the available space below the "Exception" paragraph.

line-height set to 1.3 fails. The last line: "exist for that combination of language and script" is cut-off.

line-height set to 1.4 fails. The last 2 lines: "exist for that combination of language and script" and "written text can conform using only the properties that exist for that combination of language and script" are cut-off.

line-height set to 1.5 fails. The last 3 lines: "exist for that combination of language and script", "make use of one or more of these text style properties in", and "written text can conform using only the properties that exist for that combination of language and script" are cut-off.

line-height set to 1.6 fails. The full exception (All 4 lines) is cut-off.

In addition values greater than 1.6 fail. I didn't document them but could, if it would be helpful.

FYI: One of the people at the July 25, 2019 LVTF meeting said that she does need values greater than what is specified in the SC.

In any event, it seems like using overflow:hidden could be used for a failure technique.

Thanks again, Laura

patrickhlauke commented 5 years ago

@lauracarlson to test the demo properly, you'd need to set line height not just on #limiter but the whole page ... at least, that's how I coded the script to look for line height (it actually tests the line height of the h1). then you'll see the actual point i was making with this demo...that it adapts correctly for values of line-height: 1.5 and above, but not for anything from the starting value up to 1.5 ...

lauracarlson commented 5 years ago

Hi @patrickhlauke ,

to test the demo properly, you'd need to set line height not just on #limiter but the whole page ... at least, that's how I coded the script to look for line height

You are right. Thank you. Apologies.

I re-tested debug/live view in Safari with custom stylesheets on body instead of #limited. While line-height set to 1.1, 1.2, 1.5, 1.6 pass, 1.3 and 1.4 fail. Details are as follows:

line-height set to 1.1 passes. Content is moved down into the available space below the "Exception" paragraph.

line-height set to 1.2 (barely) passes. Content is moved down into the available space below the "Exception" paragraph.

line-height set to 1.3 fails. The last line: "exist for that combination of language and script" is cut-off.

line-height set to 1.4 fails. The last 2 lines: "exist for that combination of language and script" and "written text can conform using only the properties that exist for that combination of language and script" are cut-off.

line-height set to 1.5 passes.

line-height set to 1.6 passes.

Your script is a way unscrupulous authors could game 1.4.12. How prevalent do you think it is in the wild or could become in the future?

Thanks again, Laura

patrickhlauke commented 5 years ago

How prevalent do you think it is in the wild or could become in the future?

It's probably not used in the wild since the requirement for 1.4.12 / WCAG 2.1 is still relatively fresh and i doubt a lot of sites out there try to follow it (heck, the majority of the web doesn't even follow WCAG 2.0, or in many cases even WCAG 1.0 ...)

Wouldn't want to play the numbers game. My point here is that this loophole exists, and it's due to the language used normatively.

lauracarlson commented 5 years ago

Hi @patrickhlauke,

It's probably not used in the wild since the requirement for 1.4.12 / WCAG 2.1 is still relatively fresh and i doubt a lot of sites out there try to follow it (heck, the majority of the web doesn't even follow WCAG 2.0, or in many cases even WCAG 1.0 ...)

Wouldn't want to play the numbers game. My point here is that this loophole exists, and it's due to the language used normatively.

Agreed. A loophole exists. At one time Josh asked, "do we need to have a definition of minimum - the term at least". In hind sight we should have defined the term.

Jim and Wayne are currently working clarifying text for the understanding doc. An overflow:hidden failure should help too. In my experience developers want to do the right thing and not game the system. But I respect and am enlightened by your experience with unethical developers who purposely use rules meant to protect people in order to manipulate the system. Thank you, Patrick.

lauracarlson commented 5 years ago

Jim 's Update to 1.4.12 Text Spacing Understanding. Thanks @allanj-uaag !

w3c / wcag