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.
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.
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).
Typically a combobox widget is an input field that launches an associated popup with a bunch of suggestions in the popup. In desktop browsers using keyboard, while the focus stays with the input field, pressing Up/Down arrow keys, the selection within the popup can be changed. Pressing ENTER key populates the input field with current selection in the popup and closes the popup.
For accessibility purpose, the input field is marked role="combobox", the popup is linked with the input field via aria-owns. The AT are indicated the current selection via aria-activedescendant.
While this setup works great in desktop browsers with tools like JAWS/NVDA etc., there seems to be a major issue with voiceover on iOS. On swiping the finger, the virtual cursor moves to the next element in the page from the input field, though I would expect with aria-owns set, the focus to move to the first suggestion item or to the popup.
Any suggestions on how such a combobox widget can be made accessible in iOS with voiceover?
PS: The popup and input field are not siblings in the DOM order.
It sounds like you are creating a custom combobox. If you use the native <select>/<option> elements, the combobox works correctly on ios/voiceover. If you are creating your own, follow the guidance on https://www.w3.org/TR/wai-aria-practices/#combobox. You mentioned several ARIA attributes so perhaps you're already following the advice on that page.
Swiping right with voiceover will move the focus to the next element in the DOM. If your dropdown list is hidden, then focus won't move to it. Double tapping on your <input> should display the dropdown list.
The bug is described in detail here https://bugs.webkit.org/show_bug.cgi?id=134596
Relevant part is this:
Without Scrolling you should be able to click any of the radio buttons
Now scroll down the page
Trying to click any of the radio buttons on the left results in an
offset click. One of the radio buttons below your click will receive
the event.
Expected: The radio button I clicked on gets focus
Actual: The click event is offset the amount the iframe was scrolled.
Main difference is im not using an iframe, just a div, but the same problem.
If I remove either overflow:auto (but it wont let me scroll then) or -webkit-overflow-scrolling property the correct clicks happen. It looks like it was fixed in a nightly, but this has to work now and for backwards compatibility. Is there a hack to get this to work? My best idea so far is to just not have that -webkit-overflow-scrolling prop for iOS until it works, but that kinda sucks because momentum scrolling is what makes it feel much more like an app.
I have 3 grids:- Header,Body and Footer with Body having textboxes.
I have included the Body inside a scrollviewer so that user can type as much data as he wants in the texboxes of Body.
But when the Keyboard pops up the whole view is pushed at top and I cannot see the Header.
The textboxes have wrapping on and also accepts return.
Can the scrollview move up the text when keyboard pops up?
Thanks and Regards,
Kanaya
Not entirely sure if this will help. How about some XAML?
You could capturing the Focus event of the text box that brings the Keyboard up. In that event you could set the scrollViewer.HorizontalOffset property to some caluclated value to get whatever you want in view.
Edit: HorizontalOffest is only a getter user ScrollToHorizontalOffset instead
You probably can make it scroll up like you want, but it will appear very strange to seasoned users of the WP7 operating system. Expected behavior for text input is exactly what you described, the notion Microsoft (I believe) is trying to hit here is that when you want to type something in, you want to clear everything else out of view, and only focus on the textbox at hand.