Improve badge accessibility by removing icon name fallback

Dan MHrequested to merge
3197-document-proper-aria-attributes-for-different-badge-types into main

What does this MR do?

Improve badge accessibility by removing icon name fallback

Remove the fallback that used icon names (e.g., "issue-open-m") as aria-label for icon-only badges. Add developer warning when icon-only badges lack proper aria-label. Update documentation with better examples of good vs. bad labels.

Note: ViewComponent updated in gitlab-org/gitlab!213696

Is this a breaking change?

The component API hasn't changed and existing badges will continue to render.

What changes:

  • Icon-only badges without aria-label previously fell back to the icon name (e.g., "issue-open-m")
  • Now they'll have no aria-label instead
  • Developers get a console warning in development to add proper labels

Impact: Existing icon-only badges without aria-label go from having a bad label to having no label. Both are accessibility issues, but the warning helps prevent new instances and guides fixes.

Migrations needed ( gitlab-org/gitlab!213713)

1. Security Dashboard - Merge Request Badge

File: ee/app/assets/javascripts/security_dashboard/components/shared/merge_request_badge.vue

<gl-badge ref="badge" variant="neutral" icon="merge-request" />

2. Security Dashboard - Policy Violation Badge

File: ee/app/assets/javascripts/security_dashboard/components/shared/policy_violation_badge.vue

<gl-badge variant="neutral" icon="flag" />

3. Security Dashboard - Solution Badge

File: ee/app/assets/javascripts/security_dashboard/components/shared/solution_badge.vue

<gl-badge variant="neutral" icon="bulb" />

4. Vulnerabilities - Archival Badge

File: ee/app/assets/javascripts/vulnerabilities/components/archival_badge.vue

<gl-badge v-gl-tooltip variant="warning" icon="archive" :title="popoverContent" />

Screenshots or screen recordings

Integrations

Does this MR meet the acceptance criteria?

This checklist encourages the authors, reviewers, and maintainers of merge requests (MRs) to confirm changes were analyzed for conformity with the project's guidelines, security and accessibility.

Toggle the acceptance checklist

Conformity

  • The “What does this MR do?” section in the MR description is filled out, explaining the reasons for and scope of the proposed changes, per “Say why not just what”.
    • For example, if the MR is focused on usage guidelines, addressing accessibility challenges could be added in a separate MR.
  • Relevant label(s) are applied to the MR.
  • The MR is added to a milestone.
  • Added the ~"component:*" label(s) if applicable.
  • A changeset is added when this MR will do a patch, minor, or major update. More information can be found in doc/publishing-packages.md.

Components

  • GitLab UI's contributing guidelines.
  • If the MR changes a component's API, integration MR(s) have been opened (see integrations above).

Documentation

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • Security reports checked/validated by a reviewer from the AppSec team

Accessibility

If this MR adds or modifies a component, take a few moments to review the following:

  • All actions and functionality can be done with a keyboard.
  • Links, buttons, and controls have a visible focus state.
  • All content is presented in text or with a text equivalent. For example, alt text for SVG, or aria-label for icons that have meaning or perform actions.
  • Changes in a component’s state are announced by a screen reader. For example, changing aria-expanded="false" to aria-expanded="true" when an accordion is expanded.
  • Color combinations have sufficient contrast.

Related to #3197

Edited by Dan MH

Merge request reports