Do not return an AXValue for buttons to match Safari....

chrome/browser/accessibility/browser_accessibility_cocoa.mm

Index: chrome/browser/accessibility/browser_accessibility_cocoa.mm
===================================================================
--- chrome/browser/accessibility/browser_accessibility_cocoa.mm	(revision 66823)
+++ chrome/browser/accessibility/browser_accessibility_cocoa.mm	(working copy)
@@ -210,6 +210,9 @@
         WebAccessibility::ATTR_HELP);
   }
   if ([attribute isEqualToString:NSAccessibilityValueAttribute]) {
+    // Webcore uses an attachmentView to get the below behavior.

[Chris Guillory, 2010/11/29 22:38:44]

Nit: Capitalize the 'C' in WebCore (since the 'W' is capitalized).

+    // We do not have any native views backing this object, so need
+    // to approximate Cocoa ax behavior best as we can.
     if ([self role] == @"AXHeading") {
       NSString* headingLevel =
           NSStringForWebAccessibilityAttribute(
@@ -222,6 +225,9 @@
     } else if ([self role] == NSAccessibilityCheckBoxRole) {
       return [NSNumber numberWithInt:GetState(
           browserAccessibility_, WebAccessibility::STATE_CHECKED) ? 1 : 0];
+    } else if ([self role] == NSAccessibilityButtonRole) {
+      // Does not make sense for pure buttons.

[Chris Guillory, 2010/11/29 22:38:44]

What does not make sense for pure buttons? AXValue? Can we add that to the
comment?

+      return @"";
     } else {
       return base::SysUTF16ToNSString(browserAccessibility_->value());
     }