Address Data Verification Non-critical Accessibility Issues

[governmentSponsored]

This ticket covers accessibility issues beyond those required by WCAG.

• Oddity with the Suggested Cases radio buttons: if one of the radio options is selected, the other one cannot receive tab focus until the Clear button is pressed. Ensure the controls can still be focused, regardless of selected state.
• The tables of cases in Transfers and Consolidations have Scope attributes on table data. Scope attributes should only be on table header elements.
• When modals are open, there is an H4 element with a class of "usa-accordion__heading", threw an error in Axe DevTools (medium, best practice).
• Numerous elements overlap awkwardly when viewport is zoomed by 200%. Tables get so wide that some fields go offscreen, cannot see anymore. Will need a one-column implementation (requires design update).
• Investigate the issues identified with screen reader below (VoiceOver on Flexion, may need to verify with Narrator).

Screen Reader Issues

• Region 02 H2 is read as “heading level 2, 2 items, Region, level 1, 02, level 1.” That should probably be “Heading level 2, Region 02”.
• The filter toggles do not provide information about their status (checked/unchecked). Can’t tell whether they’re on or off. They also don’t announce when the state changes. You can toggle them on and off as much as you want, and VO doesn’t say anything. If you do ctrl + option + Space, the button makes a bink noise, as intended, but it does not announce a state change, so you have no way of knowing if it’s on or off.
• Event Type and Event Status are not listed as headings, and neither are the headings over the collapsible regions.
• Each case event row is read as “Heading level 4, court district southern district of new york order filed zero six slash twenty slash two-thousand ten event type consolidation event status pending review, collapsed, button, group.” That is extremely verbose. It reads it all as one breathless line, rather than breaking them up into segments.
• Consolidation
• • Radio buttons under consolidation: the buttons themselves are read as separate elements from their labels. You have to tab through both to get to the next button. Can probably make them one item.
• • The checkbox at the top of the consolidation table does not have a label. Indeed, none of them do. We can probably avoid having a visible label, but one should be provided in the screen-readable description.
• • The table headers read their labels twice (e.g. “Debtor, Debtor”). This is redundant and not needed.
• • The text within each docket entry is listed in groups that say the same text as what the docket says. Like “annual status report reviewed - no action, group; annual status report reviewed - no action.” This is redundant.
    It appears to read the content of the confirmation modal as one long sentence. Strange that there are no breaks or pauses.
• • Approval modal should be titled “Approve Case Consolidation.” Put a period at the end of the title. That should encourage a screen reader to read it correctly. We also may want to change the lead in sentence to “This will confirm the Joint Administration of the following cases:”.
• • The Reason for rejection label does not appear to be associated with the text area in the Rejection modal. It does not get read when you focus on the text area.
• Transfers
• • The headers for Transfers are read as “heading level 4 - undefined undefined event date” etc. It’s not reading the district.
• • Update helper text for case transfers. It should say “and enter the new court division and case number.” That reduces redundancy.
• • Of note, it DOES read the radio buttons on this table correctly, compared to consolidations. This is good.
    The new case number field does not mention that it is dimmed when disabled.
    Interestingly, it reads the required fields as “required”, but also reads “star” in the label.
    For the “custom” non HTML standard checkboxes, it reads the button as separate from the label, instead of seeing them as one component.