Introduce "Accessible Name" locator strategy

[jugglinmike]

At TPAC 2019, folks working in ARIA and WebDriver discussed ways to extend WebDriver in order to help web developers learn and enforce best practices in accessibility. While discussing the prospect of new commands based on the APG, a more generic feature came up: the ability to select elements according to accessible name.

Today, it's easy for web developers to write UI tests with a "whatever works" mindset. Without a good amount of experience and forethought, the CSS selectors they choose to target elements can easily be broken by benign refactoring. In order to keep their tests passing, developers have to perform the additional maintenance work of updating selectors. Not only is this distracting and inefficient, but it's somewhat dangerous. Editing tests while refactoring diminishes developers' ability to verify equivalent functionality and increases the likelihood of regression.

Because an element's accessible name is directly exposed to end users, it is less subject to change than many of the implementation details upon which a CSS selector can rely. Web developers could use a locator strategy based on this to write tests that are more resilient to changes in their application code.

Like many accessibility best practices, web developers don't always use accessible names correctly (or at all). The promise of more resilient tests could help incentivize developers to make their applications more accessible in this way.

There are some concerns about exposing this capability to the DOM generally, both in terms of performance and security. @minorninth and @alice (the principle contributors to the Accessibility Object Model) can probably speak more to that. It's my understanding that integration with WebDriver is much more feasible. At TPAC, @cookiecrook mentioned that this WebKit and/or Safari already make this available in some privileged context.

Could a "accessible name" locator strategy fit in the WebDriver specification? If so, is there some existing algorithm we can reference?

---

Preview | Diff

[andreastt]

This seems to be superseded by #1444 by @cookiecrook. Is that correct?

[andreastt]

@AutomatedTester

[cookiecrook]

This seems to be superseded by #1444 by @cookiecrook. Is that correct?

Works for me.

[jugglinmike]

The API proposed in gh-1444 seems optimized for testing browsers, not web applications.

It's definitely important to be able to verify the browser's correctness. However, if we only define commands like "Get Computed Role" and "Get Computed Label," we may miss an opportunity to reach more developers (and to further promote best practices).

With those commands, developers will be empowered to extend their current tests with additional assertions about the accessibility tree. That's far better than the status quo! However, just like with ARIA practices themselves, it's up to the developer to recognize when and where these details are relevant and to add additional code.

In other words, the developer who is most likely to use those APIs is the same developer who is already well-versed in best practices.

If the accessibility primitives were instead exposed through locator strategies, then authors could write their acceptance tests in terms of the accessibility tree. Unlike application development, where ARIA patterns are commonly layered on after-the-fact (sometimes only inconsistently and oftentimes not at all), tests written on top of such APIs would innately require accessibility. That's what I had in mind when I opened this draft.

[zcorpan]

Right, this PR would fix issue Accessibility primitive: get element(s) by accessibility label which is different from issue Accessibility primitives: computedRole and computedLabel (#1444)