Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Locator strategy for finding an input (labellable) element by the text of the label #1580

Open
msingle opened this issue Mar 29, 2021 · 5 comments

Comments

@msingle
Copy link

msingle commented Mar 29, 2021

Add a Locator Strategy for locating an input-type element (<select>, <input>, etc and potentially even non-input labellable elements) by the text of the label for that element.

In addition to being an incredibly common use case, this will encourage improving the accessibility (a11y) of the markup - forms having labels is one of the first checks by Chrome DevTools' Lighthouse, Firefox's Developer Tools (Accessibility tab) or other accessibility checkers. These are all based off the WCAG guidelines

I'll can write it up more formally with a pull request if it seems worthwhile.

(Originally created in SeleniumHQ/selenium#9342)

@shs96c
Copy link
Contributor

shs96c commented Mar 31, 2021

I'm in favour of anything that encourages improving a11y of markup, and which makes using webdriver easier. I'll happily review a PR for this.

@jugglinmike
Copy link
Contributor

Your motivation sounds similar to gh-1440. That describes the feature in terms of the Accessible Name API, which may be a more powerful entry point than labellable elements.

@AutomatedTester
Copy link
Contributor

Just for clarity @msingle are you wanting to do the following (In python for simplicity)?

driver.find_element(By.LABEL, "some_text_in_a_for")

# this will then essentially do document.querySelectorAll("*[for='some_text_in_a_for']") which we can do the normal element storing etc

@AutomatedTester
Copy link
Contributor

Your motivation sounds similar to gh-1440. That describes the feature in terms of the Accessible Name API, which may be a more powerful entry point than labellable elements.

I think that this strategy is a half way point to #1440. One of the concerns for that was the performance cost of starting up the accessibility tree for webdriver while AOM is still being worked on.

@msingle
Copy link
Author

msingle commented Apr 15, 2021

@AutomatedTester for some html like:

<form>
<label for="customerNameWithGeneratedID1234">Name:</label>
<input id="customerNameWithGeneratedID1234" name="customerNameWithGeneratedID1234" type="text" >
</form>
// something like the following javascript (i might have messed up some syntax) 
var labelNode = document.evaluate( '//label[contains(text(),"Name:")]', 
    document, 
    null, 
    XPathResult.FIRST_ORDERED_NODE_TYPE, 
    null ).singleNodeValue; // this could probably switched to a non-XPath javascript, but this is the basic idea
var idOfInput = labelNode.getAttribute("for") // will be 'customerNameWithGeneratedID1234'
return document.getElementById( idOfInput ); // will return the '<input>'

There are some significant corner cases (eg using <label> as the parent element of <input> ), but the idea is that knowing the Id of the desired input is a means to an end (and sometimes a complicated one), but not the actual objective.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants