Should alert, status, log, and timer mention aria-labelledby in Accessible Name Guidance table?

[carmacleod]

The guidance for alert, status, log, and timer in the Accessible Name Guidance by Role table all say the following (where [role] is either alert, status, log, or timer):

Some screen readers announce the name of a [role] element before announcing the content of the [role] element. Thus, aria-label provides a method for prefacing the visible content of a [role] element with text that is not displayed as part of the [role] element. Using aria-label is functionally equivalent to providing off-screen text in the contents of the [role] element, except off-screen text would be announced by screen readers that do not support aria-label on [role] elements.

I think this should also say something to the effect of:

Use aria-labelledby if a visible label is present

For info, the marquee guidance says:
Use aria-labelledby if a visible label is present, otherwise use aria-label.

[JAWS-test]

In my opinion the content in the column "Guidance" of the table "Accessible Name Guidance by Role" do not match with the ARIA specification because on the one hand aria-label and aria-labelledby are only output with aria-atomic=true and on the other hand the output of the label has to be done with aria-atomic=true. It is not up to the AT to do it or not to do it. If AT does not do it, it would be a bug (see FreedomScientific/standards-support#291).

If aria-atomic is explicitly set to true, assistive technologies will present the entire contents of the element, including the author-defined live region label if one exists.

[carmacleod]

Thanks for pointing out that the value of aria-atomic may make a difference in whether or not the live region's label is output.

To be sure I understand your point, can I rewrite your sentence as follows?

... on the one hand in the spec aria-label and aria-labelledby are only output with aria-atomic=true and on the other hand in the APG table the output of the label has to be done with aria-atomic=true regardless of the value of aria-atomic.

[JAWS-test]

@carmacleod: Sorry, my expression is not so good because I'm not a native speaker.

What I wanted to say was: according the ARIA spec

• The label of the live region (aria-label or aria-labelledby) must only be output with aria-atomic=true and not with aria-atomic=false
• the sentences "Some screen readers announce the name of an alert before announcing the content of the alert" and "...except off-screen text would be announced by screen readers that do not support..." in the AGP table is factually correct, but contradicts the general procedure in AGP, because the AGP does not consider screen reader errors, but only describes the ARIA specification. The sentences are wrong because the ARIA specification clearly describes when the name is output and when not and does not leave it to the AT to decide whether the name is output.

[mcking65]

@JAWS-test, that is a good catch about atomic.

That only describes auto-announcement. If the user reads the status, log, or timer with a reading cursor, aria-label will not be announced; there is no place to put it without it appearing to be part of the content, which it is not. I suppose screen readers could start identifying boundaries like they do for a list, then they would be able to render aria-label. Today, screen readers do not do this.

That said, I would prefer that we deprecate these specialized live region roles. I think they create confusion and sometimes make accessibility worse. Often people will add them to an element that provides more useful semantics without the role. For example, they add role log to a table, and it would be better to keep the table semantics. In some cases, it would be more useful for something like status to be a named region, e.g., a div with role region and a name of status. Even if screen readers exposed log elements, I don't think anyone would go looking for one. They'd be looking for a chat transcript, but the only person who might to think of a log element is some accessibility geek.

So, rather than ask screen readers to expose the specialized live regions, I think we should deprecate them.

[mcking65]

See related w3c/aria#1104

[JAWS-test]

@mcking65

That only describes auto-announcement.

That's right. If the APG table is not about the automatic output of the name in case of a change of the content of the live region, but about the output of the name when reading with the arrow keys, this should be mentioned explicitly.

I suppose screen readers could start identifying boundaries like they do for a list, then they would be able to render aria-label. Today, screen readers do not do this.

The question would be why the screenreaders do not correctly output the roles for live regions:

• Either the screenreaders have errors and need to be improved (see e.g. All Live Region roles (like marquee and log) are not output correctly FreedomScientific/standards-support#277)
• Or the ARIA specification is not precise enough and does not explicitly prescribe this for the AT. In this case, the ARIA specification should clearly state that the roles for live regions not only serve the purpose that the screenreader automatically outputs a content change, but that they also serve to structure a page (such as the roles main, group, list, heading) and therefore the AT must output the beginning and end of the region (name and role) when reading with the arrow keys.