Editorial: document norm on the casing of future DOM IDs to the ARIA spec

[spectranaut]

@fstrr asked if we could normalize DOM ID casing across the aria spec (camel case or "_" separated words), but as these IDs are using for navigation it would be a breaking change of existing links. However, we should document a standard going forward.

[fstrr]

Thanks for adding this—I kept meaning to. There's also a bit of "clean-up in aisle seven" to do with the values of the id attributes. For example:

• The Prohibited States And Properties heading has an id attribute of "prohibitedattributes"
• The Allowed Accessibility Child Roles heading has an id attribute of "mustContain"
• The Required Accessibility Parent Role heading has an id attribute of "scope"

Along with a standard way of writing id attributes (maybe aligning with WCAG, which uses dash-separated-words), I'd like to update the id attributes' values so they align with the visible heading text, for example:

<h4 id="required-accessibility-parent-role">Required Accessibility Parent Role</h4>

[spectranaut]

Hi @fstrr I appreciate you taking a close look at these details of the spec!

But in the editors meeting today, we decided we don't want to change any of the existing IDs, precisely for the reasons in your comment -- which is that the link to "Allowed Accessibility Child Roles" is https://w3c.github.io/aria/#mustContain. If we update the ID ref, then these old links (littered for example, throughout old issues in the repo) will no longer work.

The id's do look a little strange, but I think in general people don't interrogate the URL text as much as they simply expect the URL to work.

[fstrr]

Okay. In that case, can we have a documented standard going forward that new id attributes have a value that matches the visible text and that they use, let's say, a dash as a separator?

[pkra]

We also discussed that some specs (e.g., core-aam) have multiple patterns that are consistently followed (e.g., roles vs properties). This means, if we enforce a single recommendation, we would create odd inconsistencies (i.e., if new IDs follow a different pattern than the existing one).

In addition, we observed that most IDs are generated at this point.

Overall, the editors came to the conclusion that we don't have good data to make a decision. We ended up on a soft recommendation to watch out for any manual ID creation (which is likely not good generally speaking) as well as making sure that IDs match any relevant pattern of a given spec.

Once we have more data, we think we will be able to revisit this.

For now, we'll add a note to the style guidelines.