Non-ideal ARIA tabs use

Using the [Accessibility page](https://2023.stateofhtml.com/en-US/features/accessibility/) from the latest (2023) survey, the ARIA tabs pattern is not being used ideally.

Each tablist on the page contains only a single tab. You can confirm that there are 5 instances of `tablist` on the page:
```
//*[@role="tablist"][contains(//*[@role],"tab")]
```
And you can confirm there are a total of 5 `tab`s on the page (one in each `tablist`):
```
//*[@role="tablist"]//*[@role="tab"]
```

While ARIA does not disallow single-tab `tablist`s, the user expectation is that a tabbed interface will provide them with choice. Given that each tab has an interactive control immediately following it, the visual and programmatic structure could lead a user to believe that button is another tab. Given there are also 5 instances (one for each `tablist`), the correlation is reasonable:
```
//*[@role="tablist"]/following-sibling::button
```

In addition, 2 of the 7 `tabpanels` on the page have invalid accName references:
```
//*[@role="tabpanel"][@aria-labelledby="radix-:Rlah:-trigger-tab-0"]
//*[@role="tabpanel"][@aria-labelledby="radix-:R25ah:-trigger-tab-0"]
```

This further confuses the pattern for screen reader users.

I encourage you to either remove the tabs pattern when there is only one option or to confirm with your users that this is not a point of confusion. And to fix the accName references. And to dump the pattern completely on the "Recommended Resources" promo box.

Start at the 2023 Accessibility page and reproduce the reported XPath checks for its tablists, tabs, tabpanels, and following-sibling buttons. Done means single-option tab patterns are removed or justified, the two invalid aria-labelledby references are fixed, and the Recommended Resources promo box no longer uses the tabs pattern.

Written by the indexing model from the issue text.