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.
Related
I was wondering (have not tested it myself) if Playwright is able to find - for example - a button and click it when it is being overlapped by another button. Or if there is a way to check if an element is more than - for example - 50% visible.
I've read the documentation on Auto-waiting but noticed that it didn't say anything about this phenomenon. isVisible() clearly states the following:
Element is considered visible when it has non-empty bounding box and does not have visibility:hidden computed style. Note that elements of zero size or with display:none are not considered visible.
And thus doesn't say anything about it actually being visible - in the sense of 'on the fore-ground' - to the end-user.
Does anyone know if this is correct or if there is a way to actually test this?
Purely wondering for scalability purposes.
If there is an element on top of the target element, you will get a timeout saying that X element intercepts pointer events, and it will fail.
I think (I'm not 100% sure) that Playwright will only try to click at the center of the element.
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 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.
I'd like to create a layout to show this table in list view, the point is to make the text field resizable according to content. I have try several method, but all fails. I am using FileMaker 12.
Any help much appreciated.
For Browse mode you can set layout objects to dynamically resize based on the layout size, but not on the object contents. If you need this functionality in Browse mode you will probably need to use a web-viewer.
In Preview mode you can use sliding left and sliding up for reduction of the size of the layout objects, but there is no option to expand.
In Browse and Find modes, if a field isn't set to have a scroll bar, the field will expand while the user is entering data, but only then. It will return to the default size when the user navigates to another field or another record.
In Preview mode, you can make the field larger than it could possibly need and set it to slide up and also reduce the size of the enclosing part. But the user won't be able to interact with the interface of the layout (can't click buttons, change data, etc.).
A workaround might be to use a tooltip. If you set the tooltip to the contents of the field itself, then the user can hover over the field to see any expanded contents.
If you really need exactly the functionality that you mention (which I would define as having field height and enclosing body part expand in list view based on the field's content length while in FileMaker), the only way I could see doing it would be to use custom web publishing to create a web page and use FileMaker's web viewer to show that web page. F 'n' web has an article that might be of some assistance if you go this route.
I have this tool tip that is created every so often. What is the appropriate actionscript etiquite?
A. To Create and remove the tooltip moveclip when needed?
or
B. To hide and show the tooltip movieclip when needed?
With these A and B, the answer is B, because creating and then removing an object a lot of times creates a lot of garbage in the memory, which eventually leads to garbage collector calls, that slow your SWF's performance. You can easily go with a single tooltip MC, just fill it with information that corresponds to the new mouse coordinates before you show it.
There is another question, not so straightforward as yours, about how to hide and show a movie clip, either via visible property or via addChild() and removeChild() (AS3 only). If you are using AS2 or AS1, use visible property to hide and show your tooltip.
There are three ways to hide something in Actionscript : Alpha, visible and remove child.
Apha: If you turn the alpha zero the renderer always comes to this displayObject and renders it at alpha zero. So the object is always rendered you just cannot see it.
Visible == false In this case the object still exists in your displaylist. So the renderer comes to the object. Sees it's property is false and leaves it but it still exists in the display list.
removeChild This means that you're removing the object from the display list. This means that the renderer never had to even check for it. Which makes it the fastest option.
addChild doesn't take that much computing power as visible check. I'm sure you can find benchmarks on this.
If you don't have a lot of objects on yours screen and the tooltip is there every second I'd go with visible is false. In all other cases go with the third option.
On a side note, I've found it always easier to manage them with a toolTipManager. A class that makes sure that you have one tooltip on the screen because usually users only use one tooltip. So that makes things easier for me. I just always create the necessary tooltips and add them to the displaylist when required and remove them. (Not recreate them) At the same time have only one tooltip on stage.