Re: 1.4.12 - Text Spacing

Sorry for the resend the last one was converted to an attachment for some reason.

Responses in-line
Sent from Andy’s iPhone

> On Sep 9, 2023, at 13:27, Guy Hickling <guy.hickling@gmail.com> wrote:
> 
> ... If you have another look through the Understanding document for 1.4.12, it will perhaps become clearer …

It is perfectly clear to me, you are missing the bulk of my point in your response.

> …web developers should not, for instance, specify both the height and width of a text container in px pixel units in the CSS …..

This is not functionally different than 1.4.10 reflow.

Also px is not device pixels, see below.


> (which fixes the size regardless of the text styling inside it), as that is highly likely to result in cropping, or other display issues, f

Right, it is a technology issue.


> or users using their own styling.

Users using their own styling can override these, and all other, CSS, unless custom style sheets are blocked (such as by poly fill).


> 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),

px is not pixels per se. px is the canonical CSS length unit, and it is referenced to the canvas abstraction layer. If some user agents parse it to device pixels is not directly relevant and a technology issue.

In essentially all user agents, all length units are resolved to px before rasterizing. Ultimately everything becomes px.

How user agents handle different kinds of zoom or user adjustment varies widely among browsers brands.

It is a technology issue.


> 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. 

Again this is an issue relating to use of inline styles more than anything, since, and this should be obvious, if a user using the hack of their own style sheet (and it is a hack on so many levels) then in-line styles are only addressed with !important or high specificity selectors.



> The SC does not forbid developers to use settings below the limits specified in the SC

I never said it did. My point that the limits shown are essentially meaningless is due to the technology. There is no standardization in terms of the metrics of any given font family.

See the following test page, where, in panel ONE, all the fonts are set to exactly the same size and weight, per the font metrics.


Unfortunately iphone won’t let me paste a plain link, and the rich link caused the last message to become an attachment. Thanks Apple:

Myndex dot com/WEB/xheightExample



> … as such (though the Understanding documents do). 

My point was illustrative not literal.


> >> " 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 

User style sheets are at best a hack. 

Style sheets are extremely site specific regarding CSS selectors. So, to be effective they need to start with a total reset of the site’s specific CSS, and then affect only the standard HTML tags.

And if the user style sheet starts with a total reset, then again, that makes this SC irrelevant, doesn’t it?


> > " 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,

Already covered in earlier SCs, “redundant” has the same weight as “meaningless”, as for both cases it results in unneeded labor (testing etc) with no functional improvement in actual accessibility.


> So I hope this clarifies that 1.4.12 is a matter for authors, not the browsers.

Not at all, this is an issue for user agent technology to enable true personalization with maintaining the original “design intent” of the site’s author.

This is a matter for technology not content creators.

Only technology, on the side of the user agent, can effectively support true user personalization in this way. 


> Browsers should not change these style settings (for line height, paragraph spacing etc), unless the user chooses to do so

I never ever claimed they should change without command to do so, by the user. But, browsers should accommodate user settings and preferences.


> …. the SC says that users must not experience problems…but only the developer can assure that, by coding correctly; the browsers cannot help there!

The site author/developer can not do any of that effectively because of the current state of the technology. The site author/developer Can not “assure” such user needs are properly met in the current technological climate.

Only browsers (or an extension thereof) can be effective at BOTH maintaining author intent AND allowing global user preference adjustment.

Browser extensions such as DarkReader have demonstrated the best way forward for user preferences is via the user agent technologies.

It is a technology issue and not an author issue.

Thank you for reading.