Comment 1 by jteh on 2008-05-03 23:28
These fields are not correctly labelled. If they were, NVDA would read the names. Observe, for example, that NVDA correctly reads the names of the fields in Trac.

There is no reliable way to determine a label for a field when the page author has not specified a label correctly. Some other screen readers use the previous piece of text, but this is not always correct. Indeed, I have observed cases where such incorrect reporting is actually very confusing.

I am leaving this open for discussion as to whether "guessing" the name for such fields is something we want to implement. While the fault is really with web pages, I understand that there are unfortunately far too many pages that don't correctly label form fields. However, I would argue that potentially incorrect reporting is perhaps worse.
Changes:
Changed title from "nvda and edit fields" to "Attempt to guess the label for unlabelled form fields on web pages"

Comment 2 by chris1988 (in reply to comment 1) on 2008-06-10 07:23
Replying to jteh:

These fields are not correctly labelled. If they were, NVDA would read the names. Observe, for example, that NVDA correctly reads the names of the fields in Trac.

There is no reliable way to determine a label for a field when the page author has not specified a label correctly. Some other screen readers use the previous piece of text, but this is not always correct. Indeed, I have observed cases where such incorrect reporting is actually very confusing.

I am leaving this open for discussion as to whether "guessing" the name for such fields is something we want to implement. While the fault is really with web pages, I understand that there are unfortunately far too many pages that don't correctly label form fields. However, I would argue that potentially incorrect reporting is perhaps worse.

I really cant think of anything or any way to improve on this. do you want me to shut the ticket? Does anybody else have any ideas?

Comment 3 by jteh on 2008-12-05 03:06
Changes:
Milestone changed from 0.6 to None

Comment 4 by kennydog (in reply to comment 3) on 2009-01-14 22:55
Replying to jteh:
Hi James. I think it would be good if it attempted to auto read the edit field name (eg. "username") as long as you leave in the ability to also manually check it as a backup. I know that in a demo of a commercial screen reader it is possible to both have it auto read as well as manually check it (eg. in case I heard it wrong and wanted to hear it again, or check if it is correct as we do in NVDA). Is it possible to make it a feature than can be turned on or left off in the options dialogue? If not, is it possible to at least have the manual option enabled at the same time. I understand that not all fields are labelled correctly, but at least having the option to query it manually, provides a good backup. Also, did you have it in your help files somewhere how to manually check a field name? I can remember it being discussed but am not sure if it was in the help files as when I located the function it was by accident playing around with the arrow keys!
Thanks heaps

Comment 5 by jteh (in reply to comment 4) on 2009-01-14 23:16
Replying to kennydog:

I think it would be good if it attempted to auto read the edit field name (eg. "username") as long as you leave in the ability to also manually check it as a backup.

I think you're missing a key point here. There is no field name for these fields - we have to guess the field name. (We already read fields that have definite labels.) First of all, I'm not sure how we can make this guess. Second, it may be inaccurate/incorrect, and as I noted above, that can be highly confusing. Note that if a name is not present, you know to check it manually. If a name is present, though, you don't necessarily know to check it manually, even if it is an incorrect guess.

Also, did you have it in your help files somewhere how to manually check a field name?

There's no specific method to query a field name. You just read the text around the field on the page. Where a field is unlabelled, that's all you can do. The idea is that generally, the label will be close to the field.

Comment 6 by jteh on 2009-07-05 11:14
Bzr branch: http://bzr.nvaccess.org/nvda/vbufGuessFormFieldLabels/
Not yet useable by users, but I've made a good start on the supporting code.

Comment 8 by k_kolev1985 on 2013-04-14 11:00
I understand the point that in some cases the "guessing" may be inaccurate, but due to the fact that most of the form fields on web pages do not provide labels, I think that the method with guessing when there is no labels will be better than nothing (even if incorrect at times).

Comment 9 by briang1 on 2013-04-14 14:34
I have torn my hair out on forms in Survey Monkeys system. It seems that as well as using tables the text can be either side of, say a checkbox and often the current nvda gets it wrong or even repeats things twice.
I don't have any examples at the moment but generally on other simpler forms things still work OK. Noted that sometimes in gmail for example one does have to move the focus about to read the fiield in Firefox quite often.

Maybe in the survey Monkey case its that the person who writes the form is able to make bad choices from the access point of view, in which case maybe the vendors of such online systems need to look at this as well.

@jcsteh: It seems you started working on this years ago, is there still a desire to implement this?

I think we still want this, though there's some controversy over whether it should be disabled by default. While I think this feature is important for usability, I also think users really need to know when the information they are receiving is possibly inaccurate. Mislabelling fields could be super problematic in a finance system, for example.

Having said that, I'm not working on this at present.

@LeonarddeR the gmail form is properly recognized by NVDA including all labels. Thus, I suggest closing this issue in favor of #8335.

The GMail example is not reproducible here, see my comment above. Thus, closing this issue in favor of the referenced one above.