Sort out name calculation for HTML input buttons

VERIFIED FIXED in mozilla21

Status

()

Core
Disability Access APIs
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: Jamie, Assigned: surkov)

Tracking

(Blocks: 1 bug)

Trunk
mozilla21
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 655889 [details]
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
(Assignee)

Updated

5 years ago
Blocks: 459353
(Assignee)

Comment 1

5 years ago
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.
(Reporter)

Comment 2

5 years ago
(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

5 years ago
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
(Assignee)

Comment 4

5 years ago
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?
(Assignee)

Comment 5

5 years ago
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.
Whiteboard: [mentor=surkov.alexander@gmail.com][lang=c++]
(Reporter)

Comment 6

5 years ago
(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).
(Assignee)

Comment 7

5 years ago
I think Steve's algorithm is applicable to input@type="image" only
(Reporter)

Comment 8

5 years ago
(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.
(Assignee)

Comment 9

5 years ago
(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.
(Reporter)

Comment 10

5 years ago
(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

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

Comment 12

5 years ago
(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.
(Assignee)

Comment 13

5 years ago
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

5 years ago
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

5 years ago
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
(Assignee)

Comment 16

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

Updated

5 years ago
Summary: Alt and title should always take precedence as image button label → Sort out name calculation for HTML input buttons
Whiteboard: [mentor=surkov.alexander@gmail.com][lang=c++]
(Assignee)

Comment 17

5 years ago
Created attachment 694784 [details] [diff] [review]
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
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #694784 - Flags: review?(trev.saunders)
(Assignee)

Updated

5 years ago
Duplicate of this bug: 562662
(Assignee)

Comment 19

5 years ago
Created attachment 695466 [details] [diff] [review]
patch2

fitting a tests
Attachment #694784 - Attachment is obsolete: true
Attachment #694784 - Flags: review?(trev.saunders)
Attachment #695466 - Flags: review?(trev.saunders)
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.
(Assignee)

Comment 21

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

did we ever decide something about only using xml tests?
(Assignee)

Comment 23

5 years ago
(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
Attachment #695466 - Flags: review?(trev.saunders) → review+
(Assignee)

Comment 26

5 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/6472bf8f484b
Flags: in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/6472bf8f484b
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
(Reporter)

Comment 28

4 years ago
Verified fixed in Firefox 23.0a1 (2013-05-07).
Status: RESOLVED → VERIFIED

Comment 29

4 years ago
updated html api mapping guide to refelect above refer to bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=20446
You need to log in before you can comment on or make changes to this bug.