In my extensive experience handling large test suites within enterprise settings, I have encountered and navigated through various challenges related to this particular issue multiple times. The decision-making process involves numerous trade-offs, and there is no definitive "one-size-fits-all" solution.

Utilizing Data Attributes

The practice of separating selectors from internal DOM attributes, such as the class attribute, is a sound approach.

Data attributes can play a role in addressing this issue. However, it's essential to be aware of the potential drawbacks before fully committing to them. While they offer benefits like decoupling test code from application-layer implementation details (e.g., class), there are also considerations to keep in mind.

I have adopted conventions like using a data-cy-component to identify the type of component represented by a specific DOM element, along with component-specific attributes associated with that component. For instance:

<tbody>
  <tr data-cy-component="row" data-cy-row-id="1">
    <td data-cy-component="cell" data-cy-cell-column="name">...
    <td data-cy-component="cell" data-cy-cell-column="email">...
    <td data-cy-component="cell" data-cy-cell-column="phone">...

This approach offers:

• A cleaner alternative from a purist standpoint.
• Enhanced extendability by allowing the addition of more test attributes without disrupting existing selectors.
• Eradication of ambiguity, especially when dealing with special characters like -.

However, there are downsides to consider:

• Increased complexity for application developers in ensuring the correct combinations of attributes. Any oversight could lead to errors in selection criteria.
• Temptation for users to not just select on these attributes but also read from them and assert values, which may not align with the actual user interactions.
• Addition of another layer of implementation details, potentially causing misalignment between what is selected and what is actually visible to the user.

Prioritizing Accessible Selectors

Cypress Testing Library advocates for utilizing selectors based on DOM data that exists for accessibility reasons—one that is considered "public" or visible. Its recommendations emphasize the importance of selecting appropriate elements.

By focusing on visible text, aria roles, and their attributes, you can benefit from:

• Testing against what is deemed a public interface, typically involving visible text instead of relying solely on data attributes.
• Identifying accessibility issues if selecting elements becomes challenging, prompting necessary improvements in site accessibility.
• Minimizing complexity associated with managing data attribute conventions by leveraging well-defined aria attributes.
• Gaining insights into accessibility gaps whenever selectors fail, highlighting areas for improvement.
• Prompting critical thinking about user interactions, particularly in scenarios where differentiation is crucial.
• Leveraging existing libraries and design systems that integrate aria attributes seamlessly, enhancing overall accessibility.

While test attributes are not discouraged, Cypress Testing Library recommends limiting usage to a single data-testid attribute, discouraging complex compound solutions unless absolutely necessary due to the effectiveness of accessible selectors.

In practical terms, incorporating proper aria markup is paramount in achieving desired outcomes:

<table aria-label="Users table">
<thead>
   <tr>
     <th id="name-column">Name</th>
     <th id="email-column">Email</th>
     <th id="phone-column">Phone</th>
   </tr>
</thead>
<tbody>
  <tr>
    <td aria-describedby="name-column">...
    <td aria-describedby="email-column">...
    <td aria-describedby="phone-column">...
  </tr>
  <tr> ...

To execute various tasks effectively:

cy.findByRole('table', {name: "Users table"}).within(() => {

   // Obtaining a visible row by its unique ID (email)
   cy.findByRole('cell', {description: 'Email', name: '<a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail=”65160d040225081c161100171c0c0b064b060a08”>[email protected]</a>'})
      .should('exist)
      .parent()
      .within(() => {
         cy.findByRole('cell', {description: 'Name'}) // Retrieving the name cell for the same row
           .should('have.text', 'Shaggy Rogers') 
       })
})

Note that handling tables presents distinct challenges compared to simpler interactions such as button clicks, necessitating the establishment of common commands.

Addressing your mentioned concern:

but there would still be tons of markup that would not be covered, unless maybe I started throwing role= on everything which seems like a dirty hack and probably against ARIA or some other W3C standard.

It is vital to assign a role only to elements accurately reflecting their intended purpose. If warranted, utilization of aria attributes should suffice for most cases. Consider adding meaningful aria-label or aria-describedby when necessary, keeping in line with accessibility standards.

While introducing new markup may seem unconventional, adhering to established standards ensures compliance and longevity. Remember, selectors represent just one facet of a comprehensive testing framework, prompting thoughtful considerations and driving improved test quality.

Based on my experience, adopting an accessible selector strategy enhances test reliability and encourages meticulous thought processes.