Bug 69736

Summary: Wrapped <label> elements aren't reported by screen readers
Product: WebKit Reporter: Alice Boxhall <aboxhall>
Component: AccessibilityAssignee: Alice Boxhall <aboxhall>
Status: RESOLVED FIXED    
Severity: Normal CC: cfleizach, dmazzoni, dtseng, mike, rniwa, webmaster
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch cfleizach: review-

Alice Boxhall
Reported 2011-10-09 20:59:41 PDT
See http://www.html5accessibility.com/tests/form-labels.html.
Attachments
Patch (11.89 KB, patch)
2011-10-09 21:58 PDT, Alice Boxhall 		cfleizach: review-
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Alice Boxhall
Comment 1 2011-10-09 21:58:32 PDT
Created attachment 110326 [details] Patch
chris fleizach
Comment 2 2011-10-10 00:11:32 PDT
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?
chris fleizach
Comment 3 2011-10-10 00:14:59 PDT
Note I did see that on test 7, VO repeated the label twice. I filed a VoiceOVer bug for that (rdar://10257905)
David Tseng
Comment 4 2011-10-10 09:57:46 PDT
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
chris fleizach
Comment 5 2011-10-10 10:01:49 PDT
(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.
Alice Boxhall
Comment 6 2011-10-10 15:21:30 PDT
Ah, ok.
Ryosuke Niwa
Comment 7 2012-01-06 10:25:49 PST
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?
Alice Boxhall
Comment 8 2012-01-08 20:35:56 PST
(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.
Note You need to log in before you can comment on or make changes to this bug.