Alert design pattern and accessible names

[ZoeBijl]

The alert design pattern’s Roles, States, and Properties section states:

The widget has a role of alert.

That’s it. And that’s fine in most cases. But when a button is added to the alert things get a bit wonky. Sometimes close buttons are added to alerts so you can dismiss them. Now your code might look like this:

<div role="alert">
  <button type="button">Close</button>
  <p>Hiya Matt, how have you been?</p>
</div>

And the alert would be announced as Close Hiya Matt, how have you been?. Which would be a bit weird.

It might be better to follow the rules for alertdialog in those cases. Which would lead to code that looks something like this:

<div role="alert" aria-labelledby="alert-content">
  <button type="button">Close</button>
  <p class="alert-content">Hiya Matt, how have you been?</p>
</div>

…or perhaps more accurately:

<div role="alert" aria-label="iMessage notification" aria-describedby="alert-content">
  <button type="button">Close</button>
  <p class="alert-content">Hiya Matt, how have you been?</p>
</div>

Could we include the following prose to the Roles sections?

If the alert contains anything other than phrasing content:

• The element with role alert has either:
  • A value for aria-labelledby that refers to the element containing the title of the alert if the aleert has a visible label.
  • A value for aria-label if the alert does not have a visible label.
• The element with role alert has a value set for aria-describedby that refers to the element containing the alert message.

[ZoeBijl]

Bit more of a rabbit hole than I thought…

OK, so alert role in ARIA editor’s draft says:

Since alerts are not required to receive focus, authors SHOULD NOT require users to close an alert. If an author desires focus to move to a message when it is conveyed, the author SHOULD use alertdialog instead of alert.

Which makes sense. That raises two questions tho:

First, if the close button is in addition to an automatic closing system, should alertdialog still be used over alert?

Second, the alert dialog design pattern itself doesn’t mention underlying content being inert. But in its “Keyboard interaction” section it links to that of the modal dialog pattern. Which states in the bullet about the Tab key that:

If focus is on the last tabbable element inside the dialog, moves focus to the first tabbable element inside the dialog.

The same applies for Shift + Tab. Does that then mean that an alertdialog should always be treated as a modal dialog?

There are plenty of places where alertdialogs aren’t like modal dialogs at all. Not in that other content is inert anyway. Notifications in both macOS and Windows are an example of that. Would it make sense to exclude the inertness of the underlying content, and the keyboard traptness, as requirements for alertdialogs in those cases?