Clarity: Signpost and Tooltip triggers need to allow for custom values for the aria-label (instead of defaulting to the value stored in the common strings service)

[kalpeshhpatel]

UPDATED

Updating to reflect need for additional inputs in both signposts and tooltips that allow consumers to set a custom aria-label on a per instance basis for both tooltip and signpost components.

• [ ] Investigate feasibility allow consujers to provide a custom value for trigger aria-label instead of defaulting to the value stored in common string service on a per component basis for tooltip/signpost triggers
• [ ] if it can be added, implement new inputs for both component triggers
• [ ] update documentation to reflect these inputs (signpost has the input documented but it's not in the implementation

Describe the bug

For signpost trigger handle, if we provide custom aria-label attribute, it always gets overrides to default aria-label="Signpost Toggle"

Steps to reproduce the behavior:

1. Go to 'https://stackblitz.com/edit/clarity-light-theme-v2-bkoqga?file=src%2Fapp%2Fapp.component.html'
2. Observe that [attr.aria-label]="'View Detail'" has been given to the signpost trigger button.
3. Inspect BUTTON LINK TRIGGER in the developer tool.
4. It's aria-label resets to Signpost Toggle and not the View Detail

Expected behavior

If we have added custom aria-label to the signpost trigger item, it should get precedence over default aria-label.

A use case is, for different signposts across the app, we may have different aria-label, which defines the meaning of button to the screen-reader.

Versions

This issue is reproducible with the latest version of Clarity.

[hippee-lee]

This is overridable with common strings. See https://v2.clarity.design/internationalization for how to set a different value.

It does look like the signpostToggle value is missing from the website so I'm going to change the title for this to reflect updating the i18n documentation list of overridable values.

[kalpeshhpatel]

This is overridable with common strings. See https://v2.clarity.design/internationalization for how to set a different value.

It does look like the signpostToggle value is missing from the website so I'm going to change the title for this to reflect updating the i18n documentation list of overridable values.

I need one help here though.

However, if I have multiple signposts on same page, and each of them represents different content, then is it possible to give different signpost labels to each of them?

Thanks

[hippee-lee]

The common strings addresses the accessibility for the signpost trigger and the associated content. These strings need to be i18n-able and for signposts this is a global settings for the app.

[kalpeshhpatel]

The global level signpost label is not an ideal case IMO. Each signpost should have an option to provide a custom aria-label attribute, since each signpost may convey different information.

I am looking for something like: [clrTooltipLabel] as mentioned here: https://v2.clarity.design/tooltips for the signpost .

Thanks

[hippee-lee]

I re-opened this and also modified it for tooltips.
Both component API's do not support adding a custom aria-label for triggers at this time but it seems like they should allow it to be overridden by consumers.

[lf-collins]

We also need to use aria-label for signpost triggers. We have some signposts on one page, we want to tell screen reader which signpost it is focusing on, and if users want to know more information about it, they can open the popover dialog. This behavior needs Clarity signpost to support custom aria-label.

[lf-collins]

Regarding the signpost content(clr-signpost-content), it is best to add role="region" to identify the boundaries of the component and add aria-label to identify the purpose of each pop-up.

[gnomeontherun]

Clarity cares deeply about accessibility, and we work with our accessibility team to identify and triage issues. We have an internal tracking system to identify and verify accessibility issues, which has captured this already. Some issues with Clarity Angular are difficult to solve without causing side effects or breaking changes, and we have to balance concerns with fixing issues and breaking changes. As we build out Clarity Core, we are able to address these root cause accessibility issues and recommend adopting the Clarity Core implementations as they become available. We are closing this issue as we have the issues tracked internally. Please follow our development and releases to see when we release relevant Clarity Core components to make this possible.