Fix: remove redundant aria-label from accordion button

[maggiewachs]

This removes the redundant aria-label on the accordion button. An ARIA attribute is not needed because the button's text is sufficient.

Description

• The accordion buttons that contain summary text in Swagger UI are named in a way that fails accessibility standards defined in WCAG SC 2.5.3: Label in Name (Level A)
• This error is present in every default installation of Swagger UI: https://github.com/swagger-api/swagger-ui/blob/master/src/core/components/operation-summary.jsx#L71
• For the websites I work on, that means thousands of accessibility violations across hundreds of our dataset pages
• Removing the aria-label (editing a single line in the source) means we don't need to create a hacky workaround to eliminate the accessible name mismatch, and would benefit all users of Swagger UI, especially those who rely on assistive tech (voice control, screen readers, etc)

Motivation and Context

This change is required for accessibility conformance and to make the accordion buttons more usable for folks on assistive tech, like screen readers and voice control software.

Fixes #9353

How Has This Been Tested?

Verified locally:

• the aria-label is no longer present on the accordion buttons that contain summary text
• screen reader announces the visible text on the accordion button correctly (VoiceOver with Safari, MacOS 14.1)
• Chrome DevTools correctly identifies the accordion button's accessible name and it matches the visible button text

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[char0n]

LGTM. Thank you!

[maggiewachs]

Thank you for the quick turnaround on this one!