some comments have been left in #1020

additional comments that i was going to bring up on yesterday's call, but we didn't get to:

I'm interested in the reasoning that legend and caption differ wherelegend allows author naming but caption does not.

Since legend names a fieldset/group/radiogroup and caption provides the name for a table or figure it seems like they should have similar allowances for naming?

Also, per @jnurthen's comment in pull request 911 I feel like it is worth asking if a reuse of legend is already applicable? I don't mean to throw a wrench in here, but the two roles really should have a lot of overlap. that is save for the next quoted bit from the current legend definition:

When an element with role legend is activated by touch or a pointer, focus moves to the first focusable element in the associated group of user interface components.

I'm curious as to how that got in there?

Right now, the caption role states the following:

Authors SHOULD set aria-labelledby on the parent figure, table, grid, or treegrid to reference the element with role caption. However, if a caption contains content that serves as both a name and description for its parent, authors MAY instead set aria-labelledby to reference an element within the caption that contains a concise name, and set aria-describedby to reference an element within the caption that contains the descriptive content.

If, given all that guidance, the author chooses not to do what the spec suggests:

1. How do we know they didn't do it on purpose? (i.e. had a use case where a name didn't make sense for their content)
2. Do we really want user agents to override that authoring?

EDIT: When I wrote this, I had forgotten name is required on table. So the above items don't really apply. But my observations below about name from caption being a not good idea still do.

Taking the example from the spec:

<div role="table" aria-labelledby="name" aria-describedby="desc">
   <div role="caption">
     <div id="name">Contest Entrants</div>
     <div id="desc">
       This table shows the total number of entrants (500) the
       contest accepted over the past four weeks.
     </div>
   </div>
   <!-- ... -->

Let's say the author did NOT use aria-labelledby and/or aria-described by. Should the accessible name of the table really be: "Contest Entrants This table shows the total number of entrants (500) the contest accepted over the past four weeks."??

Accessible names are supposed to be short; not long and descriptive. In addition, long names can interfere with users getting the important information they might want in a timely/efficient manner. For instance, given a table, the screen reader might speak the following:

1. Accessible name of the table
2. Dimensions of the table
3. The new location in the table if applicable (e.g. focused column header)

If the accessible name of the table is really long, the user has a choice:

• Listen to the whole long thing because they want to know the dimensions of the table and what got focus, OR
• Interrupt speech, but now they don't know what the dimensions are or what got focus and have to give additional commands to find this stuff out

Neither of the above strike me as a winner.

And, yes, I know. In HTML the name comes from the caption. That doesn't necessarily mean it's a good idea. 😀

There are two questions I think in your request.

1. The ability of the caption role to provide a labeling function
2. Is the coding example good authoring practice

Since the caption role provides no labeling convince for authors with the the table role it should be removed or deprecated from ARIA. No need to confuse developers with roles that don't do anything more than the generic role, other than probably generate validation errors when used in places it should not be used.

I consider the coding example above an authoring error, the code should be:

<div role="table" aria-labelledby="name" aria-describedby="desc">
   <div class="caption">
     <div id="name">Contest Entrants</div>
     <div id="desc">
       This table shows the total number of entrants (500) the
       contest accepted over the past four weeks.
     </div>
   </div>

@jongund: Roles are not just about labeling convenience for authors; they are also for exposing the nature of the objects to ATs. If an author does what you suggest, there's going to be a weird object with ROLE_SECTION in the accessible table on my platform and atspi_table_get_caption won't work.

@joanmarie
What happens when there is no caption defined when an AT calls atspi_table_get_caption, which I assume is most of the time?
Why would Orca even call atspi_table_get_caption if ARIA requires a table, grid and treegrid to have an accessible name?
Does Orca also pronounce the caption in addition to an accessible name if a caption is defined?

I think we have roles that do nothing and just confuse authors into thinking that they do something to improve accessibility. If the caption role did something like provide the accessible name, then it would be worth something to authors and users. But to sometimes have a caption role rather than a section role in the accessibility tree (or more often no "caption" like content), I am not sure it is worth the authors confusion. The table, grid, treegrid and figure role definitions in ARIA do not even mention that a caption role is even an option in using them, you need to go to the caption role definition to find a use for it and the dubious authoring example associated with it.

When there's no caption, atspi_table_get_caption returns null, as expected.

Orca has its own table navigation commands that assume we have a well-formed table without mystery objects. A proper caption with a proper role is not a mystery object. If an author does what you suggest, we get mystery objects.

@joanmarie
In the way ARIA works right now the caption role example would not be included, if you are defining a table created with role="table" there just wouldn't be a caption role option for the table, only the accessible naming options. Only HTML defines a table element with optional child of caption element with the role of caption, but the ARIA table doesn't benefit from that option because the ARIA table requires an accessible name that comes from current naming techniques, which does not include the caption role. So allowing a caption role in this situation would be confusing to authors since they will likely think it is the same as creating an table with HTML elements table and caption.

I doubt the caption role in ARIA is going any place in ARIA 1.2 at this point, but I think the authoring example should be removed entirely and any authoring guidance should be stated that it maybe be used as a target for aria-labelledby (and I would not mention aria-describedby at all since it is not required and just adds confusion in the spec) or it may be considered fallback content by assistive technologies if an accessible name has not been defined for table, grid, treegrid or figure. But I am not sure the ARIA spec is even mentioning fallback content in definitions.

@jongund: I'm afraid I don't follow you.

I just made a test case using the ARIA caption role and then used Accerciser to examine the results for Firefox and Chrome. In both instances, the table had a child with ATSPI_ROLE_CAPTION. For Chrome, getting the caption via AtspiTable works. It doesn't for Firefox, so that's a bug to be fixed in Firefox.

With the above in mind, what do you mean by:

In the way ARIA works right now the caption role example would not be included, if you are defining a table created with role="table" there just wouldn't be a caption role option for the table, only the accessible naming options. Only HTML defines a table element with optional child of caption element with the role of caption, but the ARIA table doesn't benefit from that option because the ARIA table requires an accessible name that comes from current naming techniques, which does not include the caption role.

?

@joanmarie
My main point is that in HTML a best practice for providing a "name" for the TABLE element is using a CAPTION element that is a child of the TABLE element. In an ARIA table created using role="table" the "name" must come from the use current accessible naming techniques to be valid, and current naming techniques do not include the use of a child element with a caption role.
So from an authoring point of view for providing a "name" there is a disconnect between how native HTML tables and ARIA tables work.

QUESTION: When an HTML CAPTION element is a child of a TABLE element does the browser use it to compute an accessible name in the accessibility API for the TABLE element?

@jongund:

QUESTION: When an HTML CAPTION element is a child of a TABLE element does the browser use it to compute an accessible name in the accessibility API for the TABLE element?

Yes. And that is, in my opinion, not necessarily a good thing. Consider the very example found in the HTML spec: https://html.spec.whatwg.org/multipage/tables.html#the-caption-element

The accessible name of the dice example is:

Table 1. This table shows the total score obtained from rolling
two six-sided dice. The first row represents the value of the first
die, the first column the value of the second die. The total is given
in the cell that corresponds to the values of the two dice.

That entire thing. Names are supposed to be brief and not descriptive. Because name comes from caption, the name is NOT brief and IS descriptive.

Speaking that entire thing before presenting other aspects of the table (e.g. "table with 7 rows, 7 columns") is way too much chattiness for the user. I think that's a problem.

In addition, if the user chooses to read the table via the arrow keys, the user is still at the top of the table and gets to hear all that text again.

In my opinion, what is happening for HTML is bad. The accessible name of the dice example should, in my opinion, be: "Table 1."

Hi Joanie,

I agree that the folks over at WHAT WG have used <caption> incorrectly, and the result is excessive verbosity. However, I will suggest that it's, in large part, an AUTHOR ERROR in that example: they have provided more of an accessible description than an accessible name.

The accessible name of the dice example should, in my opinion, be: "Table 1."

Actually, I would assert that it should be closer to <caption> Total score(s) obtained from rolling two six-sided dice </caption>
(See also: https://www.w3.org/WAI/tutorials/tables/caption-summary/)

It is regrettable that HTML5 does not have sufficient mechanisms to achieve all of our goals, and I fought like hell to preserve the <summary> (child) element of tables (@RealJoshue108), which would be a more appropriate place for an accessible description IMHO, but did not succeed.

NOTE: I went so far as to file a Formal Objection against Obsoleting <summary>, but was convinced to drop it in the interest of getting HTML5 out the door. (I sometimes regret being so amenable back then.)

The reasons then for obsoleting the <summary> element (It didn't render on screen, so was 'bad' because it was only for some users... but of course the browsers could have changed that too) was mostly just more bull-feathers from the former Editor (a man who demonstrated repeatedly his lack of imagination and empathy when it came to PwD)

So, I'm with Jon: <caption> IS the Accessible Name for tables (or, at least, one technique to provide that), and I would be strongly opposed to mapping (or even contemplating mapping) <caption> to Accessible Description going forward.

I'd also suggest filing a bug against that entry in the WHAT WG spec, and request that they change their example to something more appropriate (and perhaps then they may also understand why tables need both accessible names AND accessible descriptions...)

Recognizing my previous comment was somewhat tangential, I think what Jon is saying is that this is valid HTML:

<table>
   <caption>Provides Accessible Name</caption>
   <tr><td> Foo </td></tr>
</table>

Whereas this is not:

<div role="table">
   <caption>Provides Accessible Name</caption>
   <div role="row"> <span role="cell">Foo</span> </div>
</div>

I agree that this is something of a problem, but I am less convinced of Jon's suggestion: I believe instead that a case could be made for @aria-summary (which would take string text), and could be the logical counterpart to aria-describedby (in the same way that aria-label takes string text, whereas aria-labeledby takes an ID ref).

For the second example, the correct answer to Jon is do not mix the ARIA and HTML together in the same complex component: this DOES validate*:

<div role="table">
   <div role="caption">Provides Accessible Name</div>
   <div role="row"> <span role="cell">Foo</span> </div>
</div>

(* or at least should once ARIA 1.2 goes to Rec)

@johnfoliot

We have aria-description attribute now that provides the feature of your proposed aria-summary.

@joanmarie
Browsers will continue to use the HTML CAPTION element to compute an accessible name for an HTML TABLE element, it has been doing this for eons and any changes would make a lot of people upset and break many current pages. The best solution in my mind is that ARIA should add a caption role naming technique for table, grid, treegrid and figure so that the ARIA roles do the same naming feature that browser do now for the HTML TABLE and CAPTION elements. But, right now the ARIA group does not seem to have any appetite for new naming techniques.

My main concern right now with the caption role is the disconnect for naming the table between the use of HTML elements and explicit ARIA roles. I am sure most authors think using an explicit caption role will provide an accessible name for a table, grid, treeegrid and figure, and it doesn't (I checked on the Chrome browser).

Maybe the table model for accessible name and description needs to be revisited from an authoring perspective of what authors need and what roles/properties can support authors. For example:

• Child element of table with a caption role provides an accessible name.
• Child element of table with a summary role provides an accessible description.

@jongund Understood. If the group decides to support name from caption I won't stop them. :)

BUT if the group does not decide to support name from caption, what you suggested about using a generic object is concerning to me because for my platform generic objects in a table don't make sense. I would want validators to spit up on that sort of authoring.

@joanmarie
My guess is that there will be no big change to caption role in this version of ARIA, not many people in the group care about the naming implications of these roles. I would suggest making some edits to the caption definition to basically promote the use of the caption role as a target for accessible name only, and remove the confusing example including aria-describedby.

Just FYI: There is currently a JAWS bug that prevents the correct output of role=caption in Chrome and Edge: FreedomScientific/standards-support#391

I will not have time to work on this issue for ARIA 1.3.

closing as this is no longer in scope