562662 - Don't use (input type=image)'s src as accessible name when description is available.

Status: RESOLVED DUPLICATE of bug 786163

(Core :: Disability Access APIs, defect)

Description

[David Bolter [:davidb] (NeedInfo me for attention)]

I'm not sure about this. Let's discuss.

http://www.paciellogroup.com/blog/aria-tests/aria-labelledby-input.html

The idea is to leave the name blank so that AT will default to the description which is generally nicer Ux.

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Actually I don't see where we expose the src as the name (in trunk).

Comment 2

[steve faulkner]

(In reply to comment #1)
> Actually I don't see where we expose the src as the name (in trunk).

note this occurs on <input type="image"> not on <img>

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #2)
> (In reply to comment #1)
> > Actually I don't see where we expose the src as the name (in trunk).
> 
> note this occurs on <input type="image"> not on <img>

Aha! Thanks Steve.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

So yeah I see we care about src in nsHTMLButtonAccessible::GetNameInternal. Is that correct I wonder?

My archeological dig found it was added on Bug 290344.

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/accessible/src/html&command=DIFF_FRAMESET&file=nsHTMLFormControlAccessible.cpp&rev2=1.61&rev1=1.60

Marco, do you know of form controls users might want the src exposed as the name?

Comment 5

[Marco Zehe (:MarcoZ)]

(In reply to comment #4)
> Marco, do you know of form controls users might want the src exposed as the
> name?

I believe the src is always the last fall-back, if things like alt or the like fail/aren't available. And the accName is what gets rendered in the virtual buffer.

So if src is left blank, and there is only an accDescription via aria-describedby, that will never end up in the virtual buffer in the place where the actual button is. The braille display will stay blank, the speech synth will only say "button". Moreover, the accDescription is only spoken by ATs once the element gains focus, not while browsing the virtual buffer.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #5)
> (In reply to comment #4)
> > Marco, do you know of form controls users might want the src exposed as the
> > name?
> 
> I believe the src is always the last fall-back, if things like alt or the like
> fail/aren't available. And the accName is what gets rendered in the virtual
> buffer.
> 
> So if src is left blank, and there is only an accDescription via
> aria-describedby, that will never end up in the virtual buffer in the place
> where the actual button is. The braille display will stay blank, the speech
> synth will only say "button". Moreover, the accDescription is only spoken by
> ATs once the element gains focus, not while browsing the virtual buffer.


Why don't Ats expose the accDescription in the virtual buffer if the name is blank?

Comment 7

[Marco Zehe (:MarcoZ)]

(In reply to comment #6)
> Why don't Ats expose the accDescription in the virtual buffer if the name is
> blank?

I believe thus far, there is no situation where there is an accDescription but no or an empty accName. AccDescription isn't meant to replace accName, but augment it.

Comment 8

[alexander :surkov (:asurkov)]

Do we create button accessible for input@type="image"? Should we create image accessible instead?

Comment 9

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #7)
> (In reply to comment #6)
> > Why don't Ats expose the accDescription in the virtual buffer if the name is
> > blank?
> 
> I believe thus far, there is no situation where there is an accDescription but
> no or an empty accName.

Right, at least with FF.

> AccDescription isn't meant to replace accName, but
> augment it.

Agreed.

(In reply to comment #8)
> Do we create button accessible for input@type="image"? Should we create image
> accessible instead?

I wondered that to. I don't think so.

Comment 10

[alexander :surkov (:asurkov)]

Will be fixed by more generic bug 786163.