Add icon fonts to the definition of non-text content

[steverep]

Given the ubiquity of icon fonts across the web, I propose we make a simple edit to the note in the definition of non-text content. Given that emoticons are already in the note, this is not much of a stretch and may provide some clarity. The potential change might be simply:

Note: This includes ASCII Art (which is a pattern of characters), emoticons, font icons, leetspeak (which uses character substitution), and images representing text

[DavidMacDonald]

+1

[WayneEDick]

+1 for many reasons. The addition of a text alternative with the element that includes the special character will identify it as something to not be overwritten during font substitution.

[patrickhlauke]

Agree. Related, this should then also be reflected in https://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html

And lastly, it would be good to get a (non-normative, of course) technique related specifically to how to safely mark up use of icon fonts, covering both decorative uses (where you'd want to, usually, hide the container of the icon font character with aria-hidden="true") and some meaningful content uses (where there are many possible ways to convey the meaning of the icon, depending on the situation, but perhaps offer a few examples like using aria-label if it's a <button> that only uses an icon font, adding visually hidden additional text and aria-hidden="true" hiding the actual icon again, etc).

/cc @alastc since this touches on a conversation we had the other day (https://twitter.com/patrick_h_lauke/status/864486087611346944 and https://twitter.com/patrick_h_lauke/status/864488983266562052)

[alastc]

I agree with this change, but the scenario that's missing from @patrickhlauke's outline is when an LV user overrides fonts and/or backgrounds and icons disappear.

If they have visible text it isn't (much of) an issue, but this would be an issue: <span class="icon" aria-hidden="true"></span><span class="off-screen">Bookmark</span>

Or a version which uses before/after pseudo content for the icon.

This has an alternative in text, but hidden text is still hidden, so an LV user doesn't get anything. Trying to show all hidden text would be fairly disastrous in terms of breaking layouts and showing things that shouldn't be shown (e.g. dialogues for other states).

What we were discussing was adding a technique so the above would be something like: <span class="icon" aria-hidden="true" role="img"></span><span class="off-screen">Bookmark</span>

I'm not 100% on that as the solution/technique (role=img + aria-hidden?), but some means of indicating this element has an image that is content.

We could also add a failure of not doing something visible, but that's probably easier once the possible solutions are agreed.

[patrickhlauke]

What we were discussing was adding a technique so the above would be something like: <span class="icon" aria-hidden="true" role="img"></span><span class="off-screen">Bookmark</span>

Not quite. You're seemingly trying to force a particular pattern again, which was the point of my discussion...this is bad/restrictive.

Instead, yes define a role="img", but then make sure that image has alternative text that's associated with it in accordance with the accessible name and description algorithm, as that covers many different ways to achieve it. for instance, you could (though i've not gone through testing all of these in real-world UA+AT combos) explicitly set an aria-label on the <span>

<span class="icon" role="img" aria-label="Bookmark"></span>

or add an aria-labelledby relationship

<span class="icon" role="img" aria-labelledby="foo"></span><span class="off-screen" id="foo">Bookmark</span> [edited to remove the stray aria-hidden]

or similar. don't try to enshrine only one possible way to mark things up, but allow for any kind of valid way of providing an accessible name/description.

[alastc]

But "an accessible name/description" does not solve the problem, which is:

when an LV user overrides fonts and/or backgrounds and icons disappear.

What solves that problem?

Side by side example:

Note that SVG icons are fine, but font-icons become squares.

Your examples all included role="img", which is all that we're looking for, and of-course it should also include an accessible name/description, but that's a problem with a current solution covered by WCAG.

[patrickhlauke]

But "an accessible name/description" does not solve the problem: when an LV user overrides fonts and/or backgrounds and icons disappear.

Nothing on its own solves that problem. So presumably you're still thinking of using a user CSS? if so, then you need to devise a user CSS, possibly combined with extra javascript, that understands the various ways in which accessible name/description can be implemented by authors, and in the case of elements with role="img" surfaces the accessible name/description instead of the icon font

[alastc]

Yep, there are already working examples out there, e.g:

*:not([role="img"]) {
font-family: Comic Sans MS, Georgia,'Times New Roman',serif;
}

It isn't a case of surfacing the name/description, LV people in this scenario want to see the icon, not replace it.

I think the next step is a test page, but I'll start a new issue rather than continue tangenting on this one.

[patrickhlauke]

The only reliable way in which icon fonts can be made impervious to basic user setting of a different font to override author-defined fonts is...not to allow icon fonts.

IF you are still looking at the user CSS approach, an initial way to tackle this if authors do use role="img" is to explicitly exclude elements with that particular role from any forced font substitution

[patrickhlauke]

Yep, there are already working examples out there

so what's your beef with saying "But "an accessible name/description" does not solve the problem"? I didn't claim it would. what i suggested, as you can see from my examples, was not JUST accessible name/description, but did also include the role="img" which, as you say, is a working example...

[alastc]

I just meant that having an accessible name/description is already an agreed requirement in WCAG, but identifying background images as images is not. So that is the problem we're trying to solve, in violent agreement by the looks of it ;-)

[mraccess77]

Ø Bookmark

Given the placement of aria-hidden I don’t think this would be seen by AT.

[patrickhlauke]

@mraccess77 ah good catch, that was a copy-paste error on my part from just grabbing the preceding example. fixing it in my original comment...

[jake-abma]

Given the ubiquity of icon fonts across the web, I propose we make a simple edit to the note in the definition of non-text content.

When first read I also gave it a +1, after reading all info and thinking about it I have mixed feelings. Isn’t it so we’re trying to solve a problem for a technique which is somewhat hacky in it’s nature?

A font file is supposed to be for fonts, not icons. Fonts can be replaced by other fonts and everything works fine. Some symbols are added to font files but these are still general in nature like the copyright symbol and are present in other font files. (ab)using this vector based technique instead of using SVG which works way better causes the problem to begin with. Should’t we discourage this, like not promoting tables for layout, also as Patrick says:

The only reliable way in which icon fonts can be made impervious to basic user setting of a different font to override author-defined fonts is...not to allow icon fonts.

?

When we do support this we’re in for WAI ARIA solutions which are also a bit laborious.

Adding role=“image”, withholding an accessible name (or adding aria-hidden="true”) so it won’t be added to the A11Y API when it’s decorative or demanding to add aria-label or aria-labelledby. Prescribe a solution to solve this at the CSS level with “*:not([role="img”])”...

If done well we could provide a specific solution, still breaks existing implementations, not sure if we really want to do this.

[patrickhlauke]

@jake-abma while i'd love to be able to say that authors are barred from using icon fonts, the reality is that they're used quite extensively. so offering a way to at least mitigate their problems and infusing some modicum of semantic meaning is, in my view, a good pragmatic first step (as long as it's just a suggested technique, and not made mandatory somehow)

[alastc]

I suggest keeping the discussion of solutions in #297 unless you don't think icon fonts should be in the definition of non-text content?

[steverep]

@jake-abma, this change was not about solving a technique, but rather an acknowledgement that font icons are not considered text, and therefore at the very least need a text alternative due to 1.1.1. I do not think we need a technique specific to icon fonts in order to make this simple change.

[joshueoconnor]

Closing this as relevant discussion has moved to #297

[steverep]

This is not a replica of #297. This issue was proposing a specific change to the glossary definition, whereas the latter issue is meant to discuss techniques and failures.

[joshueoconnor]

@steverep Ok, np. I'll re-open but please let me know when dealt with so we can close. Thanks

[steverep]

This would be a change to a 2.0 Note, not the normative text, so I'm not sure how we would proceed here. Also, perhaps a bigger issue is that notes from WCAG 2.0 glossary terms do not seem to have been imported as notes in WCAG 2.1. Rather, they appear along with the normative text.

[WayneEDick]

I take it that this technique is necessary because failure to identify the role of icon fonts as role of image is a failure of 1.3.1.

I really like the goal of this as enabling user CSS.

One place where user CSS is very practical is with EPUB format. It is very easy to add user CSS in many places in the EPUB package, and many user agents (readers) respect the CSS changes. Some readers allow user style sheets.

It would be very useful to have a protocol for applying style to eBooks without having to write a reader extension.

Wayne

[joshueoconnor]

@steverep a PR against an existing note outlining the suggested additional text would do it.

[steverep]

@awkawk, I added back the defer label here. I presume you added and then removed it by mistake. This needs to be flagged for future discussion in a later release.

[awkawk]

I added it by accident and then removed it. I was planning to re-add it is the CFC passes.

[awkawk]

Thank you for your comment. The Working Group is not making changes to definitions that were introduced in WCAG 2.0 at this time, out of an abundance of caution regarding possibly changing the understanding of what the normative definition is for the terms. We will mark this issue as “defer” to ensure that it is re-reviewed at the next opportunity.