453594 - Fix name calculation for labels (HTML, XUL)

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

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.

Comment 1

[alexander :surkov (:asurkov)]

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

Comment 2

[alexander :surkov (:asurkov)]

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

Comment 3

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 4

[Aaron Leventhal]

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 5

[alexander :surkov (:asurkov)]

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

Comment 6

[Aaron Leventhal]

> 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.

Comment 7

[alexander :surkov (:asurkov)]

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>

Comment 8

[Aaron Leventhal]

(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.

Comment 9

[alexander :surkov (:asurkov)]

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.

Comment 10

[Aaron Leventhal]

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.

Comment 11

[Aaron Leventhal]

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.

Comment 12

[alexander :surkov (:asurkov)]

(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".

Comment 13

[Aaron Leventhal]

> 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.

Comment 14

[alexander :surkov (:asurkov)]

Agree. Marco could you do small investigation?

Comment 15

[David Bolter [:davidb] (NeedInfo me for attention)]

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

Comment 16

[alexander :surkov (:asurkov)]

(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.

Comment 17

[David Bolter [:davidb] (NeedInfo me for attention)]

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?

Comment 18

[alexander :surkov (:asurkov)]

(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?

Comment 19

[David Bolter [:davidb] (NeedInfo me for attention)]

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.

Comment 20

[David Bolter [:davidb] (NeedInfo me for attention)]

(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?

Comment 21

[Marco Zehe (:MarcoZ)]

(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?

Comment 22

[David Bolter [:davidb] (NeedInfo me for attention)]

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

Comment 23

[alexander :surkov (:asurkov)]

(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 24

[Marco Zehe (:MarcoZ)]

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.

Comment 25

[alexander :surkov (:asurkov)]

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?

Comment 26

[James Teh [:Jamie]]

(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.

Comment 27

[alexander :surkov (:asurkov)]

(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.

Comment 28

[James Teh [:Jamie]]

(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.

Comment 29

[alexander :surkov (:asurkov)]

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

Comment 30

[Marco Zehe (:MarcoZ)]

Alex, is this bug even still valid?

Comment 31

[alexander :surkov (:asurkov)]

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.