Connection preferences semantic and accessibility problems

The tor browser "Connection" preference pane has a number of semantic issues, and accessibility problems.

Firefox preferences have their own accessibility issues and really should be ported to HTML, so I'm just going to focus on the ones that are unique to the tor browser "Connection" pane.

• The "Changes to Tor Settings will not take effect until you connect" banner and button at the top (#torPreferences-connectMessageBox) are embedded in a single-row <table>. Removed in #41618 (closed).
• The Internet and Tor Network status area (#torPreferences-status-group) has no semantic structure, or any text indicating that this is giving a status. Given a "group" role in !988 (merged).
• The "Test" button (#torPreferences-status-internet-test) is placed in between text nodes, gives no feedback when it is clicked, and looses the focus when it disappears. No longer disappears with #41618 (closed). Made more responsive in !988 (merged).
• The [first] paneConnection <groupbox> doesn't manage focus when it gets hidden. E.g. if focus is within it when tor gets bootstrapped. I think this was dropped in #41618 (closed).
• #torPreferences-bridgeCard-menu is exposed directly in the middle of the DOM. This means it will be encountered during screen reader navigation. It should be hidden, or at the top of the document, or in a <xul:popupset>. Removed in #42036 (closed).
• The "Your Current Bridges" includes a checkbox #torPreferences-currentBridges-switch inside the <h2> element. It should not be inside the heading. It also has no accessible name. Fixed in #41085 (closed).
• The bridge card list (#torPreferences-currentBridges-cards) does not have any list-like semantic structure. Replaced with a grid in #42036 (closed).
• The bridge cards (.torPreferences-bridgeCard) do not have any semantic structure. Replaced with a row in #42036 (closed).
• The collapsed bridge cards cannot be focused to expand them. Removed in #42036 (closed).
• The .emoji <img> elements have both alt and title attribute. The former acts as the accessible name, and the latter as the accessible description. The alt is just the emoji character, whilst the title is a text description. On a screen reader, the emoji will be read out as its description. This results in double speech on a screen reader. Either the alt or the title should be set, but not both. Only uses title after #42036 (closed).
• The .torPreferences-bridgeCard-options <button> does not have an accessible name. Moreover, it is lacking the aria-haspopup="menu" and the corresponding aria-expanded and aria-controls. Replaced in #42036 (closed) with a labelled options menu.
• The .torPreferences-bridgeCard-qrOnion zoom button is not a <button> and cannot receive keyboard focus. Not sure if this is much of an issue since you can copy from the input. Removed in #42036 (closed).
• The QR code dialog does not seem to take focus properly when it is shown. It might also benefit from being able to save the QR code to a file.
• The "Copy Bridge Address" button is non-responsive when using the screen reader. Probably want to have an aria-live region to show the "Copied" text. Replaced with an option in the drop down menu in #42036 (closed). Also added a "Copy addresses" button for user-provided bridges, but this doesn't switch to show "Copied", so has the same experience for visual and screen-reader users.
• The "Remove all bridges" popup (#bridge-remove-modal) does not have the semantics of a dialog. #bridge-remove-dismiss is not a button and does not have an accessible name. The dialog does not receive focus when it is shown. Moreoever, it doesn't look like the firefox modal dialogs. Replaced with firefox dialog in #41085 (closed).
• The "Built-In Bridges" dialog seems to focus the "Help" button, rather than the dialog content or the radio group. The radio options are missing aria-describedby that points to the descriptive text. Help button was removed upstream, see #42303 (closed). Focus now goes to the radio options.
• The "Request Bridge" dialog uses a visual-only CAPTCHA, so is not accessible.
• The refresh captcha button does not have an accessible name.
• The "Contacting BridgeDB. Please Wait." text replaces the "Solve the CAPTCHA to request a bridge." text, but this is not announced on screen readers.
• The "Provide Bridge" dialog (manually specify bridges) input does not have a label. Also, it seems that the placeholder text is being slightly misused to give descriptive information. Added label and changed the placeholder in #41913, but should validate whether we need the "aria-describedby" or whether this overloads the user with information.
• The "Connection Settings" dialog also doesn't capture focus properly. This is actually an upstream issue where it just hides the focus ring: bugzilla bug 1708261, but we can use the same work-around as we did in #42803 (closed). Fixed in #43314 (closed).
• The connection settings dialog is missing accessible names because the labels aren't associated with their controls. Fixed in #43314 (closed).
• Some of the dialogs use a single <h3> element at the top, as well as a dialog title when I think you could just use one. If we are using a header, then I think it shouldn't be h3: the dialog should be its own context, so starting a level-3 doesn't make much sense. Replaced with xul:description in #43314 (closed).
• The "Copy Tor Log to Clipboard" does not announce the change to "Copied" when activated. This is an upstream bug: bugzilla bug 1933156.
• The Tor log input does not have an accessible name.
• The Tor log is semantically a read-only textarea. This makes it difficult to navigate with a screen reader or keyboard.
• The #torPreferences-bridges-locationGroup section (shown when there has been a bootstrapping failure not due to the internet connection) doesn't mange focus when it is hidden.
• There's a lack of semantic or contextual association between the #torPreferences-bridges-location menulist and its #torPreferences-bridges-buttonChooseBridgeForMe submit button. They come across as independent.
• The "Frequently selected locations" and "Other locations" items in #torPreferences-bridges-location are treated as disabled items, rather than as the accessible label for a role="group" element.
• Bridges <groupbox> "group" is missing an accessible name. Fixed in #43320 (closed).

This is just from a single pass-through so there may be more issues. Especially for interactive behaviour.