Consider prohibiting accessible name for listitem, rowgroup, term, time

[zcorpan]

See w3c/aria-practices#1231 , the following roles are categorized as "Do Not Name" in APG:

role	Necessity of Naming	Guidance
listitem	Do Not Name	Naming is not supported by assistive technologies; it is necessary to include relevant content within the list item.
rowgroup	Do Not Name	Naming is not supported by assistive technologies.
term	Do Not Name	Since a term is usually the name for the role="definition" element, it could be confusing if the term itself also has a name.
time	Do Not Name	Naming is not supported by assistive technologies.

Although the rationale provided for several of these is that naming isn't supported by ATs, it's not clear if they should be supported.

For time in particular, I think it's in the same situation as paragraph, where naming is prohibited.

I'm not sure if naming a time is ever useful. A time, from what I understand, isn't typically focusable, but is more like a normal word within a paragraph. To understand the context, you'd read the full paragraph.

w3c/aria-practices#1231 (comment)

I think listitem is like paragraph. It can have a marker like a bullet or a number, but that's not an accessible name. Are there reasons to name list items that are somehow different from paragraphs?

For rowgroup I could imagine it being theoretically helpful to have a name if you navigate between rowgroups in a table or grid, but I'm not sure how ATs can navigate these structures.

term seems like time, it's usually a word or a phrase within a paragraph.

[scottaohara]

definitely agree on term and time.

I personally think prohibiting naming of rowgroup makes sense too, but feel like there could be a use case there I can't presently think of if used within a grid.

listitem is the one I think would need consensus on, especially since it was specifically not prohibited during 1.2. See #833 for at least one reference to that.

[aleventhal]

Related: term -- I know what the spec says, but shouldn't a definition be linked to a term via aria-describedby, rather than aria-labelledby?

Some reasons:

• In HTML, an <acronym> or <abbr> uses @title for the definition. A title is exposed a description.
• In screen readers, a description will be announced after inner contents. In general, a name would be announced before the inner contents. It's better to announce a definition after the term, and this would also make it like the HTML experience.
• A definition is a kind of description,
• Some screen readers may skip reading inner contents when something has a name.

[carmacleod]

Note that term and definition are now covered in #1147.
In that PR, naming is prohibited on both roles.

I opened APG w3c/aria-practices#1299 to change Necessity of Naming to Prohibited for both term and definition.

So this issue is now only about:

• time
• rowgroup
• listitem

[joanmarie]

What if the rowgroup is focusable? The screen reader should say something more than the role, I think. And unlike listitem, that something more isn't the displayed text in all the descendant rows.

[zcorpan]

Is focusable rowgroups a common idiom?

[joanmarie]

Is focusable rowgroups a common idiom?

I don't know if it's common, and I am not an author, but I've seen them on occasion. Maybe the author has a big, sectioned table and wants to make it possible for the user to be able to jump amongst sections in the table before drilling down into the row content?

[zcorpan]

OK, thanks. That seems like a reasonable use case for using rowgroups, but shouldn't the UA/AT allow the user to navigate berween rowgroups even if they are not focusable? (Similaly to how users would navigate between cells or rows.)

[joanmarie]

OK, thanks. That seems like a reasonable use case for using rowgroups, but shouldn't the UA/AT allow the user to navigate berween rowgroups even if they are not focusable? (Similaly to how users would navigate between cells or rows.)

Not sure. But for the sake of argument and this issue, let's say yes. What should a screen reader say when the user navigates amongst those non-focusable rowgroups? Just "rowgroup"? Then the user doesn't know what the nature of that rowgroup is. If the rowgroup has a name, the screen reader can pass it along to the user, clarifying the nature/purpose of the rowgroup.

[sinabahram]

I want to offer some thoughts on this hypothetical example with focusable row groups. I have concerns with a row group being focusable. The way that I would design and implement this is to identify a set of orthogonal inputs which achieve the same affordance for as many audiences as possible; therefore, I would have headings at appropriate levels for each row group, assuming that’s a logical unit that makes sense for navigational waypoints, which Joanie’s example establishes as a premise. I; however, would not make them focusable by a tabindex of 0 or anything like that, but rather by use of the arrow keys since most screen readers will trap these arrow keys for virtual cursor navigation (no worries for those screenreaders that choose not to implement a virtual cursor model). This way, a non-screen-reader-using keyboard-only user can move with arrow keys, while preserving a logical and reasonable tab traversal, which the screenreader user will also benefit from. SR users get headings for rapid navigation across row groups, keyboard users get the same by way of up/down arrow keys, and making this work for either group does not disadvantage the other, which I claim by making non-interactive row groups focusable, it does disadvantage SR users at the benefit of sighted keyboard users, for example. Sorry if I’ve misunderstood the use case.

[scottaohara]

Having run into focusable row groups in the wild, it’s not entirely hypothetical, and naming can be useful in a grid where navigating by headings wouldn’t always work, since the grid would initiate application/forms mode.

That said, maybe naming should be limited to row groups within a grid, as I do think that’s where this could be beneficial, rather than within a table, where I think sina’s suggestions would be more appropriate

[sinabahram]

Color me a bit confused about this concept. If it initiates forms mode, then how is it navigable with the tab key, as it would either move to next focusable control, in which case eliminating any focusable elements within, or simply be an additional tab stop, but serving no purpose?

[scottaohara]

i didn't mention anything about navigating with the tab key?

what i was saying is that i've come across grids where rows are focusable when navigating the grid. whether they should be or not is another topic. but the point being that its not a made up scenario, and that in such situations it'd be good for them to announce a name.

[zcorpan]

Not sure. But for the sake of argument and this issue, let's say yes. What should a screen reader say when the user navigates amongst those non-focusable rowgroups?

It seems useful to study real-world examples that use multiple rowgroups to see if there is a common pattern that screen readers could use. For example, the first non-empty header cell, or a cell that spans all rows or all columns in the group, could serve as the "name" for the rowgroup, and not require extra effort from the author to name the rowgroup.

Just "rowgroup"? Then the user doesn't know what the nature of that rowgroup is. If the rowgroup has a name, the screen reader can pass it along to the user, clarifying the nature/purpose of the rowgroup.

I get your point that if an element is a navigation "stop", it likely would benefit from being able to have a name (whether explicit or by some heuristic).

It also follows that if an element is focusable, it ought to be allowed to give it a name, even if it is one of the "name prohibited" roles (such as paragraph). (Edit: I filed #1187 for this.)

The original rationale for not supporting naming for rowgroups was "Naming is not supported by assistive technologies.". This suggests that ATs don't currently support navigation by rowgroup. So I think there are several questions here:

• Would it be useful for users if ATs did support navigation by rowgroup?
• Is it better for authoring rules for ARIA to reflect current implemented reality, or is it better to be aspirational to a possible future AT behavior?

[jnurthen]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

[Consider prohibiting accessible name for listitem, rowgroup, term, time](#1117
jnurthen: lot of discussion.
scott: Agreement on time.
... rowgroup is open.
jnurthen: in APG we say "is not supported by AT"
... is that true?
mcking: I think it still falls into the discretionary bucket.
... I'd like to strongly discourage this.
... not sure if I agree with the utility statement.
... if it reads the aria-label instead of the content and leaves it to user to find out that there's more content, I think that's problematic.
... if the string is too long, it seems like a design issue.
carmacleod: jamie had another example, I think twitter. each list-item label was short to not include UI (reply, favs etc)
mcking: I feel that's an incorrect use of list-item.
jnurthen: but people are doing it and if we prohibit them, it will break.
mcking: ok but then practices can/should discourage it. We do that a lot of times.
jnurthen: yes.
Aaron: is tree-item the same?
jnurthen: this allow naming.
stefan: MS does it this way. It's not good style but even OSs are doing it.
jnurthen: term is prohibited (changed), list-items and row-group has use cases. should we change this issue to just the case of time?
mcking: I don't understand row-group. There's no way to surface the name unless focusable.
... but we don't do that in tree-grid.
scott: I've seen it in the wild. Not that I think that's good.
Aaron: aria-description might also come in.
scott: there was a bug with someone combining everything.
<Scott_O> https://bugzilla.mozilla.org/show_bug.cgi?id=1568360
joanie: we solved that one by "name from content not allowed on row-group". But that's different from the issue.
... but I think we fixed that.
jnurthen: if someone happens to focus on row-group. Should it be nothing? Or allow author to name it?
<Zakim> joanie, you wanted to also mention ancestry of rows
joanie: another potential example: what if you have a giant table, say bus table, visually clear that a row-group has three sections.
... user down-arrows into a new group.
... orca and I think others will provide context (ancestry)
... "evening buses" and then present content.
mcking: but they don't provide the name on the row-group but the cell containing "evening schedule" a header cell and provide scope.
joanie: but it's not for the cell but for the row / series row.
Aaron: is it like role=group and fieldset?
joanie: yes.
tzviya: we have lots of such tables in Wiley books.
... top-level head might be the title
... but then sub-heads.
... e.g., accounting, profit/loss table.
grouping incredibly complicated.
scribe: it's very hard to get that right.
mcking: right just not sure if that helps in addition to existing techniques. I know it's difficult.
... if it were to help, then it should be put into HTML first.
jnurthen: by prohibiting, we're asking browsers to not expose it.
mcking: yes?
jnurthen: so we're breaking people who is using this and relying on it.
mcking: are we sure they can _rely_ on it?
... if there's a way to get this information exposed, I wouldn't know how that could be.
jnurthen: have you ever focused on one?
mcking: we could do a test with focusable. Might be better if it did break. Otherwise, you're not using the patterns the way the spec wanted you to.
scott: this is also in grids, tables etc.
... so we're back to disallowing naming.
mcking: what's the purpose of that?
scott: to select the whole row.
... in a complete author take-over situation.
mcking: but row isn't row-group.
jnurthen: can we do a PR for the ones we do agree on?
... we can still tackle others later.
... but move forward, making the spec better.
carmacleod: I'll do a PR for time.

[carmacleod]

Leaving this comment here mostly as notes to myself regarding listitem; also in case others find it useful.

The ARIA 1.0 spec for listitem specified name from contents and author, and name was required.
Name from content and "name required" were dropped in ARIA 1.1 listitem in September 2015.
Looking back at IRC comments from August 20 2015 and August 27 2015, it seems the rationale was:

• "listitem is not a widget",
• "listitem is more like paragraph",
• "listitem is a container", and
• "if the author doesn't supply the name, it goes into the content and makes ridiculously long names".

Those IRC comments also acknowledged that:

• "designers like to put really hefty things in a listitem (links, text...)"
• "people are using a listitem as a widget"
• "people are putting more content in the element than you would expect, how do we tell the AT they should go into those"

Today, people are still putting a bunch of stuff in listitems. They are even giving them tabindex and focus. For example, gmail users can type n or p to focus the next/previous email listitem in a thread. This kind of thing causes browsers to have to resort to fallback handling because the spec does not cover focusable listitems (for example, see FF bug 1616851).

Handling of listitem accessible name differs across browsers, even in the non-fallback case.
To see this, inspect the Accessibility Tree for the following lists in FF, Chrome/Edge, Safari.

List 1 is a simple list made of ul/li.
Firefox exposes an li's content as its accessible name. (FF bug?) Chromium and Safari don't.

• List item 1
• List item 2
• List item 3 contains a whole bunchofspans

List 2 is also a ul/li, but now the li's have tabindex="0" or "-1".
Both Firefox and Chromium expose a focusable li's content as its accessible name. Safari doesn't.

• List item 1
• List item 2
• List item 3 contains a whole bunchofspans

Would be useful to know how prevalent focusable listitems are before we decide whether or not to remove name from author from listitem.

[carmacleod]

Removed my name from this issue because I won't get to it in the 1.3 time frame.

[jnurthen]

lets separate these out into issues

[jnurthen]

remaining roles in new issues