Just how detailed does a description of a UI window have to be if the article with it will be published within the Fediverse, but only appear in a Fediverse post as a link to the real thing? CW: long (ca. 8,800 characters)
People, I have an #
ImageDescription problem. That's because I'm about to run into an unprecedented situation. Unprecedented for me at least.
I'm planning to publish something with a screenshot of a configuration window as an article on #
Hubzilla. Granted, a Hubzilla article is not a social media post. It won't appear on any #
Mastodon user's timeline. I'm going to link to it in a post, though, even if that means that all you mobile users would have to put up with your Web browser popping up if you're actually curious about the article, and you tap the link to read it.
This means that I'd better apply the same #
accessibility rules to this article as to my posts.
This means I'll have to describe this image:
(Users of Mastodon and other microblogging projects that handle images as file attachments: The image should go here above this line/paragraph.)This also means I'll have to take a similar effort upon me to describe this image as I've recently taken to describe other images in the recent past. For reference: You can find a picture I've taken in a virtual 3-D world last year plus the 13,215-characters-long image description I've written a few months ago
here.
(Mobile Mastodon users: This is not a link to a Mastodon post. This will open your Web browser.) By the way, I still find the description lacking.
Why is that image description so long? Because I've decided to describe and explain everything which casual #
Fediverse users might be unfamiliar with. Since this is a virtual 3-D world, a very obscure one even, I expect just about nobody to be familiar with just about anything in the picture. So everything has to be described and explained. Also, if there's text anywhere in a picture, I transcribe it word by word.
So, what I have now is not a digital rendering from within a virtual 3-D world that nobody knows. Instead, it's a screenshot of a settings window in a client for virtual 3-D worlds that isn't too well-known either.
How should I do this, considering that 99.99% of all users that come by this image don't know anything about anything in it?
Of course, step 1: I'd explain that this is a screenshot of the land settings window in the Firestorm Viewer.
First issue: This information is completely useless unless you know what the Firestorm Viewer is. I'm pretty sure most of you aren't.
So, step 2: I'd explain that the Firestorm Viewer is a free, open-source, cross-platform desktop viewer, i.e. client or, if you're more familiar with that term, app for #
SecondLife and OpenSimulator-based virtual worlds.
Next issue: Some of you may not know what Second Life is. And unless you follow my posts closely, maybe even if you do, you're very very likely not to know what #
OpenSimulator is.
So, step 3: I'd have to explain both. I'd also have to describe that #
OpenSim is decentralised, and that Second Life and OpenSim-based worlds are called grids, and why they're called grids, so that I can explain that most of the hundreds of OpenSim grids are federated via the so-called #
Hypergrid, so it isn't a bunch of walled gardens.
Step 4: Here's where the actual description of the image content would start. Settings window, 488 pixels wide and 448 pixels high. Upper left and right corners of the window rounded with anti-aliasing in front of a sky-blue background, lower left and right corners not rounded. Dark grey basic colour, light grey text, the font used for the text. Title bar with a slightly-lighter-to-slightly-darker vertical gradient background, window name surrounded by shading on the left, three buttons on the right, question mark for help, short horizontal line for rolling the window up and reducing it to its title bar, cross button for closing it.
Below that, eight tabs with the same gradient background, including their titles. Fourth tab from the left, Options, highlighted with a solid, non-gradient tan background and the same light grey text colour as the other tabs. Medium grey, one-pixel high horizontal line right below and directly adjacent to the tabs.
The title of the settings. Then every single setting by literal name, what it means, what it does, what it means if the check box is on, what it means if the check box is off, what the implications are in either case. What groups are, how they work, what they do in this case. What object entry is, what a sim is because it's crucial to know that in order to learn what object entry is. What this Search is, what it does in Second Life, what it does in OpenSim, if anything. What Moderate means, what the four Second Life standard content ratings are, how they're defined. The various options of land type where Residential is selected now, what they mean, if they exist in OpenSim in the first place. The slightly embossed Snapshot image and why it only shows a question mark in front of an image that's a digital rendering of the horizon on an ocean with slight wave ripple and a somewhat dusky gradient sky with a reflection of the sun at a height at which the sun is not to be seen in the actual sky.
By now, the description would certainly have passed at least the 6,000-character mark, maybe even 7,000, 8,000, if not 10,000 characters.
Way too much for #
AltText anywhere. Hubzilla, as well as #
Friendica and #
Streams, could still handle several times as much in alt-text or even more. But neither of them could show much more than half of it as hover text, and it'd make #
ScreenReader users desperate.
If this was an image description for a post, I'd put it into the post even if that's bad, bad, bad style. It'd still be the most accessible way to go. But it's an image description for a how-to article in which that'd be even worse style.
Still, I wouldn't even have gotten to what the article is about. And that's the controls marked by the blue and red boxes in the bottom right area, including how the coordinates are measured. That'd be the last step before I finish by describing the lower edge with the very dark grey one-pixel-high horizontal line.
Why this gargantuan effort?
Because if I only described what's actually important within the context of the article, someone who's #
blind or #
VisuallyImpaired might come and ask themselves and me what this configuration window looks like, and if there's anything else in it. Visually-impaired people might be able to see that there's something like a title bar and setting controls, but they might be unable to
read what's written there, so
everything would require a #
transcription.
Also, blind, visually-impaired and sighted people alike are very unlikely to know what all these controls do if I only mention them. And as I've already written, they're very unlikely to know what the entire application is for. And as I've also already written, the latter requires some very extensive explanation.
In fact, I actually expect particularly curious people to want to know what
the other tabs look like and wish I had described them, too, down to all their controls and settings and whatnot.
So I've got these options:
- No image description whatsoever. Advantage: The least effort, especially since I'm not even sure if screen reader users can access Hubzilla articles in the first place. I've had a screen reader user tell me they couldn't access the article with the 13,000+-character image description at all. Disadvantage: People who understand that this article is on Hubzilla, thus technically in the Fediverse, loudly complaining that there's no alt-text in the image, maybe even attacking me for being ableist.
- Only a very brief image description in the alt-text. Advantages: It'd fit into the alt-text, and it'd follow established alt-text rules for blog posts. After all, a Hubzilla article is something like a long-form blog post. Disadvantage: It'd deprive almost everyone of information about this image that they don't have.
- Fully-featured image description in the alt-text. Advantages: It'd be fully informative in theory, and it won't mess up the article. Disadvantages: It'd be out-right hell for screen reader users because the screen reader would have to ramble through the whole thing for several minutes straight. And sighted people wouldn't have a chance to access the alt-text at its full extent at all, probably not even on an 8K screen.
- Fully-featured image description in the article itself. Advantage: It'd actually be fully informative because everyone could access it comfortably in some way. Disadvantage: It'd mess up the article.
Any suggestions? From Mastodon users for whom basically everything is Mastodon and who live and breathe Mastodon's accessibility standards as well as Hubzilla users who know what articles are?
#
A11y #
Inclusion #
Inclusivity
