1.4.12 Text Spacing expectations for info graphic / content reliant on layout positioning

[scottaohara]

As there is an exception for elements rendered via <canvas>, where such content is treated as 'images of text', I'm wondering if there should not be some other similar exception - or at least a level of leniency - granted for other similar types of content that aren't rendered via specifically via "<canvas>" but are rendered under similar concepts. For instance, info graphics or slides / presentations where content is laid out in very specific ways by web/content authors, and where text-spacing adjustments are respected but may not play nicely (may result in overlap, truncation or even loss of content) with the general ruleset often used to test text spacing.

examples of infographics

The first example demonstrates how after applying the text spacing styles some rather benign visual breakage, where content extends outside of the expected boundaries. Similar situations like this could create some color contrast issues with reading the text atop backgrounds it was not expected to intersect with, along with potential overflow clipping, or text overlapping with other content.   The following is a more overt example of a 'failure' as with text spacing applied, text clearly overlaps  

examples of presentations

The following demonstrates "slides" of a presentation which are rendered in markup. This is *good* because the elements of the different slides can have explicit semantics exposed, as necessary. However, being a "canvas" (but not a ``), content can be laid out in very specific ways by the content creator. Applying text-spacing adjustments to content that was created to specifically fit inside of a particular "slide", or (not demonstrated in the following images) positioned in meaningful ways where location and layout of text is important for the visual presentation, applying text sizing adjustments to such content can break it rather easily.   the content of these slides reads as follows:

Clever quotes

These guys come in two forms, inline, "The nice thing about standards is that there are so many to choose from" and block:

For years there has been a theory that millions of monkeys typing at random on millions of typewriters would reproduce the entire works of Shakespeare. The Internet has proven this theory to be untrue.

It seems to me that these all demonstrate an ability for a user to apply text spacing, but this rule doesnt' presently account for the fact that there will be some instances of web content where there are specific layouts / positioning of items made by web authors / content creators that dont' fall into standard web content document flows, or even generalized UI patterns. These sorts of issues generally fall outside of the bounds of "following responsive design best practices" as well.

It seems to me that if these sorts of components were built using <canvas>, then they'd likely be less accessible, but have an exception from this rule. Being that they're not, but represent content that is reliant on specific layout considerations and limitations, also not unlike video captions, it seems maybe these types of content are another area where this rule needs to define its applicability, if any at all.

Thanks

[JAWS-test]

I don't think we need an exception because text is either text and thus customizable according to 1.4.12 or it is Images of Text and not customizable according to 1.4.12 but customizable according to 1.4.5:

the font, size, color, and background can be set

All of your examples I would consider to be a violation of 1.4.12 or 1.4.5, depending on which technology is used. I consider the 1.4.12 exception for Canvas to be redundant and misleading, since I can't use 1.4.12 methods to customize text in Canvas (at least I suspect). Thus a canvas is automatically Image of Text

[scottaohara]

I don't think we need an exception

Then how would you suggest someone reasonably remediate? These aren't examples of typical web pages with normal content flows. The "canvas" in these cases (again not <canvas> but the actual area available to authors and content creators) size is often predetermined and content is very specifically positioned in that context. The actual content and positioning is often variable and not always in the control of the author of the actual component - but rather the component allows content creators to add and position their content how they see fit. This is a rather important feature.

These don't represent a simple "follow responsive design best practices and your content will properly wrap" situation, as the limited and generally straight forward techniques appear to cover. And treating it as such is disingenuous to the amount of effort it would actually take to alleviate some of these issues, if they can even be alleviated at all without taking away functionality from content creators.

All of your examples I would consider to be a violation of 1.4.12 or 1.4.5

None of these fail 1.4.5 as none of them are images of text. These all "fail" 1.4.12. But that's the reason I created this issue. I don't think 1.4.12 has taken into account examples like what I've posted. At least, the understanding doc and the linked techniques / references and research articles all appear to based on much more basic UI (cards being the most complex in the understanding doc). The research papers I've been reviewing by following through all the related links do not appear to be taking UI like this into account, either, but are much more focused with reading comprehension and speed when users are reading content in the context of a Word doc (as one paper specifically called this out), for example.

Please note that I do understand the intent of this SC and how adhering to it can help people read the content of web pages. These examples I'm using are some of the more "straight forward" instances of complex creator-made content that can fall down flat when attempting to test against this SC... but I would submit that's the issue here. The CSS ruleset that people use to test with works 'well' for testing web pages with much more typical document flows/visual rendering. There is nothing presently written that indicates how to handle situations like this. There aren't even practical solutions using JS to attempt to remediate these sorts of situations (e.g., one can't just assume that any stylesheet injected into the page would be from a user attempting to modify text spacing of the page). The expectations for the examples I've called out are ambiguous at best per the normative and informative text of this SC. There needs to be clarity and acknowledgement of what expectations are in situations like these, because currently that is lacking – which either indicates, to me, that these situations were not considered, or they fall outside the scope of what this SC was meant to reasonably cover.

[JAWS-test]

Then how would you suggest someone reasonably remediate?

It depends on the technology used (HTML, SVG, etc.). If it doesn't work with one technology, another should be used. I don't know if there is a solution for every technology, but just saying that 1.4.12 doesn't apply if the technology can't do it, I think is too simple. Then I could also say I don't fulfill WCAG 1.2.2 because my video player can't show captions.

1.4.12 does not require that text spacing be adjustable, only that all content be displayed correctly after adjustment (if possible). So if I need a fixed layout, I might want to choose a technology where the spacing cannot be adjusted. I agree with you that the Understanding should better define in which cases this is allowed. I would consider it acceptable for infographics, but not for slides.

[scottaohara]

So if I need a fixed layout, I might want to choose a technology where the spacing cannot be adjusted

So instead of using HTML and making the content easily accessible to people using AT, you would recommend such instances be completely re-implemented using <canvas> (for example), and taking on the huge LOE to retain the accessibility of what markup provided just so that the text spacing requirement could be avoided? Forgive me if i'm misunderstanding your intent here by saying to remediate one would choose a tech where spacing can't be adjusted... I'm not sure how else to interpret that. But, developers won't do that when all other advice would tell them they should be implementing these sorts of content using HTML to make it easier to make the content more accessible. Also, per your previous comment, you'd possibly fail them for 1.4.5 if they did ;)

but just saying that 1.4.12 doesn't apply if the technology can't do it, I think is too simple.

that's not at all what i'm saying. in fact, the technology can support text spacing in that the CSS is respected and thus the content adjusts. However, due to the requirement of these examples where layout is important for presentation, not at all a standard document flow, and often user-created rather than web author created, I'm saying the expectations of this SC are "too simple" and don't account for content that doesn't adhere to a more general document flow.

I'm trying to be fair and have been thinking if this sort of content was possible to create using markup when this SC was originally written, but being a wcag 2.1 rule, yes it definitely was.

What I think specifically needs consideration, and the part of the normative text that I think makes it very hard to handle examples like these is:

...and by changing no other style property

For more general document flows, this text makes sense and I completely agree with it. But it is also specifically what is problematic with this SC per the examples I provided (and quite a few other examples I can't presently provide).

I would find it reasonable if an exception was made for this bit specifically, so that the requirement to allow content to adjust could still be upheld, but the SC would be reasonable for situations like these where it becomes far more unlikely that web authors can totally and reasonably account for the injection of user created styles for content that doesn't adhere to the general document flow.

[alastc]

As there is an exception for elements rendered via ,

I'd say that the understanding document clarifies that canvas is not considered a "markup language that support[s] the following text style properties".

Reflow has a normative exception for this type of thing:

Except for parts of the content which require two-dimensional layout for usage or meaning.

I don't think that come up during the discussions for text-spacing though. What I'm trying to work out is how difficult it would be to remediate.

For example, in the first graphic you could add an 'inline' white background to the x-axis labels to prevent the contrast issues. If the boxes expanded with the text, the whole thing would be pretty good. (Text expanding out of a box isn't a fail as such, unless it overlaps other text or loses contrast.)

I haven't tried such fiddly markup/layout for a while though, perhaps I'm underestimating it.

[scottaohara]

For the first example, it's SVG so the box values are hard coded based on the original sizing of text nodes.

That's generally the issue with a lot of the info graphic examples. The text nodes will respect the CSS adjustments, but the containers have hard values that won't adjust to match.

What I'm trying to work out is how difficult it would be to remediate.

From my experiences it has not been easy to remediate, particularly for the content that is user created, where the expectation is that the user (original content creator - so someone using a tool, not the web developer who made it) can put in what they want, and position it in the way they best see fit. "remediation" would often result in the web author having to change what the user created... which, is not at all ideal or even something that can reasonably be done generically when content can be positioned in any sort of way/layout.

I'd say that the understanding document clarifies that canvas is not considered a "markup language that support[s] the following text style properties".

yes i understood that. was using that more to allude to the fact there is already an exception called out for this rule, and per the understanding doc - and my PR about shadow DOM which we've already discussed - there are other instances where this rule doesn't actually apply. (note: i also realized when looking through this that there is no clarifying statement that the <option> elements of a native HTML select's popup ALSO would not adhere to this rule, as those options also cannot be styled. not that that's directly related here, but more to the point it's another example of where 'html/css' support these style adjustments - except for where they don't).

[JAWS-test]

@scottaohara

So instead of using HTML and making the content easily accessible to people using AT, you would recommend such instances be completely re-implemented using canvas

My understanding of HTML is that there is no fixed layout on the web. If I need a fixed layout, then I can use PDF.

I am not sure if in a SVG the spacing is always adjustable or if I can make it so that it is not adjusted. You had included the change regarding Custom Elements - that would be a solution as well.

A canvas element may well be accessible, I can fill the canvas in the DOM with content that is output by the AT.

My only concern with your proposal is not to completely undermine 1.4.12: Because doesn't almost every web designer dream of a fixed layout? And will then claim that the appearance of the slides is essential and therefore fixed. The 3 examples in the Understanding (Figure 1 to 3) are good examples of slides with a fixed layout - but the WCAG rightly says: "Design your slides to fit their content, no matter if I adjust the spacing, change the typeface, change the font size or use zoom".

[scottaohara]

My understanding of HTML is that there is no fixed layout on the web. If I need a fixed layout, then I can use PDF.

I take it that you are not familiar with using tools to create online presentations/reports, or data viz then? There are a number of services that allow for the creation of such content and render as HTML/SVG. Some of these tools have even done a good job at ensuring the markup they produce is semantically appropriate and the content will be as accessible as the content author has created it to be. Making a PDF of such content would not be a viable solution, particularly for the content that has interactivity and dynamic content.

I am not sure if in a SVG the spacing is always adjustable or if I can make it so that it is not adjusted.

If the text is not rendered as text, then it won't adjust to these rules. But, that seems a step backwards to tell people to make their SVGs less accessible so that they don't have to worry about this rule.

A canvas element may well be accessible, I can fill the canvas in the DOM with content that is output by the AT.

I understand that, but that's not a viable suggestion as it'd be telling people to completely re-create their content/service to avoid this rule, and to have to ensure accessibility in a completely different manner than what they had already implemented.

My only concern with your proposal is not to completely undermine 1.4.12

I'm afraid that suggesting people convert their content to render via <canvas>, or to encapsulate via Shadow DOM would actually be what undermines this rule. It's not my intent to do that at all, but rather to again clarify expectations for the content / services I'm calling out, as I've already indicated in my previous comments.

The 3 examples in the Understanding (Figure 1 to 3) are good examples of slides with a fixed layout

Are they though? I do not get the impression that any of those were meant to represent presentation slides, but rather targeted instances of content within a more traditional web page. If I'm wrong, that would be great to call out in the understanding doc. But again I'd submit that those instances of content were probably created in the scope of a more general document flow are relatively, and in that context they're relatively easy to ensure they remain accessible. If they were actually representative of "slides" and thus would represent user created content, then I'd would have expected important guidance on how to adjust content in a way that meets the requirements of this rule without also having a potential negative impact on the content creator's layout, or the readability of the text.

For example, if you've ever used an online presentation creation application (google presentations, or power point for example), you'd know that each box of content has defined bounding areas and they are placed on the presentation "canvas" by the user. Applying the text spacing rule to such content will generally result in the distortion, overlapping or clipping of the content. This is why I want clarity and have expectations properly set for how this rule applies to such situations. Again, "by changing no other style property" seems very unreasonable in these particular situations. To reiterate again, an exception or at least a level of leniency, seems appropriate here.

Also, per:

but the WCAG rightly says: "Design your slides to fit their content, no matter if I adjust the spacing, change the typeface, change the font size or use zoom".

I am unable to find this quote in the WCAG spec. Could you please provide me a link?

[JAWS-test]

I am unable to find this quote in the WCAG spec.

This was not a quote, but my understanding of what WCAG says in the various SCs about spacing, zoom and reflow - freely summarized by me.

Although I may be technically lacking in understanding of the possibilities of HTML, SVG, PDF, Canvas, etc., I think it is important in 1.4.12 that all content is displayed correctly and that all functionality is preserved when text spacing or font is adjusted. If I exclude slides from this, then I would like it to only exclude them in that they do not need to be customizable. I think it's wrong to exempt them if they are customizable and then become unreadable and unusable. Then I have a problem as a user of the customization - which I can't solve.

But I don't want to argue with you any further. I think the WCAG WG should make a decision on this and document it in the Understanding. Of course I also support a decision that differs from my opinion.

[detlevhfischer]

Personally, I think @scottaohara makes a very good case for extending the canvas exception in the 1.4.12 Text spacing Understanding to include content that needs a particular presentation but gracefully manages to do so in a way that is more accessible than alternatives in canned formats. We don't want people to remediate their stuff out of scope simply to not stumble across 1.4.12.

Is it then be a matter of wordsmithing that exception in a way that does not create a loophole, and create a PR on the Understanding doc? The phrase in 1.4.10, "Except for parts of the content which require two-dimensional layout for usage or meaning" may be a good starting point, or actually already do the job (because in nearly all cases today, common web content is designed to work fine in reflow, which means it cannot claim that exception).

Should there be broad WG consensus that 1.4.12 was never intended to apply to "canvas"-like content (I suspect omitting such exception was largely an oversight), we may even add it as errata or normative change?

[scottaohara]

appreciate that @detlevhfischer, and yes completely agree - i think 1.4.10's exception is a good starting point. Including then a modified note (again similar to 1.4.10's, to indicate these specific situations would then make the normative exception text easier to add/modify (if necessary) from 1.4.10's.

For example, calling out dataviz (infographics - svgs), presentations, video and video game UI - these would all be examples of where text modifications like this "may" be possible, but are also the most likely to break the UI, and accounting for the injected user styles could result in content actually needing to become smaller to fit in the allocated areas, or even just practically impossible to move / adjust without obscuring other information (video/video game, dataviz), or altering the layout of user generated content (e.g., presentations, or dataviz to some extent).