[AriaNotify] Is NotificationId the right name?

[alisonmaher]

The current design of AriaNotify, as outlined in the spec PR and the explainer, includes a notificationId, which is a non-localized string that can be optionally used by an author to provide an AT with further context about the notification.

We have received feedback that the name notificationId is confusing, as the name implies identification rather than a way to tag common notifications across various web applications, and the name also implies that the ID would potentially need to be unique.

As such, the proposal is to update the name of notificationId to type as suggested in #1958 (comment) to better describe what the property's true intention is.

[MelSumner]

Observe that type is already a pretty overloaded term, could we consider notificationType or something that is more specific?

[alisonmaher]

@MelSumner I would be open to notificationType. The main question I have is if it would be redundant if used inside ariaNotify(). i.e. Is the 'notification' piece implied in this case? I'm not opposed to a more specific name, like notificationType, though.

[alisonmaher]

This was discussed at TPAC, with the relevant minutes noted below:

jcraig: this is going to sound like a nitpick, but I think notificationId is the wrong name for it, because it sounds like it needs to be a unique id. But it needs to be a type or a class.

Jamie: for what it's worth, everyone in the last meeting agreed that we should change the name

alisonmaher: I have an issue open to change it to type, we can change it to that

keithamus: I think type is important, because in github regions have surprising semantics sometimes. For this, you call the method for a given string, and that's easy to spot in code review

jcraig: I agree, this is much improved over that

The group seemed to like type as the new name, but as suggested by @MelSumner, I am also open to notificationType.

[spectranaut]

Discussed in today's meeting: https://www.w3.org/2024/10/24-aria-minutes.html#0fed

[alisonmaher]

@smhigley I noticed in the meeting notes that you were concerned about deciding on a name before we decide on the final functionality of the property. This makes sense, although, I do wonder if we could resolve on the name based on current functionality, and we could always re-open the issue if, based on research, the functionality changes such that the name no longer makes sense?

It seems like we all agree that notificationId isn't what we want, so even if the new name is also temporary, at least it would be a better name to have in the interim.