WCAG has a great design pattern for implementing Tabs with Tabpanels here
It uses a "roving tab index", and keyboard arrow keys to cycle between tabs.
This works great, but I recently received a request to make a tab/tabpanel widget that only shows one tab at a time, and has "previous" and "next" arrow buttons to cycle through the tabs.
Visually, the arrow buttons are on either side of the active tab. But in terms of tab-order, the WCAG design pattern specifically states that the tabpanel associated with the active tab should follow it in tab order.
Would it violate any accessibility rules to add these new arrow nav buttons to the widget, as long as I assure that their tab order is before or after the tabs/tabpanels?
I figure the keyboard functionality could remain as it currently is (using arrow keys to cycle between tabs)
I'm a blind screen reader user.
I would maintain left/right arrow keys to navigate through the tabs as usual, and don't make your arrow buttons focusable at all.
My reasoning behind this is the following:
Your arrow buttons control scrolling and scrolling is pure visual stuff
Usually, as a screen reader user, we don't have keyboard access to buttons within scrollbars. It is completely transparent for us.
IF you take a multiline text area for example, the down arrow always goes to the next line, regardless of whether the cursor is currently at the bottom of the screen.
We don't have anything special to do, and especially we don't have to manually press the down arrow button of the scroll bar. The cursor goes to the next line, and the text content is automatically scrolled one line down if needed.
The same things happen for a tab control if there are too many tabs to fit on a single line.
In that case, in popular GUI desktop libraries, you can choose to show scroll arrow buttons, or make the tabs spand multiple lines.
It never change the way to navigate: left and right arrow keys always go to the next or previous tab, regardless of what has to happen visually.
As a bonus, usually, when you click on a scrollbar button, the focus doesn't go to the button; it immediately goes back to the real content, i.e. the text in the text area, or the currently active tab for a tab control.
This is one or more confirmation that scroll buttons shouldn't enter in tab order.
As another bonus, given that you are implementing scroll buttons on your own, you should also react to mouse wheel.
Related
I have a list of elements and a sticky button, fixed at the bottom of the screen. So when the user scrolls down in the list the button stays at the bottom. This works perfectly fine but when I open up my keyboard, the button is pushed up as well, hiding the other elements which are on the top of the screen.
Can I place my button somehow that it remains sticky on the screen but when the keyboard is opened up it doesn't get pushed up?
My current (hacky) implementation is that I am hiding the button when the keyboard opens up but I don't like it very much.
you must be using any library for keyboard like react-native-keyboard-spacer or etc so you can disable that for that specific screen, another hacky implementation #mikasa
i assume you are wrapping your component with a KeyboardAvoidingView, that would explain your button getting pushed up, so you should consider passing false to "enabled" prop when your keyboard is open, this will cause the keyboard overlay your button. you can check out the docs here https://reactnative.dev/docs/keyboardavoidingview#enabled
I have a pop-out navigation menu that appears on smaller screens when an 'open menu' button is clicked, tapped or keyed with enter or spacebar. (Javascript, CSS and HTML; no jQuery).
The navigation uses divs, rather than an unordered list, with a <nav> container but the problem outlined below happens whether the menu is in divs or an unordered list.
If a keyboard user is tabbing, opens the pop-out, continues tabbing, the user is cycled round the trapped area until either a navigation link is opened with the enter/spacebar keys or the pop-out is closed by using the enter/spacebar on the 'close button' or the Escape key is pressed (with thanks to Graham Ritchie for this code).
It works fine in general. See this Codepen that works.
BUT, if the last item in the menu is both a direct link and a parent with a sub-menu, then the trapping does not work and anyone tabbing in the pop-out menu finds themselves in the browser's address bar area outside the website itself or, in the case of this Codepen where it is not working correctly, the tabbing moves down to the 'Console, Assets, Comments...' area at the bottom of the browser.
Can anyone explain why this is happening and what I need to do to resolve it? Thank you.
I am using a slickgrid in angularjjs. I have set the "enableTextSelectionOnCells" and "enableCellNavigation" to true. Now when i navigate the grid using keyboard arrow keys, the scrolling is quite weird. To scroll using keyboard arrows, i first click a cell and then press down or up arrow, the current active cell gets changed upon pressing up or down key but it is not proper, meaning the next active when clicking down key is not the immediate next cell(downwards) - Just like this example https://mleibman.github.io/SlickGrid/examples/example-spreadsheet.html
I want to excel like keyboard navigation in slickgrid, how can i achieve that.
After a week, I found that I was using a chrome extension called "smooth scroll" which used to override the behavior of slickgrid scroll. I removed the extension and scroll is working fine using keyboard arrows.
I am creating a component that shows a bunch of user photos inside a container with overflow:auto, each photo is surrounded by an <a> tag. There is no space around these images, so if the user ever users the middle click to auto scroll this list of photos it will ALWAYS open the link instead of starting auto scroll. That means auto scroll doesn't work.
Is there a trick that will make a middle click that occurs inside one of these image links to use the auto scroll rather than opening the link in a new tab?
Here is a fiddle that demonstrates the issue :
http://jsfiddle.net/uBrbb/
My original fiddle actually showed the scroll bar - which then allowed the middle click on the scroll bar itself - but in my actual case the scroll bars are hidden with a negative padding so that I can display a custom scroll bar (which I simulated using simple up/down buttons).
There are some complicated things you can do, but if possible, it would be better not to wrap the <img> elements in <a></a> to begin with, and instead handle the navigation by responding to your own click() event. In your click event, only perform navigation under the condition (e.which == 1) (left click), leaving middle click to the default behavior.
I am working with iScroll for an iPad web-app. When a user touches the next button (on top of the keyboard) focus jumps to a form element on another slide it breaks the scroller.
I have tried putting each slide in a separate form tag so it would grey out "next" when the end of the form is reached. This yielded no results and the button still jumps across slides.
How can I remove the Prev/Next buttons or at least define boundaries for it?
I've been trying to come up with an answer myself for a few days now. It seems the next/back buttons traverse all input elements visible on the page (they don't even have to be in the same / any form).
The best solution I've been able to come up with is to disable the input elements you don't want traversed.