Hi,
That's true, though I'm not sure why this is a bug here since this is already included within the algorithm prototype.

There is a test case for this in the file
docs\Proposed Name and Description Tests\Name file-label-inline-hidden-elements.html

The test case only tests for <span hidden>5</span><span>6</span>. hidden implies display: none which in turn implies aria-hidden="true". But if an author manually sets display: block, hidden should still imply aria-hidden="true. My guess is that the current implementation only uses the indirect implication, not the direct one.

I see what you mean. You know, I never imagined anyone ever actually doing that... :)

I understand your point, and it would be the case that, if hidden was processed as an override for CSS display:block, then having the hidden element exposed in the naming computation would indeed be problematic.

In testing though, using the below code, it looks like display:block overrides the hidden attribute and causes it to be displayed regardless of the hidden attribute, and the naming computation algorithm appears to correctly be exposing this in the same way that the browsers are.

<input type="file" id="test" />
<label for="test">
<span class="hidden">1</span><span>2</span>
<span style="visibility: hidden;">3</span><span>4</span>
<span hidden style="display: block;">5</span><span>6</span>
<span aria-hidden="true">7</span><span>8</span>
<span aria-hidden="false" class="hidden">9</span><span>10</span>
</label>

Please let me know if I am mistaken.

In testing though, using the below code, it looks like display:block overrides the hidden attribute and causes it to be displayed regardless of the hidden attribute

I also think that display: block should take precedence over hidden when it comes to visually hiding an element. But what about accessibility? My assumption is that

<span hidden style="display: block">1</span>

is equivalent to

<span aria-hidden="true">1</span>

This one I'm not sure what to do about, since I can't find anything in the documentation that states aria-hidden functionality is specifically subject to the hidden attribute, only that when aria-hidden is specified it must be processed accordingly no matter what other attributes are present (barring accepted qualifiers).

It would be really confusing if a developer accidentally had hidden on an element that was visually exposed to all sighted users using display:block, but that element was still totally inaccessible to all non-sighted screen reader users because of this.

Personally I think this would cause more problems than not if we did this.

since I can't find anything in the documentation that states aria-hidden functionality is specifically subject to the hidden attribute

I linked it in the original post: https://www.w3.org/TR/html-aam-1.0/#details-id-201

Per the HTML spec:

Because this attribute is typically implemented using CSS, it's also possible to override it using CSS. For instance, a rule that applies 'display: block' to all elements will cancel the effects of the hidden attribute. Authors therefore have to take care when writing their style sheets to make sure that the attribute is still styled as expected.

With that said, hidden maps to aria-hidden=true but if the display of the element with the hidden attribute is modified, then it should essentially map to aria-hidden=false.

I will open an issue for the HTML AAM to make this more clear.

Is it spying software? Is W3.org downloaded on my phone? That’s software for the disabled. Could it be tracking me and spying on my info?

Could u guys please help me out