I'm very new to React and Javascript, but hoping someone might be able to offer thoughts regarding how to reliably switch keyboard focus on a route change. In the following, selecting any of the menu items(green box is an example) on the LHS leads to a change in the main screen(orange box), but keyboard focus remains on the LHS after pressing Enter.
What I'm trying to achieve is that the keyboard focus switches to being the text highlighted(blue box), thus giving a better experience from a usability point of view. Having searched google, I believe to command to achieve this to be one of the following:
document.getElementById('content-container').focus();
document.getElementById('reviews-in-progress-title').focus();
with the stated Ids being those from the blue boxes in the debug tools. They represent the main screen and specific element, respectively however, neither achieves the desired effect.
What I am able to achieve is switching focus to the element highlighted in the red box using the following:
document.getElementById('sortable-column-manuscriptTitle').focus();
So, my question for the floor is: why is it that I'm able to switch focus to the red box, but not the blue one? It feels like this will be a pretty common (and solved/understood) problem, but I'm not currently able to crack it. Any input gratefully received.
Thanks,
Phil
Some browsers won't allow the focus to be moved to an element if it's not an interactive element. In the blue box, you have an <h1>, which is not natively focusable. In the red box, you have a <buton>, which is focusable.
To get around it, add tabindex="-1" to the <h1>.
This will allow the focus to be moved to a non-interactive element via JS but won't allow the user to tab to it.
Now, having said that, in general you should not move the user's focus unless there's a really good reason for it. You mentioned you wanted to do it for a
"better experience from a usability point of view"
As a keyboard only user, I would find that a worse experience. If I'm a new user to the app and I wanted to explore the LHS menu to see what's available, I would tab to the menu, press enter or space to select the menu, then see what appears on the right. I'd then want to tab to the next menu item and select it to see what appears, but you moved my focus over to the right so now I have to shift+tab all the way back up to the menu. If I were using a sip-and-puff device or another assistive technology instead of a keyboard, that's going to be a lot of effort.
So your intention is good but it might cause a lot of difficulty for some users. That's why I recommend not moving the user's focus unless there's a really, really good reason for it.
Of course the opposite argument can be made. If the focus is not moved then the sip-and-puff user will have to navigate all the way over to the right side to interact with what appears.
You have to do some research to see what might benefit the most users without adversely affecting other users.
Related
I am working on a web page where user has to scroll a lot.
For ease of use, I have added the back-to-top link at the bottom of the page, so user can navigate to the top of the page.
Now I have a html markup like this:
<a class="btn-primary" href="#top">
<span class="btn-content link-content">
<svg focusable="false"><use xlink:href="#arrow-upward"></use></svg>
</span>
</a>
How can I make my link more accessible? I have thought of adding aria-label, but other than that nothing crosses my mind
First of all, render your component usable, for example by following NNg’s Back-to-Top Button Design Guidelines. This is a solid basis. Thanks to #outis for the hint.
Here are some accessibility concerns that come to mind with regards to such a Back to top component.
Alternative text/accessible name
Every interactive element needs an accessible name. This text is not only what gets read by a screen reader when focussing the element, but also how voice control can identify the button, as in “Click on back to top”.
Accompanying text for sighted users
Adding a tooltip for sighted users via the title attribute is always a good idea as well, but you should never rely on that attribute to provide an accessible name, as implementation in screen readers is not good.
Even better would be having the text always visible for everyone. Not everyone gets icons correctly.
That way you also provide a very visible hint to voice command users.
The visible part needs to be included in the accessible name (alt text) for this reason. You should add role="presentation" to the SVG if you have accessible text next to it.
This is an example from the GOV.UK Design System Guidelines, who care a great deal about accessibility. They add it just before the footer on long pages.
Contrast
Since you didn’t share your CSS, we don’t know what it does with colours. You need to make sure that the icon and text’s contrast with the background are still 4.5:1 or above.
Avoid icon-fonts
You already got that right. (:
Since users with reading disorders often make their browser use a font they can read well, icon-fonts will break and remove icons that—ironically—would help them most.
Be careful with animated scroll
Often developers (or designers?) like to fly back to the top instead of the instant jump. This can help users orientate.
Nowadays we can simply specify this with scroll-behaviour: smooth and let the browser do the work.
However you implement this, you should be careful to not cause vertigo in people who are sensitive to these zoom animations. Only apply this if the user can and did not set prefers-reduced-motion
Focus
While it is important to include the button in the tab order, it should probably come right before the footer, even when it’s visible all the time.
Focus needs to be visible, of course, as for all interactive elements.
Keyboard users can easily jump back to top by using their Home key, so it’s less important to have the button in early in focus order or after each chapter or something.
When the button disappears when arriving on top, focus needs to be put somewhere else, it must not be “lost” (going to body or html).
Refer to the WCAG
I might have missed some criteria in this answer.
If you want to be sure, you can open up the WCAG-EM Report Tool and start creating a report for your component.
All criteria of the Web Content Accessibility Criteria will need to be audited by you. This is the industry standard for accessible web applications, and legally binding in a lot of states.
You can also add the Title attribute in your anchor tag
<a class="btn-primary" href="#top" title="go to top of page">
When working on the in-page navigation links, we should not forget the screen reader users, so we must ensure they know the purpose of the link. A common way is an aria-label attribute specifying a meaningful value, such as 'Go to top' or 'Back to top'. Once the aria-label is specified, the content of the link should be hidden from the screen reader (Exceptions exist) i.e.: via aria-hidden='true' .
Another detail that should not be forgotten is the focus handling. By default, most of the browsers just scroll the page when using an #Element's_ID for the href if the id does not exist, and SR/Keyboard users will be affected in such a way that after the page is scrolled to top and Tab key is pressed the focus will move to the next focusable element before the page was scrolled up, so, the result will be, an undesired page scroll down.
There is a working implementation in W3C patterns page https://www.w3.org/WAI/ARIA/apg/patterns/.
Hope this helps in your accessibility journey. The a11y world needs lot of people interested on it.
<body id="top">
...
<a class="btn-primary" aria-label="Back to top" href="#top">...
</a>
...
</body>
EDIT: this feat is impossible. since then I have given up. I shall not delete this question, but rather leave it up right here so future users can see a relevant result to their query on google regarding a similar thing
Goal: Either make a textarea bring up the virtual keyboard when focused(with js) OR make a input[type=text] have multiple lines AND bring the virtual keyboard
(I believe answered here but with unsatisfactory results.) (If anyone knows of fully compatible ways to multiple-line-ify an input[type=text] please tell me)
Expected results: virtual keyboard popup when focusing the input OR textarea fields (via javascript with no user trigger).
Real results: caret appears in text field but keyboard remains unseen.
Here's what I'm trying on a textarea:
document.elementFromPoint(document.querySelector("textarea").getBoundingClientRect().x, document.querySelector("textarea").getBoundingClientRect().y).dispatchEvent(click);
Please don't make irrelevant comments about my code organization
#WaisKamal can you show me your code since you said it works?
HTML(no CSS):
<textarea>textarea</textarea>
<input type="text" value="input" />
<script>
//document.elementFromPoint(document.querySelector("textarea").getBoundingClientRect().x, document.querySelector("textarea").getBoundingClientRect().y).dispatchEvent("click");
document.querySelector("input").focus();
document.querySelector("input").click();
</script>
You can use inputmode to determine how a virtual keyboard behaves
<textarea>textarea</textarea>
<input type="text" value="input" inputmode='text'/>
<script>
//document.elementFromPoint(document.querySelector("textarea").getBoundingClientRect().x, document.querySelector("textarea").getBoundingClientRect().y).dispatchEvent("click");
document.querySelector("input").focus();
document.querySelector("input").click();
</script>
Edit
I'm still testing this out, it seem to give some mixed results in the jsfiddle that I'm currently testing right now, sometimes it works and sometimes it does not
*Edit 2 *
It seems to have the same results without specifying the inputmode It does not work the first time the page loads but if I click somewhere on the page, it works every time I click run.
I'm only speculating here but it seems like the keyboard does not pop up without the page receiving some user interaction first, maybe this is intentional for security reasons but I didn't find any docs saying so.
As for you other question you can give a div or other container element contenteditable to have multiple rows / any dimensions you want.
-
Here is another questions and some answers to the same problem though a bit old, Show virtual keyboard on mobile phones in javascript
-
All in all it does not seem possible so show a virtual keyboard without some user interaction.
I'm working on a chat web application. I want to make sure it is accessible for everyone. Currently, when I tab to the chat content, the focus goes to the first message in the chat - which is at the top of the screen. To access the most recent messages, the user must tab through all the messages. Is there a way to override this behavior so tabbing starts at the bottom of the screen? I can't modify the order of elements in the DOM because that will display the messages out of order and confuse users who don't use a screenreader. Besides, the user would still need to tab through all of the messages to access the input to send a message. How can I make sure tabbing doesn't scroll to the top of the screen?
Bad answer
You could use positive tabindex values, but it's a bad practice.
Many explanations exist about why it's bad. Don't use tabindex.
Simple answer
People who frequently use tab to navigate usually also know that they can move backwards with shift+tab.
So you are safe if you do nothing special, and just assume they will be smart enough to navigate backwards in order to quickly reach last messages.
Better answer
Ask yourself this question: do each messages really has to be individually focusable ?
Probably the answer is no, or at least not so directly with tab alone.
For your particular case, I suggest you to make a list box instead of a flat serie of messages.
Ideally you should probably have this kind of behavior:
Pressing tab goes into the list, pressing tab again goes to the next element outside of it.
Since a single tab is sufficient to skip all messages, the input field to say something can be reached with only two or three tabs
If I want to read the messages one by one, I go to the list, and then can use arrow keys and home/end to navigate between messages in the list. Pay attention to home/end, they are often forgotten, and arrows aren't sufficient in very talky rooms.
When going outside of the list and then back in, the same message should be again focused as when leaving the list
In fact, something often forgotten is that keyboard navigation isn't just about tab. There are as well arrow keys, home/end, spacebar and enter, etc.
There are well written advices on what should do what in which situation on the Internet. Search for example "WAI authoring practice".
IN general, the most useful and most frequent used elements must be quickly reachable.
Keep in mind that if you must press many keys to reach something, you have probably failed in making a well designed interface.
you can use the tabindex attribute :
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex
You can set the tabindex number attribute on specific elements. The incremental order of the tabindex will be the selecting order.
Read more here.
I cannot get JavaScript onKeyDown for keyboard keys 1,2,3,4,5,and 6 to work with Jaws Screenreader. Specifically, I have an html document that is automatically generated with links in it. The links are related in different ways (e.g., a series of links related to dogs, and another set of links related to cats). I want the user to be able to switch between the series of links they're navigating through simply by switching the key they are pressing down. This currently works, but not for users of Jaws Screenreader. For them, nothing happens when they press down on the keys.
Other notes: the keyDown event needs to be able to occur anywhere in the document, so it's not isolated to a small area within the document (e.g., a form or a drop-down menu).
Is there a relatively straightforward solution to allow JAWS screenreader users to press different keys to switch between modes? Any help is greatly appreciated!
Are you exiting the normal browsing mode in which 1-6 and other keys are set to jump to various elements? For example 1-6 jump to headings. If not, press INSERT+Space first.
I'm assuming this is an action where someone holds down 1 and then perhaps arrows through dog-related links, or holds down 2 for cat-related links? If so, it seems to me there's probably a more usable and accessible way to implement this. In general, there has to be a really good reason for me to want to learn your site's keyboard shortcuts, especially if I can do the task with approximately the same number of strokes with screen reader native commands.
This is a 2 part question:
1)
click on one of the demo dropdowns on this page. when you tab over to the next input, the text is selected/highlighted in firefox. how can i prevent this from happening?
2) bonus: can you review my code that is hosted on google and tell me what i can improve?
Well, that is just default behavior on Firefox. A possible workaround is to have the input fields execute a JavaScript or jQuery function on select, have the function blur the field (which would deselect the text) and then refocus on the field. Very basic and I'm sure it'd need a couple extra hacks. Unfortunately without scripting, no there is nothing you can do to prevent that.
I honestly recommend that you leave it alone. That functionality was put in place so you wouldn't have to use your mouse when typing into forms, hitting tab would select all the text so you can easily retype it or hit the right arrow key to go to the end of the field. Removing the functionality will only irritate some of your visitors. If they're using the tab key to get to the next field, they probably want that functionality.