Jump to content

Image Description for the visually impaired


Max and 99

Recommended Posts

1 hour ago, barefootjeff said:

 

Sorry for my sarcasm but, if the goal is to open up caching to those with visual and other impairments, it has to clear all the obstacles from viewing the cache page to finding the cache and completing the find. By all means encourage caches suitable for visually-impaired players but it has to go beyond just making the pages screen reader friendly, those pages also have to allow their puzzles to be solved and their caches to be found, otherwise it hasn't actually achieved anything and is just building the wheelchair ramp into the building full of steps. Labeling a puzzle image as "puzzzle image" doesn't open up anything.

 

I don't think that's the goal. This is just an attempt to remove one obstacle to visually impaired users.

It's an obstacle that doesn't take too much effort to remove and, quite frankly, is something that I tend to think of as just good manners (I'm not being critical at all - many users of GS's services would never have known about the issues related to this). Simple raising awareness is valuable sometimes as well.

  • Upvote 1
Link to comment
3 hours ago, barefootjeff said:

if the goal is to open up caching to those with visual and other impairments,

 

I'm not sure we know that the goal is.  However,  there are accessibility compliance laws, and non-compliance can result in lawsuits.  I'm actually dealing with this right now in a somewhat similar scenario.  I developed a site for a US government agency that serves as an archive and dissemination site for a huge collection of publications and datasets from several branches in that agency.  Some of those publications are released periodically and, for documents prior to 1995 they're pdf files created from scanned images.   Those document are not compliant with the accessibility laws.  The site itself is compliant, but some of the content is not.   The university that I work for is mandated to have all sites in the university domains accessibility compliant.  I have a meeting next week to discuss the issue but one of the "solutions" may be to change the domain of the web site.  Removing and/or mitigating the content would take a very long time.

 

I wonder if Groundspeak is under the same pressure.  Although their website may be compliant (I don't know that it is),  the content that we are providing would not be without alt tags on images.   

 

 

 

 

 

 

 

  • Helpful 2
Link to comment
4 hours ago, Blue Square Thing said:

This is just an attempt to remove one obstacle to visually impaired users.

And sometimes there are limits to what can be done.

 

My wife is blind, and uses the descriptive audio (DVS) track for movies and TV shows when it is available. But there is only so much time for a narrator to explain the action on the screen, and often they have to describe plot-related action rather than visual humor or other interesting (but not essential to the story) details. So if we're watching at home, sometimes I hit the pause button and explain something the descriptive audio narration left out.

 

Did the narration fail? Not at all. It did the best it could given the constraints. By hitting pause, I was able to remove one of the constraints, which enabled me to do something different.

 

Likewise with truly visual content on web sites. There are limits to what can be done. Do your best, and don't worry about it.

  • Helpful 1
Link to comment
10 hours ago, Blue Square Thing said:

 

I don't think that's the goal. This is just an attempt to remove one obstacle to visually impaired users.

It's an obstacle that doesn't take too much effort to remove and, quite frankly, is something that I tend to think of as just good manners (I'm not being critical at all - many users of GS's services would never have known about the issues related to this). Simple raising awareness is valuable sometimes as well.

 

The trouble, as I see it anyway, is that putting a label on a puzzle image that just says "This is a puzzle image" doesn't remove any obstacles at all. The visually-impaired cacher is not one iota closer to being able to do anything with that cache page than they were without that label. About all it does is reinforce that this page is inaccessible to them, but if that's the goal, then fine.

 

6 hours ago, NYPaddleCacher said:

However,  there are accessibility compliance laws, and non-compliance can result in lawsuits.

 

Okay, so it's being done to comply with the letter of a law. If they'd said that in the email instead of "working towards a more inclusive and accessible experience for all players" it would have helped me get my head around what's really required.

  • Upvote 2
Link to comment

Some further thoughts...

 

There are some conditions, like macular degeneration, that could make it difficult for someone to comprehend a cache page but they can still see well enough to get around outdoors and find some geocaches. Then there are reports of strokes that do all sorts of bizarre things to visual perception. So I'm certainly not against doing anything that might help those people enjoy our pastime. Likewise, there may well be some with even greater visual impairment who like to be able to solve puzzles by themselves but get assistance from family and friends when they go out caching. For all those people, if adding alt text labels to images facilitates that and unblocks a cache that would otherwise be blocked to them, that's great!

 

I have a fair number of multis with match the photo with what you see here virtual waypoints and, where I've been able to easily describe each image in text, I'm more than happy to have done that.  For example, in GC6XHHJ where there are six numbered images that have to be matched with what's at the six waypoints, I've set the alt text to "Cascade (9), small waterfall (3), boardwalk (6), gully (5), pool (6), bridge (1)". For someone who can see well enough to distinguish those things in the outdoors but the photos are just a blur to them, it might be enough for them to experience and enjoy that cache.

 

But there are some image-based puzzles and multis that simply aren't amenable to that. For those, adding a label that just says "puzzle image" doesn't enable anything and that's really what my gripe is. I detest token jestures that are purported to be helpful but really aren't and, to me, a label that says "puzzle image" falls into that category. Maybe it ticks a box on some legal requirement, but that seems to be about all it does. It doesn't really help the people it's meant to be helping.

  • Upvote 2
Link to comment
2 minutes ago, barefootjeff said:

For those, adding a label that just says "puzzle image" doesn't enable anything and that's really what my gripe is

Actually, it does help. No, it doesn't help them solve the puzzle, but it does help them understand what the image is. Consider the difference between:

<img src="[...]" alt="photo of niraD"> [...]
<img src="[...]"> [...]
<img src="[...]" alt="Tennessee Valley Geocachers">

and:

<img src="[...]" alt="photo of niraD"> [...]
<img src="[...]" alt="image with graphical puzzle"> [...]
<img src="[...]" alt="Tennessee Valley Geocachers">

In one case, the user has no idea what the second image is. In the other, it's clear that the second image is a graphical puzzle of some sort.

  • Upvote 2
Link to comment
17 minutes ago, niraD said:

In one case, the user has no idea what the second image is. In the other, it's clear that the second image is a graphical puzzle of some sort.

 

Okay, fine, but it still doesn't allow them to do anything useful with that cache page. It's still effectively blocked to them. Maybe I'm wrong, and it seems from this thread that I am, but to me knowing why it's blocked doesn't really contribute to it being a more inclusive and accessible experience for all players. It hasn't made the content of that cache page any more accessible.

Edited by barefootjeff
  • Upvote 1
Link to comment
23 hours ago, mustakorppi said:
On 11/12/2020 at 7:07 PM, thebruce0 said:

 

I should amend my comment.

I'm speaking of strict XHTML, which does require alt="" not merely alt.

HTML5 does allow for label only with no value, but should only be for boolean attributes, and it can still cause issues if not done properly; and it's just a good habit to get into, adding ="" if the property can exist as empty.

See 3.2.3.1 

IOW, for empty alt tags, use alt="" to be safe.

I believe you will find no support for these claims in the current HTML5 specification.
 

While XHTML may still have some specialist use cases, it has no direct relevance to the cache pages on geocaching.com. As in, those pages are not even attempting to be valid XHTML, nor do they have any reason to.

 

Did you read 3.2.3.1? Here's the latest spec.

I literally summarized in that paragraph what is allowed in HTML5 vs strict XHTML, and to use alt="" to be safe - ie, whether or not it's xhtml, html5, or html4 or earlier. alt="" is universally accepted as a blank value. AND that leaving out ="" is only valid for boolean attributes where the equivalent would be for its value to be the same as the label (eg, disabled or disabled="disabled"). That's by spec.

Valid:
<img src="" alt="" />
<img src="" />
Invalid (but may still be understood):
<img src="" alt />

Edited by thebruce0
Link to comment
7 hours ago, thebruce0 said:

Did you read 3.2.3.1? Here's the latest spec.

Yes, but that was a draft from ten years ago. What I’m saying is that the current active HTML5 spec doesn’t appear to even hint that it should only be used for booleans, or that it’d be in any way ”secondary” to the double quotation mark syntax. I’m fully willing to concede I’m wrong should that be the case, but I don’t consider outdated specs as normative source of anything.

 

Further, I’m saying that the context here is the cache page, with all the other junk it has, and which has a doctype declaration <!DOCTYPE html>. If you try to render that page in an application that can only handle strict XHTML, my instinct says that you’re going to have a bad time long before you even get to the cache description. You could ask ”what about apps that only get the content through the API”, and my response would be ”what do they do with any kind of alt attribute”.

Link to comment
11 minutes ago, mustakorppi said:
7 hours ago, thebruce0 said:

Did you read 3.2.3.1? Here's the latest spec.

Yes, but that was a draft from ten years ago.

Uhh, not the latest spec which I literally just linked.

 

11 minutes ago, mustakorppi said:

Further, I’m saying that the context here is the cache page, with all the other junk it has, and which has a doctype declaration <!DOCTYPE html>. If you try to render that page in an application that can only handle strict XHTML, my instinct says that you’re going to have a bad time long before you even get to the cache description. You could ask ”what about apps that only get the content through the API”, and my response would be ”what do they do with any kind of alt attribute”.

 

And this is why I said "it's just a good habit to get into, adding ="" if the property can exist as empty"

 

Link to comment
5 hours ago, thebruce0 said:

Uhh, not the latest spec which I literally just linked.

The latest spec you literally just linked does not have a section 3.2.3.1. Attribute syntax is described in 13.1.2.3, and boolean attributes are described in 2.4.2. Neither section says anything like your claims. I would invite you to take a good look in particular at the last example in 2.4.2 and think why that’s in the spec instead of ”it's just a good habit to get into, adding ="".”

Link to comment
4 hours ago, mustakorppi said:
10 hours ago, thebruce0 said:

Uhh, not the latest spec which I literally just linked.

The latest spec you literally just linked does not have a section 3.2.3.1.

Right. Because it's the latest spec and not the same spec as the one linked for 3.2.3.1. But you know that.

 

4 hours ago, mustakorppi said:

I would invite you to take a good look in particular at the last example in 2.4.2 and think why that’s in the spec instead of ”it's just a good habit to get into, adding ="".”

Because that's an ethic, not a rule. It's a good habit. And note that the last example shows acceptable variants, including the only one - which is the subject of this thread - being a boolean attribute, not a text attribute like "alt".  I know 3.2.3.1 is not in the latest spec, I didn't say it was, only to review the latest spec which I linked, which is precisely what I did before commenting, after the prior spec was already referenced. And the latest spec supports my comments.

 

So, once again:

Valid:
<img src="" alt="" />
<img src="" />
Invalid (but may still be understood, if not "fixed" during sanitization):
<img src="" alt />

Alt is not a boolean attribute, it's text, so it is either in the tag or it is not, and if it is there, the value should be enclosed in quotes. And just like single quotes are also acceptable, a value not enclosed in quotes can also be understood but leaves room for error if there are spaces and other attributes follow. 

All of these 'ifs' are why it's a good habit to use proper form so there's no room for error or misunderstanding. No that's not a rule. It's an ethic. And that's why I'm saying it, to encourage people to use 'good form' when writing html, for consistency, understandability, and to reduce frustration if there happens to be an issue to fix.

 

Do you disagree? If so, then we are at an impasse. I've addressed how to include the alt attribute in the img tag properly using best practice. Do it loosely if you want. Whatev.

Edited by thebruce0
  • Upvote 1
Link to comment
20 hours ago, thebruce0 said:

And the latest spec supports my comments.

Yet you did not cite where.
 

You wrote multiple paragraphs of text and made up your own examples, but did not address at all the fact that the sections of the spec I mentioned say literally nothing about unquoted empty attribute syntax being only for boolean attributes, which you claim to be the case. Nor about double quote syntax being somehow stricter or better than unquoted syntax, which was your second claim.
 

You are of course free to write code that would be valid XHTML and think whatever you like about people who don’t, but that doesn’t make it the HTML5 spec and that doesn’t make it a HTML5 best practice either.

 

Also,  you can’t simultaneously claim that <img src="" alt /> is ”invalid” and that it’s ”loose”. You know full well what ”invalid” means in this context. There is literally no way you can in good faith argue that is invalid HTML5.

Edited by mustakorppi
Link to comment
2 hours ago, mustakorppi said:

Yet you did not cite where.

Oh my gosh. Let it go. My point was clear and I stand by it as does the latest spec, for anyone intending to use the ALT attribute for the IMG tag. I'm not going to debate best practices for HTML syntax any more as that's not the topic of this thread.

Last time for good measure, to the topic at hand:

Valid uses of alt tag:
<img src="url" alt="text" />
<img src="url" alt="" />
<img src="url" />

 

Link to comment
3 minutes ago, thebruce0 said:

EVEN IF you were to use the bad form of <img src="url" alt />, it would be interpreted as alt="alt", not alt="". So nodo not use alt with no value - which as I said I could still be interpreted but it is bad form.

Done.


Alt is not a boolean attribute as I’m sure you would have remembered if you stopped to think instead of rushing to pointlessly argue. If we look at the spec:

Quote

 

Empty attribute syntax

Just the attribute name. The value is implicitly the empty string.

 

Also, do take a look at empty alt in the HTML Accessibility API Mappings. This is directly linked from the spec.

 

Link to comment

:omnomnom:

1. If an attribute contains no text value, it's considered null. Concession: Yes, I misstated how an attribute with no = value is to be interpreted by standards. Rather it's the boolean attributes that states what the text value must be in order to be valid. Valid: disabled="disabled", disabled="", disabled.  Invalid: disabled="yes".  An attribute with a null value (alt, alt="") is to be treated as "null". (Notice: by 'invalid' I do not mean it won't be parsed, but the result may not necessarily be what the coder intended because it doesn't follow the attribute definition)

2. This is a matter of technical parsing the html text - it is not a definition of best practice. No good programmer will say "because you can, go for it" especially if it leads to code filled with mixed instances of "allowances" like single quotes, no quotes, and valueless attributes. Is it allowable by HTML5 spec? Yes. Is it good practice? No. A spec doc lists what is allowable, it's not a tutor for writing "good code".

3. No references I could find while searching for alt attribute use and explanations included examples of merely an alt with no =value, apart from explicit documentation of its use. Once again, the idea behind the attribute and value pairing is that there is a label, and the label contains a quoted text value. As first stated, best practice mean include the label, and include an =, and include a quoted value of 0 or more characters. EVEN IF variations are allowable, it is not recommended, and most any reputable place you look for tips about writing good html will not recommend sloppy code.

4. See my prior posts about what's valid use of the alt tag, vs what is allowable; and recognize that on my part, I will only ever recommend (even bluntly as I have) the syntax considered valid (recognizing that "invalid" as I've used is in strict context, not loose).

 

alt="alt text"

alt=""

[no alt]

 

Considering we can't even trust the HTML wysiwyg editor on this website to retain standards-allowable formatting in other areas (including css property re-formatting), I will still state the above as proper use of the alt tag, especially in geocaching context.  We done yet?

Link to comment
6 hours ago, thebruce0 said:

Oh my gosh. Let it go. My point was clear and I stand by it as does the latest spec, for anyone intending to use the ALT attribute for the IMG tag. I'm not going to debate best practices for HTML syntax any more as that's not the topic of this thread.

Last time for good measure, to the topic at hand:


Valid uses of alt tag:
<img src="url" alt="text" />
<img src="url" alt="" />
<img src="url" />

 

 

Hope it's not required.  Far too geeky for me!

Link to comment
39 minutes ago, Harry Dolphin said:

Hope it's not required.  Far too geeky for me!

 

It's not required, but like some have argued it's good to have if you are thinking about the visually impaired. And you might encounter someone angry online if you don't use them :P I most often don't either, mainly because I keep forgetting.

 

But, it can be handy in other circumstances as well - if an image doesn't load, the alt or title attributes may prompt the browser to display it as placeholder text, so if there ends up a broken image, at least you can see what it's described as. 

It can be a personal reminder too if you're just looking at your own code, and see the descriptive text :)

  • Upvote 1
Link to comment

Well before the ensuing discussion on html syntax - informative and interesting; thanks! - I decided that if it were intended to be just - alt - we would have been instructed to type it that way, rather than - alt="" -. 

 

Given that I have little extra time these days, I went ahead right then and changed all the "decorative photo"  alt descriptions to have actual descriptions [which I could change back, if needed, when the alt dust settled], with the caveat text, "not needed to locate cache".

 

For example, the alt text for the photo for We Don't Need No Stinkin' Lamp Post is <img src="https://s3.amazonaws.com/gs-geo-images/4108883e-86e6-4db9-b6ab-659c81148883.jpg" alt="truck crashing into lamp post - not needed for locating cache" />

 

I'm not sure why "decorative" photos shouldn't be announced by a text reader, and wonder if that takes away from the full experience of the cache page. As in the above example, why shouldn't those using text readers get the opportunity for a chuckle, too? 

 

I do remember that some folks find it irksome to have photos in the cache page, though. So at least until the alt="" quirk is straight, consider me an equal opportunity irker! 

Edited by VAVAPAM
Syntax. j/k
Link to comment
2 hours ago, VAVAPAM said:

I'm not sure why "decorative" photos shouldn't be announced by a text reader, and wonder if that takes away from the full experience of the cache page. As in the above example, why shouldn't those using text readers get the opportunity for a chuckle, too? 

 

W3C has this page on the reasoning, and also to help authors recognize when an image is decorative. (The entire Web Accessibility Initiative site is a tremendous resource for understanding these topics in a wider context.)

  • Helpful 1
Link to comment
On 11/9/2020 at 2:54 PM, barefootjeff said:

So I'm wondering

 

On 11/10/2020 at 4:17 PM, barefootjeff said:

so I'm really wondering

 

On 11/12/2020 at 4:45 PM, barefootjeff said:

I'm wondering how

 

if you dislike something or disagree with it, it's OK to just say so. You don't have to rhetorically, passively-aggressively "wonder" about it.

  • Upvote 3
  • Surprised 1
Link to comment
On 11/15/2020 at 7:27 PM, Harry Dolphin said:

Hope it's not required.  Far too geeky for me!

 

If you're using the "what you see is what you get" (WYSIWYG) cache page editor, it has an easy way to add alt to an image.

 

1. Click the image icon to embed an image on the cache page.

 

image.png.c2c6cbebcde31ecec7839a70ae32840f.png

 

2. Follow the dialogue to choose an image and upload it.

 

3. Right click on the image and select "Image properties."

 

4. Enter your alt text in the box I circled and hit OK. That's it.

 

image.png.4295701cf018a5f14308dd1e383963c0.png

  • Helpful 2
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...