@
hosh The alt-text police of the Mastodon Home Owners' Association (Mastodon HOA) have a tendency to be overzealous. And they don't talk to each other. They all act for themselves as lone wolves with exactly no coordination amongst each other whatsoever. You never know what kinds of rules they whip up for themselves.
Chances are that they only let image descriptions count that
come directly with the image. If they acknowledge an image description outside the alt-text,
it must be in the post itself. Not as an external link, but the description text itself.
Besides, at least some in the Mastodon HOA have problems with external links. And I don't just mean that they don't trust embedded links whose URL they can't see in plain sight, the kind that Hubzilla can create and Mastodon can't (not that Hubzilla couldn't fake a plain-sight link by embedding a different URL than the visible).
I don't mean either that probably a majority of Mastodon users don't even recognise embedded links without a visible URL as such because they don't know that such a thing can exist in the Fediverse, because Mastodon can't make them.
No, what I mean is the notion that external links for explanations are inherently bad from an accessibility point of view. "Mastodon" (as in how Mastodon users experience the Fediverse, i.e. the Mastodon Web UI or any of the popular mobile phone apps) is sufficiently accessible. But the Web outside of "Mastodon" (same definition again) may not be accessible enough.
A few years ago, I've literally read a Mastodon toot in which someone said that explanations must not be linked to. Linked websites have a risk of not being accessible. Explanations must always be directly in the same post. Apparently, they thought that everything and anything can be explained and broken down until everyone understands it within 500 characters.
This is also why Mastodon users tend to explain their images in the alt-text. It's only there where they have at least halfway enough characters for an explanation, 1,500 per image as opposed to usually only 500 in the post text. (On Mastodon, much unlike Hubzilla, the alt-text is a separate database field that exists separately for each of the up to four images per message.)
That is,
explanations must never go into the alt-text because
there are people who cannot open alt-texts to read them. But nobody on Mastodon knows that.
It should be obvious that what counts for
explanations counts for
visual descriptions just as well.
And in fact, regarding Hubzilla articles, they're actually right. I've once pointed an actually blind screen reader user to an article on my Hubzilla channel. She said she couldn't even navigate the Web interface. She literally couldn't get to the text body of the article to have it read out by her screen reader.
Hubzilla's Web interface, no matter which app is opened, is not accessible. It does not work with screen readers. It's largely still stuck in 2012 when nobdy made any ruckus about the accessibility of hobbyist Web projects.
The only reason why at least some blind or visually-impaired users can read our Hubzilla posts and comments and DMs is because they're all on Mastodon, and they read our content either on Mastodon's Web UI or a Mastodon app that supports screen readers. But they do
not read our content at the source. Because they can't.
I actually took into consideration linking to my long image descriptions. But my idea was not to link to a Hubzilla article, nor to a Hubzilla wiki or a Hubzilla card. No, my idea was to write a plain HTML document, upload it to my file space and link to that.
I've dropped that idea for various reasons:
- Generally, still, external links are frowned upon.
- I don't know if plain HTML is accessible without a CSS. And I can't add a CSS to this HTML if the HTML document is not served to the recipient by a Web server, but by a file server.
- I don't know how Google Chrome on Android or Safari on an iPhone will react when they access an HTML document on a file space. Will they display it as a website? Or will they download it onto the device as a file without opening it because, again, it is served to them not by a Web server, but by a file server?
- Mobile users dislike opening websites from apps because they dislike their browser popping open. And on Mastodon, much unlike Hubzilla, almost everyone is on a phone and a dedicated app almost all the time.
- This also means that mobile users would have the image and the description in two separate apps. The image in their Mastodon app, the description in their browser.
- I would need much more description.
Right now, when I have multiple images, my long descriptions consist of a preamble that contains all necessary explanations and, if applicable, visual descriptions of elements that are common to all images. The individual descriptions for each image follow.
But if I had one image description file per image, then each image description would need the whole preamble included. I can't just add the preamble to the first description file.
What if someone opens the third description file first? They'll only have a very incomplete description. And linking to the first description file is inconvenient. I would have to know the URL of the first file before completing and uploading the other files because I'd have to include the URL of the first file in them. And the users would have to have three documents open (the image post, the description of the image they're interested in, the description of the first image with the preamble) just to experience one image. Spread across two phone apps.
And that's why I can't put my additional long description in an external document.
#
Long #
LongPost #
CWLong #
CWLongPost #
FediMeta #
FediverseMeta #
CWFediMeta #
CWFediverseMeta #
AltText #
AltTextMeta #
CWAltTextMeta #
ImageDescription #
ImageDescriptions #
ImageDescriptionMeta #
CWImageDescriptionMeta #
AltTextPolice #
MastodonHOA #
CharacterLimit #
CharacterLimits #
CharacterLimitMeta #
CWCharacterLimitMeta #
500Characters #
MastodonCulture