In the Native Widgets and Custom Widgets section of Accessibility Insights for Web, the assisted test highlights widgets on the webpage being tested.
In the "How to test" section of the "Cues" section for Native Widgets and Custom Widgets , the tester is guided to interact with the highlighted widgets to determine whether it adopts any of these states: Disabled, Read-only, Required.
However, even though WCAG 2.1 SC 3.3.2 Labels or Instructions explicitly states that inputs have labels, including clear indication of required fields, the "How to test" section does not include verification that those Required fields have a visible indicator. It only directs the tester to "inspect its HTML to verify that the states are appropriately coded.
Thus, a required field could be one that exposes its required state to a screen reader but doesn't have a visible indicator that it's required.
Shouldn't AI for Web include a test for a visible indicator for fields that are required?
Thank you for the suggestion! I work on Accessibility Insights, and I've created a feature request in our github repo for this. Our team will take a look and decide what should be done, and will update this question once we address it.
UPDATE: We believe that failure to visibly indicate required fields is not a violation of this (or any) SC. Neither the 3.3.2 SC itself nor the Intent section of the Understanding document explicitly mentions it, nor is there a documented Failure example for it. (It does appear in the Examples and Sufficient Techniques, but those don't constitute requirements.) I believe the need to communicate required fields is addressed by Errors > Error identification.
Related
I'm currently in the process of setting up Cypress for my project. Currently we're only using testing library for frontend tests. And reading the Cypress documentation has gotten me a bit confused as the two libraries seem to have opposite philosophies in regards to how you're supposed to query for elements.
Testing library basically says test what the user can see/touch and only use data-testid if all else fails. Cypress on the other hand states that best practice is that you should query elements by data-testid / data-cy attributes.
I feel conflicted between the two approaches. I get the point about we should test what the user actually sees (testing library). But I do also get that those things often change (cypress) and we need to spend time updating tests whenever we make small changes (i.e "Ok" -> "Done"). And when testing with data-cy attributes, are we not also ignoring accessibility / screen readers?
What are your thoughts on this?
React Testing library(RTL) is specifically made to write tests from a user perspective. From their Guiding Principles:
The more your tests resemble the way your software is used, the more confidence they can give you.
Meaning, RTL wants you to use accessibility queries like getByRole and only fallback to getByTestId for cases where you can't match by role or text, or it doesn't make sense (e.g. the text is dynamic).
However, thanks to the render method allowing us to specify props (compared to Cypress), we have much more flexibility and may entirely omit dynamic text.
Cypress, on the other hand, runs with all dependencies. In case of dynamic content from a C.M.S or multi-language application, things are not that easy using getByRole("heading", {name: /welcome/i }). In this case, the recommendation of testId's make sense.
My personal recommendation is to use accessibility query selectors in both Cypress and RTL, unless the text is dynamic. Then testId's in Cypress and a combination of testId's & accessibility query selectors provide the best solution.
It should also be noted that Playwright and Cypress test-generator tools select by accessibility query selectors.
I thought a lot for a few days before answering this question and I even got to do some tests, and after that time I came to the conclusion that the Cypress approach is the best.
The main reason that led me to this answer was that when the testing library says that we should test what the user actually sees, it is already applicable in Cypress even when we use a data-testid, because let's suppose you have a button that exists in the DOM, but it is not visible when you select this button, with the data-testid when you try to click in this button Cypress will return an error saying that the button is not visible and if you really want to do this action you must apply force:true. The same happens if the button is not clickable or if there is another element in front of the button.
Cypress already checks by default in click and type actions if the element:
element is into view
it is visible
it is not disabled
it is not detached
it is not readonly
it is not animating
it is not covered
fire the event at a
descendent
Also if you fetch the element by text, placeholder, or class, this does not guarantee that the element is actually visible to the user, as the element can be in the DOM and not be visible to the user for various reasons.
So the best way to make tests easier to maintain, easier to read, and avoid flaky tests is to use the data-testid and whenever possible or necessary combine the location of the element with an assertion to ensure that the element is visible. Example:
cy.get('[data-testid="button"]').should('be.visible')
I hope I had contributed to the discussion and would love to hear other people's points of view.
I have extended a class by one method, using the Enhancement Framework.
Now, my problem is that I want to add ABAPDoc to it but cannot find any way to do it!
The code in the Enhancement Include section seems to be editable in no way.
Is there any way to do it at all? I tried also from ADT in Eclipse but this calls the SAP GUI anyway.
What are you trying to do is indeed impossible.
The enhancement include is a technical object and it cannot be edited from the tab you highlighted, it is auto-generated as you changing pre- and post-methods.
What this tab shows is not an include itself, but the placement of the enh. include within the parent object
If you want to change the method comment from enhancement, you should go to Technical details tab and click on changed object, or just go to the class in SE24 and press to pre/post exit button, and you will end up in the same include:
You can write the ABAPDoc-syntaxed comment, but for me it didn't work, and Eclipse didn't recognized my comment written in SAPGui, maybe you will be luckier.
ABAPDoc team describes this piece in a fuzzy manner, it may be an expected behavior:
This ABAPDoc is only available to ADT and not SE80? I can not use it in SAP GUI development?
You can also write it in the source code and you will get also warnings when you execute a check, but there is no dedicated tools support like source code element information or quick assist (Ctrl+1)
To your principal question, ABAPDoc is a two-way road when viewing: the ABAPDocs can be viewed both from the Eclipse and SE80, and they are automatically showed in SE80 description fields (but only if they are declared synchronized).
But it seems to be a one-way road for edit: they can be created only in ADT Eclipse to be fully compatible. If the object cannot be opened in Eclipse natively like your enhancement you are out of the luck.
I put seems because I am not 100% sure. Maybe on later systems it was fixed, but on my 750 they are not recognized by Eclipse for enhanced methods.
The only reliable way of "editing" via SE80 is writing the comments to descriptions and then importing these SE80 descriptions into ABAPDoc in Eclipse
which is ridiculous in context of your question, so there is no way for you.
My English so limited, so I can't write a lot details. But I am trying to get "Hover" mouse hover effect. So which Object Functions help me for that.
You can see that effect below image.
Thanks
a short version: None
The Full Story:
In spite of a minimalistic composition of the initial Question text, one may realise that any automation, intended to work on top of the MetaTrader Terminal 4 MMI-Add-On elements, that are not integral part of the Chart's GUI-Objects, is not directly accessible from the MQL4-code-base.
Neither in a passive-observer role ( just reading some of the MMI-Add-On element's values ) nor in an active-agent/actor mode ( trying to click / type-in a value / etc ).
This said, one may investigate other technologies to handle the intended functionalities via some O/S-controlled resources, but this direction goes beyond the reach of the MQL4-language contructors.
For further details do not hesitate to click-through to follow the Headline URL.
A few years back i worked in a company where i could press CTRL+T and a TODO-comment was generated - say my ID to be identified by other developers was xy45 then the generated comment was:
//TODO (xy45):
Is something available from within Intellij 14 Ultimate or did they write their own plugin for it?
What i tried: Webreserach, Jetbrais documentations - it looks like its not possible out of the box (i however ask before i write a plugin for it) or masked by the various search results regarding the TODO-view (due to bad research skills of mine).
There is no built-in feature in IntelliJ IDEA to generate such comments, so it looks like they did write their own plugin.
Found something that works quite similar but is not boundable to a shortcut:
File -> Settings -> Live Templates
I guess the picture says enoth to allow customization (consult the Jetbrains documentation for more possibilities). E.g. browse to the Live Template section within the settings, add a new Live Template (small green cross, upper right corner in the above picture) and set the context where this Live Template is applicable.
Note: Once you defined the Live Template to be applicable within Java (...Change in the above image where the red exclamation marks are shown) context you can just type "t", "todo" and hit CTRL+Space (or the shortcut you defined for code completion).
I suggest to reconsider using that practice at all. Generally you should not include redundant information which is easily and more reliably accessible through your Version Control System (easily available in Idea directly in editor using Annotate feature). It is similiar to not using javadoc tag #author as the information provided with it is often outdated inaccurate and redundant. Additionaly, I don´t think author of TODO is that much valuable information. Person who will solve the issue will often be completly different person and the TODO should be well documented and descriptive anyway. When you find your own old TODO, which is poorly documented, you often don't remember all the required information even if you were the author.
However, instead of adding author's name, a good practice is to create a task in you issue management system and add identifier of this task to the description of the todo. This way you have all your todos in evidence at one place, you can add additional information to the task, track progress, assign it etc. My experience is that if you don´t use this, todos tend to stay in the code forever and after some time no one remembers clearly the details of the problem. Additionaly, author mentioned in the todo is often already gone working for a different company.
Annotated TODO with issue ID
I want to evaluate my content blocks before running my test suite but the closures' property names is in bytecode already. I'm ooking for the cleanest solution (compared with parsing source manually).
Already tried solution outlined in this post (and I'd still wind up doing some RegEx/parsing) but could only get it to work via script execution engine. It failed in IDE and GroovyConsole. Rather than embedding a Groovy script in project's code, I thought I'd try using Geb's native classes.
Is building on the suggestion about extending Geb Navigators here viable for Geb's PageContentSupport class whose contentTemplates contain a LinkedHashMap of exactly what I need? If yes, would someone provide guidance? If no, any suggestions?
It is currently not possible to get hold of all content elements for a given page/module. Feel free to create an issue for this in Geb's bug tracker, but remember that all that Geb can provide is either a list of content element names or a map from these names to closures that create these elements.
Having that information isn't a generic solution to your problem because it's possible for content elements to take parameters and there are situations where your content elements will be available on the page only after some other actions are performed (for example you have to click on button to reveal a section of a page that uses ajax to retrieve it's content). So I'm afraid that simply going over all elements and checking if they don't throw any errors will not cut it.
I'm still struggling to see what would "evaluating" all content elements prior to running the suite buy you. Are you after verifying that your content elements still work to get a faster feedback than running the whole suite? I'm pretty sure that you won't be able to fully automate detection of content definitions that don't work anymore. In my view it will be more effort than it's worth.