See http://www.html5accessibility.com/tests/form-labels.html.
Created attachment 110326 [details] Patch
Comment on attachment 110326 [details] Patch Changing <label> to be static text will cause all elements inside the <label> to be lost. Thus <label>label<input></label> will not report the <input> as an element, which will be a regression. I just tested that website with VoiceOver on Lion, and it seems that VoiceOver reads all of the labels for the input fields. What is motivating this change?
Note I did see that on test 7, VO repeated the label twice. I filed a VoiceOVer bug for that (rdar://10257905)
The issue on Snow Leopard (haven't tried it on Lion) (on test cases 3 and greater): • VO-cmd-j to the edit field result: voiceover reads "edit text" expected: voiceover reads "label wrapped edit text" We suspect that the root cause is because the title UI element is a parent of the text field being labeled. If VoiceOver follows alll references to title UI elements, this would cause a cycle (so perhaps VO ignores this case)? reproduces on both Chrome and WebKit r97062
(In reply to comment #4) > The issue on Snow Leopard (haven't tried it on Lion) (on test cases 3 and greater): > • VO-cmd-j to the edit field > > result: > voiceover reads "edit text" > > expected: voiceover reads "label wrapped edit text" > > We suspect that the root cause is because the title UI element is a parent of the text field being labeled. If VoiceOver follows alll references to title UI elements, this would cause a cycle (so perhaps VO ignores this case)? > > reproduces on both Chrome and WebKit r97062 This was a VoiceOver bug. Fixed in Lion.
Ah, ok.
Is this bug fixed for Lion? Can we close it then? Does WebKit pass all test cases on http://www.html5accessibility.com/tests/form-labels.html now?
(In reply to comment #7) > Is this bug fixed for Lion? Can we close it then? Does WebKit pass all test cases on http://www.html5accessibility.com/tests/form-labels.html now? Yes, with the exception of the duplication mentioned by Chris.