Open Bug 631591 Opened 13 years ago Updated 2 years ago

different accessible name depending on the label element association method used

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Windows Vista
Type:
defect

Tracking

()

People

(Reporter: faulkner.steve, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-us) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4
Build Identifier: Firefox/4.0b10pre

the text label exposed via MSAA for a text input  is different depending on how the label is associated with the text input full details :http://www.html5accessibility.com/tests/placeholder-labelling.html

Reproducible: Always

Steps to Reproduce:
1.got to http://www.html5accessibility.com/tests/placeholder-labelling.html
2. use a tool such as inspect32 to show info exposed via accessibility API
3. check test cases "placeholder with label associated using label element and for/id attributes" and "placeholder with label associated by wrapping label element around text and input"
Actual Results:  
for "placeholder with label associated by wrapping label element around text and input" accessible name =	label text + placeholder text
for "placeholder with label associated using label element and for/id attributes" accessible namer =	label text

Expected Results:  
the two should result in the same accessible name value. which of the text cases is correct is undetermined
Component: General → Disability Access APIs
Product: Firefox → Core
QA Contact: general → accessibility-apis
<label for="a1">label</label> <input id="a1" type="text" placeholder="pootish">

Doesn't expose placeholder text because of rule taken in bug 604391: Expose placeholder as name if name is otherwise empty.

<label>label <input type="text" placeholder="pooter"></label>

Exposes placeholder name due to the same reason (since it's recursive name calculation). I think this corresponds to ARIA name computation algorithm (perhaps extended to HTML markup). For example, I think you would see the same for:

<span role="label" id="a1">label</span> <input aria-labelledby="a1"type="text" placeholder="pootish">

<span role="label" id="a2">label <input type="text" placeholder="pooter" aria-labelledby="a2"></span>

I'm not sure we need to fix anything here.
(In reply to comment #1)
> <label for="a1">label</label> <input id="a1" type="text" placeholder="pootish">
> 
> Doesn't expose placeholder text because of rule taken in bug 604391: Expose
> placeholder as name if name is otherwise empty.
> 
> <label>label <input type="text" placeholder="pooter"></label>
> 
> Exposes placeholder name due to the same reason (since it's recursive name
> calculation). I think this corresponds to ARIA name computation algorithm
> (perhaps extended to HTML markup). For example, I think you would see the same
> for:
> 
> <span role="label" id="a1">label</span> <input aria-labelledby="a1"type="text"
> placeholder="pootish">
> 
> <span role="label" id="a2">label <input type="text" placeholder="pooter"
> aria-labelledby="a2"></span>
> 
> I'm not sure we need to fix anything here.

hi alex, 
there is no role=label in ARIA.
the 2 cases wrapped vs for/id should produce the same result no?
(In reply to comment #2)

> hi alex, 
> there is no role=label in ARIA.

Well, not in Gecko ARIA implementation :) David, your call?

But @role="label" can be replaced on anything else in the example.

> the 2 cases wrapped vs for/id should produce the same result no?

I would say yes, at least from the point of view of page author since these ways to provide a label are equivalent. But I tried to give explanation why it doesn't happen and why it may be considered as correct approach and as a feature. I don't have strong opinion what should we do here.
(In reply to comment #3)
> (In reply to comment #2)
> 
> > hi alex, 
> > there is no role=label in ARIA.
> 
> Well, not in Gecko ARIA implementation :) David, your call?

Oops. Yeah I guess this was removed from the spec. I need to do a proper cross reference again.

I'll need to make sure we don't rely on role="label" in our front-end code (unlikely). Filed bug 634322 for this.
(In reply to comment #3)
> (In reply to comment #2)
> > the 2 cases wrapped vs for/id should produce the same result no?
> 
> I would say yes, at least from the point of view of page author since these
> ways to provide a label are equivalent.

I think this is enough to confirm this bug status.

> But I tried to give explanation why it
> doesn't happen and why it may be considered as correct approach and as a
> feature. I don't have strong opinion what should we do here.

I think we need to reach a consensus here. Steve do you think our implementation is fair (comment 1), or do you feel strongly it needs to change?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think that it will not be expected by authors that the 2 methods will produce different results as they are supposed to be equivalent.

If I as an author provided a visible text label  would not expect the resulting accessible label to be a concatenation of the 2 sources.

There is a also question of whether this behaviour will be the same across browsers, I think that is an important consideration and would hazard that it will not be.

What I strongly believe is the two methods should produce the same result.
(In reply to comment #6)

> There is a also question of whether this behaviour will be the same across
> browsers, I think that is an important consideration and would hazard that it
> will not be.

True, but hard to do while there's no specification how to expose HTML to AT APIs. I know there's some work but never heard it was finished.

> What I strongly believe is the two methods should produce the same result.

We follow general algorithm of name computations. We need new one to make that happen. I think we should join to that HTML to AT group and clarify this.
(In reply to comment #7)
> (In reply to comment #6)
> 
> > There is a also question of whether this behaviour will be the same across
> > browsers, I think that is an important consideration and would hazard that it
> > will not be.
> 
> True, but hard to do while there's no specification how to expose HTML to AT
> APIs. I know there's some work but never heard it was finished.
> 
> > What I strongly believe is the two methods should produce the same result.
> 
> We follow general algorithm of name computations. We need new one to make that
> happen. I think we should join to that HTML to AT group and clarify this.

Hi alex,

The work is definitley not finished, but is being actively developed (by me at least)

http://dev.w3.org/html5/html-api-map/overview.html

>I think we should join to that HTML to AT group and clarify this.

please do!
(In reply to comment #8)

> Hi alex,
> 
> The work is definitley not finished, but is being actively developed (by me at
> least)

ok, great. I didn't know you're on it.

> http://dev.w3.org/html5/html-api-map/overview.html

> >I think we should join to that HTML to AT group and clarify this.
> 
> please do!

I bet I read early drafts from Cynthia and did comments in the past. I can run thought the spec and check it against Firefox (after fx4 though). How can I help else? Do you have a separate thread where you keep discussions?
Hi alex, 

>I can run thought the spec and check it against Firefox (after fx4 though) 

that would be great.

>How can I help else?
One of the aims of the document is to get converging implementaions across browsers(where necessary)so for example the this bug is one where they may well be divergence and therefore need to get agreement on how it shoudl work.

>Do you have a separate thread where you keep discussions?

there is no dedicated list, you can file bugs against the document using the w3c html wg bugzilla (need an account)

http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG&component=HTML%20a11y%20APIs%20(editor:%20Steve%20Faulkner,%20Cynthia Shelley)
Alexander are you owning this one?
(In reply to comment #11)
> Alexander are you owning this one?

I would, do you think it should be targeted to fx5?
(In reply to alexander :surkov from comment #12)
> (In reply to comment #11)
> > Alexander are you owning this one?
> 
> I would, do you think it should be targeted to fx5?

Hi Alex any update on this? I recently updated the tests http://www.html5accessibility.com/tests/placeholder-labelling.html and found that firefox is still borked.
I think we should get this moving again. I am currently working on bug 670083 and also have a simple idea how to fix this bug too.
This is still a problem in Firefox 61.0a1 nightly. I noticed that placeholder does not even appear in the current name calculation spec any more. Steve, is this bug still valid at all, then?
Flags: needinfo?(faulkner.steve)
(In reply to Marco Zehe (:MarcoZ) from comment #15)
> This is still a problem in Firefox 61.0a1 nightly. I noticed that
> placeholder does not even appear in the current name calculation spec any
> more. Steve, is this bug still valid at all, then?

not Steve, but some thinking: I think placeholder is exposed via API separately for each platform, for example, 'placeholder' object attribute on IA2, and thus it was removed from name computation. However I'd argue it should be exposed via accessible name as a fallback mechanism. We could expose 'explicit-name:false' object attribute in addition for those who rely on it.
Marco, this issue is still present in Firefox, take the test case
https://s.codepen.io/stevef/debug/PeBroL it is expected that both inputs will have an accessible name of "label" the first input does, the second input has an accessible name that include both the label text and the placeholder text "label pootish".
Note that in Chrome and Edge the accessible names are the same "label" for both inputs as expected.
Flags: needinfo?(faulkner.steve)

Still an issue
test case: https://cdpn.io/pen/debug/ExoEQjQ
in chrome Version 100.0.4896.60 (Official Build) (64-bit) both result in accessible name = apple
in Firefox 100.0b1 (64-bit) label wrapped results in acc name = apple banana

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.