376481 - Provide a 'labelGuess' attribute hint

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, enhancement)

Description

[Willie Walker]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070402 Minefield/3.0a4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070402 Minefield/3.0a4pre

At CSUN 2007, we discussed the idea of providing an attribute hint ('labelGuess') for assistive technologies.  This hint would provide a guess for the object that might be labelling an interactive component on a page.  For example, "Username:" might be labelling a text entry field. In the meeting we had, the majority of us agreed that this logic should live in Gecko itself rather than being something that all assistive technologies should need to implement.  Furthermore, we also agreed that it needs to be done even if there are web accessibility guidelines that specifically state the need for labelFor identification: web content providers just don't provide labelFor information.  :-(

Since attributes are text strings, we'd need a way to map a string to an object and substring.  I'm not sure of the best way to do this.  Perhaps it could be something along the lines of a nested numeric path similar to what at-poke shows us (e.g., "0.5.4.2_0_12") means "starting at the html document frame, get child 0 and then child 5 of that child and child 4 of that child and child 2 of that child.  The label is the substring(0,12) of the accessible text for that object.").


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Aaron Leventhal]

I'm not sure what the logic should be.

Also, I'm not sure if we'll get to this in Firefox 3, given the severity of all the other bugs we're facing.

Comment 2

[Willie Walker]

The logic is likely to not be very simple, and I doubt the guess will consistently be 100% accurate.  By pushing the logic to the screen reader, however, the work will need to be duplicated inside each screen reader, and I suspect the logic would require a bunch of round tripping to make a good guess.  As a result, it would be much nicer to have this stuff at the source.

Comment 3

[Aaron Leventhal]

I definitely see the point. If someone wants to spec out a good heuristic that might help us get it into FF3.

Comment 4

[Aaron Leventhal]

Actually, we should just ask on mozilla.dev.accessibility for opinions.

Comment 5

[Aaron Leventhal]

Will, one other idea might be just to say
"label-guess" = "true"
when the labelled-by and label-for relation use a heuristic instead of a marked-up label.

That might be easier than using something like "0.5.4.2_0_12"

I'm not sure how hard that will be for us to code, but it's a thought.

Comment 6

[Willie Walker]

(In reply to comment #5)
> Will, one other idea might be just to say
> "label-guess" = "true"
> when the labelled-by and label-for relation use a heuristic instead of a
> marked-up label.

Hey!  I like it.  :-)  It means I wouldn't have to do any extra work.  :-)

Comment 7

[Aaron Leventhal]

Calculating the pretend label-for is going to be very hard. What if we only provided labelled-by in these guessing cases?

Comment 8

[Aaron Leventhal]

I've started a thread on this on mozilla.dev.accessibility.

Test cases would be super. The more the better.

Comment 9

[Willie Walker]

(In reply to comment #7)
> Calculating the pretend label-for is going to be very hard. What if we only
> provided labelled-by in these guessing cases?

We could work with that, I think.  I'm confused about why doing the label-for is going to be hard if you already have figured out the relationship, though.

Comment 10

[Aaron Leventhal]

It's hard because we'd need to check for the relationship on every element, as opposed to label-for where we only need to check on form controls that are unlabelled.

To make the label-for guess performant we'd really need to run through the entire doc once ahead of time, use a hash table as we collected the results, and keep it updated through any DOM mutations. Sound fun? If it's not necessary, which I don't think it is, we should probably stay away from that!

Comment 11

[parente]

I think Will means that once you make a labelled-by guess, follow that relation to get the widget on the other end, and give it inverse relationship, label-for. You only do the guesswork once, then assign the inverse to the relation target.

Comment 12

[Aaron Leventhal]

Who's to say tee author will do labelled-by first?

Also, assigning the relation means using a hash table, otherwise we'd be bloating our objects, because almost anything could be a label.

Comment 13

[Willie Walker]

Just curious how things are going here -- I don't want to see the good momentum die.  This would be a very useful thing to have.

Comment 14

[Aaron Leventhal]

I have ideas on what to do, but it's lower priority than making the basic APIs work without crashes etc.

Comment 15

[Tom Brunet]

Here's a general idea of what Home Page Reader used as a heuristic.  First, from the documentation that comes with the product:

HPR renders a label for each control by looking for one of the following pieces of information: 
1. Surrounding LABEL element. LABEL element with for attribute value matching control element ID. 
2. Text immediately following or preceding the control element in the same, previous, or next item. 
3. Text in the previous, next, or above table cell. 
4. title attribute.
---

That's a little vague for this purpose, so here's a little more detail.

For text inputs:
1. Text/img that precedes control in same item.
2. Text/img that follows control in same item (nothing between end of text and item)
3. Text/img that precedes control in previous item/cell (not another control in that item)
4. Text/img in cell above without other controls in cell above
    Throw out #4 if other controls in this cell above

For checkboxes/radio buttons:
1. Text/img that follows control in same item.
2. Text/img that precedes control in same item (nothing between start of text and item)
3. Text/img that follows control in next item/cell (not another control in that item)
4. Text/img that precedes control in previous item/cell (not another control in that item)
5. Text/img in cell above without other controls in cell above
    Throw out #5 if other controls in this cell above
---

An item boundary usually created a visual line break, but I don't think I can easily expand more on that.  Also, you might want to consider labels for radio groups?

This heuristic wasn't perfect, but worked quite well for us - at least for most situations that didn't completely ignore UI guidelines.  Eyeballing it, you might run into trouble if a survey-like set of radio buttons had labels below each radio button.

I hope this helps a little.

Comment 16

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

Mass un-assigning bugs assigned to Aaron.

Comment 17

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

Eitan, do you think you'll need some logic like this for our Android solution?

Comment 18

[Eitan Isaacson [:eeejay]]

Yeah, I it would be useful.

Comment 19

[Marco Zehe (:MarcoZ)]

Are we still planning to do anything with this?

Comment 20

[Joanmarie Diggs]

My guess would be "no." ;) Might as well close it.

Comment 21

[Marco Zehe (:MarcoZ)]

OK, I think the better course of action is anyway to educate web developers more and more to use proper labeling instead of doing guess work.