1149787 - label incorrect for field

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[James Nurthen]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Build ID: 20150320201757

Steps to reproduce:

Look at the Accessible Name for the input field in the code below. 

<label title="The field &quot;User Name&quot; is mandatory." for="dialogTemplate-dialogForm-login-name1"><img src="/careersection/2014PRD.2.3.78.3.0/images/i_red_star.gif" title="The field &quot;User Name&quot; is mandatory." alt="">User Name<span class="hidden-audible"> This field is mandatory</span></label>
<input type="text"  maxlength="255" autocomplete="off" name="dialogTemplate-dialogForm-login-name1" id="dialogTemplate-dialogForm-login-name1">


Actual results:

The Accessible Name reported by the Accessibility API was

The field "User Name" is mandatory.User Name This field is mandatory


Expected results:

The Accessible Name should be
User Name This field is mandatory

Comment 1

[Marco Zehe (:MarcoZ)]

Alex, ideas?

Comment 2

[alexander :surkov (:asurkov)]

In this case input's name is computed from label's content, this is
1) img providing "This field User is mandatory" via @title
2) text node providing "User name"
3) text node of span providing "This field is mandatory"

So actual results seems correct. What does it make you to think otherwise?

Comment 3

[James Nurthen]

(In reply to alexander :surkov from comment #2)
> In this case input's name is computed from label's content, this is
> 1) img providing "This field User is mandatory" via @title

This is incorrect. The img has alt="". This should take preference over title. The Image should be marked as being decorative.

> 2) text node providing "User name"
> 3) text node of span providing "This field is mandatory"
> 
> So actual results seems correct. What does it make you to think otherwise?

Comment 4

[alexander :surkov (:asurkov)]

(In reply to James Nurthen from comment #3)
> (In reply to alexander :surkov from comment #2)
> > In this case input's name is computed from label's content, this is
> > 1) img providing "This field User is mandatory" via @title
> 
> This is incorrect. The img has alt="". This should take preference over
> title. The Image should be marked as being decorative.

I missed that @alt thing.

Comment 5

[alexander :surkov (:asurkov)]

reading further we have a comment:

// No accessible name but empty 'alt' attribute is present. If further name
// computation algorithm doesn't provide non empty name then it means
// an empty 'alt' attribute was used to indicate a decorative image (see
// Accessible::Name() method for details).

So atl="" doesn't affect on accessible name but it affects on how the image should be treated by screen reader if no name has been provided.

Do we have any spec wording on this?

Comment 6

[Marco Zehe (:MarcoZ)]

I am just cycling back to this, and see that there is contradictory information in the HTML Accessibility API Mapping spec. The name calculation for the img element clearly states that if no alt is there, title should be used. https://www.w3.org/TR/html-aam-1.0/#img-element-accessible-name-computation

However, the special case entry in the mapping table about img with an empty alt attribute says: "ARIA role presentational". This means the above acc name calculation should be read as follows:

1. If aria-labeledby ...
2. If not, use alt.
2.A if alt is not present, continue to 3.
2.b if alt is present and has an empty string, stop right here and mark as presentational.

However it does not explicitly say so, leaving a lot of room for interpretation and ambiguity.

Steve, how was this originally intended?

Comment 7

[steve faulkner]

> 2.b if alt is present and has an empty string, stop right here and mark as presentational.

Marco, yes this is the correct interpretation. 
I will file a bug on html-amm to make this less ambiguous.

Comment 8

[Marco Zehe (:MarcoZ)]

(In reply to steve faulkner from comment #7)
> > 2.b if alt is present and has an empty string, stop right here and mark as presentational.
> 
> Marco, yes this is the correct interpretation. 

Thanks for the confirmation, Steve!

> I will file a bug on html-amm to make this less ambiguous.

Fantastic!

Alex:
(In reply to alexander :surkov from comment #5)
> reading further we have a comment:
> 
> // No accessible name but empty 'alt' attribute is present. If further name
> // computation algorithm doesn't provide non empty name then it means
> // an empty 'alt' attribute was used to indicate a decorative image (see
> // Accessible::Name() method for details).
> 
> So atl="" doesn't affect on accessible name but it affects on how the image
> should be treated by screen reader if no name has been provided.

As we can see from above, this is no longer per spec. If we encounter an alt="", we must stop name calculation and treat the image accessible as if it had role="presentation" on it.

Comment 9

[alexander :surkov (:asurkov)]

revisiting the example, is the bug's point that HTML:img's name shouldn't be computed from connected HTML:label element, because HTML:img is not labellable per HTML spec?

Comment 10

[Marco Zehe (:MarcoZ)]

No. If you have 

<img alt="" title="Some title for whatever reason" />

The image should be treated as prsentational now. Right now, we fall back to using the title as acc name. As if there was <img title="some title" />. Instead, we should treat the image as presentational. Because alt="" specifically says "this is decorative".

And of course, img isn't labellable, so attaching a label element to it is invalid.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to Marco Zehe (:MarcoZ) from comment #10)
> No. If you have 
> 
> <img alt="" title="Some title for whatever reason" />
> 
> The image should be treated as prsentational now. Right now, we fall back to
> using the title as acc name. As if there was <img title="some title" />.
> Instead, we should treat the image as presentational. Because alt=""
> specifically says "this is decorative".

Aha, we have ten years old bug 429656, where we introduced the original behavior, which is opposite to what the spec says. Before making a change, I would like to double check the world has changed and empty @alt + @title is no longer an issue for the web nowadays. See old days Jamie's comment from the mentioned bug:

"Unfortunately, there are some web sites which explicitly set the alt attribute to an empty string but set the title to something useful. In these cases, the title is disregarded; nothing is exposed for either name or description. Despite the fact that this is bad design on the part of the web sites, it would be better if Gecko could expose the title as the name in cases where alt is explicitly an empty string but the title is specified."

> And of course, img isn't labellable, so attaching a label element to it is
> invalid.

It is a separate issue, I afraid with own roots as well. Btw, do we have any data what other browsers do? Does everyone but Firefox follows the spec?

Comment 12

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #11)
> Before making a change, I
> would like to double check the world has changed and empty @alt + @title is
> no longer an issue for the web nowadays.

Unfortunately, it seems I didn't include real world examples in bug 429656, so I'm honestly not sure. And I wouldn't necessarily know if it were happening in my daily usage without looking at the DOM/code for everything I use.

> Btw, do we have any
> data what other browsers do?

I checked Chrome. It follows the spec; i.e. it doesn't expose name as title in this case.

While we obviously don't want to "break the web" and we need to be pragmatic, where there is contention, I'd say go with the spec. If it turns out that this breaks things, we should get this sorted out in the spec.

Having said that, I still think we should expose the title as the description in this case. Previously (before bug 429656 was fixed), we just threw away the title altogether; it wasn't even exposed as description. This way, the AT at least has a chance of recovering from bad authoring to some extent. FWIW, Chrome *does* expose the title as description in this case.

Comment 13

[Marco Zehe (:MarcoZ)]

(In reply to James Teh [:Jamie] from comment #12)
> Having said that, I still think we should expose the title as the
> description in this case. Previously (before bug 429656 was fixed), we just
> threw away the title altogether; it wasn't even exposed as description. This
> way, the AT at least has a chance of recovering from bad authoring to some
> extent. FWIW, Chrome *does* expose the title as description in this case.

That would mean we wouldn't be following the spec. The spec says "treat as presentational", and to my understanding, this means: Don't expose that graphic in the a11y tree at all. Whereas for us to expose the description, we would have to create a graphic accessible with no name, and I can already see some ATs going after the SRC and exposing that, then.

Comment 14

[Marco Zehe (:MarcoZ)]

OK ignore me, Chrome and Firefox actually expose stuff similarly if no title is present, e. g. the name is explicitly "", not NONE. And the explicit-name is set to true, so that should help ATs get tis right if we expose title as description if name is "".

Comment 15

[James Teh [:Jamie]]

Yup, that's been the behaviour since forever, even before this title change. The spec doesn't quite reflect prior reality here.