Closed twnk closed 3 years ago
twnk
commented
3 years ago I am happy to take on any additional work to make this improvement acceptable, such as integrating the alt text editor into the feature image in similar way to the in-post image editor does, but I wanted to supply a minimal working implementation and get feedback on whether this work is welcome first.
concentrateddon
commented
3 years ago Is this still the case? When I’m using the web editor on my iPad, tapping a feature image (which appears above the article headline) brings up a box for a caption, and a button labeled “Alt.” Tapping Alt switches the caption to an “alternate description” text field.
twnk
commented
3 years ago Looks like it was fixed by these pull requests but the issue wasn't closed!
annapin
commented
1 year ago @twnk I don't know if this issue is resolved. My company has just undergone an Accessibility audit for WCAG 2.1 AA compliance by a 3rd party that specializes in Accessibility. They are citing our blog (which we post using Ghost) as being non-compliant. They suggested we reach out to you to figure out how to update the alt attribute on images to make sure they can be coded as decorative via a null (alt="") alt attribute. Currently they have two alt text attributes, which is non-compliant and we can be sued because of it. Can you offer any help?
There's been some minimal prior discussion (a few years ago now) on forums and elsewhere regarding alt text on feature images, mostly regarding using them for 'captions' or image attribution both of which are not the primary purpose of alt text.
Alt text ("alternative text description") is shown to the user as fallback content if the image fails to load or if the user chooses not to display images, but the primary purpose of alt text is for accessibility for visually impaired users. Anyone navigating websites using a screen reader depends on alt text to understand what the image was meant to show.
Most themes currently either omit alt text on feature images, or inappropriately use another attribute such as the post title. This is a particularly bad UX for users with screen readers, as it means they will be read the title aloud twice in addition to being denied any meaningful textual equivalent to the feature image. It should therefore be considered a UX bug, and not a feature request.
Feature images are called feature images because they are typically chosen to be striking and interesting, and they frame the content of the post nicely. They are generally the most important image included on a post, and often the only image. According to the HTML Spec "If the src attribute is set and the alt attribute is set to a value that isn't empty, the image is a key part of the content; the alt attribute gives a textual equivalent or replacement for the image." The post title, or other metadata, is only ever exceptionally a textual equivalent. The only example I can think of would be a photography portfolio site with one post per photograph. In almost all other cases, these images ought to have proper alt text, which cannot be derived from other metadata fields.
In short, Ghost sites should support defining specific alt text for feature images. This is a very minor change in terms of code, with only a few lines required to add the form element to the post editor, but it requires a database migration and schema change to include a field for the alt text to be made available in the post context in templating. I have made the necessary modifications and will reference this issue in the pull requests to Ghost, Admin and SDK.