From IRC's #accessibility channel: <surkov> MarcoZ, I don't think it's correct, I think if you'll put XXX there to bring an attention then it should be ok <surkov> because iirc xforms label much similar with XUL and HTML label <surkov> with the one exception: xforms label is always inside xforms control if they are linked <surkov> so I think name should be either aggregated or be taken from instance node <surkov> from instance node I mean like in nsXFormsAccessible::GetValue bug 453417 puts a marker in the appropriate spot to indicate that something needs to be done.

changing summary to be more general Now HTML label - name calculation from subtree is allowed XUL label/description - name calculation from subtree is denied XForms label - no name calculation

XUL label and description doesn't calculate the name from subtree starting from bug 407359

Comment on attachment 351513 [details] [diff] [review] patch From the information provided in the bug and patch, I cannot understand what the problem is, and how the patch is the solution.

Comment on attachment 351513 [details] [diff] [review] patch Patch fixes: 1) labels doesn't follow general rules (getting name from label) 2) label role allows getting name from subtree

> 1) labels doesn't follow general rules (getting name from label) So, making label fall back on the nsAccessible GetNameInternal impl makes it do the right thing? Which rules is it breaking right now, in terms of getting the name from the label? > 2) label role allows getting name from subtree Is that what it used to do and it shouldn't? Or that's what you want it to do and now does with this patch? To me it looks like the code this patch removes for HTML label allowed getting the name from subtree.

Yes, HTML label can't get name from subtree anymore and labels can be labelled by markup, i.e. <label for="label">label</label><label id="label>label</label>

(In reply to comment #7) > Yes, HTML label can't get name from subtree anymore and labels can be labelled > by markup, i.e. > <label for="label">label</label><label id="label>label</label> Hmm, I'm not sure either change is correct. Probably the name computation docs needs to be changed.

What rules? 1. Use label for labels. Examples. a) <label for="label">label</label><label id="label>label</label> b) <label for="label">label</label><span role="label" id="label>label</span> b) <span role="label" aria-labelledby="label">label</span><span role="label" id="label>label</span> 2) Name from subtree for labels. a) HTML label allows name from subtree b) XUL/XForms label doesn't allow name from subtree.

For #1, when do labels point to labels? HTML doesn't allow it, and I don't see any use case for doing it. For this, we should do whatever makes our code simplest. I can see the benefit of removing unnecessary code. For #2, okay I see.

For #1, when do labels point to labels? HTML doesn't allow it, and I don't see any use case for doing it. For this, we should do whatever makes our code simplest. I can see the benefit of removing unnecessary code. For #2a, how does the new code allow HTML label to do name from subtree? Although, thinking about it now perhaps this really isn't important anyway. For #2b, okay I see how the code allows that.

(In reply to comment #11) > For #1, when do labels point to labels? HTML doesn't allow it, and I don't see > any use case for doing it. For this, we should do whatever makes our code > simplest. I can see the benefit of removing unnecessary code. It's just a way to have common code. Another point is since we create accessible for HTML elements basing on frame type then if author puts ARIA role on HTML label then the following example may have sense <label for="label">label</label><label role="button" id="label>label</label> Also from the AT point of view #1a - #1c should be the same thing. If ARIA allows name of label from another label then it may have a sense to do this for HTML case as well. > For #2a, how does the new code allow HTML label to do name from subtree? > Although, thinking about it now perhaps this really isn't important anyway. Out new code doesn't allow name from subtree for labels. Name from subtree calculation rule is based on role so that we have a rule "don't use name from subtree for labels".

> we have a rule "don't use name from subtree for labels". Right, but is that the right rule for labels? I went to go look in the spec. Guess what? Label is no longer in the spec, and description has no Name From rule. We should check to see whether IE has a name for an HTML label. I don't know if we'd break anything by removing that. It might be worth having Marco check with a few screen readers. I'm not convinced that we're 100% sure that we have the right name from rule for labels.

Agree. Marco could you do small investigation?

This bug seems to have fallen off the radar? Should probably cancel the Aaron review.

(In reply to comment #15) > This bug seems to have fallen off the radar? Should probably cancel the Aaron > review. Yes, sure if this makes happy you ;) ideally someone of us should do that investigation and we should come to an agreement.

It would make me happier if Aaron was more available to us :) I'm happy to leave him on r? if he's willing. It sounds like we are just waiting to see if IE exposes an accessible name for html labels?

(In reply to comment #17) > It would make me happier if Aaron was more available to us :) I'm happy to > leave him on r? if he's willing. I don't mind. Once we get an agreement we can correct r?. We could clean it up now, it's up to you if you like :) > It sounds like we are just waiting to see if IE exposes an accessible name for > html labels? Yes, IE can give us a hint what should we do. But original question is why HTML lablels differ from XUL lablels and should they be treated by the same way?

After a quick chat with Alexander, I think we should have one strategy for calculating the name of html and xul (and xform?) labels. I think usually labels would not have a large subtree to look through so including the name from subtree rule as a catch all shouldn't hit us too bad performance-wise, and will allow us to provide better naming.

(In reply to comment #13) > I went to go look in the spec. Guess what? Label is no longer in the spec, and > description has no Name From rule. > Which spec?

(In reply to comment #19) > After a quick chat with Alexander, I think we should have one strategy for > calculating the name of html and xul (and xform?) labels. I think usually > labels would not have a large subtree to look through so including the name > from subtree rule as a catch all shouldn't hit us too bad performance-wise, and > will allow us to provide better naming. What if the label contains the form field, and that form field happens to be a select with a hundred option elements?

Let's make sure we have a case like that in our mochitests.

(In reply to comment #21) > What if the label contains the form field, and that form field happens to be a > select with a hundred option elements? The meantime HTML label allows name calculation from subtree (comment #1). However I believe our name computation won't go into hundred of options in your case, it will use accessible name of select and its value.

Comment on attachment 351513 [details] [diff] [review] patch Cancelling review since somehow this never got anywhere. Alex if you think this should be dealt with or have a new patch, please re-request review.

HTML a11y spec doesn't address labels at all: http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#calc Jamie, do you have opinion on whether label should pick up accessible name from subtree or not?

(In reply to alexander :surkov from comment #25) > Jamie, do you have opinion on whether label should pick up accessible name > from subtree or not? If I understand correctly, this happens already and makes sense to me.

(In reply to James Teh [:Jamie] from comment #26) > (In reply to alexander :surkov from comment #25) > > Jamie, do you have opinion on whether label should pick up accessible name > > from subtree or not? > If I understand correctly, this happens already and makes sense to me. Yes, it happens for HTML labels. It doesn't for XUL ones. So we need to fix XUL labels and file bug to HTML a11y spec to address label names.

(In reply to alexander :surkov from comment #27) > Yes, it happens for HTML labels. It doesn't for XUL ones. So we need to fix > XUL labels Ah. That'd be nice, actually. There are some focusable labels in Thunderbird/Seamonkey for which we have an ugly hack which forces the text into the name so they'll be read. (Ideally, their content should be read some other way - e.g. part of dialog description - but that's another matter.) Technically, a label shouldn't need a name because a label is just presentational and isn't actually a control used by the user. However, right or wrong, the reality is that labels are sometimes used for purposes other than labelling a control; e.g. a message.

filed bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=20033

Alex, is this bug even still valid?

considering the tendency is to deXULify Firefox, and we have no known bugs, where such behavior was a problem, then I suggest to wontfix this bug.