@JAWS-test do you think these issues are a side effect of invalid code, or did the implementors genuinely not understand the spec?

@MelSumner Neither nor. If the specification is unclear, every browser does what it thinks. The specification should be clear, then the browsers know how to do it right.

Updated the title due to the re-ordering in #122

+1

This issue is an older one, but I believe it still needs to be addressed.

The behavior in these cases is unclear:

<label role="presentation" for="test">First Name</label>
<input id="test" type="text">

<label role="presentation">
    <span>First Name</span>
    <input type="text">
</label>

I would expect the accessible name to remain "First Name" in both scenarios, but the specifications are not clear on this.

The current wording, particularly the phrase "unless the element is marked...", is ambiguous. It is unclear whether this refers to the "current node" or to the "element (e.g., an HTML label or SVG title)".

To resolve the ambiguity, changing it to "unless the current node is marked..." would provide clarity.

There is still one issue to address regarding the Presentational Roles Conflict Resolution. Even if role="presentation" is applied to the <input>, its accessible name will still be computed according to the original specifications. It might be useful to add a note about this behavior.

I’m opening a tentative PR to address these points.

I think we need to talk about this in the WG meeting. I'm not convinced this is an AccName specific issue since the application of the presentational role doesn't just impact the name but also the role, and any focusable element has its presentational state ignored.

FWIW i agree with @giacomo-petri's assumption that even if a label is given a role=none, it would be used to name an input in those scenarios. A label doesn't have a role that's exposed to the a11y tree - so marking it as presentational won't even do anything in the a11y tree.

similarly, i'd also expect (which matches reality) that the name of this fieldset is "foo" <fieldset><legend role=none>foo</legend>...</fieldset> - suppressing/changing the element's role shouldn't undo the other mappings or functionality the element has in HTML - in this case, naming the parent fieldset.

It's strange behavior to have so many exceptions just because developers make so many mistakes.

What is the point of having the role of presentation or none if it only works sometimes?

We're twisting ourselves into pretzels to accommodate code that is simply invalid. We need a better solution than this.

@MelSumner i don't see this as adding exceptions. there are differences in behavior here, as i mentioned by jaws test, and further called out in the back and forth i was having with Giacomo in his PR for this issue. so it's not unreasonable to to get this clarified, since there isn't full interop.

i don't disagree that some of this could be considered invalid code from the authoring side - but the ARIA spec is clear that unless a host language explicitly states that certain features are not to be overwritten by ARIA, or ARIA doesn't have other stipulations written, then ARIA takes precedent.

additionally, this isn't about making role=none not work (its purpose is to remove role semantics - that's not changing with this discussion or PR). But changing the role of an element in HTML (to any role, not just role=none) does not mean its implicit behaviors / functionality also change. So a label or legend should still provide a name to their associated input or fieldset, respectively. role=none can negate the role semantics of those elements (well, if label even had one to negate that is...) but the other behaviors/functionality of HTML should not be impacted by the role change - hence they should still name the elements they are associated with, since that's their native HTML behavior.

but if role none is put on the "current node", as is one interpretation of the spec text (which i think is probably the right one) - THEN the role=none kicks in and the element shouldn't be named, because it can't be, it no longer has a role that allows it to be named. so role=none working as it should. no twisting.

TBH, where there is a problem here, it's not even unique to role=none. but putting any role on a label will break it naming an input in Firefox (but not chrome or webkit).

with that said, i think @giacomo-petri has done a good job at trying to address this issue. i had some confusion about what the expected outcome should be due to the wpt that was initially made, but after clearing that up, it looks like this was on the right track and it'll make things more consistent / keep things accessible even if authors do something weird, once this has been finalized.