Expand my Community achievements bar.

Generate unique image IDs

Avatar

Level 2

10/16/23

Request for Feature Enhancement (RFE) Summary: Duplicate Image component IDs decrease accessibility score
Use-case:

Our accessibility tool detected a WCAG AA violation, when the same image is used multiple times on the same page. When the same image is used multiple times on the same page, both instances share the same ID. That should not be like that according to WCAG and W3C. HTML IDs must be unique. There is also a support ticket for that: E-001038208. Our developers recommend this being fixed on a platform level not in custom code to ensure WCAG and W3C compliance for all customers.

Current/Experienced Behavior: When the same image is used multiple times on the same page (e.g. hero image is used also in content), both instances share the same ID.
Improved/Expected Behavior: All instances of the same image have different IDs by combining the already existing image ID plus the JCR path to make it truly unique.
Environment Details (AEM version/service pack, any other specifics if applicable): AEMaaCS 2023.9.13665.20230927T063259Z
Customer-name/Organization name: ÖGB Verlag
Screenshot (if applicable): see attachments
Code package (if applicable):  
2 Comments

Avatar

Administrator

10/25/23

@martinkastler 

Thanks for proposing this idea
 
This has been reported to the engineering under the internal reference ASSETS-30741. The product team will triage this request to verify feasibility based on the prioritization model. This post will be updated according to the Jira request status.
Status changed to: Investigating

Avatar

Level 1

2/16/24

Hello, we are also interested in a unique image/file/object ID that is truly unique and not shared by duplicate copies of the same image within the DAM.  We seek a lookup that doesn't return multiple images even if they are the same image.  We need to be able to provide an immutable ID that can be used to locate an exact image - even if this image were moved.  I gather there are other requirements for the same.

 

The proposed solution above sounds like it might work for our use, although I'm wondering if we'd actually want to prepend a hash of the JCR path vs the path itself if that is what is being proposed.  We're looking for an ID that would be more friendly/terse than a lengthy path. 

 

To be honest, I am a PM and am not that versed in the existing UUID that is available,  I don't recall the name, but I know that when used it can return more than one image.

 

The hash of the jcr path would also mean the original location of the image in combination with the uuid would be unique, but importantly there would be no meaning/attachment of the original path to it's ongoing use.  The image could move but this new unique ID would still be unique and not subject to collision.

 

Does above sound correct?  What is the status on the request as I gather there could be a platform fix that would make the existing uuid suitable for our purposes.

 

If we could not wait for a fix or there is not one coming, do you have a suggestion for how to approach a custom image ID in the standard DAM workflow?  Any concerns with a hash of jcr path appended to UUID (or whatever the correct name is for the existing attribute).

 

Thanks.