RE: 1.4.12 - Text Spacing

I use the Stylus extension for Chrome and created a custom stylesheet to apply the styles WCAG requires for testing 1.4.12. It’s not adjustable like the one you linked to, but it doesn’t need to be.

Steve Green
Managing Director
Test Partners Ltd


From: Michael Livesey <mike.j.livesey@gmail.com>
Sent: Sunday, September 10, 2023 5:40 PM
To: Marcos Villaseñor <villasenor.marcos@gmail.com>
Cc: Guy Hickling <guy.hickling@gmail.com>; WAI Interest Group discussion list <w3c-wai-ig@w3.org>
Subject: 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<mailto: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<mailto:guy.hickling@gmail.com>>
> Date: Saturday, 9 September 2023 at 14:11
> To: WAI Interest Group discussion list w3c-wai-ig@w3.org<mailto: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
>
>
>
>