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.