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.
Related
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).
I tried and understood what could be the purpose of the accessibilityActivationPoint but in vain.
When a focused accessible element is activated, that property should indicate VoiceOver the specific area it's going to activate when a user double-taps the element (Apple reference) : for me, it's always the selected element itself.
I understood the selected element is considered as a block by VoiceOver, whatever the other elements inside. Once a double tap occurs to activate this block, VoiceOver calls accessibilityActivate to know what to perform (Apple reference).
1/. I've written many tests by creating a custom view including a switch control. Whatever the value of accessibilityActivationPoint inside (or outside on another switch control), the value of the switch control never changes. Is it a proper use case or am I totally wrong ?
2/. When we gather many elements inside one accessible element, how is VoiceOver able to activate one of them while they aren't accessible by definition ? Pointing one of them thanks to the accessibilityActivationPoint should work ?
Personally, I couldn't make it work and think that I'm really confusing accessibilityActivationPoint and accessibilityActivate.
Any help would be appreciated, thanks in advance.
Yes, you have the right idea with accessibilityActivate and accessibilityActivationPoint. Note that, in order for it to work, the accessibilityActivationPoint needs to be a point within the Control that you are trying to activate in on-screen coordinates (use the convert function!).
I think the short answer is "yes" to answer your second question, but, just to clear up confusion about when Accessibility Activation Point is useful, I'll go into more detail about it.
By default (aka, the default behavior for AcessibilityActivate()), when any view is activated by VoiceOver, VoiceOver will send a "tap gesture" to the center of the view. The position of this "tap gesture" can be changed by updating the accessibilityActivationPoint attribute on a view. Below, I have an example for how this property can be used.
Let's say you have a blank button (in the image below, the button is the gray box) next to some text:
For the purpose of accessibility, you may want to make the entire view that holds the button and text an Accessibility Element (so that VoiceOver users can easily understand that the button is associated with the text "Worldspace Attest"). In the image below, I am using Accessibility Inspector to show that the view holding both of these elements is an Accessibility Element.
Notice in these images that the button is not in the center of the view, but rather, it is to the right. When you activate this view using VoiceOver, the view will not select the button; instead, it will send a "tap" to the center of the view (which is the same as tapping the text, which does not do anything). In order to select the button, you have to set the view's accessibilityActivationPoint to be the on-screen coordinates of the button:
view.accessibilityActivationPoint = self.convert(button.center, to: UIApplication.shared.windows.first)
This should make it so that this button is usable by a VoiceOver user.
I hope this information clears up any confusion about the Accessibility Activation Point property. The example I used above can be found in this repository in the "Active Control Name" demo.
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.
Visible in the context of UI-testautomation can mean two different things:
Visible anywhere on the website. You can see it immediately or after you scroll
Visible in the viewport, which means, that you can see the element without scrolling.
In the Ranorex documentation the definition isn't clear regarding this. So what is in Ranorex the exact definition for "visible"?
The visible attribute itself just means that it is possible in general to bring the element to the visible region. If the visible attribute of a parent element is set to false it might also not be possible to make the element itself visible.
It means that visible anywhere on website.
It means if you get visible true but cannot click you need to scroll first.
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.