Code is created by people. HTML elements are code, which is created by people.
As part of developing those elements, people can tag them with attributes (including but not limited to “id”) that make them easy to find, via tools, for testing purposes. This can be done deliberately and consciously, or automatically as part of the creation of the element.
When that doesn’t happen, testers and developers have difficulty locating elements to drive the product, or to read data that is contained with them. In the software business, what’s our approach to solving this problem?
If we considered (intrinsic) testability, we could identify and address the problem way earlier and way more easily, at development time.
Nah! Instead, we create elaborate tools and protocols (hello, XPath) that have a high chance of being brittle and unreliable. When those don’t work, we try to produce more and more elaborate magic wands (hello, “no-code tools”, “AI”, and “self-correcting tests”) that are still brittle and unreliable.
These are lousy solutions to something that shouldn’t be a problem in the first place. Then we spend ages on their care and feeding. Of course, all this reduces the time that we could spend on deeper testing. Then people ask “why is testing taking so long?” and “why didn’t you find that bug?”
If you’re having trouble quickly and reliably identifying an HTML element, that’s a bug. It’s a testability bug, and it has a near-certain probability of being an accessibility bug as well.
In its testability context, the bug slows down testing and makes it harder. That gives deeper and more subtle bugs more chance to survive without being detected. Report that bug.
In the accessibility context, the bug makes it harder for screen readers to work reliably. That means that people with disabilities will have trouble with the product, and it may also run afoul of accessibility-related regulations. Report that bug.
When those reports are instances of a pattern of bugs, and you identify that pattern, there’s a chance that the pattern can get addressed. That takes a step closer to more efficient, deeper, more valuable testing.
If we can’t figure out how to solve the easy stuff like this, we don’t have a chance on complicated stuff.