Alt Text field for apostrophe-images

[plantainrain]

Create a new dedicated field for alt text for apostrophe-images. Currently the title or description field is being used for alt text, but improving the the schema to include a dedicated field for alt text would be good, as well as adding explicit help text to each field. To avoid any sort of BC break and confusion on previous implementations of these fields, we can create a feature flag (an option passed to the apostrophe-images module) that would activate these new fields.

Alt text would be made available the same way other image fields are here:

apostrophe/lib/modules/apostrophe-attachments/lib/api.js

Lines 449 to 460 in 81cdcc5

	if (o.credit) {
	value._credit = o.credit;
	}
	if (o.creditUrl) {
	value._creditUrl = o.creditUrl;
	}
	if (o.description) {
	value._description = o.description;
	}
	if (o.title) {
	value._title = o.title;
	}

[abea]

@bgantick made the point that help text for the legacy fields might not always be the same. I think I'd be in favor of being somewhat opinionated with those, at least "description"--possibly simply renaming that to "caption." People can still use them for various purposes, but the intent will be clearer.

[fredrikekelund]

Report from the wild: we're using the description property to render alt attributes for images in our projects

[abea]

That's fairly common here as well, @fredrikekelund, and you raise a good point of clarification. The problem I think @mtthwmnc is looking to solve is that it's not clear in the user interface which field is to be used for the alt text. Not really clear to the developers as well. So at P'unk we've ended up with a mix of projects using the description field, the title field, and a few using project-specific alt-text fields.

In 3.x I think this is going to be cleared up, but this suggestion would help clear things up without breaking old projects. We should discuss the best way to do that, however.

[boutell]

Using a feature flag means we can be bold and remove anything that we don't feel is still useful. I think it would make sense for the alt field to default to the current value of the title field if it is not edited. That could be visually obvious based on code similar to that we use for the title/slug relationship.

…

On Fri, Oct 5, 2018 at 9:12 AM Alex Bea ***@***.***> wrote: That's fairly common here as well, @fredrikekelund <https://github.com/fredrikekelund>, and you raise a good point of clarification. The problem I think @mtthwmnc <https://github.com/mtthwmnc> is looking to solve is that it's not clear in the user interface which field is to be used for the alt text. Not really clear to the developers as well. So at P'unk we've ended up with a mix of projects using the description field, the title field, and a few using project-specific alt-text fields. In 3.x I think this is going to be cleared up, but this suggestion would help clear things up without breaking old projects. We should discuss the best way to do that, however. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1661 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB9fYXYQ40Vv_E6wXypvlFKhhpPb41pks5uh1rRgaJpZM4XI3_A> .

-- *Thomas Boutell, Chief Software Architect* P'unk Avenue | (215) 755-1330 | punkave.com

[abea]

Since the default right now for apos-images-widget is to use title for the alt attribute, I agree with what (I think) Tom is saying. This continues, but the flag could make it official, meaning it changes the help text ("This title will be used for image 'alt' text (for SEO and accessibility)") for the title field.

description can stay or not. Maybe that updates to be labeled "Caption", since that's what it's defaulted to now.

I understand some clients might have need for a third text field for images, but that really seems like the exception, which could be set on a per project basis. This change could be focused on righting the lack of clarity while maintaining connection with the default image widget.

[bgantick]

Since this is an enhancement, we should avoid re-enforcing bad habits. I would even go so far as to say title shouldn't be used as alt text in apostrophe-images-widgets and this enhancement could rectify that (as well as not use a div element for the rendered description). Alt text is meant to be descriptive and I don't think title suffices. My recommendation is to add an additional alt field and perhaps change description to caption. The enhancement could also add help text to all fields describing how they are used. Again, I really don't think title should be used for alt text. Again, this is an opt-in feature and we can be bold here.

[abea]

My recommendation is to add an additional alt field and perhaps change description to caption. The enhancement could also add help text to all fields describing how they are used.

I like this.

[boutell]

I am having trouble understanding why the right text to show the vision impaired user is not also the right text to support browsing and searching in the media library. People don't often do something well if they have to do almost the same thing twice.

[bgantick]

title and description might be used in combination to produce a <figcaption>, whereas alt would be descriptive, contextual text to use in an alt attribute (not synonymous with either of the other two fields - see examples here: https://webaim.org/techniques/alttext/#context)

[boutell]

I see. Is there a sensible fallback behavior we could offer, something that makes sense to do if the user doesn't enter both?

[bgantick]

I think falling back to an empty alt attribute would be reasonable here (images with alt="" are treated as decorative and are ignored by screen readers, etc) - there are instances where an empty alt is actually desired.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bgantick]

Would like to confirm that a dedicated alt text field will be a thing for A3. Doing this a lot project-level in 2.x projects

[abea]

Yes, that's correct. A3 will only have a simple single image widget, which lets us start fresh and get this right.

Here’s my first pass at fields for Apostrophe 3 image documents:

• Title - Taken from the file name, but editable. Not used in the default widget markup.
• Slug - required for all docs
• Published - I think this would only prevent it from being loaded in templates to the public. See apos-secure-attachments for more security.
• Media tags
• Alternate text - Used as the alt attribute
• Caption - Used in figcaption in the default widget
• Subsection of metadata - Some of this is taken from the image file itself. This is all current functionality.
  • Credit
  • Credit URL
  • Camera model
  • Capture date

This isn’t changing much other than adding “caption” and explicitly renaming “description” to “alternate text” to clarify usage. People can do whatever they want in their templates, but this would communicate intent.

CC @localghost443 @stuartromanek

[boutell]

So the purpose of title, by default, is solely ease of finding it again in "manage images" / "choose images"?

…

On Mon, Jun 22, 2020 at 10:26 AM Alex Bea ***@***.***> wrote: Yes, that's correct. A3 will only have a simple single image widget, which lets us start fresh and get this right. Here’s my first pass at fields *for Apostrophe 3* image documents: - Title - Taken from the file name, but editable. Not used in the default widget markup. - Slug - required for all docs - Published - I think this would only prevent it from being loaded in templates to the public. See apos-secure-attachments <https://github.com/apostrophecms/apostrophe-secure-attachments> for more security. - Media tags - Alternate text - Used as the alt attribute - Caption - Used in figcaption in the default widget - Subsection of metadata - Some of this is taken from the image file itself. This is all current functionality. - Credit - Credit URL - Camera model - Capture date This isn’t changing much other than adding “caption” and explicitly renaming “description” to “alternate text” to clarify usage. People can do whatever they want in their templates, but this would communicate intent. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1661 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAH27MBDDEWB3355SRRLNDRX5SYLANCNFSM4FZDP7AA> .

-- THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

[boutell]

Something else to have on radar here is the actual filenames. People don't love that these can't be changed, are often the original crappy DSC2308234 string from the camera, and have no ongoing relation to the title if the title is changed later. However most seem to agree that filenames aren't all that vital to SEO if you're doing the rest of the SEO job properly for images, so I'm not sure if it's a priority.

…

On Wed, Jun 24, 2020 at 3:19 PM Tom Boutell ***@***.***> wrote: So the purpose of title, by default, is solely ease of finding it again in "manage images" / "choose images"? On Mon, Jun 22, 2020 at 10:26 AM Alex Bea ***@***.***> wrote: > Yes, that's correct. A3 will only have a simple single image widget, > which lets us start fresh and get this right. > > Here’s my first pass at fields *for Apostrophe 3* image documents: > > - Title - Taken from the file name, but editable. Not used in the > default widget markup. > - Slug - required for all docs > - Published - I think this would only prevent it from being loaded in > templates to the public. See apos-secure-attachments > <https://github.com/apostrophecms/apostrophe-secure-attachments> for > more security. > - Media tags > - Alternate text - Used as the alt attribute > - Caption - Used in figcaption in the default widget > - Subsection of metadata - Some of this is taken from the image file > itself. This is all current functionality. > - Credit > - Credit URL > - Camera model > - Capture date > > This isn’t changing much other than adding “caption” and explicitly > renaming “description” to “alternate text” to clarify usage. People can do > whatever they want in their templates, but this would communicate intent. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#1661 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAH27MBDDEWB3355SRRLNDRX5SYLANCNFSM4FZDP7AA> > . > -- THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

-- THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

[boutell]

(If it is a priority, significant rethink needs to happen regarding attachments.)

…

On Wed, Jun 24, 2020 at 3:20 PM Tom Boutell ***@***.***> wrote: Something else to have on radar here is the actual filenames. People don't love that these can't be changed, are often the original crappy DSC2308234 string from the camera, and have no ongoing relation to the title if the title is changed later. However most seem to agree that filenames aren't all that vital to SEO if you're doing the rest of the SEO job properly for images, so I'm not sure if it's a priority. On Wed, Jun 24, 2020 at 3:19 PM Tom Boutell ***@***.***> wrote: > So the purpose of title, by default, is solely ease of finding it again > in "manage images" / "choose images"? > > On Mon, Jun 22, 2020 at 10:26 AM Alex Bea ***@***.***> > wrote: > >> Yes, that's correct. A3 will only have a simple single image widget, >> which lets us start fresh and get this right. >> >> Here’s my first pass at fields *for Apostrophe 3* image documents: >> >> - Title - Taken from the file name, but editable. Not used in the >> default widget markup. >> - Slug - required for all docs >> - Published - I think this would only prevent it from being loaded >> in templates to the public. See apos-secure-attachments >> <https://github.com/apostrophecms/apostrophe-secure-attachments> for >> more security. >> - Media tags >> - Alternate text - Used as the alt attribute >> - Caption - Used in figcaption in the default widget >> - Subsection of metadata - Some of this is taken from the image file >> itself. This is all current functionality. >> - Credit >> - Credit URL >> - Camera model >> - Capture date >> >> This isn’t changing much other than adding “caption” and explicitly >> renaming “description” to “alternate text” to clarify usage. People can do >> whatever they want in their templates, but this would communicate intent. >> >> — >> You are receiving this because you commented. >> Reply to this email directly, view it on GitHub >> <#1661 (comment)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AAAH27MBDDEWB3355SRRLNDRX5SYLANCNFSM4FZDP7AA> >> . >> > > > -- > > THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER > APOSTROPHECMS | apostrophecms.com | he/him/his > -- THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

-- THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

[abea]

Maybe there's no purpose for title. I was working under the assumption that there had to be one, but maybe not. This is where looking at other CMSes would be useful.

[boutell]

If... there's... no... purpose... for... title... then... right, it can't just be used as alt, because sometimes you need alt to be blank. A descriptive name that exists whether you want "alt" or not and is used to power search when browsing for images is reasonably useful, no?

…

On Wed, Jun 24, 2020 at 4:43 PM Alex Bea ***@***.***> wrote: Maybe there's no purpose for title. I was working under the assumption that there had to be one, but maybe not. This is where looking at other CMSes would be useful. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1661 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAH27LRTS3I7X575QXQ353RYJQP5ANCNFSM4FZDP7AA> .

-- THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

[abea]

Theoretically, yes. I don't know if it's something many people take time to fill out in practice. Does no real harm, though. Having the title default to the file name, but be editable, seems fine and covers bases.

[sachowdhary786]

Hi all, is this something that is still on the radar/high priority?
As without this, our company is non-compliant to standards.
Unless there is a work-around that we are unaware of in getting the ALT text to display for the images?

[abea]

@sachowdhary786 The question of this issue is how to add a dedicated alt text field. That will be part of Apostrophe 3.

There is no barrier to meeting this accessibility requirement in Apostrophe 2, but it does require you to choose the field you will use for alt text. The most common choice, I think, is description. You then would write your templates to use that field in the alt attribute. You could even add fall back options in the template so it could use other fields if someone leaves description blank.

[sachowdhary786]

Brilliant!
I will go back and give this a shot.
Thanks for coming back to me so quickly on this!

[abea]

You're welcome. Unfortunately this became less clear for 2.x than it should have been.

[abea]

This is all done for A3. There is a dedicated alt text field and no more confusing description field.