Closed scoutb-cogapp closed 2 weeks ago
I found I was able to focus on the sidebar's .main
div after removing links and from there use arrows to scroll.
Has anyone else tried and found they can't?
I edited the manifest to completely remove the links (https://gist.githubusercontent.com/Saira-A/41d645a926e28888ec22c87fbf03214e/raw/a8cc631c3fc9386c971ed57dcbf5444edda4b509/gistfile1.json) and from there it doesn't let me scroll at all using the arrow keys - the tabbing goes straight from the panel open/collapse button to the footer options
Is that with the panel open or closed @Saira-A?
With it closed I get the panel arrows highlighted and then tab takes me to the footer, but that's what I'd expect with the panel closed.
If I open the panel, either before tabbing, or as part of the sequence, I get the main div focused and I can scroll.
It's for both - whether it's open or closed it goes straight from the panel arrows to the footer icons. That's with Chrome, I just tried it on Safari and it completely skips the footer icons as well (though not the bottom search bar if it has one)
Weird. I guess we could just stick tabindex=0 on the main div. Something like
this.$main.attr('tabindex', 0);
on line 38 of MoreInfoRightPanel.ts
should do it I think.
I'll take a look at that tomorrow.
UV version: universalviewer@4.0.25
I'm submitting a: bug report => please fork one of these codesandbox examples with a repro of your issue and include a link to it below
Page area
information sidebar
Issue description
The sidebar is made to fit the size of the image viewer which means that it becomes scrollable when the content outgrows the space given. This scrolling needs to be possible for keyboard users. As long as there is at least one link (or other focusable item) inside the sidebar, this is no problem: the user tabs to this item and then they can use the up and down keys to scroll. However, if there is no focusable item inside, there is no way for a user to tab into or otherwise access the sidebar and they won't be able to read the whole content.
Note that the same issue applies to the sidebar modal (the box that pops up when users activate the info icon on slim screens where there is no space for the sidebar). But i expect the fix is in the same place and will apply to both.
Steps to reproduce
Expected behaviour
Keyboard users can view the whole sidebar even if it doesn't contain any links.
Possible fix
Include the sidebar in the tab index. That way a keyboard user will be able to interact with it even when there are no other focusable elements inside.
WCAG criterion
2.1.1 Keyboard (Level A)
Related code