Authorization buttons lack informative semantics

[smhigley]

Authorization button semantic issues:

The main authorization button and per-operation authorization buttons have some issues with their accessible name and ARIA attributes:

• The main authorization button does not communicate whether it is locked or unlocked in its name
• The operation-specific authorization buttons use the word "button" in their name, which is redundant and will cause "button" to be announced twice
• Operation-specific authorization buttons lack context about which operation they are associated with. This affects screen reader users who navigate by tab or by form control.
• All buttons lack an indication that they open a dialog (e.g. through aria-haspopup)

Q&A (please complete the following information)

• OS: Windows (also repros on macOS/VoiceOver and iOS/VoiceOver)
• Browser: all
• Version: all
• Method of installation: n/a
• Swagger-UI version: latest master
• Swagger/OpenAPI version: n/a

Content & configuration

The issue repros on https://petstore.swagger.io, and I tested locally by cloning swagger-ui and running it locally off the master branch

Describe the bug you're encountering

Screen reader users lack some contextual information when they encounter authorization buttons.

To reproduce...

Fire up your screen reader of choice and navigate to the buttons in question

Expected behavior

Screen readers should announce "Authorize" + the state of the button (locked or unlocked) + the specific operation (if applicable) + the fact that it opens a popup

[smhigley]

PR on the way

[hidegh]

@smhigley there was another thing very misleading on the UI - the lock icon appeared on public, non secured [AllowAnonymous] endpoints as well.

[danbivins]

Is this issue being worked on at all? Is there a reason why it seems it's gone stale?