xhtml - accesskey for select not allowed?

[Udo Marx]

Greets to ciwah!

I'm doing a little webproject for a local session event.
Tryin' to meet latest standards i failed to do this:
--snip--
<select name="fromcountry" accesskey="l" title="[Alt]+[l]">
<option value="dummy">dummy</option>
</select>
--snap--
W3C validator says: there is no attribute 'accesskey'
the url:
http://www.netzteil.com/session/test.html
I included the w3c-links for test.
Plz help me out, TIA.
--
Freundliche Gruesse,
Netzteil - Udo Marx
http://www.netzteil.com

[Jukka K. Korpela]

Udo Marx wrote:

Tryin' to meet latest standards
Why? They don't work on the WWW. XHTML works on IE only if you fake it
as classic HTML.
i failed to do this:
--snip--
<select name="fromcountry" accesskey="l" title="[Alt]+[l]">
<option value="dummy">dummy</option>
</select>
--snap--
Wrong approach. Country selection should _not_ be made with a dropdown,
unless you have just a handful of countries. Use a text input field, and
accept both country names and standard abbreviations.
W3C validator says: there is no attribute 'accesskey'

Because there is no such attribute defined for <select> in the DTD you use.

In practice, forget accesskeys. Most accessibility experts regard them
as useless or harmful. Besides, title="[Alt]+[l]" would be both useless
(you would see the "hint" only when you don't need it any more) and
misleading (you cannot possibly know how accesskeys are used in the
user's environment - there might be no Alt key to begin with).

[Roy Schestowitz]

__/ [Jukka K. Korpela] on Sunday 11 December 2005 11:11 \__

Udo Marx wrote:

Greets to ciwah!

I'm doing a little webproject for a local session event.
Tryin' to meet latest standards

Why? They don't work on the WWW. XHTML works on IE only if you fake it
as classic HTML.

i failed to do this:
--snip--
<select name="fromcountry" accesskey="l" title="[Alt]+[l]">
<option value="dummy">dummy</option>
</select>
--snap--

Wrong approach. Country selection should _not_ be made with a dropdown,
unless you have just a handful of countries. Use a text input field, and
accept both country names and standard abbreviations.

I must say that I disagree. Most folk are unaware of standard abbreviations.
Moreover, too much freedom as in an open string leaves room for ambiguity,
frustration and requires programming that provides a level of tolerance. The
whole thing can be hard to maintain. Even if you list all countries in the
world, the size of the form would not become far larger, maybe just 5 KB
(uncompressed).

W3C validator says: there is no attribute 'accesskey'

Because there is no such attribute defined for <select> in the DTD you use.

In practice, forget accesskeys. Most accessibility experts regard them
as useless or harmful. Besides, title="[Alt]+[l]" would be both useless
(you would see the "hint" only when you don't need it any more) and
misleading (you cannot possibly know how accesskeys are used in the
user's environment - there might be no Alt key to begin with).

I have seen cases where different accesskeys get assigned on different
platforms. This is a real PITA to maintain and test.

the url:
http://www.netzteil.com/session/test.html
I included the w3c-links for test.
Plz help me out, TIA.

Roy

--
Roy S. Schestowitz
http://Schestowitz.com | SuSE Linux | PGP-Key: 0x74572E8E
6:55am up 1 day 14:03, 18 users, load average: 1.14, 0.74, 0.59

[Jukka K. Korpela]

Roy Schestowitz wrote:

__/ [Jukka K. Korpela] on Sunday 11 December 2005 11:11 \__

Wrong approach. Country selection should _not_ be made with a dropdown,
unless you have just a handful of countries. Use a text input field, and
accept both country names and standard abbreviations.
I must say that I disagree.
Most folk are unaware of standard abbreviations.

Then they use the names, or they consult a list of abbreviations that
you link to.
Moreover, too much freedom as in an open string leaves room for ambiguity,
frustration and requires programming that provides a level of tolerance.
The purpose is to minimize users' problems, and this inevitably means
that the author needs to do some work, or to utilize other people's work.
Even if you list all countries in the
world, the size of the form would not become far larger, maybe just 5 KB
(uncompressed).
The problem is the size experienced by users when they see a hundred
names in a list that can be scrolled down in a window of 10 or so names.
And how does it work in speech-based user agents?
I have seen cases where different accesskeys get assigned on different
platforms. This is a real PITA to maintain and test.

Perhaps, but how does that relate to "accesskey attributes considered
harmful", which was the message in my text that you quoted? It's
pointless to discuss the details of something that should not be used at
all.

the url:
http://www.netzteil.com/session/test.html
I included the w3c-links for test.
Plz help me out, TIA.

What was your point in quoting that without saying anything about it?

[Chris Morris]

Roy Schestowitz <ne********@schestowitz.com> writes:

__/ [Jukka K. Korpela] on Sunday 11 December 2005 11:11 \__

Wrong approach. Country selection should _not_ be made with a dropdown,
unless you have just a handful of countries. Use a text input field, and
accept both country names and standard abbreviations.

I must say that I disagree. Most folk are unaware of standard abbreviations.
Moreover, too much freedom as in an open string leaves room for ambiguity,
frustration and requires programming that provides a level of tolerance. The
whole thing can be hard to maintain. Even if you list all countries in the
world, the size of the form would not become far larger, maybe just 5 KB
(uncompressed).

Hmm. I have a list of countries that is almost exactly
5KB. Unfortunately there's then an extra 7KB overhead from all the
<option> and </option> tags.

More importantly it's harder to use - many countries have multiple
overlapping names that could reasonably used in such a form (consider
England/United Kingdom/Great Britain) - do you include all of them, or
only one, etc. Additionally a 400-long <select> input is difficult to
use even if you know what you're looking for (harder with the mouse
than the keyboard).

With Burma/Myanmar, for example, the choice over which form to use (or
both) has capacity to offend people. Hide it behind a plain text
<input> and silently accept both behind the scenes, and no-one takes
offence.

My preferred solution is not to include a country field at all - just
have a <textarea> address field and leave it at that. In the case
where some other piece of software needs the country explicitly
identified, our solution is to:
1) use <input type="text" ...>

2) if it's not in the list of allowed countries when the form is
submitted, return an error

3) When returning the error and giving the user another go at the
form, we give an option to immediately select the five countries a
combination of soundex and levenshtein has given as 'most likely' to
be what they meant from their previous input, or to try typing in
again.

It's not perfect, and the addition of some more alternative names,
common abbreviations, etc. would be useful, but we don't tend to get
complaints about that bit going wrong.

--
Chris

[Lachlan Hunt]

Jukka K. Korpela wrote:

Udo Marx wrote:

Tryin' to meet latest standards

Why? They don't work on the WWW. XHTML works on IE only if you fake it
as classic HTML.

i failed to do this:
--snip--
<select name="fromcountry" accesskey="l" title="[Alt]+[l]">
<option value="dummy">dummy</option>
</select>
--snap--

Wrong approach. Country selection should _not_ be made with a dropdown,
unless you have just a handful of countries. Use a text input field, and
accept both country names and standard abbreviations.

Why not? Ideally, I think both a list and text box should be provided
so the user may select their country if it's in the list or enter their
own in the text box if it's not. I'll admit the UI for selecting from
select lists isn't ideal in all UAs, but good ones allow the user to
type the first few letters and the first match will be selected. As
long as the options are in alphabetical order, this makes it fairly easy
to find the item they're looking for.

The best UI, however, may be to provide combo box where the user starts
typing and they're presented with a list of closest matches, much like
the way Google Suggest works. This could be implemented using
javascript to transform the text box/select list into the custom
control. Alternatively, if it ever gets standardised and implemented,
make use of the <datalist> element from the WHATWG's proposed HTML5
extensions which is intended to do exactly that.

W3C validator says: there is no attribute 'accesskey'

You can use the accesskey attribute on the list's associated label
element, but as Jukka pointed out, it's best to avoid them.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[Chris Morris]

Lachlan Hunt <sp***********@gmail.com> writes:

[...<select>, country lists, etc...]
The best UI, however, may be to provide combo box where the user
starts typing and they're presented with a list of closest matches,
much like the way Google Suggest works. This could be implemented
using javascript to transform the text box/select list into the custom
control. Alternatively, if it ever gets standardised and implemented,
make use of the <datalist> element from the WHATWG's proposed HTML5
extensions which is intended to do exactly that.

It occurs to me that the easiest way to implement combo boxes in HTML
would be for the browser developers to say that <select> (not
multiple) will use a combo box method - you can still select, as you
type the possible selection gets narrowed down, and you can send
something different if you want (which the server-side process should
deal with appropriately *anyway*).

The disadvantage is that it would imply you could enter user-supplied
values in situations where either:
- you can't, and that's user-unfriendly
- you can, and the server-side process incorrectly accepts it
Exposing the latter isn't really a problem, but the former is.

Nevertheless, an extra attribute on <select> would seem more
appropriate than an entire new element to do substantially the same
thing. Either way browser support will need to catch up before it
works for users, but with <select> most of the options are still
available.

--
Chris

[Udo Marx]

Lachlan Hunt <sp***********@gmail.com>:

W3C validator says: there is no attribute 'accesskey'

You can use the accesskey attribute on the list's associated label
element, but as Jukka pointed out, it's best to avoid them.

What a nice and vivid discussion =:-)
my point was not select or not,
but the missing of accesskey to select-elements.
THX to Lachlan.
--
Freundliche Gruesse,
Netzteil - Udo Marx
http://www.netzteil.com

[Dr John Stockton]

JRS: In article <87************@dinopsis.dur.ac.uk>, dated Mon, 12 Dec
2005 12:54:41 local, seen in news:comp.infosystems.www.authoring.html,
Chris Morris <c.********@durham.ac.uk> posted :

More importantly it's harder to use - many countries have multiple
overlapping names that could reasonably used in such a form (consider
England/United Kingdom/Great Britain)

Not a good example - they have definite and distinct meanings.

England is the part south of Scotland and east of Wales.

The United Kingdom (of GB & NI) is the Realm, ruled by HM & TB.

Great Britain is the Big Island, and the little ones nearby, but not the
Isle of Man, the island Ireland, or the Channel Islands.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

[Chris Morris]

Dr John Stockton <jr*@merlyn.demon.co.uk> writes:

JRS: In article <87************@dinopsis.dur.ac.uk>, dated Mon, 12 Dec
2005 12:54:41 local, seen in news:comp.infosystems.www.authoring.html,
Chris Morris <c.********@durham.ac.uk> posted :

More importantly it's harder to use - many countries have multiple
overlapping names that could reasonably used in such a form (consider
England/United Kingdom/Great Britain)

Not a good example - they have definite and distinct meanings.

That was my point - they are distinct regions that people can identify
as coming from (or indeed all three) and a form designer needs to
include all three if they use a drop-down to avoid people looking for
the "wrong" one. This then has scope to worry people in England as to
the difference between picking England and picking GB.

So, it's easier not to use a drop-down.

--
Chris