This is a 500 error page, so instead of the image saying something like:
“Drawing of a woman screwing in a lightbulb”, it makes more sense to use
“500 internal server error” as the alt text.
It’s worth mentioning here that a browser used with a screenreader will
indicate unambiguously that the user has landed on an error page,
regardless of the page content. I usually don’t bother reading the
content, because … what’s the point?
“Drawing of a woman screwing in a lightbulb” is excellent wordplay. The
parse is ambiguous. The first thing I thought was, “How did they get
a person inside a lightbulb?” Or maybe it’s just the drawing inside the
bulb?
“Drawing of a woman replacing a lightbulb” would be less loaded. For
even less ambiguity: “This drawing depicts a woman replacing a
lightbulb”.
I’d argue that exposing the error code at all is an accessibility problem. It requires the user to know what 403 (or what have you) means, and there’s no reason for a non-technical user to know that. For any diagnostic purpose, the user can examine the actual HTTP response via other tools.
I’d argue that exposing the error code at all is an accessibility
problem. It requires the user to know what 403 (or what have you) means,
This mindset, taken to its extreme, leads to error messages like
“something went wrong”. It’s at least partially responsible for things
like the hijacking of NXDOMAIN by ISPs. NXDOMAIN hijacking serves two
purposes: it prevents the “unwashed masses” from having to deal with a
failure case, and it funnels them to ISP-controlled ad portals.
I’m a strong believer in the old maxim that knowledge is power.
Depriving a user of knowledge deprives them of agency.
Yeah, that didn’t make sense to me either – even without that, the error is already described on the left, so why re-describe it in the alt text? If anything, the image is decorative so the “responsible” take should be to use alt=”” to have screen readers ignore it? (https://www.w3.org/WAI/tutorials/images/decorative/)
It’s worth mentioning here that a browser used with a screenreader will indicate unambiguously that the user has landed on an error page, regardless of the page content.
Is this based on the assumption that the screen reader will read the title of every newly loaded page, or something else?
As a low vision user I am very encouraged by articles like this because it shines a bit of attention on accessibility. That said, we are suffering from basic accessibility problems on most sites that make them completely unusable, or extremely painful to use.
This is because most developers have no context for what it’s like to actually use accessibility tools for more than a few moments to check a box saying they meet the minimum accessibility guidelines. On the web the best thing is people who follow standards and use HTML and CSS wisely which gives accessibility tooling lots of things to work off of. For example, just having the comment blocks themselves be a specific class and style will let me navigate just through the comments skipping all the in between control mechanisms making a site much more enjoyable to use. Well used styles, headers, articles and other web features are game changing for accessibility. This site for example is mostly incoherent when it comes to use of those features, making navigation more painful.
Obviously responsible stewardship of good UX is the priority, but I think it’s important to seek fun ways to fulfill our responsibilities. Those goals aren’t incompatible and absolutely can align, as the article illustrates with several examples.
Side note: would have appreciated if the non-Medium link was used instead, Medium’s reading experience is a lot worse.
Thanks! Noted for next time!
Making a note to check the comments before reading an entire article on Medium!
It’s worth mentioning here that a browser used with a screenreader will indicate unambiguously that the user has landed on an error page, regardless of the page content. I usually don’t bother reading the content, because … what’s the point?
“Drawing of a woman screwing in a lightbulb” is excellent wordplay. The parse is ambiguous. The first thing I thought was, “How did they get a person inside a lightbulb?” Or maybe it’s just the drawing inside the bulb? “Drawing of a woman replacing a lightbulb” would be less loaded. For even less ambiguity: “This drawing depicts a woman replacing a lightbulb”.
I’d argue that exposing the error code at all is an accessibility problem. It requires the user to know what 403 (or what have you) means, and there’s no reason for a non-technical user to know that. For any diagnostic purpose, the user can examine the actual HTTP response via other tools.
This mindset, taken to its extreme, leads to error messages like “something went wrong”. It’s at least partially responsible for things like the hijacking of NXDOMAIN by ISPs. NXDOMAIN hijacking serves two purposes: it prevents the “unwashed masses” from having to deal with a failure case, and it funnels them to ISP-controlled ad portals.
I’m a strong believer in the old maxim that knowledge is power. Depriving a user of knowledge deprives them of agency.
“Screwing in” is ambiguous too as some light bulb fixtures are bayonet-type.
That doesn’t make it ambiguous.
Yeah, that didn’t make sense to me either – even without that, the error is already described on the left, so why re-describe it in the alt text? If anything, the image is decorative so the “responsible” take should be to use alt=”” to have screen readers ignore it? (https://www.w3.org/WAI/tutorials/images/decorative/)
Is this based on the assumption that the screen reader will read the title of every newly loaded page, or something else?
Presumably I’ve just gotten lucky and always seen error pages with stock titles. So I have to walk back that assertion.
I would imagine it would be based on the HTTP response code.
As a low vision user I am very encouraged by articles like this because it shines a bit of attention on accessibility. That said, we are suffering from basic accessibility problems on most sites that make them completely unusable, or extremely painful to use.
This is because most developers have no context for what it’s like to actually use accessibility tools for more than a few moments to check a box saying they meet the minimum accessibility guidelines. On the web the best thing is people who follow standards and use HTML and CSS wisely which gives accessibility tooling lots of things to work off of. For example, just having the comment blocks themselves be a specific class and style will let me navigate just through the comments skipping all the in between control mechanisms making a site much more enjoyable to use. Well used styles, headers, articles and other web features are game changing for accessibility. This site for example is mostly incoherent when it comes to use of those features, making navigation more painful.
maybe accessibility is about responsibility. Doesn’t align with fun.
Obviously responsible stewardship of good UX is the priority, but I think it’s important to seek fun ways to fulfill our responsibilities. Those goals aren’t incompatible and absolutely can align, as the article illustrates with several examples.