[a11y] Restructure WalletTable component

[TylerAPfledderer]

Proposal

This issue is to propose structural improvements to the WalletTable component, in post-completion of its migration to Chakra UI (see #9982).

I would argue that for accessibility purposes it should be an accordion list and not a table.

Firstly, the structure of the component in its current state is rendering nested Tables; essentially, each wallet item row is a table element wrapping a tr element.

Visually speaking, it behaves more like an accordion, with each Wallet listing having a clickable header that reveals more details.

Even if I were to fix the structure to not have the nested tables, I see two issues:

1. The clickable wallet items do not have focus to be able to reveal the additional details via the spacebar or enter keys. The accordion item headers are buttons so that would alleviate that blocker for those who can only navigate with a keyboard, and includes those with the screen readers.
2. I believe a table here would not provide enough accessibility necessary for a blind user with a screen reader to discern the list of information after applying filters from the sidebar and comparisons from the three dropdown options. There might be a case of cognitive overload instead.

As to No. 2, I would want to look for an efficient way to provide dynamic info to a screen reader only to give information to a user about their three comparative selections for each wallet item. Currently the comparisons are only through visual indicators of icons (the check and 'X' marks). And a table cell at least in the current state would not provide enough information to minimize cognitive load to identify which Icon is for which selection. It also would take a long time for the user to reach the arrow to toggle the dropdown of more content and might forget that it's there.

In short: I think there a too many pieces of functionality clashing along with the improper rendering of HTML structure that compromise accessibility.

---

I'm thinking of this interactive approach:

1. User navigates through the filter sidebar to select their options
2. User then navigates to the comparison selections to select three items to compare (a separate container sitting above the list)
3. User then navigates to the list, which reads off with the total number of results from the filter. (This number could be left in the same place as before, but the accordion list would still read this off)
4. When a user tabs over each wallet item (with focus assuming they are accordion buttons), there would be some read-out stating the name of the wallet then each comparison item on whether or not the wallet has the selected feature.
5. Should the user wish to gain more info about the wallet item, then they can toggle this header they are focused on with the spacebar then move through the contents inside.

cc @pettinarip, @corwintines, @minimalsm for thoughts and discussion, recognizing the original implementation comes from PR #6457

[pettinarip]

Just for convenience and easy access, this is the page using the WalletTable: https://ethereum.org/en/wallets/find-wallet/

---

Wow @TylerAPfledderer I think this would be really great to have! This page is also one of the most visited pages we have on the website so I can see that a lot of people will benefit from this.

I totally agree in terms of the a11y improvements. Regardless that having nested tables is allowed and correct, it is not recommended for screen readers.

Now that we have Chakra on our toolbox, it might be a good time to leverage on top of that and use the Accordion component.

look for an efficient way to provide dynamic info to a screen reader only to give information to a user about their three comparative selections for each wallet item

That would be a really good improvement. Are you thinking about having something like a hidden text next to each icon?

Re: the interactive approach

Would be great to have something like that. I'd suggest adding a Skipnav (probably on the sidebar) to jump straight to the results. Something like: "Skip to the results".

---

Just out of curiosity, do you see any benefit that we will lose from not using a table?

[corwintines]

Strongly in favor of this. A refactor using chakra first implementation instead of just refactoring would be great here.

Same question @pettinarip has about potential lost benefit. However, even if we are losing something, I do imagine the pros of this new approach will outweigh any cons.

[corwintines]

I think the Accordion makes a lot of sense here as well.

[TylerAPfledderer]

@pettinarip @corwintines

Are you thinking about having something like a hidden text next to each icon?

If we put each "comparison result" as hidden text with the respective icon, it should still reach the screen reader on readout at initial focus of the accordion item.

Would be great to have something like that. I'd suggest adding a Skipnav (probably on the sidebar) to jump straight to the results. Something like: "Skip to the results".

Yes. Since there are two separate sections of options, maybe if user reaches the filter, they could have two skip nav options to either skip to the comparison options or to the results.

What might get lost (kinda) is some of the content in what would be called the accordion item "header". There are the social icon links that would still be clickable -- though clicking one would also trigger expanding content as it is now -- and you could still tab to it. But the readout will mention both that a link or two exists and then at the end would say something like "button collapsed" in relation to the clickable area. Would this create cognitive load?

Example:

<h2>
  <AccordionButton>
    <Box as="span" flex='1' textAlign='left'>
      Section 1 title
      <a href="#">Link</a>
    </Box>
    <AccordionIcon />
  </AccordionButton>
</h2>

In NVDA, on focus of this button, it will read out as Section 1 title Link button collapsed heading level 2

Side note: a heading element wraps the button so it is provided the role for the total content.

[pettinarip]

Would this create cognitive load?

I'd say so. Reading the title + 3 links + the rest, might be too much. Not saying this is a blocker but would be a nice to have solution.

Idea: could we aria-hidden the links when the accordion is collapsed, and only show them when it is expanded?

[TylerAPfledderer]

That might be possible. What that should do is have the screen reader completely skip them in the tabbing order. Which means the links should be supplied for SR only someplace else, like before the button link in the expanded content, say.

But using aria-hidden will still allow the sighted keyboard user to be able to tab to the links (Only the screen reader will disable the behavior). And the keyboard user can instead use the arrow keys to navigate between the accordion items.

[TylerAPfledderer]

Now with PR #10032 merged, are there any other outstanding thoughts here with this component for a11y?

[TylerAPfledderer]

cc @pettinarip @corwintines

[victoriabowen]

3 months ago I was so devastated when my withdrawal request was declined , then I realized I had been ripped off like over 200k of my bitcoin investment funds .
I have never found myself in such a situation in my whole life .Thanks to my colleague at my workplace who introduced me to an expert on bitcoin recovery , cryptorecoverypro@solution4u.com , they did their magic and the rest is history. They were able to retrieve my funds back in full within 2 weeks and I was so happy that I had to share these experiences .