Re: Dropping <input usemap="">

Jason White wrote:
> There is (apparently unpublished) research purportedly showing that it 
> is widely misused,

Unpublished?  These results have been mentioned several times, why are 
you choosing to ignore them?  Feel free to inspect these 345 example 
pages yourself.

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-August/012334.html

The results not only indicated misuse, but for those that don't break, 
it indicated a lack of use cases which couldn't be addressed using <img> 
instead or some other alternative.  See below for my detailed analysis 
of the pages.

Robert Burns wrote:
> On Aug 14, 2007, at 10:02 PM, Jason White wrote:
>> There is a significant accessibility problem associated with the 
>> proposal to drop USEMAP on INPUT, namely that if an author desires 
>> to use an image map as a form input field, the only alternative 
>> would then be to apply @ismap (a server-side image map).

Perhaps, but the big question is *WHY* would an author want to use an 
image map as a form control?  What are the real use cases you are trying 
to address?

>> Server-side image maps present an accessibility obstacle to those who are
>> unable to operate a pointing device. This is why client-side image 
>> maps are preferred and ought to be encouraged, and why @alt is defined 
>> for <area>.

That's true, but that doesn't address the lack of use cases that cannot 
be addressed using <img usemap> or other alternatives.

>> The proposal to omit @usemap on <input> would eliminate the accessible 
>> solution, whilst leaving the inaccessible option of a server-side 
>> image map intact.

Solution to what, exactly?  Without a use case, the accessibility 
problem you've presented is non-existent.

> I agree with Jason 1005. I'd like to add that @usemap on INPUT is really 
> the same thing as @usemap on IMG. Its the same feature supported in a 
> polymorphic manner.

Why is it useful to do <input usemap> instead of <img usemap>?

> It may  not have been implemented correctly in UAs, 
> however that can be dealt with by filing bug reports. The fact that it's 
> not correctly implemented in UAs may also point to the reason and the 
> solution to why it has not been widely used by authors.

That may be one reason.  The other is the *lack of convincing use cases!*

> If we're going to support @usemap on IMG (and I think we should) then we 
> should also support @usemap on INPUT. I often surprised at the lack of 
> imagination here, but an obvious use-case for this would be to submit 
> form data based on where a user clicks on the INPUT image. This could be 
> used in games, it could be used to provide GUI selection of items, it 
> could be used in all sorts of ways (if it were implemented correctly).

Hypothetical use cases like that are useful for determining what to look 
for, but are not strong enough on their own to support your case.  You 
need to provide evidence of such use cases and clearly demonstrate why 
usemap on input is a better solution than usemap on img or any other 
alternative solution.

These are the kinds of possibilities you could look for.

* Sites that use <input usemap> for legitimate use cases.

* Sites that use regular image maps that, when clicked, cause a form to 
be submitted using JavaScript.  This could include cases using either 
usemap or ismap.

* Sites that use image slices to construct a pseudo-image map for 
multiple input controls, each of which perform a different function.

There may be some other things you could look for as well.  This is a 
good example for how Paving the Cowpaths works.  You don't necessarily 
need to find the exact solution in use, just sites that demonstrate the 
use cases.

However, the presence of such sites alone doesn't necessarily support 
your case, since you would still need to explain why usemap on input 
would be the superior solution to any other, taking into consideration 
the existing solutions being used and other possible solutions.

And also, you have explain why the use cases are significant enough to 
bother spending time on, and for UAs to bother implementing.  This is 
related to the proposed Baby Steps principle that Hixie added to the 
wiki.  In other words, it's sort of like a cost/benefit analysis to 
justify it.


*Analysis of Results*

This is the analysis of the research Hixie performed earlier.  I 
manually inspected the first 50 results in the list.  I have not 
personally inspected the rest yet, as it was very time consuming. 
Please feel free to continue, although I expect much more of the same 
results.

These are the pages I found which don't in UAs that support usemap on 
input, but each one has other alternative solutions available.

This set use image maps to turn the input buttons into links.  They do 
not use forms and so the input controls themselves are useless. 
Therefore, none of them demonstrate use cases for usemap on input. 
These sites do break in browsers that don't support usemap on input, 
like IE, but all of them would be solved by using either <a 
href=""><img></a> or <img usemap>

* http://darrylo.com/web_promotion.htm
* http://dvs.si/
* http://ezbizz.com/site/
* http://hammitup.com/
* http://intenseactionkrew.com/
* http://livevibesrecording.com/pages/purchase.html
* http://newenglandlighting.com/newpages/new.html
* http://planetabuba.net/secciones/galeria/buba/bgal.html
* https://publish.insightbb.com/html-jsp/publish/Wsb/index.php

These sites use image maps on input controls with forms, and use the 
image maps to turn some areas into hyperlinks.  These would be solved by 
using separate input elements an links for each appropriate section.

* http://greatvision.org/

These sites also use a map intended to turn some areas into hyperlinks, 
however none of the ares actually cover the image itself since it's too 
small.  Thus its presence doesn't break anything, but nor does it serve 
any purpose.  In some cases, the image map is complete useless or is 
actually used for other images on the page, and the usemap on the input 
is a mistake.

* http://hiddenvalleymuskoka.com/dinner.html
* http://lifelong.kookmin.ac.kr/login.asp

These sites use areas with javascript links that submit the forms.  In 
each case, the image maps itself is useless.  They only require the 
input controls and appropriate event handlers.

* http://est.yescall.com/company/
* http://bvba2.bib-bvb.de/V?RN=411217204
* http://linkcommand.com/index.php
* http://paydayloantoday.com/
* http://piperenterprisesinc.com/
* http://shop.divebooty.co.uk/

The rest of the sites that weren't listed are the ones that break to 
some degree in browsers that support usemap on input.  (i.e. there may 
be workarounds that users can use, such as clicking out side the the 
areas covered by the image map or pressing enter within a text field, 
but such workarounds don't fix the problem)

There are 2 sites which come close to being valid use cases:

* http://www.wheresmysquare.com/

That one would actually be solved equally well by using a combination of 
usemap and ismap on an img element.  The only purpose of the form is to 
submit the cordinates where the user clicks, which is exactly what you 
get with <img ismap>.  I suspect it has been implemented using input in 
this case because img with usemap and ismap only functions sanely in 
Firefox.  Other browsers either only make use of the server side map, or 
the client side map, but not both.

There are also alternative solutions that could be used, which have been 
used on numerous similar sites.

http://www.milliondollarhomepage.com/
http://freeblogpixel.anthonet.com/
http://www.2millionpixels.com/

(The first 2 use a regular image map, the latter seems to use some 
JavaScript implementation for more interactive features.)

Since both ismap and usemap are still in the spec, the spec will need to 
explicitly define how to handle cases where both are used together. 
This will need more research to determine how that can be defined 
without breaking content.

* http://realestate.bannisterdesign.com/grostick.com/search.php

This attempts the use the areas to label the locations using tooltips. 
However, it actually functions better in browsers that don't support 
usemap on input because when one clicks on an <area>, it uses JavaScript 
to submit the form.  But the coordinates are then not sent to the 
server.  In IE, the coordinates do get sent, and so the results are 
localised to the area selected on the map.

The areas provide no accessibility benefits whatsoever in this case.  In 
fact, it's not entirely clear how they would.  Are you expecting that 
activating an area would submit its coordinates?  That's not how it 
appears to work in implementations.  So, if you can find some really 
convincing use cases, you would have to explain how it could be 
implemented in a way that actually provides the purported accessibility 
benefits.

Even if those problems can be solved, I just can't see how to justify 
the cost of fixing the <input usemap> for the extremely limited benefit 
of a single, obscure use case that currently works better without it.

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Wednesday, 15 August 2007 09:36:39 UTC