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.
Related
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.
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 am trying to simulate traffic on QlikView dashboards for the purposes of load testing. I have created a number of simple dashboards that I am viewing in a web browser. When I click anywhere on a graph or select a field in a list box, I can see that network traffic is generated as the application filters to display updated results.
I would like to simulate this traffic by opening the dashboards with PhantomJS and pretending to click on a few different places. Ideally, I would like to select an object such as chart or listbox and click on that programmatically but clicking on random coordinates within the page should suffice as well. However, the usual JS/JQuery click() operations do not appear to have any effect within QlikView even when displayed in a browser.
Any input as to how to approach this would be much appreciated.
Thanks.
Some additional info per comment: Yes, unfortunately I've tried everything on that page and just about everything else produced by stackoverflow/google searches. I can grab elements and do all the normal operations but the pages produced by qlikview are structured differently from any I've worked with. The majority of the elements are clickable and you actually interact with dashboards by dragging the mouse over sections of graphs to zoom in, or selecting criteria from listboxes. Somehow they fire Ajax calls from deep in qlikview's js but on the surface all elements appear as mostly divs and spans without explicit onclick functionality which may be why they don't respond to anything I've tried so far. For this reason I think moving further away from working with individual elements and simulating something like selecting a random portion of the screen may be best but no luck so far.
I want to make my application accessible.
my application want to behave differently while screen reader is on and off
for example : http://jsbin.com/pakiwuqa/6/edit
when screen-reader(jaws) is on #textContent should be in tabbing after #btn1 or #btn2,
when screen-reader(jaws) is off #textContent should not be in tabbing
is it possible to test that jaws is on or off using javascript ?
I think you misunderstand how a screen reader (SR) is supposed to work, you don't need to put #textContent in the tabbing order.
If the SR user is browsing, they will likely read by using the arrow keys, and they will read through all the non-hidden content in source-code order (#textContent, item 1, item 2). This is standard behaviour and useful, if it could not read the content apart from things you can tab to, it wouldn't be much of a reader.
The role=application is oddly placed though, as that div does not contain any form controls, and might prevent some screen readers from reading #textContent. Application is a region, and should wrap a set of form controls or interactive widgets. When inside a container marked as application, the page is supposed to handle key presses.
If the user is filling in a form, the SR will behave more how you are expecting, and they will skip the #textContent unless it is marked up as a <label>, you use aria-describedby, or they use the arrow keys.
Lastly, there isn't a reliable way of detecting assistive technology on the web, and there are privacy concerns with that approach. It may never be possible, plus when you factor in not everybody who has a disability uses a SR, you find you're better off building an accessible page/application versus hack.
Im making an FTP client, which will rely a lot on javascript.
When browsing through the files, you can navigate using the arrow keys. I add a class of .selected to the currently selected filename, but how can I make this clear to screenreaders? How do I make them focus on the current filename?
Would the best way be to make every filename an anchor, which will get the focus when the filename is selected? And also, where can I find a good guide on web application accessibility? I know the W3C has a checklist for content accessibility, but most of the points there don't apply to web apps.
Simplest way to do this is perhaps to have a series of checkboxes, each with a unique ID, paired with a label:
<input id="chk01" type="checkbox"/><label for="chk01">File1.txt</label>
Using this technique, the input is doing the work of exposing a selected-ness for you, while the label takes care of associating it with the name: when focus goes to the checkbox, the screenreader will automatically read out the associated label text. It's all plain HTML, nothing special required. You're free of course to add in selection coloring on top of this - so long as you keep it in sync with checkbox state.
It may be possible to do something similar with A tags; you can use WAI-ARIA properties to set role="listitem" and aria-selected="true"/"false" as appropriate on the items, with role="list" on the parent container. A screenreader will then read these out as list items, rather than links. This technique is more involved, however, and would really need to be tested with an actual screen reader (eg JAWS, or the freely-available NVDA) to ensure it works.
I would suggest you use a javascript framework to help with accessibility in conjunction with WAI-ARIA For examples of accessible jQuery see
https://github.com/fnagel/jQuery-Accessible-RIA/wiki and for examples of accessible drag and drop with WAI-ARIA see
http://dev.opera.com/articles/view/accessible-drag-and-drop/
First - make sure your basics are covered. The Web Content Accessibility Guidelines (WCAG) don't cover interactivity well, but many of its points remain applicable to web applications.
Next - learn about the ARIA standard for Accessible Rich Internet Applications. This will cover a lot of the interactivity you're trying for.
Some relevant links:
http://webaim.org/ for common accessibility problems, plus some invaluable surveys of screen reader usage
http://www.w3.org/WAI/intro/wcag.php - overview of WCAG 2.0
http://www.w3.org/WAI/intro/aria.php - overview of ARIA
There are a number of books on accessibility, which tend to get outdated fairly fast. Sadly, I'm not aware of any book-length discussions of ARIA -- it's still in development. Try reading the specs.
Last but not least -- get a screen reader and learn to use it. Formal compliance with accessibility standards is great, but nothing beats real testing. NVDA is a free and fully featured screen reader that has decent support for ARIA: http://nvda-project.org/
Hope this helps.
When browsing through the files, you can navigate using the arrow keys.
Building upon a previous answer that neglected this feature, wrap the entire widget in a div with role=application. This notifies the screen reader that JavaScript will be used and will allow the user to navigate the widget with the arrow keys while using a screen reader. The excerpt below details how to design the widget to be accessible. Yes, it's not the simplest solution, but it is the most complete. Take your pick.
Description: A widget that allows the user to select one or more items from a list of choices. (listbox). Keyboard Interaction: Tab: When a list is tabbed to, select the first item if nothing else is already selected. A second tab will take the user out of the widget to the next tab stop on the page. Up/down arrows navigate up and down the list. Shift+Up Arrow and Shift+Down Arrow move and extend the selection. Typing letter or several letters to navigate (same letter goes to each item starting with that, different letters go to first item starting with that entire string). Shift+F10: If the current item has an associated context menu, then this key combination will launch that menu. Selection
Checkbox - Space toggles checkboxes, if the list items are checkable Selectable List Items
Space acts as a toggle to select and deselect the current item. If previous items have been selected, it also deselects them and selects the current item. Shift+Space selects contiguous items from the last selected item to the current item. Ctrl+Arrow moves without selecting. Ctrl+Space selects non-contiguous items and adds the current selected item to all previously selected items. Ctrl+A - It is recommended a checkbox, link or other method be used to select all. The Ctrl+A key could be used to provide the shortcut key.
It is recommended the developer use different styling for the selection when the list is not focused (hint: non-active selection is often shown with a lighter background color). WAI-ARIA Roles, States, and Properties: The listbox container has a role of listbox.Each entry in the listbox should have a role option and should be DOM children of listbox.If is not a DOM child of listbox, then it should be referenced in the listbox by aria-owns.If all items in the listbox are not DOM children of the listbox, then set their aria-setsize and aria-posinset accordingly; otherwise, this information cannot be computed for context by the user agent.If the listbox is not part of another widget, then it should have a visible aria-label referenced on the listbox by
aria-labelledby.Each selected list item should have aria-selected="true".
Examples:
Single select listbox
Listbox in an iframe
Refer to the authoring practices for accessible widgets for examples and more information.
From what I understand, YUI has a large amount of support for ARIA.
See:
http://developer.yahoo.com/yui/theater/video.php?v=kloots-yuiconf2009-a11y
Make sure your solution conforms to ARIA:
http://www.w3.org/WAI/intro/aria.php
HTH