a11y: Response table is not accessible

Q&A (please complete the following information)

• OS: [e.g. macOS] Windows 10
• Browser: [e.g. chrome, safari] Chrome
• Version: [e.g. 22] 131
• Method of installation: [e.g. npm, dist assets] npm
• Swagger-UI version: [e.g. 3.10.0] swagger-ui-react 5.11.3
• Swagger/OpenAPI version: [e.g. Swagger 2.0, OpenAPI 3.0] OpenAPI 3.0

Content & configuration

Basic default configuration

Describe the bug you're encountering

We use a tool called Sort Site to evaluate our site for 508 accessibility compliance. It is flagging that the Responses table is not accessible. "Identify row and column headers in data tables using "th" elements and mark layout tables with "role=presentation". Data tables allow screen reader users to understand column and row relationships. Layout tables read cells as a series of unrelated paragraphs with no tabular structure. Without th or role, screen readers apply heuristics to decide whether a table is a layout table or data table. These heuristics vary greatly between screen readers, and are affected by browser being used, window size, and font size (so the outcome is very unpredictable without th or role). If a data table has headers marked up using td, then change these to th. If a data table has no headers, add th elements describing each row and/or column. If the table is only used for layout add role=presentation to the table element." Violates WCAG 2.0 A F91 https://www.w3.org/TR/WCAG20-TECHS/F91.html
This is in the table with class "responses-table" contained in the div with class "responses-inner".

To reproduce...

Click to expand a method pane such as a POST command and see the Responses table.

Expected behavior

No accessibility error :)

Screenshots

Here's the area of the screen

Additional context or thoughts

Here's the Sort Site error info and solution

Search the Swagger UI source for the responses-table class and inspect the table shown when a method pane is expanded. Reproduce the issue with the default configuration and verify the response table has appropriate accessible table semantics and no longer triggers the reported WCAG error.