I'm making an accessible web application. One of the feature is a button that allows users to scroll to a certain section of the page. I'm using window.scrollTo(x,y) for this functionality.
Now testing my application using the built-in Mac VoicerOver, I found that although I can click on the button and scroll with no problem, after scrolling, VoiceOver doesn't read anything. Instead I have to click on the mouse one, or use the keyboard equivalents to make it read the content that's on the screen after scrolling.
I'm afraid that some users may not realize that they need another click after clicking on the button. I have two possible solutions:
When the screen reader read the button, it also tells the user that if they want to go to the livechat, they need to click again after clicking on the button. I know how to implement this one, but it looks verbose and dumb.
Change my code so that VoiceOver will read the content after scrolling. I don't know how to implement this one.
The content I would like the screen reader to read is wrapped in a tag.
If you are only scrolling the page, then most screen reader users will not care that you scrolled. With limited or no vision, whether the screen scrolls or not does not matter because the screen cannot be seen.
However, if you are scrolling the page in order to put a certain element into view, then that would benefit screen reader users too.
It sounds like you're trying to do the latter:
allow users to scroll to a certain section of the page
In that case, you also need to put the keyboard focus on that element via the focus() javascript call. Moving the focus will cause VoiceOver to read that content. But to move the focus to a natively non-focusable element (such as an <h2> or a <section> or <p>), the receiving element will need tabindex="-1".
<h2 tabindex="-1" id="myh2">some heading</h2>
and then somewhere you'd have this javascript:
var element = document.getElementById("myh2");
element.focus();
Related
I have a problem with Office UI Fabric's Panel (well, also Modal). I'm rendering them with multiple input fields to provide data for my app. Due to the number of fields the controls are rendered with a scroll bar. After scrolling down and clicking outside of the input, the focus is being set on the first textfield/dropdown in the container panel what causes the whole thing to be scrolled to the top. Is there a way to prevent setting the focus/scrolling to the first element when clicking outside of the input?
This was indeed a bug and has been resolved already. Tested it in the version 5.56.0.
On a given form, we replace one component with another.
The original component is a series of TextFields, and the new form is some informational text and a button. We hide the first one, and show the second one (the UI designer has both Containers within the form).
I tried using scrollRectToVisible with various values but it didn't seem to make any difference with the scrolling.
continueButtonContainer.setHidden(false);
f.forceRevalidate();
Button continueButton =
(Button)StateMachine.GetInstance().findByName("ButtonContinue", f);
f.scrollComponentToVisible(continueButtonContainer);
f.scrollComponentToVisible(continueButton);
I'm expecting the continue button to be near the top of the screen.
If the screen was scrolled before displaying the continue button, the button ends up right at the bottom of the screen (it was below the bottom of the screen before I put in the scrollComponentToVisible line(s).
After the user scrolls the screen, the button goes up to where it needs to be, and stays there.
If the screen is not scrolled, the button appears where it should be.
I know I can probably add some invisible containers underneath the button and force them onto the screen, but I would rather have a slightly more robust solution.
There are a few issues with this. First you are using forceRevalidate which should be used in very rare cases.
Second it seems that you are invoking this on a Form, this is a bit misleading. While it seems that:
f.add(myCmp);
Adds a component to the form it is really a synonym to:
f.getContentPane().add(myCmp);
That's important because you need to invoke the scrollComponentToVisible on the scrollable container which will actually do the work and ideally be the direct parent of said component. I'm assuming it's the content pane in your case but it depends on layout etc.
The last part is letting the layout do its job. If you are invoking this before the form is showing this might not work. Notice that doing it after a call to show is meaningless as the form might take time with transitions. You can use a show listener or override the laidOut callback method to perform things like this.
Any idea why NVDA reads clickable word when tabbing through text in html example:
<h1 tabindex="1"> testing </h1>
NVDA will read clickable testing
In first place remember that tabindex are not a good practice in a11y, and also headers don't need a tabindex NVDA provides a header navigation with the H key. About the clickable I can say from my experience is a known issue for NVDA, if you check that in other SR (Voice over or Chromebox) should be read properly
Short answer:
the tabindex attribute implies functionality to some screenreaders.
Long answer:
Two primary ways that a screen reader user will navigate your webpage are by skipping through interactive elements or by headings. Interactive elements are things like links, buttons, form fields and any other piece of functionality that the user will initiate on your page. These are navigated by using the 'tab' key.
The other primary way they will navigate your page is by headings. In fact, a survey from webaim lists headings overwhelmingly as the primary method of navigating a page to find information (source). In your example, you have given the heading a tabindex which will give the impression that it has some functionality or interactivity to it. To my understanding, both JAWS and NVDA will read out 'clickable' on elements that have a tabindex, as they could easily (and typically would) have some javascript click handlers that are not evident from the screenreader.
Answer:
It's because of attribute tabindex which makes this element keyboard focusable. One can focus it by pressing TAB key on a keyboard.
Hint #1: Attribute tabindex with value above 0 should be generally avoided!
Don't use tabindex="1", tabindex="2" and so on. Only tabindex="0" or tabindex="-1" can be useful in some cases. Otherwise you can create a complete mess for a user experience.
Read more:
Google: Using a tabindex greater than 0 is considered an anti-pattern.
WebAIM (accessibility): This is almost always a bad idea.
MDN: Avoid using tabindex values greater than 0.
Hint #2: Generally no need to make focusable elements that a user cannot interact with.
As in specific case no sense to make a heading element keyboard focusable if a user cannot interact with it.
If you are concerned about screen reader users have no worries as they read non focusable content just fine. A quote from Accessibility Developer Guide: As opposed to keyboard only users, screen reader users usually do not use the Tab key to read a page! Read the "Screen readers browse and focus modes" to know the difference between navigation using Arrow keys and Tab key.
But... Exception to the rule exists
Exception to the rule exists and it's probably a good idea in cases where developers set tabindex="-1" to headings which they want the focus to be moved programmatically for the purpose of accessibility. Such cases are for example fresh content update with AJAX in single page applications. The focus would be moved to a heading for a user to get aware of the content update and to be able to start from there. Also it can be useful when currently focused content is about to get removed from the DOM (a.g. deleting currently focused table entry) or moving a focus to an error summary heading after a form submit trial etc.
In my case (VoiceOver on MacOS), it seems that H1 is announced as clickable only on Firefox. On Chrome, it's announced correctly.
This leads me to believe it's a Firefox bug.
I am trying to build an app using Extjs 4.1. In general: it is a viewport with a tree panel on the west and a center panel that it is actually a tab-holder panel. When a user clicks on a tree node a tab is populating the center view. I had set an attribute in the tree panel that after selecting a node it gets deselected (deselectAll). The reason for this is that the user can open many tabs from different places (e.g. within each tab). But, when I set the above attribute it is producing an error (the “data” is undefined). The data that is undefined is the data related to the tree node. So, the question concerning selection model:
How can I address this problem (a solution may be to select the fist node, but I don’t want it)?
As for the history utility, I need to implement browser back button. Especially I want to disable browser’s refresh button. If user opens let’s say 15 tabs and accidentally click on browser refresh or “F5” he/she will lose everything. I had tried many things but with no luck. I am unable to understand “Ext history util”. So,
Is there any good example out there?
Could anybody guide me on how to do it?
Notice that the application is built respecting the new “MVC” architecture.
Stopping the refresh event is pretty easy - providing that your page has the focus. E.g.:
Ext.getDoc().on('keypress', function(event) {
if (event.getCharCode() == event.F5) {
event.stopEvent();
console.log('you stopped the refresh event');
}
});
If your page doesn't have the focus then there is nothing that can be done -- but most of the time your page loses the focus when a different browser tab is opened so F5 would be refreshing that one instead anyway.
I'm still trying to wrap my wits around the first part of your question, but I thought I would share that.
EDIT
Instead of trying to stop the default browser behavior (something which you can only do on a very limited basis), you should look into state management. ExtJS supports it on many components. Here is the ExtJS example.
Also here is the example of controlling browser history.
I'm trying to show a context menu when I left-click a NotifyIcon. Just calling NotifyIcon.ContextMenuStrip.Show() doesn't work very well. A solution has been posted here before that calls a secret method using Reflection:
Dim mi As System.Reflection.MethodInfo = GetType(NotifyIcon).GetMethod("ShowContextMenu", Reflection.BindingFlags.Instance Or Reflection.BindingFlags.NonPublic)
mi.Invoke(Icon, Nothing)
This works great, except that I also need to control where the menu is shown. I want to wait for the SystemInformation.DoubleClickTime to elapse between receiving the NotifyIcon.MouseUp event and displaying the menu, so that I can handle single-clicks and double-clicks separately. But invoking the ShowContextMenu method displays the menu at the current mouse position when ShowContextMenu is called, not when the icon was actually clicked. Which means that if the mouse moved during the DoubleClickTime, the menu will be displayed in a different part of the screen. So if I can control where the menu is shown, I can just save the mouse coordinates when I receive the MouseUp event, and then I can ensure that the menu is displayed near the icon. Is there a way to do this?
Thanks in advance.
Well, I just discovered that there are existing programs that exhibit this same behavior. I just went through all the icons in my system tray and about half of them do it. If you left-click the icon and then move the mouse during the delay before the menu appears, the menu will appear at the last mouse location, wherever that is on the screen. Snagit is one application that does this. Outlook is the only program in my tray that always shows the menu where I clicked the icon. But Snagit looks like it's using a .NET ContextMenuStrip, while Outlook is probably using a native menu.
So either this is standard behavior, or it's a problem that no one else has been able to solve either. And as a user, I've never noticed this behavior until yesterday when I was testing my own application. So I guess it's not that big of a deal and I won't worry about it.