Review CSS Fonts Module Level 4

[michael-n-cooper]

CSS Fonts Module Level 4 may present accessibility challenges that need to be addressed at the spec level - or it may not. Need review to check.

APA tracking of this review

[IanPouncey]

Is there an update on this issue yet @digilou? Please let me know if you need help.

[digilou]

Sorry @IanPouncey I was on vacation a bit. I'll be emailing you tomorrow with some questions.

[digilou]

@IanPouncey @michael-n-cooper here is the only potential problem that stands out to me:

• adding emojis as a font-family.

In 2.1.3 Generic Font Families "emoji" is added as a generic font family option. Emojis have become very common in everyday electronic communication, and are often recognized universally. The questions I have about instituting this as an option:

• Is it universal enough for people to understand (cognitive disabilities)?
• In that case, is alternative or title text available for people who can see, but may not know what it is.
• Are they open and standardized across OS platforms? If not, what are its fallbacks?
• Is alternative text available? Or does the screen reader rely on its own or the UA unicode library?

This may affect 9.3 Selecting the text presentation style: The font-variant-emoji property.

Thoughts about emoji accessibility, and possible workarounds by other accessibility professionals:

• Accessible Emoji
• Accessible Emoji, Tweaked

[michael-n-cooper]

Attempting to understand the spec - I think the "emoji" font family is pretty innocuous, it means "use an unspecified emoji font to render this text", but that should only work if the character codepoints are in the emoji range, and if they aren't it won't work for anybody, so not an accessibility differentiator.

The font-variant-emoji property required a closer look, but I think is probably also accessibility-neutral. It allows the stylesheet to say "display the emoji glyph" or "display a predefined text description of the emoji". That opens the possibility that a user style sheet could kick it into text mode even if the author puts it in emoji mode, which is an accessibility benefit. Hopefully non-visual AT would automatically handle the characters in text-mode anyways regardless of what the CSS rule says - this might be an implementation note we would request in an accessibility considerations section.

My bigger concern is with wingdings fonts, where the font is used to mis-represent characters in order to achieve symbols, a widespread usage that predate emojis and hopefully will die off as emojis become fully mainstream. However, an example in font-display: block indicates the existence of such fonts; it calls it "badly designed" but doesn't say anything further about that situation that I can find. We might want to request in an accessibility impacts section that it advise authors use emojis and not wingdings.

Also, if the WG thinks authors may continue to use such fonts, that may mean there is a need for a "fallback" or "alternative" text on a character level - but I'm not sure if that's a feature for the CSS fonts module, or another CSS module, or some sort of "authoring practice" we might want to develop somewhere.

[digilou]

@michel-n-cooper @IanPouncey Do we need to keep this open for further discussion? Or make a recommendation and close?

[michael-n-cooper]

Potential a11y considerations statement: "When using fonts whose glyphs convey meaning that is not consistent with the Unicode code point, authors need to provide an alternative version."

Also note the homographs are a security issue, so the security people might wanna address that. (credit @AutoSponge for this note)

[digilou]

@svgeesus APA agrees there are no accessibility issues, but would like to include an Accessibility Concerns section. See the following comments from Michael:

Potential a11y considerations statement: "When using fonts whose glyphs convey meaning that is not consistent with the Unicode code point, authors need to provide an alternative version."

Also note the homographs are a security issue, so the security people might wanna address that. (credit @AutoSponge for this note)

[svgeesus]

Thanks for the update! By an alternative version do you mean an alternative font, or alternative text?

[digilou]

Good catch @svgeesus! Alternative text.

[svgeesus]

I'm going to change "need to provide" to "should provide" because RFC2119 - "need to" does not indicate a requirement level.

[svgeesus]

@michael-n-cooper wrote:

My bigger concern is with wingdings fonts, where the font is used to mis-represent characters in order to achieve symbols, a widespread usage that predate emojis and hopefully will die off as emojis become fully mainstream. However, an example in font-display: block indicates the existence of such fonts; it calls it "badly designed" but doesn't say anything further about that situation that I can find.

It does say why it is badly designed, in the context of fallback fonts:

so if the text is displayed with a fallback font instead there will be confusing letters scattered around the page rather than the desired icon

it fails though to say why it is badly designed in terms of screen readers (you will hear "C" read out, which makes no sense) and also fails to say what a better designed font would do.

Since Unicode 7.0 there has been a "printer" character, U+1F5A8 🖨 so I propose to:

1. link this example to further discussion in the Accessibility concerns section
2. explain that a well-designed font would associate the printer glyph with the printer character, and explain that this will work better for all users (people using screen readers, and people using fonts).

However, could someone who uses a screen reader tell me how this next paragraph is read?

This is a 🖨

[svgeesus]

I just added this, how does it sound?

The use of fonts to provide a visual rendering of text should not, in general, impact accessibility. For example, people using a screen reader to render text to speech will not download fonts, and are unaffected by what those fonts would have contained.

However, this assumes that the semantics conveyed by the font glyphs and the semantics conveyed by the characters are the same.

Historically, this has not always been the case. For example, in the early days of the Web it was common to use fonts (such as "Symbol", though others were used) to make Latin letter have Greek glyphs; while this worked visually, it would not work with a screen reader and text was also hard to search or index because the mapping was font-specific. With the rise of Unicode, it is now standard practice to use Greek characters for Greek text, and for Greek glyphs in fonts to map to Greek characters.

Sadly, but avoidably, this practice persists with badly designed icon fonts. For example, such a font might put a "printer" icon on the Latin letter "P". This practice scatters meaningless letters through the text, which negatively affects text searching and indexing, gives hard to understand rendering if the icon font does not load, and impedes screen readers. A well designed font must assign such icons to semantically meaningful characters. For example, the printer icon might be assigned to the string "printer" or to the Unicode character 🖨 U+1F5A8 (PRINTER).

[JAWS-test]

@svgeesus

However, could someone who uses a screen reader tell me how this next paragraph is read?

Acoustically, JAWS and NVDA output it as "Printer" (as text, not graphics). On the Braille display, it is output as an unknown character or not, because there is no equivalent in the Braille alphabet. This is problematic because there are people who rely only on the Braille display (either because they are deaf or because they have to make a phone call at the same time).

Please also note that many Unicode characters are not output acoustically by the screen reader either, because it does not know them. The screen readers know the printer character because it is often used. Most characters are not known to the screen reader.

The solution here in GitHub is better: The character is displayed as a graphic with alternative text.

[svgeesus]

Thanks, @JAWS-test for the information.

I think the issue of limited Unicode coverage in screen readers, and limited Unicode coverage in Braille displays, should be treated separately to "mismatch between Unicode code point and glyph". Partly because they seem to have very different, and potentially conflicting, solutions.

[digilou]

@svgeesus for the most part we really like (and appreciate!) the suggested text you proposed. We have one concern about your proposed text for an Accessibility Considerations section. APA suggests including a more prescriptive listing when it comes to using emojis or images in fonts. Based on research that @autosponge has done in the past, we suggest adding the following how-to hierarchy to achieve greater accessibility, while meeting developers where they are:

1. Wrap the emojis in role=img and add some alternative text. This has the highest support level.
2. Use a ligature font to ensure that Braille devices will convey the same information as a screen reader.
3. Use the correct astral planes and unicode code points. This will help screen readers, but leaves Braille devices behind.

[svgeesus]

The @AutoSponge resource is really interesting, thanks for the pointer! Given

Caveat: I'm not an expert in unicode, foreign languages, or screen readers

it would be useful to get some I18n and Unicode expert review on that document. Maybe TAG review too?

Turning now to the specific points:

1. This is a markup suggestion. In general, CSS gets given the markup, CSS tries to avoid saying "change this markup so we can style it easier". So I can suggest the markup, but can't (in CSS Fonts 4) require it.
2. Could you explain what is meant in more detail? I'm not very familiar with Braille fonts or Braille processing, and how they use ligatures. An example would really help.
3. Yes, of course :)

[svgeesus]

The solution here in GitHub is better: The character is displayed as a graphic with alternative text.

Here is the HTML markup that GitHub generates for character 🖨 U+1F5A8 (PRINTER):

character <g-emoji class="g-emoji" alias="printer" 
fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f5a8.png">🖨</g-emoji> 
U+1F5A8 (PRINTER).

[AutoSponge]

1. This is a markup suggestion. In general, CSS gets given the markup, CSS tries to avoid saying "change this markup so we can style it easier". So I can suggest the markup, but can't (in CSS Fonts 4) require it.

Even if this is a NOTE, it's more clear to the developer what will have the widest support when the implementation is not a ligature (see below). This is the most common approach for wrapping non-standard text (emojis, emoticons, etc.) generated from user supplied content (e.g., tweets).

2. Could you explain what is meant in more detail? I'm not very familiar with Braille fonts or Braille processing, and how they use ligatures. An example would really help.

AFAIK, ligatures render characters to the page which CSS transforms into the image that's mapped to that specific sequence of code points. This means that Braille displays get the correct number of characters to display (as plain text).

When an emoji is used, its code point(s) have no corollary Braille characters and when the display is limited to a set number of characters, even if it wanted to expand the emoji into its well-known name, it may not be able to.