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.
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 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.
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'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 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.