Bug 112842 – AX: when no other label on provided on form elements, WebKit should fall back to using @title

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[James Craig]

AX: when no other label on provided on form elements, WebKit should fall back to using @title 

Load attached test case. @title is exposed as AXHelp here. It should be exposed as the label, and only fall back to helptext if there is another label provided according to the ARIA name calculation steps:

http://www.w3.org/WAI/PF/aria/complete#namecalculation

[James Craig]

Created attachment 194114 [details]
test case demonstrating bug

[Radar WebKit Bug Importer]

<rdar://problem/13467139>

[James Craig]

related to bug 114535

[James Craig]

Filed as a spec bug on ARIA 1.1 to more explicitly disallow null, empty, or whitespace-only strings as "valid" label value.

PFWG-ISSUE-609 (empty string labels are technically valid): Text Alt Comp section does not explicitly disallow empty strings as a valid label [ARIA 1.1]

https://www.w3.org/WAI/PF/Group/track/issues/609

[Samuel White]

Created attachment 210411 [details]
Patch.

Patch stops empty labels from being used when we're computing accessibility text.

[WebKit Commit Bot]

Attachment 210411 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/platform/mac/accessibility/input-title-expected.txt', u'LayoutTests/platform/mac/accessibility/input-title.html', u'Source/WebCore/ChangeLog', u'Source/WebCore/accessibility/AccessibilityNodeObject.cpp']" exit_code: 1
Source/WebCore/accessibility/AccessibilityNodeObject.cpp:1175:  Extra space after ( in if  [whitespace/parens] [5]
Source/WebCore/accessibility/AccessibilityNodeObject.cpp:1175:  Extra space before ) in if  [whitespace/parens] [5]
Source/WebCore/accessibility/AccessibilityNodeObject.cpp:1177:  One line control clauses should not use braces.  [whitespace/braces] [4]
Total errors found: 3 in 5 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Samuel White]

Created attachment 210413 [details]
Patch.

Fixed style issue.

[chris fleizach]

Comment on attachment 210413 [details]
Patch.

View in context: https://bugs.webkit.org/attachment.cgi?id=210413&action=review

patch looks good otherwise.

> LayoutTests/ChangeLog:1
> [phone]  Samuel White  <[e-mail]>

ditto about email address

> Source/WebCore/ChangeLog:1
> [phone]  Samuel White  <[e-mail]>

you need to fix your email address here. I believe you can set this in your bash profile

> Source/WebCore/ChangeLog:8
> +        Don't let input elements include empty labels in their

no need for two lines here.

[Mario Sanchez Prada]

(In reply to comment #8)
> [...]
> > Source/WebCore/ChangeLog:1
> > [phone]  Samuel White  <[e-mail]>
> 
> you need to fix your email address here. I believe you can set this in your bash profile

JFTR, in my case I do that by having the following in my ~/.bashrc file of my Linux box:

 export EMAIL_ADDRESS=[e-mail]

[Samuel White]

Created attachment 210474 [details]
Patch.

Doh! Thanks for catching the email issue. Forgot to config git on this computer.

[Build Bot]

Comment on attachment 210474 [details]
Patch.

Attachment 210474 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/1692646

New failing tests:
platform/mac/accessibility/input-title.html

[Build Bot]

Created attachment 210483 [details]
Archive of layout-test-results from webkit-ews-14 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-14  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.4

[Samuel White]

Hmm. Not sure why this test was passing yesterday and failed today with zero changes. Is this a possible false positive? Did something major land that could have broken this Chris?

[chris fleizach]

not sure. i guess we should re-run locally and see if it repros. the fix seems pretty safe

[Samuel White]

(In reply to comment #14)
> not sure. i guess we should re-run locally and see if it repros. the fix seems pretty safe

At first glance it looks like http://trac.webkit.org/changeset/155022 may be causing these input elements to expose their title via help text.

[Samuel White]

Created attachment 210497 [details]
Patch.

As suspected, http://trac.webkit.org/changeset/155022 changed how we compute AXTitle and AXDescription. Attached is an updated patch that accounts for these changes. Thanks.

[WebKit Commit Bot]

Comment on attachment 210497 [details]
Patch.

Clearing flags on attachment: 210497

Committed r155078: <http://trac.webkit.org/changeset/155078>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Samuel White]

*** Bug 119695 has been marked as a duplicate of this bug. ***