hidden HTML/XUL label pointing to control should participate in a11y name computation

NEW
Unassigned

Status

()

10 years ago
11 months ago

People

(Reporter: surkov, Unassigned)

Tracking

(Blocks: 2 bugs, {access})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 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.
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.
Duplicate of this bug: 652291

Updated

8 years ago
Blocks: 374212
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.
(Reporter)

Comment 4

7 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
Whiteboard: [mentor=surkov.alexander@gmail.com][lang=c++]
(Reporter)

Updated

7 years ago
Duplicate of this bug: 780854
(Reporter)

Comment 6

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

Comment 7

7 years ago
Posted patch wipSplinter Review
it doesn't work because we don't cache relations for non accessible elements.
(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.
(Reporter)

Comment 9

7 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"
(Reporter)

Updated

7 years ago
Whiteboard: [mentor=surkov.alexander@gmail.com][lang=c++]

Comment 10

6 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.
(Reporter)

Comment 11

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

Comment 12

6 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.
(Reporter)

Comment 13

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

Comment 14

6 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.
(Reporter)

Updated

6 years ago
Duplicate of this bug: 759705
(Reporter)

Comment 16

6 years ago
q4 nom per bug 759705 comment #2
Blocks: 923199
(Reporter)

Updated

5 years ago
Blocks: 956711
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?
Flags: needinfo?(surkov.alexander)
Flags: needinfo?(jteh)
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.
Flags: needinfo?(jteh)
(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.
Flags: needinfo?(jteh)
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.
Flags: needinfo?(jteh)
(Reporter)

Comment 21

11 months 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?
Flags: needinfo?(surkov.alexander) → needinfo?(mzehe)

Comment 22

11 months 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.
(Reporter)

Comment 23

11 months 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
Flags: needinfo?(mzehe)
You need to log in before you can comment on or make changes to this bug.