andy-blum
commented
1 year ago @areagan1030 and/or @oliviaflory can you take a look at the issues marked with 🎨 ?
Open andy-blum opened 1 year ago
andy-blum
commented
1 year ago @areagan1030 and/or @oliviaflory can you take a look at the issues marked with 🎨 ?
oliviaflory
commented
1 year ago @andy-blum
❓Sets of checkboxes need to be reachable using arrow keys
This is definitely a ? for me as well because according to the Carbon checkbox accessibility guidance, the checkboxes are all individual tab stops. And as you mentioned above, when I suggested moving to arrow keys Michael G said that would not be following the expected keyboard behavior.
❌ 🎨 The placement/design of the "clear" button needs to be re-examined. When items are selected and filters are applied, a new button pops into the DOM allowing users to clear their selections. The location of this button, however, places it in a location that's not intuitive to assistive technology users, as they'd have to search in reverse to find it. We have two primary options to fix this:
- Move the clear-selections button to the bottom of the filter panel. This would make it easier for AT users to discover the button after making their selections
- Keep the clear-selections button in the DOM but disable it when no filters are applied. In this way, AT users can scan over the button and know it's there, then return to the top of the filter panel if they wish to clear all their selections.
Additionally, the title of the filter panel updates with the number of selected filters, but per https://github.com/carbon-design-system/carbon-for-ibm-dotcom/issues/9392, these updates are not announced to AT users.
Yes, here are my thoughts on the options:
shift+tab would likely bring the user back to the bottom of the filter panel?❌ 🎨 The visual appearance of filters with sub-items does not convey the existence of those sub-items. Under Technologies, there is a list of sub-items to filter on. This is correctly announced to AT users with the use of aria-expanded, but there's no visual indication that sub-items exist until and unless a user clicks on Artificial Intelligence. We need to provide some sort of visual affordance that there are sub-items in there.
We could provide a caret to indicate the additional items. I've seen in ibm.com/products that there are occasionally more than just two levels (we've seen 5). So how we indicate the levels is tricky. AND how do we make the level selectable and also a dropdown (this is not possible with accordion right now)
Additionally, and on a personal level, I'm not sure how I feel about some items having checkboxes and some not. Was there some design-specific reason to have two separate looks for filter items?
In #10132 I was considering if we should change the filter panel to a tree component because this allows for multiple levels with visual indicators, has less tab stops for the keyboard user, etc. But...it's challenging because you normally wouldn't mix a multi select (checkboxes) and single select tree together.
IBM.com/products needed a filter panel that mixed single select and multi select options, so that is how we ended up with a mix of visual styles. I have a ton of explorations on this from two years ago, I also tried out radio buttons which were shot down.
I did some additional research and found Amazon does do something similar to what we are currently doing (no visual indicator for sub levels), but that doesn't mean it's correct.
andy-blum
commented
1 year ago it's challenging because you normally wouldn't mix a multi select (checkboxes) and single select tree together. ... I also tried out radio buttons which were shot down.
I'd be curious to hear the reasoning as radio buttons are the perfect solution for this. What if we used radio buttons but styled them to look like checkboxes? Then only one could ever be selected and they would match the visuals of the multi-select
mbgower
commented
1 year ago I'm having challenges digesting this thread, so let me play this back to you. I hear 3 problems:
Are those accurate? Assuming they are: 1) one does not use arrow keys to navigate between checkboxes unless they are in some kind of multi-select dropdown. I would not describe what I'm seeing here as a dropdown. Ergo, it's a set of checkboxes and Tab is used to navigate between them. My surprise at any screen reader requesting this suggests that there is something odd going on under the covers that is making them misunderstand what I'm seeing visually. A call with everyone might help 2) I question the interaction, as described by the screen reader user. Here is what I assume happens here... a) I set a filter b) I review the results c) if I don't like the filter, I clear it and start again OR I modify. That flow seems reasonable to me, and the clear button at the top of the filter seems fine. Shoving it at the bottom of the set of filters seems even worse, as I'd have to navigate to the bottom of them to clear, then navigate back to the top to set the filter. 3) We'd better talk about the mixed filter space
andy-blum
commented
1 year ago @mbgower
You want the ability to select multiple product types, but a screenreader user has complained they want to operate between the checkboxes for those products with arrow keys
That's correct, agreed that a call with all parties might be best.
You have put the clear filter button at the top, but a screen reader user has complained that is not a great experience because they have to move up the page to activate
It's not that the button is at the top, it's that it's not in the DOM at all until a selection is made, then the button is added in an area the AT user has already passed through, so they might not know it exists at all.
mbgower
commented
1 year ago I hear the concern, but it doesn't make sense to me to force the user to go through the whole filter settings to reach the clear filter button. I would follow up with them. One possibility is to have the Clear filter button there disabled on load. Disabled buttons won't be in the tab order, but would be read by other JAWS modes. I would revisit this. I suppose you could always put one at the top and one at the bottom of the filter area...
andy-blum
commented
1 year ago Agreed, and that's in the main issue description:
- Keep the clear-selections button in the DOM but disable it when no filters are applied. In this way, AT users can scan over the button and know it's there, then return to the top of the filter panel if they wish to clear all their selections.
I probably should have been clearer about leaving it in the DOM where it is.
oliviaflory
commented
1 year ago Review 6/27
Entire filter panel is list item
Currently:
Olivia & Amanda to sync
Description
Following a meeting to review the accessibility of the Filter Panel, the issues below have been identified.
❓Sets of checkboxes need to be reachable using arrow keys
According to Ram, the checkboxes in the filter panel need to be navigable using the arrow keys to move through the set of all options. The ARIA Authoring Practices Guide, however, does not seem to match this assessment:
It seems @mbgower also recommends against arrow-key navigation in #10132 per Olivia's comment.
❌ Non-checkbox filter buttons are announced as "frames" by JAWS
I'm unable to test with JAWS and VoiceOver isn't announcing this quite the same, so I'm sort of guessing here, but I think this might be related to the use of
aria-controls.On the top-level accordion items (Product Types, Technologies, etc), we have this markup:
On the second-level non-checkbox items (like those under Technologies), we have this markup:
Note that both use the
aria-controlsattribute, but the first one also usesaria-expanded. I'm wondering if the use ofaria-controlswithoutaria-expandedis a pattern used to imply something else. On the other hand, Technologies => Artificial Intelligence does have child items and thearia-expandedattribute. Perhaps the problem is related to using<button>vs<div role="button">?Either way, every single second-level item makes use of the
aria-controlsattribute, even when there are no subitems. We should probably fix that.❓Nested filter options are all announced when they are expanded
Again, this seems to be a JAWS-specific bug that I can't duplicate in VO. During the meeting, Ram showed that when a second-level item with children was expanded, all of the list items were read out immediately.
❌ Mobile version's popup doesn't transfer focus correctly
On iOS voiceover, the filter panel is placed in a modal overlay, but doesn't transfer focus into the modal or trap focus within the modal. This may or may not be an issue specific to the filter panel.
❌ 🎨 The placement/design of the "clear" button needs to be re-examined.
When items are selected and filters are applied, a new button pops into the DOM allowing users to clear their selections. The location of this button, however, places it in a location that's not intuitive to assistive technology users, as they'd have to search in reverse to find it. We have two primary options to fix this:
Additionally, the title of the filter panel updates with the number of selected filters, but per #9392, these updates are not announced to AT users.
❌ 🎨 The visual appearance of filters with sub-items does not convey the existence of those sub-items.
Under Technologies, there is a list of sub-items to filter on. This is correctly announced to AT users with the use of
aria-expanded, but there's no visual indication that sub-items exist until and unless a user clicks on Artificial Intelligence. We need to provide some sort of visual affordance that there are sub-items in there.Additionally, and on a personal level, I'm not sure how I feel about some items having checkboxes and some not. Was there some design-specific reason to have two separate looks for filter items?