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.
Related
I'm facing a very weird (& blocking) issue using diagrams.net webapp.
I'm trying to add some nodes in the Format Panel. I created a new tab in this panel & added in it some new inputs.
There are text inputs, checkbox inputs & textarea.
But the behavior is absolutely not the expected one.
For text & cb inputs, everything works fine, but textareas behavior is... at least very weird:
The field can't get focus by mouse clicking (remember that click works on other inputs). The only way to set the focus on it is by using JS focus() method.
Text inside the tag can't be selected by mouse. If element has the focus, text can be updated. Moreover, even if text can be changed, text cursor cannot move from the end of the text.
Textarea box is not resizable. There is the bottom-right arrow to resize it & I added the "resize" value to be sure but the feature doesn't disable but I juste can't. BUT ! If I set the attribute "disabled" then I can resize the box. Unfortunately, I can't disable the textarea since I want to put it because I need to write in it.
I can't show you code for now (it's just a new node creation using document.createElement) but you can easily test this: go to drawio webapp & when the webapp is loaded, use the Inspector in the developer tools to add a new textarea node in the format panel (div with ".geFormatContainer" class) : element is not focusable with the mouse, text inside it is unselectable & box is not resizable as long as "disabled" attribute is not set.
I added a click listener in the component to check if click did something & it does, but it doesn't give the focus to the element (document.activeElement says that body is focused -_-) so I think there is something in mxgraph which avoids the element's classic behavior. But what ?
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'm trying to count (and sum up) different (physical) items and input those counts in a spreadsheet. Is there a way to increase (or decrease) an integer in a field in OpenOffice Calc? Mouse or keyboard input.
Either a shortcut+macro combination or something along the lines of these (fictive) arrows:
i.e. pressing up would increase the field to value 43
In fact I would be happy for any suggestion for an open programme that would digitalize such input and produce some sort of csv or similar output.
Via View - Toolbars - Form Controls get the toolbar Form Controls visible.
There you have Spin Button control (see tooltips).
Insert this on the sheet by clicking it and pull the size of it with the mouse. Pull it longer than width.
Right click the control and select Control... from the context menu.
On the Data tab set the Linked cell to A3 for example.
Now switch the design mode to off by clicking the corresponding button at the toolbar Form Controls (see tooltips).
What I'm trying to do is simple: bring a label in front of an image within a subview.
But all of the options for arranging are disabled/un-selectable when my label is selected. I find this happens often.
What could be the reason that I'm almost never allowed to change the z-axis of my objects in the Arrange menu? Is it a better practice to avoid this feature and set the order of views programmatically?
It can depend on how you have selected the label (similar to how the label can only be moved with the keyboard when selected in some ways).
A simple alternative is to look at the list of view in the pane on the left and to drag the views up and down to change the order.
It happens sometimes. In that situation, click the view or image you want to send back then you will see little square box at the edges of image from which you can re size your image, Just click on it once and then go to Editor > Arrange > Choose option according your need.
I have an email client application, and I'm changing the way we show attachments for an email. Previously we had them up at the top of the email viewer in a scrollable list; now we're moving them so that they're displayed as a list at the bottom of the email content. For reasons related to the UIWebView control, it was necessary for me to implement these attachments as HTML code that is programmatically appended to the HTML of the original email (instead of doing them like a normal person would, where each attachment is just a UIView in iOS).
I'm now trying to configure accessibility for these HTML elements and running into some problems. Each "attachment" consists of a button-like background which is actually constructed from 3 images: one for the left side of the button, one for the right side of the button, and a middle portion which is stretchable (this allows the button to stretch in width without distorting the edges). There's also a paper clip image and a right-arrow image laid out on the "button", and two sub-DIVs for displaying the file name and its size.
The problem is that I want to make the outer DIV that encompasses all of these sub-elements to be the only thing that is focusable by Voiceover, and I want to be able to control what is announced by Voiceover for this DIV (so that I can include the file name, its size, whether or not it's currently downloading etc.). However, it seems that the only things Voiceover wants to focus are the three-subimages that make up the button background (and they're announced by their filenames) and the two sub-DIVs that show the filename and the file size. If I hide all of these sub-elements from Voiceover by setting aria-hidden="true", then nothing gets focused at all. If I set aria-hidden="false" on the outer DIV, the DIV is still not focused.
Is there any way to make a DIV focusable by Voiceover even when it doesn't contain any inner HTML content that Voiceover would focus on its own? I think I could hack a solution where I stretch a completely transparent PNG over the DIV and make that the only inner element with aria-hidden="false", but even then I'm not sure how to get Voiceover to read something other than the file's name.
Update: OK, it seems I can sort of achieve this by adding role="button" on my DIV while keeping all of the sub-elements aria-hidden="true". The entire DIV is now focusable, but it still announces itself as a "button" (I'd like it to say "attachment" instead as the type, but I can live with "button" if necessary). The main problem I'm now encountering is that Voiceover seems to ignore the aria-label property, and instead reads out any text that is contained in my sub-DIVs. Is there any way I can get Voiceover to read the aria-label property that I explicity set instead?