786163 - Sort out name calculation for HTML input buttons

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

Attachment: Test case.

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

Comment 1

[alexander :surkov (:asurkov)]

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.

Comment 2

[James Teh [:Jamie]]

(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.

Comment 3

[steve faulkner]

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

Comment 4

[alexander :surkov (:asurkov)]

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?

Comment 5

[alexander :surkov (:asurkov)]

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.

Comment 6

[James Teh [:Jamie]]

(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).

Comment 7

[alexander :surkov (:asurkov)]

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

Comment 8

[James Teh [:Jamie]]

(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.

Comment 9

[alexander :surkov (:asurkov)]

(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.

Comment 10

[James Teh [:Jamie]]

(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

Comment 11

[me]

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

Comment 12

[alexander :surkov (:asurkov)]

(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.

Comment 13

[alexander :surkov (:asurkov)]

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)?

Comment 14

[steve faulkner]

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.

Comment 15

[steve faulkner]

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

Comment 16

[alexander :surkov (:asurkov)]

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

Comment 17

[alexander :surkov (:asurkov)]

Attachment: patch

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

Comment 19

[alexander :surkov (:asurkov)]

Attachment: patch2

fitting a tests

Comment 20

[Trevor Saunders (:tbsaunde)]

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.

Comment 21

[alexander :surkov (:asurkov)]

Trev, ping?

Comment 22

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #21)
> Trev, ping?

did we ever decide something about only using xml tests?

Comment 23

[alexander :surkov (:asurkov)]

(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.

Comment 24

[Trevor Saunders (:tbsaunde)]

(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 25

[Trevor Saunders (:tbsaunde)]

Comment on attachment 695466 [details] [diff] [review]
patch2

>+      <rule attr="value" type="string" explict-name="false" reordered="true"/>

explicit-name

Comment 26

[alexander :surkov (:asurkov)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/6472bf8f484b

Comment 27

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/6472bf8f484b

Comment 28

[James Teh [:Jamie]]

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

Comment 29

[steve faulkner]

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