Earlier quoted context omitted.
This is generally a bad idea for accessibility reasons: • Screen readers won’t be able to do anything with it; • Some mobile users especially will turn off web font loading; • Even if custom fonts are enabled, it’s not terribly uncommon for them to fail to load for any number of reasons; • It’s best for performance if you can do something like `font-display: optional` or `font-display: fallback`; but if you are actua…
Sure, but all of those negatives are also true of the thing you’d use in place of a private-use codepoint: an inline-reflowed image. Private-use codepoints at least have the advantage over inline images of being “opaquely” copy-and-paste-able into other documents, machine-read, etc. Any system that works in term of Unicode text will pass along the private-use codepoints in the stream, where it might strip higher-leve…
Not true: your inline image should have alt text, e.g. if ⅌ didn’t exist then you’d use an image of that shape with alt="per". If the image doesn’t load, it’ll be replaced by the word “per”, and screen readers will read it as “per” or “graphic per” or similar (I believe JAWS adds that “graphic” prefix, not sure if you can convince it not to by careful ARIA attributes—or even if you can, whether you should; these things are a bit dangerous to fiddle with).
Alternatively you might use inline SVG, which gets you vector goodness, and can definitely (rather than possibly) be presented to screen readers as the word “per” perfectly.
Another fancy trick is to use ligatures to replace entire words: make your own fancy web font replace the sequence “ per ” with “ ⅌ ”.