Understanding 1.4.12: clarify the intent and author responsibility #1687
Conversation
|
I think the change is very good. Thank you! But I do not understand what the following means:
I suggest to define this more precisely or to remove it |
it would be something like "the page runs a script that constantly checks if the user made some CSS changes/injections, and strips them out again" or similar. basically adversarial coding that tries to prevent any changes to layout. unusual perhaps, but possible... |
|
(and to clarify: if a browser/user agent prevents things from happening - for instance because of CSP policies - then that's not, to my mind, a problem of the content, but a decision of the browser, so not a failure per se of the SC - but in an audit, i'd note this as 'while it passes, note that...' perhaps) |
|
@patrickhlauke I understand your explanation, but the proposed text does not make it clear enough, I think |
|
From the survey/today's discussion, I see that the comment about wanting to keep the "that people can override". Again, I'll reiterate that this is not actually what the SC normatively says. The SC doesn't say that the user must be able to change the text metrics (compare with, say, the resize text SC which normatively says "text can be resized"). It says normatively that "no loss of content or functionality occurs by setting all of the following and by changing no other style property" - it does not stipulate that users can set these style properties (or how), just that if they do manage (somehow) to "set" them, then content/functionality is not broken. That, to me, is the nuance given by using the "when people override..." wording. it's more in the sense of "if people manage to override". |
|
From today's minutes, I see that the use of "when" is still causing confusion. Happy to change this to "if" ... does that make it clearer? (basically still making sure that the wording here doesn't imply that the user's ABILITY to change text metrics is what determines pass/fail, but rather that when/if users to manage to change the metrics, whether or not content starts breaking/becoming non-functional is the actual point of the SC). so, imagine the first sentence there swapping out the "when" with "if" ... does that make it clearer? /cc @gundulaniemann
|
|
In fact, specifically when looking at Patrick's comment from '13 days ago', I prefer the wording with 'when'. Yet I can live with each of the two 'when' and 'if'. "Further, this SC is not concerned with how users change the line height and spacing metrics. It does not require that content implement its own mechanisms to allow users to do this. It is not a failure of the content if a user agent or platform does not provide a way for users to do this. Content does not fail this SC if the method chosen by the user - for instance, the use of an extension or bookmarklet - fails to correctly set the line height and spacing text properties on the content (provided that the content is not actively and purposely preventing the properties from being added)." |
As discussed in #975 and other places, there is confusion about what the exact responsibility of authors is with 1.4.12.
questions like "if i use the bookmarklet and nothing happens, do I fail this SC?" or "how can a user change text metrics on mobile/tablet/some other environment that doesn't allow bookmarklets/extensions to run?" are very common when discussing 1.4.12 and how to interpret it.
my understanding at least is that 1.4.12 is not about "this method must work", but rather "IF a user manages to inject/change the metrics, THEN content should not overlap/become unreadable/stop working".
to try and clarify this a bit more, I've made some tweaks to both the intent, and the author responsibility section.
/cc @mraccess77 @alastc as I think we've said roughly the same/agreed on this in the past