Text spacing: does it require compatibility with one or all methods?

[JAWS-test]

Understanding for SC 1.4.12 says

Such changes may be achieved via user stylesheet, bookmarklet, extension, or application.

In practice, it is often the case that customization does not cause any problems with user styles, but with the bookmarklet. Reason is:

• Adjustment with User Styles takes place when rendering the page, so that the rest of CSS can react to it.
• Adjustment with bookmarklet is done after rendering the page, so the text often flows out of the blocks.

Is SC 1.4.12 met if user styles work but the bookmarklet doesn't?

[alastc]

The bookmarlet is not the ultimate arbiter, for example, it cannot work on sites with a strict 'content security policy'. My backup then is the stylish plugin, which is also applied at the end of the cascade.

However, I'm struggling to see a way that a site would adapt to a user style sheet that would not also work with bookmarklet / plugin approach? The site has no means to know there is a user stylesheet.

[JAWS-test]

I'm afraid that doesn't answer my question. My question was whether one or all of the methods mentioned in the Understanding have to work or what happens if one of the methods leads to a bad result and the others do not.

The site has no means to know there is a user stylesheet

That may be, but I've already found several pages in the test where the bookmarklet adjusts the texts so that the texts overlap, while with userstyles everything was ok. I didn't find out the exact cause. It could be that it's not the CSS, but the JS. This means that when the page is loaded, the JS determines how much space the text containers need and and these are then positioned. If I adjust the distances afterwards, the JS function is not triggerd again.

[JAWS-test]

If the bookmarklet is only to be used for testing purposes, but is not used by impaired people, I am in favor of deleting it in the Understanding. Otherwise, I am in favor of describing in the Understanding whether all or only one method must work.

[patrickhlauke]

what the SC requires is that IF a user manages to change the spacing metrics, the site doesn't become unusable (cut off/overlapped content etc). it does not specify how users would change those metrics, nor does it require that the site somehow makes provision for/makes it easy to actually change those in some way by the user.

and yes, i think from a testing point of view, this makes it tricky because some tests (like bookmarklet etc approaches) change those metrics after the page has loaded/scripts have executed, so if the site does any kind of metric checking on load, the end result will differ (for instance, for my edge case demo https://codepen.io/patrickhlauke/pen/jgVGOp i had to explicitly run the metric calculation script on an interval rather than just on page load)

[mraccess77]

@JAWS-test I have used favlets similar to that one to change the font in situations where I could not use an extension like Stylus -- such as on mobile devices. I personally don't add space between words/letter/lines so I don't use this bookmark -- but folks certainly could use it for an accommodation.

[JAWS-test]

Do I understand the answers correctly: 1.4.12 requires that the adjustment works correctly with all possible methods? I.e. all methods should be tested, because they can give different results. If one method does not work, the SC is not fulfilled...

Or is one method sufficient, because it could considered as a conforming alternate version? Precondition would be probably that on the page there is a hint about this conforming alternative version?

I would rather prefer the second variant.

[JAWS-test]

One more thought: Since the bookmarklets do not work reliably, a page containing iFrames and/or special security settings for the execution of JavaScript, for example, does not fulfill 1.4.12 with regard to the bookmarklets. But with user styles these pages would work. If 1.4.12 requires all methods to be supported, many pages would violate 1.4.12. This is probably not intended. Therefore, my suggestion would be that 1.4.12 does not require the bookmarklets to work, even if the customization with bookmarklets works in itself, but the display is not correct.

[patrickhlauke]

Do I understand the answers correctly: 1.4.12 requires that the adjustment works correctly with all possible methods?

i'd say no. it doesn't say anything about any methods at all. only that if users, somehow, manage to set the text spacing metrics, and they actually kick in, that then things don't break. and yes, it's quite vague beyond that. if an attempt by the user to change metrics doesn't work (like the example of the bookmarklet and iframes), it's not the fault of the site author.

if a site doesn't dynamically properly (and things break) for injected styles (because it's doing a size calculation on page load, and any subsequent changes to text spacing lead to broken/cut-off/non-functional content), then that IS arguably a failure? if so, THAT would be good to document.

[JAWS-test]

If the following applies:

• Text spacing cannot be adjusted: no problem
• Text spacing can be adjusted, but errors occur: is a problem

then it could lead to web developers deciding not to allow text spacing adjustment to meet SC 1.4.12 (e.g. by defining specific spacing with !important that is not overwritten by the unspecific spacing by the bookmarklet).

SC 1.4.4 does not require all methods of font size adjustment to work, but only one method ("Check that the text resizes by one of the methods above, and can be resized to at least 200% of the default", F94). Font size adjustment would also be possible via bookmarklet - but if it didn't work, nobody would probably consider it a violation of 1.4.4. My question is whether 1.4.12 has higher requirements than 1.4.4?

[goyalvarun601]

Hi. We are facing the same situation with iFrames. Are there any guidelines or recommendations on how to deal with that situation right now? Thanks.

[JAWS-test]

We are facing the same situation with iFrames

I suggest to do the test always with User Styles instead of bookmarklet, than there is no problem in iFrames

[goyalvarun601]

Thanks for the response @JAWS-test I can do the test internally but how would the user be able to adjust the spacing?

[JAWS-test]

In my opinion a user would not use a bookmarklet but User Styles. The bookmarklet was created for testing and not for the users. That's why I'm also in favor of removing the reference to the bookmarklet from the Understanding

[mraccess77]

Some tools have tests failing this SC if "!important" is used - but from this discussion it doesn't seem like that is a failure of this SC - right?

[goyalvarun601]

Can you be more specific what you mean by "User Styles"? I am not sure how a user would be able to add styling to content inside an iframe unless they have some level of programming knowledge.

[mraccess77]

User styles would be set using a browser like Firefox or Internet Explorer through a user level style sheet that is uploaded/set. Styles can also be added through Stylus extension in Chrome/Firefox which aren't user level but do apply within iFrames.

[patrickhlauke]

Some tools have tests failing this SC if "!important" is used - but from this discussion it doesn't seem like that is a failure of this SC - right?

i'd say that those tools are a bit...ambitious / wrong. i'd take the presence of !important as a possible flag to say "this needs manual review", but nothing more

[JAWS-test]

with user styles you don't need any knowledge at all: except CSS to define them

[ernistkg]

@JAWS-test, I have a question regarding iframes.

Suppose there is a web application that hosts Cross-Origin iframe with text content. Customers that are visiting this web site can't use bookmarklets, because CORS policy does not allow that. How customers of the web site are supposed to increase text spacing? They can open dev tools and manually inject styles, but it doesn't look like valid option. I'm really confused.

[patrickhlauke]

how actual users change the styles is not the concern of the WCAG SC. it only says that if the users do manage to specify increased letter/line/etc spacing, that content shouldn't stop working.

[JAWS-test]

@ernistkg @patrickhlauke

how actual users change the styles is not the concern of the WCAG SC.

True. However, we do not know which method a user uses. So, if we want to clarify whether a page complies with SC 1.4.12, the tester (not the user) has to keep trying until she or he finds a method that allows her/him to adjust the content in the iframe as well. This does not work with the bookmarklet. Therefore, a browser plugin such as Stylish should then be used. If the spacing cannot be adjusted even with this, the source code should indeed be manipulated, even if the user would not do this of course. Sometimes I also open the iFrame in a separate browser window to be able to apply the bookmarklet

[ernistkg]

@patrickhlauke @JAWS-test Thank you for the clarification. I think it is more clear now for me.

[ernistkg]

@patrickhlauke @JAWS-test

I'm curious about mobile browsers where we can not disable CORS policy, install Stylus plugin or even edit source code. Bookmarklets also doesn't work on iFrames when mobile browser are used. Browser built-in tools can't modify iFrame content styles. I don't see any options for mobile browser users.

Do we meet Success Criteria if only desktop browsers are adjustable for text spacing?

Thanks

[patrickhlauke]

the point of the SC is that you're not actively blocking it, and that if a user does manage to set different metrics, things don't blow up. nothing more. again, the SC says nothing about how users can/should go about changing the metrics. if they are on mobile/tablet browser, where they can't run bookmarklets or plugins, that's not your concern.

[ernistkg]

@patrickhlauke

Thank you for the clarification! I really appreciate it!

[alastc]

Marked as ready for survey thanks to #1687

[AshankGG]

@patrickhlauke - Irrespective of method used, does this SC also applies to native/hybrid apps? If yes, then do we have any specific approved method for testing it?

[patrickhlauke]

as the SC is scoped to In content implemented using markup languages that support the following text style properties..., purely native apps are out of scope. technically native/hybrid apps contain webviews with actual markup language content, there's no practical way for a user to actually change text spacing metrics (however they do it ... a bookmarklet, extension, user stylesheet, etc). theoretically you could test the actual web content inside the webviews in isolation in a browser, and I suppose technically the SC does apply to the webview content itself - so a pedant may insist on testing those. not sure what the rest of AGWG think on this...

[patrickhlauke]

@alastc can this issue be closed since https://github.com/w3c/wcag/pull/1687 which tried to address this was merged? or are there still aspects left open to discuss?

[mraccess77]

Web content defined by WCAG seems to not include embedded web content in apps. But if you were to apply WCAG to non-web content then the question would do those capabilities exist - you'd only need to validate that the methods that do exist work - practically this is likely to be very limited outside web content in the browser.

[AshankGG]

@patrickhlauke - Per your comment above, Can I assume that webview content should not be tested for 1.4.12 and even if it may be insisted to test but practically it's not possible to do so?