1.4.5 / 1.4.9 Image of Text and <text> inside SVGs

[patrickhlauke]

Ongoing discussion (today) about whether or not text inside SVGs passes "Images of Text".

https://webaim.org/discussion/mail_thread?thread=9282&id=40208#40208

The normative wording only defines "images of text" as https://www.w3.org/TR/WCAG21/#dfn-images-of-text

text that has been rendered in a non-text form (e.g., an image) in order to achieve a particular visual effect

Generally, this is understood to mean text that's been presented as part of a bitmap or something. SVG can contain text as actual <text> elements of similar. So from this perspective it would pass these SCs.

However, once you dig into the rationale for/the intent of the SC, it becomes clear that the idea is that text (rather than images of text) can also be adapted more easily to users' needs

https://www.w3.org/WAI/WCAG21/Understanding/images-of-text.html

The intent of this Success Criterion is to encourage authors, who are using technologies which are capable of achieving their desired default visual presentation, to enable people who require a particular visual presentation of text to be able to adjust the text presentation as needed. This includes people who require the text in a particular font size, foreground and background color, font family, line spacing or alignment.

This is currently not the case for SVG text...changing any preferred font size/typeface/etc settings in the browser has no effect on text inside SVGs. No current user agent provides the ability to change these by default. So...unless a site that uses SVG text also provides custom mechanisms/controls (to satisfy the "Customizable: The image of text can be visually customized to the user's requirements"), I feel this is actually a fail.

I'll hazard a guess that this was not even an issue at the time WCAG 2.0 came out / wasn't really considered then. However, it would now be good to provide some guidance, and to perhaps expand the normative definition of "images of text" accordingly.

What's everybody else's take?

[alastc]

My simple yardstick (which hadn't previously been challenged by the scenario SteveG talked about) was generally: Is it bitmap or not?

SVG stays crisp when zoomed, but UAs don't provide the same controls as HTML based text, so I see the point about it not meeting all of the intent of images-of-text.

I haven't done much experimentation with complex SVGs, but my understanding is that:

• It is theoretically possible to change foreground/background colors with CSS, but not really implemented at the moment (not accessibility supported).
• It would be difficult/impossible to apply different fonts/spacing/line-height to text in an SVG as the author generally assumes a position and size relative to other elements in the SVG (thinking of graphs, infographics etc).

The first issue I'd put to user-agents, the second is more tied to the purpose & capabilities of SVG.

Overall, it would be useful to add some nuance for what is basically vector text used in different ways than HTML text without accessibility-support for adaptation.

E.g. SVG is considered an image. If the size, position & color must be relative to its surroundings (e.g. graphs/infographics) then it does meet the "to achieve a particular visual effect" aspect. If not, then it fails 1.4.5.

[JAWS-test]

1.4.5: "font, size, color, and background can be set"

I'd say: If a few rules are followed when designing SVG, it is no problem to make it compatible with SC 1.4.5.

• size: no problem with browser zoom
• fonz-size: no problem (the font size selected in the browser is used in the SVG graphic)
• background-color in HCM (Firefox, IE): no problem (if no color is defined or if a color of the operating system is used: http://www.w3.org/TR/css-color-3/#css-system)
• text-color in HCM (Firefox, IE): no problem (if a color of the operating system is used. In IE it is even possible to detect the contrast adjustment via Media Query and then adjust the colors: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/-ms-high-contrast. In other browsers (such as Firefox), this is only possible via the indirect method that JS checks whether background graphics are displayed or not.)
• colors without HCM: possible by adapting the CSS (e.g. via userstyles, bookmarklet etc.)
• colors with the filter (Chrome): no problem
• font-style: no problem (the font selected in the browser is used in the SVG graphic)
• letter spacing and word spacing: customizable via CSS
• line-height, paragraph spacing: as far as I know, these are the only text properties that can't be easily defined in SVG via CSS. However, the SC itself does not explicitly state that the line or paragraph spacing must be adjustable. Especially since the requirement for line and paragraph spacing for normal text was only added with WCAG 2.1 (SC 1.4.12) and did not exist when WCAG 2.0 was formulated.

Since 1.4.12 for text does not require the website to offer the possibility of adaptation, but only the page must not prevent adaptation, the claim should not be higher for text in SVG. Of course, it is also possible to offer a tool like in G175, with which the colors/size/font can be adapted inside SVGs (https://www.w3.org/WAI/WCAG21/Techniques/general/G175).

1.4.9: "No Exception"

Since there is no exception, any SVG would violate the SC.

[goodwitch]

I agree with @JAWS-test. The question simply is "Can you customize text (font, size, color, and background) of <text> in an SVG?

I created a little code pen with 3 different types of SVGs https://codepen.io/collection/XEzrkj

After reviewing the normative text of 1.4.5 closely, I believe the following:

• Pass: <svg> with <text> - see https://codepen.io/goodwitch/pen/rNebrZP
  -- why? because you can use css to customize (change font, size, color, and background) the <text>
• Fail: <svg> with <path> drawn text - see https://codepen.io/goodwitch/pen/MWeexRQ
  -- why? because you cannot customize the font
• Fail: with .svg as a src - see https://codepen.io/goodwitch/pen/pobbBeK
  -- why? because you cannot customize the text

Can AGWG make a ruling on this? I'd like us to be consistent with this answer across our industry.

[JAWS-test]

Many thanks for the examples, @goodwitch. I took a closer look at the first example:

• Windows High Contrast Mode does not work (colors in SVG graphics are not adjusted)
• Adjusting the colors per user style is very difficult, because it does not work with e.g. * {color: ...; background-color: ...}, but only with fill. But I have to analyze the source code of each graphic to find out which CSS selector I need to set the correct fill value

I do not consider this to be acceptable. Therefore I would consider SC 1.4.5 only to be fulfilled for SVG graphics if colors are used that can be adjusted without additional effort, i.e. if the SVG graphic inherits the colors of the HTML document and does not define its own colors.

Imagine a document with several SVG graphics, each with different text elements with different backgrounds. Then I have to be an expert in CSS and SVG and furthermore I have to have a lot of time to adjust the colors to my needs.

Another problem is to adjust the font size or to select a different font with a different letter spacing. Both can be easily done in SVG via User Style, but neither the objects in the background nor the graphics as such scale. This means that I quickly run the risk that my text is no longer displayed completely.

[goodwitch]

@JAWS-test from the normative of 1.4.5, Windows High Contrast Mode is not required...right?
And there isn't anything in this SC that says it has to be easy to customize the text.

So...if we are sticking to normative...I believe we've got to let this pass (as a sad low option). OR...somebody needs to add a note clarifying that this is NOT a pass.

In reality...I technically think this is a sad low pass of normative (and should be addressed in a WCAG 2.x release or silver).

P.S. I've always been curious...what is your real name, @JAWS-test ? (I'm Glenda Sims at Deque)

[JAWS-test]

@goodwitch:

• the SC only requires: "the font, size, color, and background can be set". Whether the High Contrast Mode is a form of adjusting color and background or not: there is no information about that. I would say: Yes, it should be. But I am afraid that most people here would deny that (see Do issues with Windows high contrast mode fall under WCAG 2.1? #623).
• of course the SC does not demand that it must be easy. However, I consider the difficulties of color adjustment of complex SVG to be so high that I would not consider the SC to be fulfilled in a WCAG test if I cannot adjust the colors with simple CSS statements. To complicate the situation, I first have to find out if the graphics can be adjusted at all. It would be good if the WCAG Working Group would make a decision and publish it in the Understanding.
• I am sorry: for professional reasons I cannot tell you my name