A text only web is pretty niche. Can this project really afford to start slicing off additional portions of its userbase? I agree that multilingual blind users are in the minority, but those users are probably the most likely of anyone to be interested in a text-only web.
And even ignoring blind users, it's just... what's the point of any of this if Gemini is not going to be semantic? It's like religiously adhering to the GNU principles of always printing human-readable text on the command line, and then not shipping a shell with a pipe command or any text parsing capabilities. From just about any perspective, whether you're worried about accessibility, or parsing, or search -- it's useful to know what language a document/section is in.
One of the few advantages of having a limited, well-defined, non-extensible spec is that it's easy to work with and write parsers around. And immediately Gemini is just saying, "filtering sections by language? Good text-to-speech support? No need for that."
If nothing else, Gemini is theoretically built specifically for generality[0], and it's already guaranteeing out of the box that it can't be used well with voice assistants. Those things aren't a fad, a general-purpose document format kind of needs to support them. And trying to have a voice assistant that intuits the current language is just a really bad system for everyone.
That's one reason inline links are not allowed (they have to be a separate line): it would complicate the parser.
It shouldn't be too hard to add a "language switch" line, so that sections (but not words within sections) can be different languages.
Making Wiktionary or Etymonline in Gemini would require you to add a line break for each foreign word, which seems annoying to read.
I don't see though, why the spec can't allow links that are written on a newline for markup simplicity but displayed inline? And then the same could be done for foreign words.
I agree with you that those behind Gemini should take this issue seriously, but maybe something like what I've mentioned is what they have in mind as their answer. Not sure.
it would be nice to have more accesible interfaces for everyone. helping one person doesn't mean you fail to help everyone, in fact, helping one person in terms of accessibility generally has the effect of helping everyone.
we're asking for some access. not all the access. scoped properly, it doesn't seem to be that insurmountable of a development goal, honestly.
How does facilitating multilingual screen-reading help someone who is neither multilingual nor uses a screen-reader? How can it possibly help everyone? (like literally 100% of people, you are suggesting?) What am I missing?
- better support for users who are not multi-lingual (a client could try to auto-translate sections that are not in the user's native language)
- better search capabilities (find me all documents that contain a French passage)
- better voice-assistant support (if a document is being read out loud for any reason, it would be nice to be able to handle multiple languages well. This also combines with the auto-translate capabilities above.)
Basically, all of the reasons why Gemini includes a "lang" attribute in the first place, except recognizing that parsers and clients want to be able to make use of that on a section-by-section basis rather than purely at the document level.
Sometimes documents are big and expand across multiple languages. It's just a bad abstraction in general to assume that each document would only have one language type[0]. Documents/books in the real world don't work that way, and a document format that can't accurately represent a giant portion of classic literature isn't a very good general-purpose format.
[0]: yes, technically Gemini allows you to specify multiple top-level languages, but that's not useful for anything. If I'm parsing a document, I don't want it to tell me "hey, there's some French in here somewhere, good luck!" Tell me where it is.
Then "accessiblity" in general is not niche, it effects everyone or almost everyone.
But "accessibilty" is a broad concept, applying to all sorts of different unrelated needs. Vision impairment, cognitive differences, mobility needs, etc.
Some of them effect more people than others. Some of them will be "niche", effecting few people. it is just a fact, right? It is faulty logic to say that because "accessibility" effects everyone, every single accessibility accomodation is also therefore of use to everyone. It's not so.
How much need is there for multi-lingual screen-reading? I have no idea. It's obviously not universal -- I don't need it for instance, although I may need other kinds of accessibility attention -- but there may be lots of need for it! But we can't prove it one way or another just from language games around the general concept of "accessiblity".
Whether developers ought to accomodate even niche accessibility needs is a separate ethical or practical argument.