I think @river’s point is that it’s most important to accommodate limitations due to circumstances beyond the user’s control. And these are limitations that can prevent people from getting or keeping a job, pursuing an education, and doing other really important things. In all cases that I’m aware of, at least within the past 15 years or so, complete lack of JavaScript is a user choice, primarily made by very techy people who can easily reverse that choice when needed. The same is obviously not the case for blindness or other disabilities. Of course, excessive use of JavaScript hurts poor people, but that’s not what we’re talking about here.
If using <details> made the site impossible to use for blind people, that would obviously be much more important, but here the complaint is that… the screen reader reads it slightly wrong? Is that even a fault of the website?
Fair point. Personally, I wouldn’t demand, or even request, that web developers use JavaScript to work around this issue, which is probably a browser bug, particularly since it doesn’t actually block access to the site.
On the other hand, if a web developer decides to use JavaScript to improve the experience of blind people, I wouldn’t hold it against them. IMO, making things easier for a group of people who, as @river pointed out, do have it more difficult due to circumstances beyond their control, is more important than not annoying the kind of nerd who chooses to disable JS.
I suppose it’s possible that some people have no choice but to use Lynx or Netsurf because they’re stuck with a very old computer. But for the most part, it seems to me that these browsers are mostly used by tech-savvy people who can, and perhaps sometimes do, choose to use something else.
I suppose it’s possible that some people have no choice but to use Lynx
or Netsurf because they’re stuck with a very old computer. But for the
most part, it seems to me that these browsers are mostly used by
tech-savvy people who can, and perhaps sometimes do, choose to use
something else.
And what percentage of those lynx users is tech-savvy blind people? Or
blind people who are old and have no fucks left to give about chasing
the latest tech? There are, for instance, blind people out there who
still use NetTamer with DOS. DOS, in 2022. I’m totally on board with
their choice to do that. Some of these folks aren’t particularly tech
savvy either. They learned a thing and learned it well, and so that’s what
they use.
Many users who need a significant degree of privacy will also be excluded, as JavaScript is a major fingerprinting vector. Users of the Tor Browser are encouraged to stick to the “Safest” security level. That security level disables dangerous features such as:
Just-in-time compilation
JavaScript
SVG
MathML
Graphite font rendering
automatic media playback
Even if it were purely a choice in user hands, I’d still feel inclined to respect it. Of course, accommodating needs should come before accommodation of wants; that doesn’t mean we should ignore the latter.
Personally, I’d rather treat any features that disadvantage a marginalized group as a last-resort. I prefer selectively using <details> as it was intended—as a disclosure widget—and would rather come up with other creative alternatives to accordion patterns. Only when there’s no other option would I try a progressively-enhanced JS-enabled option. I’m actually a little ambivalent about <details> since I try to support alternative browser engines (beyond Blink, Gecko, and WebKit). Out of all the independent engines I’ve tried, the only one that supports <details> seems to be Servo.
JavaScript, CSS, and—where sensible—images are optional enhancements to pages. For “apps”, progressive enhancement still applies: something informative (e.g. a skeleton with an error message explaining why JS is required) should be shown and overridden with JS.
I’m certainly okay with a little more JS if it means folks without sight
or poorer sight can use the sites more easily.
In my experience (the abuse of) JavaScript is what often leads to poor
accessibility with screen readers. Like, why can I not upvote a story
or comment on this site with either Firefox or Chromium? ISTR I can
do it in Edge, but I don’t care enough to spin up a Windows VM and test
my memory.
We need a bigger HTML, maybe with a richer set of elements or
something. But declarative over imperative!
Like, why can I not upvote a story or comment on this site with either Firefox or Chromium?
I use Firefox on desktop and have never had a problem voting or commenting here.
We need a bigger HTML, maybe with a richer set of elements or something. But declarative over imperative!
The fallback is always full-page reloads. If you want interactivity without that, you need a general-purpose programming language capable of capturing and expressing the logic you want; any attempt to make it fully declarative runs into a mess of similar-but-slightly-different one-off declaration types to handle all the variations on “send values from this element to that URL and update the page in this way based on what comes back”.
I use Firefox on desktop and have never had a problem voting or
commenting here.
Yes, but do you use a screenreader? I do.
The fallback is always full-page reloads. If you want interactivity
without that, you need a general-purpose programming language capable of
capturing and expressing the logic you want;
Sure, but most web applications are not and do not need to be fully
interactive. Like with this details tag we’re talking about here? It’s
literally the R in CRUD and the kind of thing that could be dealt with
by means of a “richer HTML”.
So in order to make your site slightly more accessible to screen readers, you’ll make it completely inaccessible to browsers without JavaScript?
i was born without javascript and life has been so hard for me
Accessibility isn’t just about disorders.
I think @river’s point is that it’s most important to accommodate limitations due to circumstances beyond the user’s control. And these are limitations that can prevent people from getting or keeping a job, pursuing an education, and doing other really important things. In all cases that I’m aware of, at least within the past 15 years or so, complete lack of JavaScript is a user choice, primarily made by very techy people who can easily reverse that choice when needed. The same is obviously not the case for blindness or other disabilities. Of course, excessive use of JavaScript hurts poor people, but that’s not what we’re talking about here.
If using
<details>made the site impossible to use for blind people, that would obviously be much more important, but here the complaint is that… the screen reader reads it slightly wrong? Is that even a fault of the website?Fair point. Personally, I wouldn’t demand, or even request, that web developers use JavaScript to work around this issue, which is probably a browser bug, particularly since it doesn’t actually block access to the site.
On the other hand, if a web developer decides to use JavaScript to improve the experience of blind people, I wouldn’t hold it against them. IMO, making things easier for a group of people who, as @river pointed out, do have it more difficult due to circumstances beyond their control, is more important than not annoying the kind of nerd who chooses to disable JS.
Well, disabling JS is not always a choice. Some browsers, such as Lynx or NetSurf, don’t support it. But yeah, I generally agree.
I suppose it’s possible that some people have no choice but to use Lynx or Netsurf because they’re stuck with a very old computer. But for the most part, it seems to me that these browsers are mostly used by tech-savvy people who can, and perhaps sometimes do, choose to use something else.
And what percentage of those lynx users is tech-savvy blind people? Or blind people who are old and have no fucks left to give about chasing the latest tech? There are, for instance, blind people out there who still use NetTamer with DOS. DOS, in 2022. I’m totally on board with their choice to do that. Some of these folks aren’t particularly tech savvy either. They learned a thing and learned it well, and so that’s what they use.
Many users who need a significant degree of privacy will also be excluded, as JavaScript is a major fingerprinting vector. Users of the Tor Browser are encouraged to stick to the “Safest” security level. That security level disables dangerous features such as:
Even if it were purely a choice in user hands, I’d still feel inclined to respect it. Of course, accommodating needs should come before accommodation of wants; that doesn’t mean we should ignore the latter.
Personally, I’d rather treat any features that disadvantage a marginalized group as a last-resort. I prefer selectively using
<details>as it was intended—as a disclosure widget—and would rather come up with other creative alternatives to accordion patterns. Only when there’s no other option would I try a progressively-enhanced JS-enabled option. I’m actually a little ambivalent about<details>since I try to support alternative browser engines (beyond Blink, Gecko, and WebKit). Out of all the independent engines I’ve tried, the only one that supports<details>seems to be Servo.JavaScript, CSS, and—where sensible—images are optional enhancements to pages. For “apps”, progressive enhancement still applies: something informative (e.g. a skeleton with an error message explaining why JS is required) should be shown and overridden with JS.
(POSSE from https://seirdy.one/notes/2022/06/27/user-choice-progressive-enhancement/)
I mean not for not, but I’m fairly certain you can constrain what can be executed in your browser from the website.
I’m certainly okay with a little more JS if it means folks without sight or poorer sight can use the sites more easily.
In my experience (the abuse of) JavaScript is what often leads to poor accessibility with screen readers. Like, why can I not upvote a story or comment on this site with either Firefox or Chromium? ISTR I can do it in Edge, but I don’t care enough to spin up a Windows VM and test my memory.
We need a bigger HTML, maybe with a richer set of elements or something. But declarative over imperative!
I use Firefox on desktop and have never had a problem voting or commenting here.
The fallback is always full-page reloads. If you want interactivity without that, you need a general-purpose programming language capable of capturing and expressing the logic you want; any attempt to make it fully declarative runs into a mess of similar-but-slightly-different one-off declaration types to handle all the variations on “send values from this element to that URL and update the page in this way based on what comes back”.
Yes, but do you use a screenreader? I do.
Sure, but most web applications are not and do not need to be fully interactive. Like with this details tag we’re talking about here? It’s literally the R in CRUD and the kind of thing that could be dealt with by means of a “richer HTML”.
On modern browsers, the
<details>element functions builtin, without JS.In fact that’s the entire point of adding the element.
Yes, and the article recommends against using
<details>.