Sure, sometimes you have to make tradeoffs for what you have time to invest in.
But this isn't really about supporting the world's Lynx users specifically. There's a reason I put a whole class of non-mainstream UAs in there (and in particular Siri, given how likely it is that entirely non-visual UAs are to become more mainstream at some point, perhaps soon, on top of the awareness that intermediary UAs like GoogleBot are of course ubiquitous and clearly important). And which UAs you try to support has a chicken and egg effect on which UAs get employed as intermediaries in accessing your site/app... and therefore which UAs you think you see using it. Usage follows accessibility perhaps even more surely than accomodation follows demand.
If that weren't enough, the decision to do the things that would mean that your site is usable in Lynx is not just a feature -- it's also a technical decision. And like other technical decisions (database, language, library, application architecture, idioms and patterns you use, and data serialization/interchange format... which is actually part of what this decision actually is), it matters to how well your product performs and how tractable it is to develop and maintain, as well as how widely it can be consumed.
If you're having to make cold hard decisions about ROI for features, chances are decent that you're better off for thinking about whether it works in Lynx and why, even if not one single user visits with that specific UA.
Fair enough in a way, but on the other hand.. will that be like JPEG2000, which browsers might support when websites use it, which might be when browsers support it?
Or put differently, how would someone who can't use or even see your thing become your user?
But this isn't really about supporting the world's Lynx users specifically. There's a reason I put a whole class of non-mainstream UAs in there (and in particular Siri, given how likely it is that entirely non-visual UAs are to become more mainstream at some point, perhaps soon, on top of the awareness that intermediary UAs like GoogleBot are of course ubiquitous and clearly important). And which UAs you try to support has a chicken and egg effect on which UAs get employed as intermediaries in accessing your site/app... and therefore which UAs you think you see using it. Usage follows accessibility perhaps even more surely than accomodation follows demand.
If that weren't enough, the decision to do the things that would mean that your site is usable in Lynx is not just a feature -- it's also a technical decision. And like other technical decisions (database, language, library, application architecture, idioms and patterns you use, and data serialization/interchange format... which is actually part of what this decision actually is), it matters to how well your product performs and how tractable it is to develop and maintain, as well as how widely it can be consumed.
If you're having to make cold hard decisions about ROI for features, chances are decent that you're better off for thinking about whether it works in Lynx and why, even if not one single user visits with that specific UA.