alexander :surkov (:asurkov) Reporter
	Description • 15 years ago

spun off bug 501445.

(In reply to comment #9)

> Don't know if we should ignore the label, or create an accessible for it. But
> we should definitely put its name on the referenced accessible as that
> accessible's accName.

> Wasn't there some talk about that if a n element is originally hidden, but
> being pointed to by aria-labelledby or aria-describedby, that it should be
> created nevertheless?

Yes it's a bug 476986.

	David Bolter [:davidb] (NeedInfo me for attention)
	Comment 1 • 15 years ago

Yep. IMO we should expose hidden labels if they are part of a label/desc relation. I thought we did this... if not let's definitely create a test and fix.

	Marco Zehe (:MarcoZ)
	Comment 3 • 12 years ago

This example was recently brought to my attention in a big university project. The radio buttons in this example don't get the label text even though the label explicitly participates. The only workaround is to use a CSS clipping method, e. g. don't move them off-screen, but hide them by making them so small the text doesn't show up. Accessibles for the labels are created, by the way, they're just not being associated.

According to their testing, this only applies to radio buttons. Associating hidden labels to entries, however, works.

	alexander :surkov (:asurkov) Reporter
	Comment 4 • 12 years ago

steps to fix:

1) add 
dom::Element* NextElm() to RelatedAccIterator and HTMLLabelIterator (get idea from IDRefsIterator)
2) use HTMLLabelIterator::NextElm() in Accessible::GetHTMLName() instead HTMLLabelIterator::Next()
3) add a test into name/test_general.html

	alexander :surkov (:asurkov) Reporter
	Comment 6 • 12 years ago

It can be seen in the wild (see examples in description of bug 780854).

	alexander :surkov (:asurkov) Reporter
	Comment 7 • 12 years ago

it doesn't work because we don't cache relations for non accessible elements.

	Trevor Saunders (:tbsaunde)
	Comment 8 • 12 years ago

(In reply to alexander :surkov from comment #7)
> Created attachment 674152 [details] [diff] [review]
> wip
> 
> it doesn't work because we don't cache relations for non accessible elements.

I'd think the easiest way to fix that is what I did in bug 796955 to do the caching based on content changes not a11y tree.  Of course you'll have to decide if you care enough to fix the xbl nonsense.

	alexander :surkov (:asurkov) Reporter
	Comment 9 • 12 years ago

(In reply to Trevor Saunders (:tbsaunde) from comment #8)
> (In reply to alexander :surkov from comment #7)

> I'd think the easiest way to fix that is what I did in bug 796955 to do the
> caching based on content changes not a11y tree.

agree

>  Of course you'll have to
> decide if you care enough to fix the xbl nonsense.

I don't thumb up for "from chipping come chips"

	Andy Perdana
	Comment 10 • 11 years ago

*BUMP*
I'd really like to see this bug fixed.
Sorry, for not introducing any help of sort though. I just bumped into this at work today and thought someone should see that there's still interest in a fix.

	alexander :surkov (:asurkov) Reporter
	Comment 11 • 11 years ago

(In reply to Andy Perdana from comment #10)
> *BUMP*
> I'd really like to see this bug fixed.
> Sorry, for not introducing any help of sort though. I just bumped into this
> at work today and thought someone should see that there's still interest in
> a fix.

what is your case? the bug fix is not going to be trivial so we need to have an idea how the bug hits our users.

	Andy Perdana
	Comment 12 • 11 years ago

I have a form on a site and each input has a label, but having a readable label for month of birth and year of birth seems stupid, because through the size of the input it's obvious what to enter where. Also it doesn't fit into the layout of the form.
But leaving them out would make it not so easy if you're not able to see properly therefore I wanted to aid screenreader users with two additional labels which I planned to hide with overflow: hidden and a fixed size of the parent holding all three labels. But because of this bug it doesn't work as expected and because I hope that many more developers will try to do so as well but fail, I'd like to see it fixed.

	alexander :surkov (:asurkov) Reporter
	Comment 13 • 11 years ago

(In reply to Andy Perdana from comment #12)
> I have a form on a site and each input has a label, but having a readable
> label for month of birth and year of birth seems stupid, because through the
> size of the input it's obvious what to enter where. Also it doesn't fit into
> the layout of the form.
> But leaving them out would make it not so easy if you're not able to see
> properly therefore I wanted to aid screenreader users with two additional
> labels which I planned to hide with overflow: hidden and a fixed size of the
> parent holding all three labels. But because of this bug it doesn't work as
> expected and because I hope that many more developers will try to do so as
> well but fail, I'd like to see it fixed.

Does aria-label not work for you for some reason?

	Andy Perdana
	Comment 14 • 11 years ago

I didn't know that this attribute existed, but it works which is also a better solution than CSS-hidden labels. Thanks a lot.

	alexander :surkov (:asurkov) Reporter
	Comment 16 • 11 years ago

q4 nom per bug 759705 comment #2

	Marco Zehe (:MarcoZ)
	Comment 17 • 6 years ago

Alex, I can no longer reproduce this, nor the duped bug 780854. The accessibles get created and the labels properly associated to the radio buttons. The fiddle in bug 780854 as well as Jamie's test case all are working for me. Any idea which bug might have fixed this? The changing to a markup map maybe?

	James Teh [:Jamie]
	Comment 18 • 6 years ago

The reason my test case in bug 780854 now works is that the label accessible gets created. Note that the following does *not* set the name of the input correctly:
data:text/html,<label for="foo" style="display: none;">foo</label><input id="foo">
This is a truly hidden label, not just off-screen.

	Marco Zehe (:MarcoZ)
	Comment 19 • 6 years ago

(In reply to James Teh [:Jamie] from comment #18)
> The reason my test case in bug 780854 now works is that the label accessible
> gets created. Note that the following does *not* set the name of the input
> correctly:
> data:text/html,<label for="foo" style="display: none;">foo</label><input
> id="foo">
> This is a truly hidden label, not just off-screen.

Yes but is this even supported by specifications? E. g. in the CoreAM spec, it says to remove accessibles from a tree that are display:none;, and it doesn't give any exceptions. I also don't see anything in the Accessible Name and Description Computation spec that hints that this should work. Unless I'm missing something.

	James Teh [:Jamie]
	Comment 20 • 6 years ago

Looking at the spec, I agree it's not supported. The spec does require that hidden elements referenced by aria-labelledby are included in name computation, and that already works. However, this is specific to aria-labelledby; it does not require this for other things such as <label for>.

There is some confusion as to whether this bug was referring to both truly "hidden" elements and off-screen elements or just off-screen. If hidden, I guess we're saying that's a wontfix (because spec). If off-screen, that's a fixed/worksforme.

	alexander :surkov (:asurkov) Reporter
	Comment 21 • 6 years ago

(In reply to James Teh [:Jamie] from comment #20)
> Looking at the spec, I agree it's not supported. The spec does require that
> hidden elements referenced by aria-labelledby are included in name
> computation, and that already works. However, this is specific to
> aria-labelledby; it does not require this for other things such as <label
> for>.

it does (https://www.w3.org/TR/accname-1.1/)

"If the current node is hidden and is not directly referenced by aria-labelledby or aria-describedby, nor directly referenced by a native host language text alternative element (e.g. label in HTML) or attribute, return the empty string. Otherwise ..."

> There is some confusion as to whether this bug was referring to both truly
> "hidden" elements and off-screen elements or just off-screen. If hidden, I
> guess we're saying that's a wontfix (because spec). If off-screen, that's a
> fixed/worksforme.

the attached patch is about solving inaccessible labels case, so we may treat the bug same way. However I think we follow the spec and compute name correctly both for @for and aria-labelledby for inaccessible labels, correct?

	James Teh [:Jamie]
	Comment 22 • 6 years ago

(In reply to alexander :surkov from comment #21)
> it does [require inclusion of hidden labels in name computation] (https://www.w3.org/TR/accname-1.1/)
> "If the current node is hidden and is not directly referenced by
> aria-labelledby or aria-describedby, nor directly referenced by a native
> host language text alternative element (e.g. label in HTML) or attribute,
> return the empty string. Otherwise ..."

That specifies what should happen if the element is hidden and is *not* an associated label; e.g. when recursing in a name-from-content situation. 

It does explicitly mention native marup such as <label>:

> D. Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none"). 

It doesn't explicitly mention how this should be handled if the host markup label is hidden, though.

> However I think we follow the spec and compute name
> correctly both for @for and aria-labelledby for inaccessible labels, correct?

If an associated <label> is hidden, we don't include it in name computation for the control it labels. See my test case in comment 18.

	alexander :surkov (:asurkov) Reporter
	Comment 23 • 6 years ago

(In reply to James Teh [:Jamie] from comment #22)
> (In reply to alexander :surkov from comment #21)
> > it does [require inclusion of hidden labels in name computation] (https://www.w3.org/TR/accname-1.1/)
> > "If the current node is hidden and is not directly referenced by
> > aria-labelledby or aria-describedby, nor directly referenced by a native
> > host language text alternative element (e.g. label in HTML) or attribute,
> > return the empty string. Otherwise ..."
> 
> That specifies what should happen if the element is hidden and is *not* an
> associated label; e.g. when recursing in a name-from-content situation. 

you're right, that part can only be applied for aria-labelledby and so things, leaving native markup references out of box, which is weird

> It does explicitly mention native marup such as <label>:
> 
> > D. Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none"). 
> 
> It doesn't explicitly mention how this should be handled if the host markup
> label is hidden, though.

agreed

> > However I think we follow the spec and compute name
> > correctly both for @for and aria-labelledby for inaccessible labels, correct?
> 
> If an associated <label> is hidden, we don't include it in name computation
> for the control it labels. See my test case in comment 18.

so, we'd need to clarify the spec, I think that html:label shouldn't be different from aria-labelledby references, and yeah, we need to finish that patch