"at least" should be "at most" in WCAG 2.1 SC 1.4.12 #635
Comments
|
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. |
|
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..." |
|
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. |
|
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. |
|
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. |
|
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. |
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) |
|
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) |
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. |
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"? |
|
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". |
alastc
added
Survey - Has pull request
|
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" |
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. |
|
To me this is essentially about the English interpretation. From looking at how "at least" is used elsewhere in WCAG 2.1:
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.
However, that has it's own logical problems if the authored value is greater than the guideline value! |
|
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 ***@***.***> 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
<#635?email_source=notifications&email_token=AB6Q4F3BDLZ7JZYNUBS7IC3QAHCOVA5CNFSM4GY7OLA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2LWYRY#issuecomment-513240135>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB6Q4F6JVQBFTHVSQ7GKSBLQAHCOVANCNFSM4GY7OLAQ>
.
|
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... |
|
@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:
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
|
|
"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 ***@***.***> 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
<#635?email_source=notifications&email_token=AB6Q4F3CMWACQB5QRLCEAC3QBCPVJA5CNFSM4GY7OLA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2XIKXA#issuecomment-514753884>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB6Q4F2SIHCJ3A5BU2LWWCDQBCPVJANCNFSM4GY7OLAQ>
.
|
|
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. |
|
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 ***@***.***> 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
… <#m_2239106345731555159_>
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
<#635?email_source=notifications&email_token=AB6Q4FYMCIQ6PPAENGJ3ZS3QBDHVTA5CNFSM4GY7OLA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2XYHUQ#issuecomment-514819026>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB6Q4F4JUGPOC2POD6I5AF3QBDHVTANCNFSM4GY7OLAQ>
.
|
|
Hi @Myndex,
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!)
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."
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. |
|
Hi @alastc
Understood - in this case IMO it's a bit too concise as the purpose is non-intuitive as specified.
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).
Yes, that's also clarifying.
SVG has letter-spacing and word-spacing but not the other two, so does that make SVG exempt?
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 |
|
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 ***@***.***> 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
<#635?email_source=notifications&email_token=AB6Q4FY2F5VHVR64HKHU3VTQBDQ7JA5CNFSM4GY7OLA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2X4S3Q#issuecomment-514836846>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB6Q4F7BLIE7WI7PD2ABTJTQBDQ7JANCNFSM4GY7OLAQ>
.
|
|
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. |
Hi @WayneEDick
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.
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
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.) |
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:
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). |
|
@alastc wrote:
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. |
|
LVTF Resolution from July 25, 2019 meeting:
|
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) this demo cuts off text with 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 |
|
Hi @patrickhlauke , Thank you very much for creating the demo. I tested the debug/live view in Safari with custom stylesheets set.
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 Thanks again, |
|
@lauracarlson to test the demo properly, you'd need to set line height not just on |
|
Hi @patrickhlauke ,
You are right. Thank you. Apologies. I re-tested debug/live view in Safari with custom stylesheets on body instead of #limited. While
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, |
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. |
|
Hi @patrickhlauke,
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 |
|
Jim 's Update to 1.4.12 Text Spacing Understanding. Thanks @allanj-uaag ! |
"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".
The text was updated successfully, but these errors were encountered: