Unicode Roman Numerals and Screen Readers
shkspr.mobi
shkspr.mobi
There’s a difference between listening to an audio book or proofreading text, for example. In the latter case, the user may want to hear “capital X”, not “ten” in “Act X, scene III”.
For proofreading, blind people often prefer their TTS system to be predictable rather than smart, but often wrong.
For example, Apple’s TTS tended to pronounce the “Read” in “Read me.txt” in the past tense, but that didn’t bother users much. Its imperfect smartness around abbreviations (“Dr. Mulholland” vs “Mulholland Dr.”, “St. Albans” vs “Albans St.”, to mention a few) bothered them more.
(Weirdly, the iOS TTS system seems to handle these worse than MacinTalk did around 1990)
And then there are cardinal vs ordinal contexts:
Mac OS X -> "ten"
Pope John X -> "the tenth"
Malcolm X -> "ex"
King's X -> "cross"
X-mas -> "christ"
X-ing -> "cross"
10 X 2 -> "by" or "times"
Although on the other hand, now that I think of it, what's wrong with the zebra crossing?
In Max Headroom, the main television network, Network 23, was owned by the ZikZak Corporation, controlled by an Asian CEO named Ped Xing.
Giving him a street sign name follows a pattern established by Max himself, who (in universe) was a sort of digital reconstruction of the connectome of maverick journalist Edison Carter. (In real life he wasn't even CG, just actor Matt Frewer in prosthetic make-up!) The last thing Carter saw before his seemingly fatal motorcycle crash was a sign that read "MAX HEADROOM 2.3M"; the "headroom" term being common in Britain where American signs might use "clearance".
> Although on the other hand, now that I think of it, what's wrong with the zebra crossing?
"PED XING" is painted on the road (or written on a sign) to alert drivers of an upcoming zebra crossing.
The painted-on-road signs are written in reverse word order so that each word is readable in order as you approach by car. Another one seen on U.S. freeways is "SLOW VEH LANE", written as "LANE VEH SLOW".
https://external-preview.redd.it/_3aW7Flq4ATeZSTqkEnbU0PHOYU...
Therefore you'll typically see "XING PED" or even "XING PED NO" which are both intended to be read in reverse, as the driver drives.
Text that's written left-to-right and then right-to-left and then left-to-right again is named, in Greek, "boustophedron" after how the ox plows. I wonder what bottom-to-top road writing is called in the jargon lingo?
In Europe they are written as you'd read them, so top to bottom.
You'll see STOP BUS.
BUS
STOP
_____
o o
|x |
| |
o o
=====
But while driving it doesn't. It reads opposite. Yet it doesn't mean that a bus needs to stop there. It's a place for the bus to stop, should it drop off passengers, and / or there are people waiting to get on.
But since you're driving you read bottom to top and you'll see STOP BUS.
In the US they're smarter, and you'll see
STOP
BUS
_____
o o
|x |
| |
o o
=====
While I get the logic of that idea, in practice at least for shorter texts that e.g. fit on two or maybe even three lines you're often/usually? still able to read the whole thing in one go and in the regular top-to-bottom order, so now you're wondering what a "Lane Fire" is supposed to be.
> When I was a kid, and I would see the school crossing signs, and there's a picture of the little kids walking, and then it would say "School Xing" And I thought that the "Xing" was a word. And I pronounced it "zing."
It's PED XING, as in "Pedestrian crossing." It's read in order as you approach each word, not from a satellite view.
(A Google Image search shows examples of "PED XING" alone, but I don't know if this is official or common.)
[1] https://en.wikipedia.org/wiki/File:Denmark_road_sign_A17.svg
[2] https://en.wikipedia.org/wiki/File:Denmark_road_sign_E17.svg
(Red triangles are warnings, and blue rectangles are information. The blue sign is used at the crossing, and the red one some distance before if if that's necessary -- typically on faster roads.)
The text is intentionally fully-redundant with the graphic, when both are used.
EDIT: Not sure what I did to elicit so many downvotes on a personal anecdote. I was not advocating the exclusive use a PED XING sign just giving a situation where zebra crossing markings may be insufficient.
See also in transport timetables, where every other country in the world would use a 24-hour clock, the USA not only uses the 12-hour clock, but furthermore does an extra layer of abbreviation used only in the USA and nowhere else. I was in a New York airport staring at signs saying 9:06p and similar for several minutes before I even worked out they were supposed to be times. The US makes no accommodations for tourists even in major international transport hubs. Strange country.
It's not weird at all. The rules were created at a time when the United States was very monolingual.
Europe made its rules around symbols because there are lots of people speaking lots of languages next to one another and crossing borders.
Not weird at all. Just logic and history.
That also is the reason why, even today, the train on traffic signs is a steam train; it makes it easier to distinguish it from a truck.
I also would be curious when, if ever, the USA was “very monolingual”. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4092008/:
“At the time of independence, non-English European immigrants made up one quarter of the population and in Pennsylvania two-fifths of the population spoke German. In addition, an unknown but presumably significant share of the new nation's inhabitants spoke an American Indian or African language, suggesting that perhaps a third or more of all Americans spoke a language other than English. With the Louisiana Purchase in 1803 (which doubled the size of the country), the Treaty of 1818 with Britain (which added the Oregon Country), the Adams-Onís Treaty of 1819 with Spain (which gave Florida to the U.S.), and the Treaty of Guadalupe Hidalgo in 1848 (which acquired nearly half of Mexico), tens of thousands of French and Spanish speakers along with many more slaves and the diverse indigenous peoples of those vast territories were added to the linguistic mix.”
https://en.wikipedia.org/wiki/Comparison_of_European_road_si...
I’ve also seen them on roads where the median strip was over 10 meters wide, with a ditch _and_ guard rails. I guess that’s what they have SUVs for.
That’s a problem that a lot of countries solved a long while ago… The solution is a bit of paint every 10 years or so.
There are cultural reasons, with the US preferring words and abbreviations and steadfastly refusing pictures that are standard in most of the world. But it is not a technical problem.
It's not clear to be what else you think the water might be obscuring in this scenario. Maybe potholes, on poorly maintained roads you're not familiar with? At least where I live, that's not a problem.
Technically:
* https://en.wikipedia.org/wiki/Chi_(letter)
> The 'X' comes from the Greek letter Chi, which is the first letter of the Greek word Christós (Greek: Χριστός, translit. Khristós, lit. "anointed, covered in oil"), which became Christ in English.[1] The suffix -mas is from the Latin-derived Old English word for Mass.[2]
That's internet revisionist history.
The real reason was to save space in writing. "X" as an abbreviation for Christ is very common in Christianity, and has been for a couple of thousand years now.
Even Roman Catholic priests' robes have "ΧΡ" on them as an abbreviation for "Christ."†
† https://www.catholic.com/qa/what-does-the-symbol-of-the-p-wi...
Even the abbreviation has a history. And a couple Unicode symbols: and ⳩ (weirdly, one displays in HN and the other does not.)
A lot of accessibility knowledge and work is spent just on primitive bugs and shortcommings of screen readers. If only screen readers added a few dozen lines of code, the entire world wouldn't need so many workarounds for them.
Introducing Roman Numeral VII into a document would require googling in every combination of operating system and software.
I've always found it kind of funny that it's easier to type a smiley than an em-dash in most software these days.
Really?
https://en.wikipedia.org/wiki/Cuneiform_Numbers_and_Punctuat...
How should 𒐉 be read exactly? Should it just say "Cuneiform Numeric Sign Four Dish"? Should it say 4? Should it say 4, but in Arameic? How should it deal with the fact that the system didn't have a symbol for the Radix Point, and so the actual value of numbers depends on context?
The point of a screen reader isn't to simply declare what characters are on the screen. Otherwise, it wouldn't be able to read English. The point of a screen reader is to interpret human-readable text into human-listenable sound.
How is that character typically used? Perhaps as a scientific signifier of units? Or as an insert for another letter to create emphasis? Maybe both! Can the screen reader infer the context from the surrounding text? Or perhaps it's just a rarely used symbol, and the default output should be a blip that indicates a symbol or something.
But c'mon, it's pretty obvious how roman numeral unicode characters should be read. The software shouldn't choke on those!
Maybe it is in this special case, but it still sets a precedent that could lead to making something that should be simple and robust to something that is overengineered and complex, just because it has to accomodate an ever-increasing number of special cases, despite these cases making up a miniscule amount of the problem space.
However, now that I think of it, it isn't even obvious in this special case. Yes roman numerals do have unicode code points, but many documents just represent them using latin letters instead, because it is easier to type and doesn't require unicode support.
Now, should the screen-reader read "IV" as "Four" or as "I-Vee", which is a common abbreviation in medical texts? Sure, we could say "If it isn't using the unicode roman numeral, then its latin letters", and I am sure that it wouldn't be long for people complaining that this is a missing feature.
No, I don't think screen readers should do that unilaterally! That case—where latin letters are used—is legitimately tricky for the reasons you describe. If screen readers get it wrong, I understand.
What I'm talking about is the other case, in which the author used the roman numeral unicode characters specifically. Most of the software in the article did worse with those characters compared to the latin letters! There's really no excuse for that!
Yes there is, and it's a pretty good one: The occurrence of these symbols make up a miniscule fraction of the problem space, and they can be written using our everyday arabic numerals without any loss in context or information.
I do not think that any time anyone on the internet writes "XV" to represent "15", they should be required to use the special roman numeral characters. I certainly don't intend to do that in my own life—I don't have enough hours in my day—even though I recognize the problem it represents for screen readers.
However, if I do go out of my way to use the special unicode characters, that should not trip up screen readers! I have done the screen reader an extra favor that they should be taking advantage of.
As an imperfect analogy, imagine if a screen reader was ignoring the alt text on images. You might say "well, images with alt text represent a small fraction of the problem space", considering how many photos are casually uploaded to Instagram every day. And I agree—the internet is always going to contain some untagged images, and especially with the rise of AI, I'd love to see screen readers actually attempt to describe them. However, that is not an excuse for ignoring alt text when it is present! Covering "edge cases" like this is the core job of the screen reader!
It is exactly the "going out of my way" that makes software tripping up on this understandable to me.
It's not a common occurrence. Simple as that. Same as Babylonian Cuneiform Numerals are not. Sure, it's way more likely that a screenreader has to read a Ⅳ than a 𒐉, but compared to the size of the problem space, both are just miniscule, and a system that doesn't handle either, will still behave correctly almost the entire time.
> You might say "well, images with alt text represent a small fraction of the problem space", considering how many photos are casually uploaded to Instagram every day.
But images are a common occurrence in the problem space. The fact that the `alt` attribute is often not set, doesn't change that.
In addition, the `alt` attribute is a simple system, designed with systems having to parse it in mind, that conveys a tangible advantage over not using it. What advantage does writing "In Hamlet, Act Ⅳ, Scene Ⅸ..." have over writing "In Hamlet, Act 4, Scene 9..."?
If you know that they actually exist as separate code points then yeah, sure, it's kinda obvious. The same is true about "AV", "st" and "ſt" ligatures, I guess.
There's really no excuse for any Unicode symbols not to be properly read by a screen reader, except developer cluelessness or carelessness.
It's typical 2020's internet moaning: "Stop liking things I don't like."
Why do people wear suits and dresses to fancy events? Formal clothing is no more functional than casual wear, it's merely more annoying to put on and harder to move around in. People wear formal clothing because of the effort required—if everyone is willing to get dressed up for a party, the party must be special enough to be worth dressing up for!
Roman numerals are similar; they confer an additional sense of prestige precisely because they are more difficult to read. The XXI Olympic Games must be something really special, because you went through the effort to decode "XXI".
XIV+XXIII = XXXVIIII = XXXIX
VI*VI = VI*V+VI*I = VVVVVVIIIIII = XXXVI
Subtraction is a little tricker since you need to convert numerals first but it is very simple to do in your head once you get it down and is easier to do in your head than on paper, same with multiplication and addition.
XXII-IV = XVIIIIIII-IIII = XVIII
I bet you love both Roman's and their numeral system now. Next up, Vernier and his wonderfully accurate scale that lets your eyes see a difference of microns or even thousandths of an inch.
14 + 23 = 39?
This is a good example what makes roman numerals bad: sometimes a I means 1, sometimes it means -1.
Bloody French.
1. The President of France is also, ex-officio, Co-Prince of Andorra, so their president is a monarch, though he's not a monarch of France.
2. The Wallis and Futuna Islands, which are an overseas collectivity of France, is still divided into three kingdoms with recognised kings.
It’s a way of thinking common with some engineers: the problems are supposed to simplify themselves to fit in their nice and neat solutions. It’s very, very common here. It’s almost cute to see it resurfacing every single time the opportunity arises. You can be certain that at some point, someone will advocate for a neat sexagesimal or hexadecimal system because division.
The world is what it is.
The world could be better.
The world still is what it is.
Your software not handling Roman numerals won't stop people from using them.
There are times when making a futile stand against It, which will neither stop It nor slow It down, is necessary for your own psychological well-being. If you draw that line at the existence of Roman numerals, well, go in peace. However, saying that Roman numerals are pointless and shouldn't exist and therefore your software won't support them is really only screwing over the people who rely on that software because you insist on trying to derive Is from Ought.
People stopped using the þ and ȝ in English because the technology at the time couldn't handle it. People adopting new practices and habits to make it easier for technology is as old as technology.
There are few people who can read MCMXCVI fluently. It's not accessible for the majority of the population, with or without screen reader. Just don't use Roman numerals if you want your number to be widely understood.
Yes, but it will make my software easier to write, grok and maintain, all things that are beneficial to handling the 99.999% of the problem space that doesn't include an ancient way of writing numbers.
There's always going to be a painful tail of slow adapters with standards.
No, but I do compare the amount and importance of occurrences in a problem space, with the amount of work and fallout the solutions to accomodate these occurrences will cause.
* https://en.wikipedia.org/wiki/Cistercian_numerals
Proposed for, but not in, Unicode:
* https://www.unicode.org/L2/L2020/20290-cistercian-digits.pdf
* https://www.kreativekorp.com/ucsur/charts/cistercian.html
* https://news.ycombinator.com/item?id=34588808
For the LaTeX users:
https://www.researchgate.net/figure/The-cuneiform-notation-o...
See also, the history of zero: https://en.wikipedia.org/wiki/0#History
No, it pronounced it “one thousand, nine hundred and ninety-six”—a number rather than a year. I’m mildly curious which it would have pronounced “1996” as.
I think this shows pretty neatly that even numerals are ambiguous as to pronunciation: depending on the situation, I might pronounce the number as “one thousand, nine hundred and ninety-six” or “nineteen hundred and ninety-six” (when it’s a number; which will depend on factors like what other numbers are around, and my mood) or “nineteen ninety-six” (a year; or very occasionally but riskily a number—as that text could suggest “$19.96”!).
One possible solution in all these cases is to annotate the desired pronunciation so that that is what a screen reader will encounter. Unfortunately, I don’t think you can do this without negative side-effects that are typically worse than the problem. Ideally it’d be a simple attribute like <img>’s alt or interactive elements’ aria-label, but you can’t use either of these on a simple span, and this won’t work:
<span aria-label="nineteen ninety-six">1996</span>
<span class="sr-only">nineteen ninety-six</span><span aria-hidden="true">1996</span>
I’ve been dealing with CSS Counter Styles recently (in my own lightweight markup language, powered by that plus parsing), now I have the crazy idea of adapting its @counter-style rule’s speak-as property (… which I will also admit doesn’t actually permit anonymous counter style values, but hey ho):
<span style="speak-as:symbols('nineteen ninety-six')">1996</span>
For years specifically, I’m curious if wrapping them in <time> changes any screen reader’s understanding:
<time>1996</time>
I’ve picked on numbers here, but it applies to a variety of other things too. https://news.ycombinator.com/item?id=35168439 elsewhere in this thread shows half a dozen different pronunciations of “X”.
I really hope there’s something I’ve missed, but I don’t think there is. Perhaps we should make one. I think I’ve also demonstrated that it needs to be speech-specific, not just something like aria-label.
> <span aria-label="nineteen ninety-six">1996</span>
Why won't that work? Is that a bug in screen readers or not allowed by the specifications?
The problem with the first approach is that there are very few accessibility "experts." Experts, in this arena, are plain people that have done the work to learn how accessibility tools work, how HTML and JavaScript interact with those tools, and do work auditing websites or apps for accessibility, or working at a training center or something. Those people do demanding work that very few others are able to do, so are in short supply. They don't want to come home to dig into code others have written to find that they didn't label a button, or they didn't tag this div with a lang attribute so a TTS engine, if it even has more than the most popular European languages, will speak Ukrainian instead of Russian. Some screen readers don't even try to guess at a non-Latin language, they just read out "Serilic letter ER, Serilic letter U, Serilic letter S," and so on. Why? Because ESpeak, the TTS engine I have in mind, is an open source project that has no guarantees as to its usability in any context or purpose. And yet, because it has support for so many languages that no other TTS engine supports, it's used by Google. Just look at your ChromeBook's list of TTS engines. For the longest time, it was also used in Google Translate. Your open source project might just be used in a big company someday. Yet, how many people contribute to it? How many linguists are on the team? How many people try to make it sound better?
The problem with the second approach is that developers aren't taught anything about accessibility, so feel woefully underprepared to face accessibility issues. So they punt to the "experts," of which there are very few. They don't begin looking at documentation, or look into NVDA source code to see how accessibility is done on a programatic level, or oh I don't know, ask disabled users to test their software cause what if they say no? Oh no maybe I'll offend a blind person! /s. So it goes nowhere.
So, don't sit there and blame screen reader developers if you've not looked through their code and seen all the workarounds they do to get text to read as well as they do now, and the ESpeak code, now ESpeak-ng cause the old developer died or something, and seen how few maintainers it has. Now, big companies like Apple and Microsoft have little excuse for how crappy their TTS engines and screen readers are. Apple's TTS engine is one of the best, but the voice usually used, Alex, hasn't been updated in some time, although MacinTalk has filed down some of his rough edges. Still, those teams are also very small, not like the hundreds working on the iPhone's camera. Apple could, and should, hire more people in those rolls, especially as the bugs are piling up high at this point. But I doubt they will. They've lost their sense of design and beauty and are now just another enshittified tech company.
Easy: By writing "In Hamlet, Act 4, Scene 9..." instead.
There simply is no reason to use relics of cultures that fell before long before the invention of the printing press in a modern context such as a TTS based screen reading software, if said relics interfere with such systems functionality.
This goes double for instances where such relics have multiple representations, that make the problem unnecessarily harder than it already is. Roman Numerals are one such instance, because we can write IV or Ⅳ.
And neither does Mr. Shakespeare.
And because he doesn't, the decision how his works are represented in modern systems, is not up to him.
Also, according to online images, the First Folio had "Actus Primus. Scoena Prima." rather than "Act I Scene I"!
Same as I are welcome to decide if supporting something that makes up a tiny tiny fraction of all written text in my software is worth the extra time and effort to build and maintain it, or not.
Btw. is it also a bug if a screenreader doesn't support Babylonian Cuneiform Numerals? They have Unicode Code points as well.
I have no opinion on Cuneiform.
Using another font, using a different way to represent numerals, or using bold text, isn't editing, it's formatting and styling. When my webbrowser renders markdown to html, it's not editing the text, its reformatting it.
That ellipsis looking thing will be fun for screen readers.
But the question I now have to ask is: What tangible advantages do roman numerals confer in the spaces where they are still kept around.
Roman numerals carry the connotation of the numbers belonging to a title, the same way Writing Something Like This does. Except you can't do that with arabic numerals. They're all case-less.
It's essentially a way of capitalizing numbers not entirely dissimilar to how Roman script in general is used as a way of capitalizing the English alphabet.
Okay.
I. Weigh 500g of flour into a mixing bowl
II. Add one egg
III. Pour 2 cups of milk into the bowl
IV. Mix until you have a runny dough
How I stopped worrying and love Linux - An Essay
9 surprising ways how powershell can help my workflow
> It's essentially a way of capitalizing numbers
Okay, so how do I capitalize, say, 175,000,000,000 using roman numerals if I want to, eg. write the title of article about how many params GPT-3 has? A way of capitalizing numbers, that suddenly stops being useful when numbers are large, isn't a very good way in my opinion.
In your example,
I. Weigh 500g of flour into a mixing bowl
II. Add one egg
III. Pour 2 cups of milk into the bowl
IV. Mix until you have a runny dough
1. Weigh 500g of flour into a mixing bowl
2. Add 1 egg
3. Pour 2 cups of milk into the bowl
4. Mix until you have a runny dough
> Okay, so how do I capitalize, say, 175,000,000,000 using roman numerals if I want to, eg. write the title of article about how many params GPT-3 has? A way of capitalizing numbers, that suddenly stops being useful when numbers are large, isn't a very good way in my opinion.
Right, in which context would you capitalize the number 175,000,000,000? It's not really part of a name. If the model was called GPT-175,000,000,000, then I'd see why you'd consider writing it in roman numerals, but it isn't.
Within e.g. the title of a article, roman numerals allows you to further capitalize a number.
Like you could write "Doom II Ships On Four Floppy Disks". This makes it clearer that the II is part of the name.
"Henry the 8th" or "Henry the 8." conveys exactly the same information as "Henry VIII". The context makes it clear that the numeral is part of a designation. The same is true for "Star Wars Episode 4", "Act 2 Scene 5", "Harry Potter 2" or any other use of a title.
The difference is: 8 is trivially easy to parse. With "VIII", software has to accomodate people writing it in unicode and people writing it in latin letters, plus the parser needs to handle the subtraction logic, otherwise "Henry IV" will be sad, and as a human, depending on the font used, I may have to look twice whether there are 2 I's or 3.
> This is strictly harder to parse.
What? How is this harder to parse? The dot after the numbers makes it increadibly clear that this is a list item. You know what CAN be hard to parse at a glance? The difference between "III" and "II".
> roman numerals allows you to further capitalize a number.
No they don't because there is no such thing as a "capitalized number".
If I want to make a number stand out visually, I have multiple choices that don't require using an antique way of writing numerals: I can use <b>, <u>, <i>, change the font, font size or even color my numbers.
> This makes it clearer that the II is part of the name.
"Doom 2 ships on 4 floppy disks" is just as clear. As with the examples above, the context determines what is part of a title, and what isn't.