Re: 1.4.12 - Text Spacing

Hi Guy and Marcos,

many thanks both for your comprehensive replies which I think help resolve
a lot of the confusion with 1.4.12.

regarding testing, has anyone used the chrome extension for 1.4.12 or have
any suggestions for developer tools that could help developers assess, and
therefore pass, this criterion?

Below is a link to the chrome extension.

https://chrome.google.com/webstore/detail/text-spacing-editor/hgiacbohdkgnobadgihbamoccokjpcca

On Saturday, September 9, 2023, Marcos Villaseñor <
villasenor.marcos@gmail.com> wrote:
> To add to what Guy and Steve note, it’s also common for designers to
insist that developers follow their designs with “pixel perfection”,
ignoring the fluid nature of the web. This is compounded by CMS designers
adopting strategies (like setting artificial character limits) to prevent
content editors using the CMS from “breaking” their design intent with more
content than they envisioned.
>
>
>
> The result is that, if the style sheet is ever overridden, the content
becomes inaccessible to everyone. For example, fixed size containers
truncate text, preventing anyone from reading the full title or important
content within an element. Navigation, tables and other content displayed
in limited space is affected particularly badly.
>
>
>
> We test designs and implementations with the parameters set in 1.4.12 and
I personally find it a very helpful criterion to ensure that designers
understand their work needs to be resilient, rather than beautiful but
inflexible (as it would be in the print world).
>
>
>
> Marcos
>
>
>
> From: Guy Hickling <guy.hickling@gmail.com>
> Date: Saturday, 9 September 2023 at 14:11
> To: WAI Interest Group discussion list w3c-wai-ig@w3.org
> Subject: Re: 1.4.12 - Text Spacing
>
> Hi Andrew,
>
> Steve is quite correct in what he says, and there is nothing wrong with
the way SC1.4.12 is written. It is certainly not meaningless, if you read
it carefully, and if the Understanding document for 1.4.12 is also read. In
fact this is one of the clearer SCs (in spite of the complex subject it
covers). It means, for authors, exactly what it says. If you have another
look through the Understanding document for 1.4.12, it will perhaps become
clearer (and you will also see that it makes clear the SC is for content
authors, not the browsers or users).
>
>
>
> The purpose of this SC is to ensure that developers don't write CSS that
causes problems for users using their own stylings, up the limits specified
in the SC itself. (Users can do this using a suitable browser add-on, or
even their own stylesheet if they are technically minded enough for that.)
In other words, if the user decides to increase the line height to 1.5
times the font size, for example (as some users with dyslexia do), or add
extra space after the paragraphs to show wider separation for clarity, they
should be able to do so without some of the text being cropped or
disappearing.
>
>
>
> This means that web developers should not, for instance, specify both the
height and width of a text container in px pixel units in the CSS (which
fixes the size regardless of the text styling inside it), as that is highly
likely to result in cropping, or other display issues, for users using
their own styling. Using px units on containers is a actually very common
mistake that developers not interested in accessibility make (it comes down
to us from the early days of the Web), and that is the reason this SC was
created - to stop exactly that kind of bad coding from the developer.
Over-writing of adjacent text also often occurs when the developer uses
absolute positioning of their content - another common mistake from
pre-accessibility times - for users that are using their own stylings.
>
>
>
> The SC does not forbid developers to use settings below the limits
specified in the SC (standard defaults are lower than these limits), but it
does mean that they should test their work, up to those settings mentioned
in the SC, to ensure none of the problems mentioned above (cropping,
over-writing, and other things) occur. Likewise test teams in organisations
trying to implement accessibility should also make the same test, and
external accessibility auditors also certainly make those tests as a matter
of course (at least, the good ones do!). So this is a very real issue that
is tested for. (Testers can simply change the CSS in their browser using
the developer tool, but there are also a few testing widgets available that
apply those settings.)
>
>
>
>> " The author shall not set the viewport or..."
>
> Speaking purely from memory, I don't think any of the SCs mention the
"author" as such (though the Understanding documents do). This is because
the WCAG as a whole is specifically written for web authors - there is an
entirely separate guidelines for the browsers and other user agents. Web
developers who implement accessibility know that all the SCs apply to them,
not the user or the browsers, and they know the WCAG house style for the
SCs does not specify "author" (but the Understanding docs do).
>
>
>
>> " user style sheets are a hack at best..."
>
> No, they aren't a hack, they are a valid way for users with various
impairments to adjust styling and colours to suit their own requirements
(and browser add-ons are alternatives to do the job for the user). What
developers must avoid is doing things that prevent users from doing so, or
that make things difficult (such as over-writing) when they do.
>
>
>
>> " does the author “block” things like zoom or other personalizations"
>
> SC4.1.12 is specifically written to forbid authors from doing so. But it
is written in a testable way, i.e. so that a specific test can be applied
to a web page to ensure line-height and other stylings can be tested. A
separate SC exists for when the user zooms (the Reflow SC), and that is
also written in a testable way. In contrast, just saying "author shall not
set the viewport or other features is such a way as to" is not easily
testable in itself, it is a rather high-level, vague statement.So the SCs
are worded the way they are for a reason.
>
>
>
> So I hope this clarifies that 1.4.12 is a matter for authors, not the
browsers. Browsers should not change these style settings (for line height,
paragraph spacing etc), unless the user chooses to do so, any more than
developers are required to use them. But the SC says that users must not
experience problems (up to those specified limits, preferably even beyond
them) - but only the developer can assure that, by coding correctly; the
browsers cannot help there!
>
>
>
> Regards,
>
> Guy Hickling
>
>
>
>