-
Notifications
You must be signed in to change notification settings - Fork 25.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add alt value to the archive item teaser image #1914
Comments
Have a look in the closed issues as this was proposed before to see what my thoughts are on adding this complexity to theme. Adding |
Where an This is why it was added there in |
I had another look in the closed issues, and I'm going to assume that this comment in #1474 refers to the issue of unnecessarily adding complexity to the theme that you were talking about. If adding |
Summary
The
alt
tag is currently hardcoded blank for the archive single imageminimal-mistakes/_includes/archive-single.html
Lines 16 to 24 in edae4ea
It would be nice to be able to use information within the
post
to populate it.Motivation
After running HTMLProofer over my site, I got lots of errors along the line of
image /assets/images/foo.jpg does not have an alt attribute (line xxx)
for images that generated in the "You may also enjoy" related posts section.It would be nice, for SEO purposes if for no other reason, for the current hardcoded
""
value to be changed to something a bit more dynamic.I would propose at least initially attempting use
post.header.image_description
if it has been specified in the post front matter. Something like what I have currently deployed on my site:I'm happy to create a PR that adds this code in.
Drawbacks
Currently, supported metadata for header images would seem to be limited to
post.header.image_description
, which is fine if yourpost.header.teaser
andpost.header.image
refer to the same image, but probably less good if otherwise. In this case, you would probably want to use a currently non-existentpost.header.teaser_description
attribute. Perhaps that should be added...?Having said that, the proposed change above is non-breaking: if you have
post.header.image_description
it will be used, if not, current default behaviour is maintained.The text was updated successfully, but these errors were encountered: