Imagine saying accessability hardware - like corrective lenses - is niche.
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.
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.
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.
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.
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.
But at Apple we were well aware that accessibility features like closed captions were often used by people with no disabilities. We would add stuff knowing that all sorts of people would find uses for it.
I can easily imagine a language tag would also be useful for filtering out a German-language gemini for instance.
This was a double edged sword however. Like with closed captions/subtitles, we knew that many people using them that had hearing issues were older and also likely had out of date glasses prescriptions.
But this didn't stop the AppleTV designers from lowering the contrast of the font by displaying it over a transparent background, lowering the font size, using Helvetica instead of an accessible font, and removing the positional text feature that indicated who was speaking. And in typical Apple style, there was no option to make the text more legible.
All of these choices were made to appease people without disability who were using the feature for whatever reason. I didn't like it.
So I guess what I'm saying is, accessibility features are good for all sorts of reasons but don't lose sight of the much, much smaller group of users who require the feature in order to use the product at all.
I think it is important to be honest and upfront when we talk about accessability in software because I've seen so many times when developers and product owners dismiss it entirely. I really want to stress the point that thinking about accessebility as a niche is exclusionary and unethical.
I think about my time working at Net a Porter - UK upmarket online fashion retailer - where I brought up some accessability concerns especially around their terrible in-house captcha and it was dismissed as "they arent our target market" which is so blanetly untrue, but all stems from this myth that accessability is only for a small group of users.
> don't lose sight of the much, much smaller group of users who require the feature in order to use the product at all.
The people who need to use captions/subtitles are not a "much smaller group". I think about foreign language media, where i need the subtitles (like when I watched Dark on Netflix), or even primarily English media but has some forign language (I watched Lost recently - there's a fair bit of Korean and Arabic in that). Or even when you're watching TV around someone who's sleeping.
Everyone needs "accessability", and if you don't now, you will eventually.
This is uncharitable. They were specifically talking about multilingual accessibility. You responded to something they didn't write.
I've always loved that the Kindle, even with such a simple use case as reading a book, supports so many ways to see it and interact with it, so even people without vision or motor problems can use it the way they like best.
A better example would be things like wheelchair accessibility for instance, which is indeed very much not implemented everywhere.
To be clear I'm not saying that it's a bad idea to implement accessibility features, It's actually quite commendable. I just feel like in practice it's a lot of additional work to get it right and even then it may not do much good at all. Again, while the "lang" attribute is technically supported by HTML, I struggle to find places where it's used in the wild, even in places where it doesn't seem like it would be technically difficult to do it (like dictionaries and language learning websites).
If I was a gemini developer I'd definitely listen when people complain about bad accessibility, but I would also take the time to understand how people deal with things like multilingual content in practice and how to make it easier, because clearly at the moment "lang=" is not it.
That's my point :)
> Also it's a pretty bad example because very rarely do you need to worry about "corrective lense accessibility", except maybe for things like VR helmets.
Ahh, but what corrective lesnses points to is degregation in eyesight. So ways to make viewing/experiencing content _without_ glasses is definitely a concern to between 50%-70% of adults.
Yes, and a minority of those users are visually impaired, hence it is a niche. Maybe you considered "niche" to mean "preference" or "novelty"?
" niche, adjective
denoting products, services, or interests that appeal to a small, specialized section of the population. "