Currently, Gecko often exposes the URL as the name of an image button, even if the alt or title attributes are provided. In addition, the value attribute takes precedence over the alt attribute. Str: 1. Open the attached test case. 2. Examine the accessible name of the button for "Just alt". Result (correct): The name is "alt". 3. Examine the accessible name of the button for "Just title". Expected: The name should be "title". Actual: The name is a URL. 4. Examine the accessible name of the button for "Alt with empty value". Expected: The name should be "alt". Actual: The name is a URL. 5. Examine the accessible name of the button for "Title with empty value". Expected: The name should be "title". Actual: The name is a URL. 6. Examine the accessible name of the button for "Alt and value". Expected: The name should be "alt". Actual: The name is "value". Note: This last case is arguable. I'd argue that alt is clearer as alternate text for an image. I suggest the following: 1. If alt is present and not empty, use alt. 2. If value is present and not empty, use value. 3. If title is present and not empty, use title. 4. Otherwise, the name should probably be empty and the src exposed as an attribute, rather than exposing the URL, similar to how this is handled for graphics. Otherwise, it isn't clear that an AT should resort to an algorithm for deriving a name from a URL, since it can't assume that the name is a URL. Test case in the wild: The "Add to cart" button on http://www.amazon.com/Philips-Shoqbox-Bluetooth-Portable-SB7200/dp/B007PZYBTY/ref=sr_1_3?ie=UTF8&qid=1340481237&sr=8-3&keywords=philips+shock+box Related NVDA issue tickets: http://www.nvda-project.org/ticket/2491 http://www.nvda-project.org/ticket/2601

I don't have strong opinion on this. So let's do what is reasonable. Historically we preferred @title over @src and @data attributes (see bug 287390) and at some point I believe we regressed. Can you please argue why @alt should preferred over @value and @src is preferable to expose as object attribute. Any thoughts about @data attribute? Should we keep the logic shared between input@type="button", @type="submit", @type="image" and button elements? cc'ing Steve.

(In reply to alexander :surkov from comment #1) > Can you please argue why @alt should preferred over @value I believe (but this is controversial) that most authors would be more familiar with @alt as alternate text for an image, as it is used for the <img> element. It's true that @value is the text for submit buttons, but @value has all sorts of different meanings for the input element depending on the @type. :) > and @src is > preferable to expose as object attribute. From my description: > 4. Otherwise, the name should probably be empty and the src exposed as an attribute, rather than exposing the URL, similar to how this is handled for graphics. Otherwise, it isn't clear that an AT should resort to an algorithm for deriving a name from a URL, since it can't assume that the name is a URL. > Any thoughts about @data > attribute? I don't know if it's useful, since it is entirely arbitrary. > Should we keep the logic shared between input@type="button", > @type="submit", @type="image" and button elements? type="button"/"submit" are a bit different because the alt attribute isn't valid there and they don't have an src. They're more like the <button> element containing only text.

traditionally and currently the alt has been the method prescribed to label an input type="image" the accessible name calculation suggested in the HTML to accessibility API guide [1] is: 1. Use aria-labelledby 2.Otherwise use aria-label 3.Otherwise use alt attribute 4.Otherwise use title attribute 5.If none of the above yield a usable text string there is no accessible name [1]http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#input-image

So input type=image (do the same as we do for img): a) name: alt attribute, then title (no value) b) src as object attribute input type=button, submit a) name: value, atl then title attribute (no src) we used to expose @data attribute for a while then we could continue to keep it. Sounds good?

1) use nsHTMLInputElement::FromContent and then nsIFormControl::GetType() to detect image button 2) change HTMLButtonAccessible::Name() (see comment #4 if it doesn't get objections) 3) add HTMLButtonAccessible::GetAttributesInternal similar to ImageAccessible.

(In reply to steve faulkner from comment #3) > 3.Otherwise use alt attribute > 4.Otherwise use title attribute > 5.If none of the above yield a usable text string there is no accessible name So the value attribute isn't used any more, even as a last resort? One HTML 4.0 reference I have suggests it should be, though it is obviously quite old. The argument for this is that type="submit" uses value. I still think alt should take precedence, though, and probably title as well (though I'm slightly less certain about that).

I think Steve's algorithm is applicable to input@type="image" only

(In reply to alexander :surkov from comment #7) > I think Steve's algorithm is applicable to input@type="image" only Right, but this reference notes that value is relevant for type="image" as well.

(In reply to James Teh [:Jamie] from comment #8) > (In reply to alexander :surkov from comment #7) > > I think Steve's algorithm is applicable to input@type="image" only > Right, but this reference notes that value is relevant for type="image" as > well. a link please? we could use it as a last resort to fix accessible name then.

(In reply to alexander :surkov from comment #9) > > Right, but this reference notes that value is relevant for type="image" as > > well. > a link please? we could use it as a last resort to fix accessible name then. Sorry; I didn't include a link in the first place because i wasn't sure I could find one, but here it is: http://htmlhelp.com/reference/html40/forms/input.html Here's the relevant paragraph: > The image input type specifies a graphical submit button. The SRC attribute must be included to specify the URI of the image. The ALT attribute should be used to give replacement text for those not loading images. ALT is a new addition in HTML 4.0; some browsers rely on either the NAME or VALUE attribute as alternate text, so authors should use all three attributes for the same purpose where possible. However, this is really old, is by no means a spec and was written to accommodate ancient text browsers, as explained here: http://htmlhelp.com/feature/art3c.htm

Hi, is it alright that i start working on this bug ? (first bug)

(In reply to me from comment #11) > Hi, is it alright that i start working on this bug ? (first bug) it depends on your (c++) skills, if steps from comment #5 looks more or less clear then go ahead.

Getting back to discussion. From user perspective: plain <input type="image"> gives a button texted "Submit query". If @alt attribute is provided then its value is used a button text. This makes input@type="image" special. Jamie, Steve do you agree that we should prefer the visible text over @title (@title should be used as description if provided)?

i think in Firefox case it makes sense as "Submit query" is the visible text. In IE for example, if no image is available it just shows the broken image icon and doesnot have an accessible name. Will update guide to suggest firefox behaviour.

thoughts on amended calculation? 1.Use aria-labelledby 2.Otherwise use aria-label 3.Otherwise use alt attribute 4.Otherwise the user agent may provide a default text string such as 'Submit Query' 5.Otherwise use title attribute 6.If none of the above yield a usable text string there is no accessible name

It works in Firefox case. What about Jamie's comment #10? Should we try @value attribute after @alt and before @title?

algorithm for input@type="image" 1.Use aria-labelledby 2.Otherwise use aria-label 3.Otherwise use alt attribute 4.Otherwise use value attribute 5.Otherwise the user agent may provide a default text string such as 'Submit Query' 6.Otherwise use title attribute 7.If none of the above yield a usable text string there is no accessible name note: 4th item is name calculation from value@ attribute. that was done for compatibility: Firefox gets visible label from @alt, from @value if no @alt and then default "Submit Query" text. algorithm for input@type="submit" and input@type="reset": 1.Use aria-labelledby 2.Otherwise use aria-label 3.Otherwise use value attribute 4.Otherwise the user agent may provide a default text string such as 'Submit Query' or 'Reset' 5.Otherwise use title attribute 6.If none of the above yield a usable text string there is no accessible name algorithm for input@type="button": 1.Use aria-labelledby 2.Otherwise use aria-label 3.Otherwise use value attribute 4.Otherwise use title attribute 5.If none of the above yield a usable text string there is no accessible name

fitting a tests

Comment on attachment 695466 [details] [diff] [review] patch2 >diff --git a/accessible/tests/mochitest/name/test_button.html b/accessible/tests/mochitest/name/test_button.html >deleted file mode 100644 >--- a/accessible/tests/mochitest/name/test_button.html >+++ /dev/null I think I'm fine with all the xml testing stuff, but I think I'd like to have simple testName() tests too since its less likely they're broken, and its easier to understand correct behavior from them.

Trev, ping?

(In reply to alexander :surkov from comment #21) > Trev, ping? did we ever decide something about only using xml tests?

(In reply to Trevor Saunders (:tbsaunde) from comment #22) > (In reply to alexander :surkov from comment #21) > > Trev, ping? > > did we ever decide something about only using xml tests? yeah we agreed xml tests are plain and nice and certainly it's worth to continue to use them in the future ;) seriously if you want them js-based then I can file a bug but I wouldn't change that now.

(In reply to alexander :surkov from comment #23) > (In reply to Trevor Saunders (:tbsaunde) from comment #22) > > (In reply to alexander :surkov from comment #21) > > > Trev, ping? > > > > did we ever decide something about only using xml tests? > > yeah we agreed xml tests are plain and nice and certainly it's worth to > continue to use them in the future ;) I still don't really like them, but I guess I'll live. > seriously if you want them js-based then I can file a bug but I wouldn't > change that now. up to you I'm not sure how much better it would be.

Comment on attachment 695466 [details] [diff] [review] patch2 >+ <rule attr="value" type="string" explict-name="false" reordered="true"/> explicit-name

Verified fixed in Firefox 23.0a1 (2013-05-07).

updated html api mapping guide to refelect above refer to bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=20446