I have an application which has a main section and a footer. the main section has a tabIndex="-1". The footer holds the copyright thing.The main section further holds some widgets which holds the buttons in a list.When the page loads, the screen reader announces the page load.The body is the default active element. On tab, the focus moves to the first button in the main section.This is the expected behavior. But i don't see this behavior in the virtual cursor mode. So the page loads, the live expression in chrome shows the body as the active element. when i press the down arrow, the screen reader starts reading the footer instead of traversing the dom from up.It entirely skips the main section.Not sure what the issue is. I can't share code as it is proprietary.
I have tried setting the tab index of the main section container to 0.
Expected: the screen reader(in virtual cursor mode/browse mode) NVDA + Chrome should read the dom structure from the top and not skip the main section.
Actual: It skips the main section and directly reads the footer.
You're using roles or semantic HTML elements, I suppose? These have a profound effect on screenreader behavior.
You mentioned that there are buttons in "main" - this might be throwing the screenreader into forms mode, so that the screenreader has nothing to 'read' except button labels, which you get with tabbing. In forms mode, any 'document-like' content will be ignored, unless it's mentioned in an aria-describedby attribute.
You should use tabindex="-1" sparingly - only in cases when you are going to call focus() on that element. It's not clear whether you're doing that. What happens when you remove the tabindex attribute entirely from main?
Also try separating the document part of "main" from the buttons part, with distinct roles for each (e.g. "document" and "application", but there are others you can try).
Related
Is it important to place a focus indicator on a skip link destination even if the target is non interactive ? Do you believe that focus indicator should always be present in order to orient users to know where they are on a page?
No, anything that isn't focusable should not have a focus indicator.
Just make sure that when you do skip to a section that the page scrolls to that page correctly so it is at the top (or near to the top) of the page (i.e. if you have a position:fixed header make sure that wherever you scroll to is not obscured by it).
For a "sighted" user the page change and location will be evident, for a "non-sighted" user on a screen reader their screen reader will guide them as long as you have managed focus correctly onto the non-focusable item (so make sure you use tabindex="-1" so you don't break this pattern if doing this programatically rather than with an anchor).
I use "sighted" and "non-sighted" here as obviously some people use a screen reader who do not have a sight impairment but it is easier to use this for illustration purposes.
What this boils down to is "expected behaviour", which is a key part of accessibility.
It is expected that anything with a focus indicator is interactive, adding focus indicators to non-interactive elements is a bad idea for this reason.
Secondly it is expected behaviour that a skip link will scroll the page to the relevant section, heading etc. As long as this happens your users will be fine.
The only reference I can find on W3C on focus visible enhanced says:
Some elements can take focus (such as the target of a skip link), however, it is only when the element is operable by keyboard controls that this criterion applies.
There's a web page where I'm trying to use Tampermonkey to give focus to an element in an iframe which is cross-origin to the top document. Copious use of console.log() tells me that my script is executing, getting the proper element, and calling focus() or click() on it, but the component isn't scrolling when I press space; I have to manually click on the element for it to scroll from keyboard input (the page is otherwise responding to keyboard input just fine). I used "inspect" on the element I want and then entered $0 into the console to make sure that I referring to the correct element in my script. I even have my Tampermonkey script use the setTimeout() trick, with a timeout of 1 second, but that's of no help.
A few other things of note:
While the page is loading I can scroll up and down using the arrow keys, but as soon as it finishes loading it won't respond to those keys again until I click the element with my mouse.
If I click on the element, press Tab to give focus to the next element, then press Shift-Tab to cycle backwards,
the result is that there's that thin blue outline around my desired element, seeming to indicate that it has focus, yet pressing space or the arrow keys won't scroll it.
I'm using Chrome 68.0.3440.106
EDIT: The pages in question are rented books from VitalSource viewed with their in-browser book viewer. Unless you already have a book with them that's currently valid you won't be able to view the problem pages.
I'm tring to make come UI test using Coded UI. Unfortuanley, It seems to not have access to all DOM elements in browser.
I want to assert value of one text block in form, and by"Add Assertion" the lowest element i can assert is form itself. All tags contained by form was flatten and putted to "id" property in "Add Assertion" widnows, like in the screen below:
Is there a way to assert only one tag in form? In this case i want to assert value "Szczegóły przesyłki: 0--1526203258"
It depends on how your web page is designed. From the image shown it it not clear what field contains the Szczegóły przesyłki: 0--1526203258. However, given (1) the scroll bar and (2) that the Id field is shown and is empty, it is probably the Inner Text field.
Given the number of lines shown above and below the required text you are likely to have selected a larger than necessary part of the screen. When creating an assertion is it often best to move the cross hairs tool around the screen to find the smallest control that contains the required field. Such a UI Control will have no child controls.
I have found that occasionally the Coded UI cross hairs tool loses its place and leaves all four (UP, DOWN, LEFT and RIGHT) arrows grey and inactive, as shown in the screenshot. When this happens try clicking the refresh button located between Add Assertion and the arrows. Some of the arrows should then be shown as black and active. If the DOWN arrow is grey (inactive) and some of the other arrows are black then the properties panel shows a UI Control that has no child components. You should be able to find a UI Control that contains only the required text.
I have a script that uses jQuery UI's graggable and droppable functionality.
Items are dragged from left panel into main area and dropped.
There are two scenarios:
Items are dropped into other boxes, preset on page load or can be dropped into main area to create a new box. The items can be moved between the boxes. Everything works fine with this setup.
In second scenario there are no preset boxes in main area. They are supposed to be created whn an item is dragged and dropped from the left panel. However, for some reason it only allows me to create one box. Here's an example.
My level of UI proficiency is not high enough to spot what the problem is.
Your problem is that in this code:
$.when(createEmptyStack()).then(function(data) { ... }
data is always "" meaning that you're attempting to add a new element to the page with the same id over and over again (your AJAX request to createEmptyStack is not returning anything in the response). This is why it works fine the first time; the id doesn't exist and so the code works as expected.
When you drag another item into the main area, the element may be successfully appended, but it has a duplicate id. This code:
putCardIntoStack(ui.draggable,newstackId);
(in the same block as the code above)
Is always called with the draggable object and just STACK as the newstackId.
In short, this is a problem with your server-side code not returning a stack id. According to Firebug, your AJAX request isn't returning anything at all.
I am trying to display items retrieved from an XML DB using xforms:select1 control using appearance=xxforms:tree. The items appear collapsed or expanded automatically and the behaviour is not the same for all the items retrieved. I have the following questions regarding xxforms:tree view:
how to make sure this view shows sub-nodes (those expandable/collapsable using +/- icon) as collapsed or expanded always, irrespective of, for example, the no. of nodes covered by the + icon?
how to render select1 with tree appearance without making any of the items hyperlinks?
how to make sure no item is highlighted/selected by default?
...and although the docs say xxforms:menu is also a possible appearance (URL http://www.orbeon.com/orbeon/doc/reference-xforms-extensions#tree), the details are not available...
About which branches of the tree should be open — By default all the nodes leading to selected nodes are open, this so the selected values are all visible. But you can change this default behavior and specify which nodes should be open using the xxforms:open attribute. For more on this, see the section "Controlling which tree nodes are initially open" on Selection Controls. Note that this feature was added in October 2010, so it is not included in Orbeon Forms 3.8, and until Orbeon Forms 3.9 is released, you'll need to get a nightly build for this.
About using links in the tree — At this point, the nodes you can click on in the select1 appearance="xxforms:tree control are rendered as links, so users know that this is something they can click on to make a selection. I assume that you don't want them to show as links because the tree might be "read-only" in your case (for information only, not to make a selection). This isn' supported at this point. As a workaround, you could use CSS to change the pointer and appearance of links in the tree so to users they don't even notice that this those are links.
About the menu appearance — It works very much like the tree appearance. See for instance this example using the menu.