The default bug view has changed. See this FAQ.

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

NEW
Unassigned

Status

()

Core
Disability Access APIs
8 years ago
3 years ago

People

(Reporter: surkov, Unassigned)

Tracking

(Blocks: 2 bugs, {access})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

8 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

6 years ago
Blocks: 374212

Comment 3

5 years ago
Created attachment 633975 [details]
Example where labels moved off-screen don't participate in accessible name calculation

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

5 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

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

Comment 6

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

Comment 7

5 years ago
Created attachment 674152 [details] [diff] [review]
wip

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

5 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

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

Comment 10

4 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

4 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

4 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

4 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

4 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

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

Comment 16

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

Updated

3 years ago
Blocks: 956711
You need to log in before you can comment on or make changes to this bug.