WebAIM Feedback - SC 1.4.15 – Adapting Text

[jared-w-smith]

As the many GitHub comments indicate, this success criterion is very problematic as written, but notable improvements have been suggested. We generally agree with David’s suggested wording here, with two exceptions…

First, it should be clarified that “text styles of the page can be overridden by the user…”. Exclusion of this language or inclusion of the “a mechanism is provided…” text will invariably result in authors believing that this requires them to provide the functionality via an in-page widget or user preference when this is not (we believe) the intent.

Second, user overrides of “font family” opens up too many variables for testing and should thus be removed. What if the font characters in the user-specified font are significantly disproportionate to the author-supplied characters in size, shape, etc.? The variations introduced by font family customization are, we believe, adequately covered by the manipulation of line, letter, and word spacing. The only other possibility to ensure consistent testability is to define a specific font face (e.g., Verdana) which introduces other notable difficulties.

WebAIM supports the general concept of this success criterion, but additional clarification and consideration is needed in order for it to be viable.

[alastc]

The variations introduced by font family customization are, we believe, adequately covered by the manipulation of line, letter, and word spacing.

That is probably true in sizing, but not for things like font-icons, and that is the most obvious issue when you use a font-override. Given that there is some buffer room needed for the line/letter/word spacing, would an odd font make that much difference?

It is the act of override the font that causes the most issues, not the sizing (at least from trying a few fonts, I don't know that many whacky fonts except wingdings).

[jared-w-smith]

@alastc -

Then I guess we have misinterpreted all of this. If an intent of this technique is to fully disallow icon fonts, why not simply state as much? I certainly didn't consider this in an "Adapting Text" success criterion.

Overriding icon font families makes as much sense as overriding Arial with Wingdings or Chinese and expecting there to be no loss of content. I presume in this scenario that all text content would therefore fail this SC, no?

If the icon font presents content, then this must be provided via SC 1.1.1. However, I do understand the scenario you're trying to address where a user might globally override all font families (is there any data to indicate how common this is?), but where the equivalent alternative for such icons may not presented (it's off-screen or defined via aria-label). But this approach would also introduce an extraneous, likely confusing character in place of the icon font - certainly a cue that something is awry. I don't have a good solution to this, but disallowing icon fonts seems to be a sledgehammer solution - and it's certain to trigger much displeasure from the design community.

[alastc]

Hi Jared,

Font icons are an obvious issue, but like the keyboard SC, it is intended to enable the user action in general. That way it is forward looking if some other technique comes up that prevents people overriding the fonts (colors, spacing etc).

Overriding icon font families makes as much sense as overriding Arial with Wingdings

Indeed, but how does a user with a general UA tool know how not to override font-icons on a particular site? They are just characters in a font, probably in an <i> or <span>. Anything general like * {font-family: Verdana !imprtant;} will kill them.

Changing fonts was a key requirement from the LVTF, but it is possible there is a more elegant way of doing it.

To be honest, I think people are moving away from font-icons, SVG is a better solution without considering accessibility. (And another popular article on that.)

So long as there is a fall-back technique such as marking them with aria-hidden or role=img so the browser tools can identify icons, that should make it feasible.

[lauracarlson]

Hi @jared-w-smith ,

You wrote:

I don't have a good solution to this, but disallowing icon fonts seems to be a sledgehammer solution - and it's certain to trigger much displeasure from the design community.

Agreed. FYI: @alastc has filed Issue 297: Add technique for identifying CSS generated content-images.

I have drafted several techniques for icon fonts one of which is: Providing a Semantically Identified Icon Font with role=img. The objective of this technique is to show how to provide a semantically identified icon font that does not disappear if a user overrides font-family via user stylesheet.

Thanks,
Laura

[lauracarlson]

Hi @jared-w-smith ,

Jared wrote:

As the many GitHub comments indicate, this success criterion is very problematic as written, but notable improvements have been suggested. We generally agree with David’s suggested wording here, with two exceptions...

First, it should be clarified that “text styles of the page can be overridden by the user…”. Exclusion of this language or inclusion of the “a mechanism is provided…” text will invariably result in authors believing that this requires them to provide the functionality via an in-page widget or user preference when this is not (we believe) the intent.

Second, user overrides of “font family” opens up too many variables for testing and should thus be removed. What if the font characters in the user-specified font are significantly disproportionate to the author-supplied characters in size, shape, etc.? The variations introduced by font family customization are, we believe, adequately covered by the manipulation of line, letter, and word spacing. The only other possibility to ensure consistent testability is to define a specific font face (e.g., Verdana) which introduces other notable difficulties.

WebAIM supports the general concept of this success criterion, but additional clarification and consideration is needed in order for it to be viable.

Thank you for your comment and general support of this Success Criterion (SC). The latest SC text, which the AG Working Group has agreed to accept into editors draft for public comment is:

If the technologies being used allow the user agent to adapt style properties of text, then no loss of essential content or functionality occurs by adapting all of the following:

1. line height (line spacing) to at least 1.5 times the font size
2. spacing underneath paragraphs to at least 2 times the font size
3. letter spacing (tracking) to at least 0.12 times the font size
4. word spacing to at least 0.16 times the font size

Note: Examples of text that are typically not affected by style properties are open captions and images of text, which are not expected to adapt.

Editor's note: The Working Group seeks to include overriding text color, background color, and font-family as part of this SC, but is not yet able to identify a way to do so that is sufficiently testable.

It has a scoping clause in place and does not have a requirement for authors to provide a mechanism/widget. Does that help to alleviate your concern?

The SC Text does not specify overrides of font family. As the SC text states, we are investigating that aspect. If you have suggestions, we would love to hear them.

Thanks again,
Laura

[jared-w-smith]

Hi @lauracarlson -

Thank you for your efforts on this SC. I'll need to explore the icon font techniques you and @alastc have proposed, but the changes to the SC text as proposed appear to be acceptable to me.

Are there any scenarios, excluding icon fonts, where content loss may occur by font substitution that are not addressed via the four requirements listed?

[lauracarlson]

Hi @jared-w-smith

You wrote:

Thank you for your efforts on this SC.

You are welcome.

I'll need to explore the icon font techniques you and @alastc have proposed, but the changes to the SC text as proposed appear to be acceptable to me.

Thank you very much, Jared.

Are there any scenarios, excluding icon fonts, where content loss may occur by font substitution that are not addressed via the four requirements listed?

We have been trying to work that out. Please check the Adapting text user to content requirements table.

Thanks again,
Laura

[awkawk]

@jared-w-smith As you indicated that you are satisfied above, closing.