Check every page and interaction in reportbuilder component and fix any accesibility issue that could appear.

Apart from that, we need to address all these comments Jun left on MDL-72588

Accessibility

Headings

1. It would be good to add a heading for the tab panels, even as sr-only headings. This can help screen reader users who navigate by headings to easily reach the tab panel if there's a heading available for the tab panel.

core/dynamic_tabs

1. This is pre-existing, but since the ul element has been assigned the "tablist" role, the li element is being seen by accessibility checkers as missing its parent ul element. We should add "role="none"" to this element to override its native role.

core_reportbuilder/toggle_card

1. (Also pre-existing) I don't think that the div containing the card body needs to be labelled by its heading. We only need to label these div containers if they serve as a landmark for the page (e.g. they are assigned with an ARIA landmark role).

core_reportbuilder/local/audience/form

1. I think that it would be appropriate to enclose the card's title in a heading element (e.g. h3, then styled as h4 or h5). This would also help screen reader users to easily navigate the forms via their respective headings.
2. Instead of adding the disabled class to the edit-audience and delete-audience icons, it would be better to set the disabled attribute. Keyboard-only users might get confused if they land on these disabled buttons and do not know that they are supposed to be disabled.
3. It would be more appropriate to render the edit and delete audience as buttons. Rendering them as buttons (e.g. as <button type="button">), especially if you assign them the "btn btn-link" (and optionally "btn-icon") classes, will make it easier for users with accessibility needs to easily click on them as this styling increases the clickable area of the buttons. Keyboard-only users can also activate these buttons using the space key as well.
4. When adding multiple audiences (e.g. Assigned system roles then Manually added users), duplicate IDs can exist. Unless the form instance div's ID is being used in JS, I don't think it's necessary to have this ID.
5. There's also no need for the form div to be set as labelled by the title div.

Also we need to address the comment Shamim left on MDL-72952

1. At the moment there is an accessibility issue on the editor tab. If you click on the 'delete column' icon in one of the columns and then click on the cancel button in the confirmation dialogue, you'll lose the focus. The focus should go back to the element that triggered the dialogue (in this case the 'delete column' icon). We have a similar issue when clicking on any of the 'move' icons. Another issue is that the 'delete column' link does not have the proper focus outline (see screenshot-1). I agree that this is out of the scope of the current issue, but please create a follow-up issue so we don't forget this.