icons: remove <desc> content from icons where not needed

[blackfalcon]

General Support Request

With the data for Auro icons there is a label for desc. For the most part, these descriptions are poorly written, and in the context of use, the visual description of the icon is not of value to a user of assistive technology.

For example, if an icon for an error is included in the accessible name of an element on the page, it will include the following text: "triangle with exclamation mark." If there is additional content with the error icon, for example, "WARNING!" the assistive technology will read back to the user, "WARNING! triangle with exclamation mark."

When SVGs are used with auro-icon, it was assumed that adding aria-hidden="true" to the SVG wrapper would suppress the reading of this desc text. Assistive technologies like macOS VoiceOver sees this as essential text, and logic considers that if there is a <desc> then the developer intended this to be announced.

Possible Solution

Quickly reviewing all the desc content for the icons, other than the icon that denotes a link to an external site or opens a new window/tab, none of these have real assistive value when in use.

I would recommend that all the desc content be deleted from the SVG data, except in cases where we intend the content to be read aloud.

Additionally, items like role and aria-labelledby will have to be addressed to either be removed or dynamic based on use.

If it is determined that the only use case for the desc is with external link icons, it could be proposed to move that functionality to auro-hyperlink and remove the need to support desc in the SVGs.

The expected outcome is that all icons without desc data would be rendered as fully decorative and NOT read by assistive technologies.

<svg
  xmlns="http://www.w3.org/2000/svg"
  class="ico_squareLarge"
  viewBox="0 0 24 24"
  part="svg"
  role="presentation"

  <!-- guarantee the SVG never becomes focusable in Firefox or old Chromium builds, -->
  aria-hidden="true"
  focusable="false"
  <!-- guarantee the SVG never becomes focusable in Firefox or old Chromium builds, -->
  
  style="min-width:var(--auro-size-lg, var(--ds-size-300, 1.5rem));height:var(--auro-size-lg, var(--ds-size-300, 1.5rem));fill:currentColor"
>
  <title></title>
  <desc></desc>
  <path d="M7.44 11.14..." />
</svg>

Additional context

In the rare cases that the icon is not considered presentational, a user of the SVG raw can edit the metadata for the SVG and address accessibility. Users of auro-icon can place aria-label on the custom element tag, and this will be supported by the accessibility DOM tree.

I also want to point out that even in its current state, there are cases where the desc content is NOT used in the accessibility DOM tree. One leading example is within buttons. When an icon appears inside a “button-with-icon” design pattern, accessibility engines apply the rule that this icon is inside a button and it is assumed as decorative.

If there is no aria-label on the button, then the desc content is read aloud. If there is an aria-label attribute on the button element, in this case, this will override the desc content to the assistive technology. If there is no desc the button will have no accessible name and that will be a WCAG violation.

This needs to be considered with icon-only elements like auro-button. In this use case, it must be made clear that users of an icon-only auro-button MUST add aria-label content to the button.

Exit criteria

No response

[blackfalcon]

UPDATE:

With some further investigation, I have also learned that Safari (on both macOS and iOS) intentionally do not announce SVG <title> and <desc> content when the SVG is nested inside an interactive element like a link.

VoiceOver only reads the link’s accessible name generated from either aria-label, alt, or the actual string within the link.

Chrome on macOS will announce the SVG’s title and description because it exposes the SVG as a separate accessible node, but this behavior is inconsistent and cannot be relied upon.

On iOS, all browsers use WebKit, so the SVG title and description are never announced. As a result, SVG <title>/<desc> should not be used to convey functional or behavioral information (such as “opens in a new tab”); that information must be included in the link’s accessible name or via visually hidden text within the link itself.

All of this supports the decision to remove the <title>/<desc> text from the SVG. This adds weight to the discussion about updating components like auro-hyperlink to add the ... opens in new window... to the anchor element itself and not rely on the <title>/<desc> from the SVG.

NOTE:

Currently, links with the external-link-stroke.svg or new-window-stroke.svg icons, the new-window notification is NOT being read back to an AT user using Safari. This is NOT a WCAG violation. The use of the new-window icon is considered a best practice, and there are no requirements for reading this information back to the user.

[megrenn]

prioritized for Q1 improvements, tracked in ADO here: https://dev.azure.com/itsals/E_Retain_Content/_workitems/edit/1438966

[blackfalcon]

We may want to consider moving this repo to the @AuroDesignSystem namespace. It's the last repo that is still publishing on the deprecated @alaskaairux namespace.