Is the accusation that smallcaps significantly hurts my question's software compatibility well founded?

Question

An edit was suggested to my recent Polaris question. The edit reason was:

replace the weird font tricks with regular characters, for search engine and translation software compatibility

I rejected the edit because smallcaps are used in the Polaris rules to denote key conflict phrases and this markup is particularly important in making my question easy to read. We have an established tradition in other system's Q&A of using the published formatting when possible to denote e.g. spell, magic items, so I figured this would be good practice in general, in addition to particularly being useful for my question.

However, it would be bad if people are unable to read the question because of smallcaps, or if they were unable to find it via Google for that reason (though in the latter case that sounds like a problem Google would probably be interested in solving). Are the objections given as reasons for the edit well founded? Should I remove the smallcaps?

Answer 1

Yes, the small caps you're using are bad for machines. People also may have issues with them.

AceCalhoon pointed us in comments to a question on Super User about the usage and purpose of these glyphs. The top answer explains they're not intended for usage as regular written text, and that trying to use them that way breaks stuff:

Those characters are not intended for regular Latin-alphabet text but for phonetics, Cyrillic-alphabet text, for use as mathematical symbols (representing variables), or similar.

I recommend just bolding or italicising your special terminology (e.g. as Let us discuss this further or Let us discuss this further), and picking a more ordinary sort of title. I would recommend this even if machines could handle the small caps.

---

This analysis strictly applies to using the Unicode smallcaps characters to assemble smallcaps text, and does not reflect upon small caps in general. PDFs have a way to make small caps machine-friendly via providing a machine-friendly layer. Websites can also make screen reader friendly smallcaps via CSS styling, but that isn't available to us via markdown.

Screen readers: unintelligible

I downloaded the latest version of NVDA, one of the popular screen readers I'm accustomed to from my accessibility work, and ran it through your question. What it read out was mostly unintelligible. The small caps sections were gibberish, and it was hard to recognise when the normal English words were starting again before the screen reader had already dived right back into another section of gibberish.

Out of concern your generator may be using Cyrillic characters where it should instead be using the Unicode standard small caps, I assembled the text "ʜᴇʟʟᴏ ᴛʜᴇʀᴇ" using excusively those Unicode small caps. It was similarly unintelligible.

The Unicode wikipedia article I just linked has certain paragraph text in small caps. It's perfectly legible. It's rendered in small caps due to the CSS styling I mentioned above, however.

Google: can't work with your smallcaps text very well

If I google for the text "struggling with escalating" on our site, I find your question just fine. Google has your question indexed. You'll notice the "struggling with escalating" phrase is bolded in the search extracts.

If I turn it into "struggling with escalating" but only if or "struggling with escalating" let us discuss this further, none of the small caps text is bolded.

If I search specifically for your smallcaps text with "struggling with escalating" Lᴇᴛ ᴜs ᴅɪsᴄᴜss ᴛʜɪs ꜰᴜʀᴛʜᴇʀ, Google bolds that text just fine, indicating it doesn't treat the Unicode smallcaps characters as equivalent to ordinary text.

Google Translate has no idea what to do with the text "Lᴇᴛ ᴜs ᴅɪsᴄᴜss ᴛʜɪs ꜰᴜʀᴛʜᴇʀ" but can work with "Let us discuss this further" just fine.

People: may dislike it

Small caps usage can be a useful formatting convention sometimes. When established as a standard style in a document it can be very useful for helping special terminology stand out.

RPG.SE doesn't use that convention. Instead, our formatting choices include bold and italic for special terminology, and we can use those regardless of how they're formatted in the RPG's text.

Bucking our common formatting conventions can be unwelcome. In this case, the esoteric title and body text can be seen as an attempt to grab attention, and Stack Exchange users generally dislike attempts to grab attention whether via esoteric titles, funny images, or other methods.

The book using small caps as a convention is fine, but that's a convention that requires translating into a different equivalent convention here: bold/italics.

Answer 2

The F in your iterations of Let Us Discuss This Further appears as a white box for me. Kind of a case-in-point: if this is happening to me, it’s happening to others, it’s degrading the readability and accessibility of the website, and therefore it should not be done. This site does not offer any feature that will correctly render small caps, and faking it through abusing obscure Unicode characters is a terrible idea (here and anywhere else).

Answer 3

The observation is founded

1. Style is secondary to comprehensibility

Though we do prefer to maintain the style used in sources, this isn't a hard rule and is always secondary to making sure posts are comprehensible.

We also have a limited palette of styling tools available and have to make do with them.

2. These aren't small-caps anyway

These aren't small-caps versions of letters for the most part, they're mostly International Phonetic Alphabet (IPA) symbols, with the s being a normal lowercase s and the ꜰ character being the only real small-cap character, but part of the unreliably-available Latin Extended-D block (“a Unicode block containing Latin characters for phonetic, Mayan, and Medieval transcription and notation systems”).

Semantically these strings of characters are gibberish — it just happens that sighted non-computer readers see their resemblance to small capital Latin alphabet letters and can parse the result as words. This is much like how • can be typed in front of a sentence, but it only visually resembles list formatting and doesn't create an actual semantic list item, or you could write ‘Р’ instead of ‘P’ but the computer will still think (correctly) that you want it to transmit a Cyrillic letter Er and that you mean a rolled r sound should be produced.

In theory, a computer could be taught to “understand” that humans misuse Unicode characters for visual effect, and be given a translation table to be able to figure out which semantic characters the writer intended another human to believe they were seeing. In practice this is impractical until we have near-AI though, because though such a translation table would be easy to implement, it would be very difficult to teach the computer when to not apply the translation and instead interpret them as their actual meanings — syllables in IPA, or Cyrillic letter sounds, or whatever. That kind of fine, contextual nuance is currently beyond or barely within our programming abilities. And besides, avoiding having to make the computer guess what a character is “supposed” to be is why Unicode was invented.

But that's a tangent. The bottom line is that these letters have specific meanings already and a computer is going to do what it's been told, which is to treat them as strings of (mostly) IPA symbols.

Use available styling instead

For game technical terms, we typically capitalise or bold them. In this case capitals would be less faithful to the source, so bold it is.

This won't be misunderstood by anyone or -thing, and serves to accurately delimit which parts of the question text are mentions of game-mechanical phrases and which parts are the question itself.

A tangent about Unicode in URLs

Some browsers can paper over it in some circumstances, but the fact is that most bare Unicode characters aren't legal in URLs and there's a special scheme to encode them so that the page fetch request will be correctly understood on the other end. That scheme makes http://rpg.stackexchange.com/questions/94462/lᴇᴛ-ᴜs-ᴅɪsᴄᴜss-ᴛʜɪs-ꜰᴜʀᴛʜᴇʀ actually be the URL http://rpg.stackexchange.com/questions/94462/l%E1%B4%87%E1%B4%9B-%E1%B4%9Cs-%E1%B4%85%C9%AAs%E1%B4%84%E1%B4%9Css-%E1%B4%9B%CA%9C%C9%AAs-%EA%9C%B0%E1%B4%9C%CA%80%E1%B4%9B%CA%9C%E1%B4%87%CA%80 (notice the hyphens and lowercase Ss scattered in there, which didn't need percent encoding). That's why sometimes copying and pasting the URL of the question visually preserved the small-caps-hack characters and sometimes it didn't.

Answer 4

The reasons are well-founded. The original question was not written in English. This meant it was extremely difficult to access the page using a screen reader.

The SuperUser question Why shouldn’t I use Unicode characters to simulate typographic styles (such as small caps or script)? (linked a couple of times already) has a lot of reasons but it misses the important one, that is, tricks like that make the web harder for disabled people to use. We should be making things easier to use for disabled people, not harder.

As an aside, making things easier for screen readers also makes things easier for search engines. One of the early goals for the StackExchange network was to be the top search result in Google.