aria-colspan / aria-rowspan on td / th elements without colspan / rowspan

[dd8]

The colspan and rowspan attributes both default to 1 on th / td in the DOM and the table processing model if the attributes are absent.

https://html.spec.whatwg.org/multipage/tables.html#forming-a-table https://html.spec.whatwg.org/multipage/tables.html#dom-tdth-colspan

Authors MAY use the aria-colspan attribute on any element that is allowed the colspan attribute in HTML, or any element with a WAI-ARIA role which allows the aria-colspan attribute.

https://w3c.github.io/html-aria/#att-colspan

Should the only allowed value be aria-colspan=1 on th / td when colspan is absent? (to avoid conflicts with the default value of 1). Ditto with aria-rowspan and rowspan.

Edit: or put another way these both result in the same DOM, and the same rendered cell, but it looks like only the second one is prohibited with the current wording:

<td aria-colspan='2'>Cell</td>
<td aria-colspan='2' colspan='1'>Cell</td>

I think this is a bit different to attributes like aria-required vs required, since I don't believe there's any way to change the table processing model with script.

[scottaohara]

Hi @dd8,

Thank you for raising this issue. I'm going to re-review how these are working and, along with some other table element rules that need to be updated, make necessary edits.

[dd8]

@scottaohara I'm writing some unit tests to test our implementation against the spec wording - so may end up filing another issue.

I've also raised a couple of issues against the W3 validator: https://github.com/validator/validator/issues/1198 https://github.com/validator/validator/issues/1196

[scottaohara]

after digging into this more, I'm thinking the best course of action would be to file some really odd browser quirks and remove the MAY rules for this version of the spec. The SHOULD NOT and MUST rules would still apply, so we can keep those in and make further updates in the next version of the spec as needed.

@stevefaulkner, @patrickhlauke thoughts?

[stevefaulkner]

@scottaohara agreed

[patrickhlauke]

after digging into this more, I'm thinking the best course of action would be to file some really odd browser quirks and remove the MAY rules for this version of the spec. The SHOULD NOT and MUST rules would still apply, so we can keep those in and make further updates in the next version of the spec as needed.

@stevefaulkner, @patrickhlauke thoughts?

would removing that MAY clause not essentially result in:

• use colspan when the element allows colspan
• should not use aria-colspan if there's already a colspan (but if you do, they need to match value)
• must not use both colspan and aria-colspan if there's a mismatch in value

essentially...making it pointless? (use colspan; then, if you have good reason, double it up with aria-colspan that says the same thing)

[scottaohara]

@patrickhlauke deleting my previous comment cause I was looking at the text for the next version rather than what's there now.

But yes, further updates are needed (and i'm working on them) but doing any more at this point would require getting updated implementations.

the should not now would indicate to developers that they're using aria needlessly since they already declared the native colspan.

the must not indicates that not only are they using aria needlessly, they're also just doing stuff wrong.

so, "pointless" as much as warning anyone about misuse of ARIA is pointless. But as mentioned, I think that's the best we can do for right now without removing it all and asking current implementations to revert changes / filing requests for new rule implementations.

[scottaohara]

jeez. i clearly need to call it a day. pushed up the wrong changes. will get this sorted tomorrow.