<20080126075954.GU18827@sideshowbarker>
Current votes: None.
--7mIJwGTFTwAlEXlA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jerason Banes <jbanes@gmail.com>, 2008-01-25 23:41 -0600: > Long story short, accesskeys were an idea that worked better on paper than > they did in practice. They inevitably interfered with normal browser > operation as well as other accessibility features in such a way as to * > reduce* the accessibility of many web pages. Another long story short: accesskey mark is already in use in a significant amount of existing content, so leaving it unspec'ed for implementors does not seem like a practical option -- not if we care about trying to ensure that behavior of that content is consistent/ interoperable across UAs. To elaborate a bit: A class of content in which accesskey markup is in particularly wide and effective use (effective as far as its content providers and users of it are concerned) is content intended for viewing, as one of its possible delivery contexts, on mobile handsets. Most handsets don't have keyboards or real pointing devices that let you quickly point and click on links; instead they just have numeric keypads and "5-way" directional pads that are basically the equivalent of arrow keys plus an enter key/mouse button. In the context of delivering content to those devices, it's useful to provide numbered access keys for quick access to certain links on a page -- to save users the time and trouble of needing to use the 5-way on the handset to scroll to the links and activate them. And that's why there's a large body of existing content that has accesskey markup: sites that takes browsing from mobile handsets into consideration as one of their possible delivery contexts. > The intended replacement is the XHTML Role Access > Module<http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolem= odule>. I think it might be more accurate to say that's one proposal for providing a better means to meet the same requirement that accesskey was originally intended to meet. > A few links on the subject: >=20 > http://www.cs.tut.fi/~jkorpela/forms/accesskey.html >=20 > The original version of this document had a much more positive attitude to > > the accesskey attribute. Experience and analysis has shown, however, th= at > > the idea of author-defined shortcuts is generally not useful on the Web. I guess this is a case where anybody making that assessment might need a little more experience -- and need to do a little more analysis that involves looking at the existing content I mentioned above. The use case of accesskey for Accessibility considerations (targeted to improve accessibility of content intended in the context of using it from a computer that has a full keyboard or equivalent) is not the only use case it should be judged on. Whether it's turned out that accesskey markup has failed to be effective for that use case is something that doesn't really matter. Because it's clearly not the only case for which it has come into use in existing content. And even if we make the determination that HTML5 will ultimately not make the accesskey conformant for authoring, we would still need to have it spec'ed for implementors in HTML5 if we want the existing content that already uses to remain usable/interoperable. [quoting Jukka] > > Unfortunately, browser support to the attribute is limited, and rather > > primitive. Not true now since many/most browsers on mobile handsets support it (and note that Jukka says on that page that he wrote that part a long time ago). [quoting Jukka] > > The accesskey attribute tends to mask out the functionality of > > a browser's predefined keyboard control, which is often much more impor= tant > > than page-specific access keys. Whether for a particular site the access keys provided by site or the browser's predefined keys are more important is something for users of that site to decide. What's needed is for browsers to be made smarter so that they can provide a way for users to be able to access both. [quoting Jukka] > > Moreover, browsers do not indicate that access keys are > > available. That doesn't matter for the case of numbered access keys in the class of content I've mentioned. Because those sites don't expect the browser to indicate that access keys are available. Instead, they put a numbered image inline next to each link that has a numbered access key. There are of course other ways that a browser can make access keys discoverable. As far as desktop browsers, Konqueror does it by displaying tooltip-like popups next to the links when you press and release the Control key (without pressing any other key in combination with it). Anyway, all that said, I'm not a fanboy for accesskey. I think in hindsight it's clear to all of us now that it should probably have been better thought out before it got spec'ed originally and put into a standard. But then so should have a lot of other things. The general problem we face with that what-we-now-see-as-bad-legacy markup now is that because it did make it into a standard and authors and content providers ended up using it in their content, we are stuck with figuring out a way to spec that markup -- that is, if we want users to be able to access that content without breaking how the content providers using it are expecting that markup to work in browsers. --Mike --=20 Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ --7mIJwGTFTwAlEXlA Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIuQYJKoZIhvcNAQcCoIIIqjCCCKYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BjAwggLpMIICUqADAgECAhBdFwgAZc4B5Ol2lzmSVl4xMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAxMDkwNjA0 NTVaFw0wOTAxMDgwNjA0NTVaMFYxDjAMBgNVBAQTBVNtaXRoMRAwDgYDVQQqEwdNaWNoYWVs MRYwFAYDVQQDEw1NaWNoYWVsIFNtaXRoMRowGAYJKoZIhvcNAQkBFgttaWtlQHczLm9yZzCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGtwItgkmRxAVKby78mnX9+hFgkHVut tDlWvbhBg3TmGfe74PwfMAuHmhOf/OqqffMr7a4uwfhMUJYo2f05JZPjJdJaIo1sVHtrTDU2 D/g480FzxFEGqAMAYvEniy4vUKDD/HHcZuUtmzDHKoHIWmZu0O9moiEXa4CRrpi23Sdr64Bt KYMUKt+rjdQW999qvPXIM6BeanXKm/3Uh+JMk8czR1wL0qooMMeTAndr1+Z0OrUNjRXSvmTu RARmdHGe9b7bqUblsfEHqr22cK5YMZ5nrfPRITt/RUfg2lSrPKoVmgqZa4qOErFuxS2CQ40b 5XPv7IqylGQL/LUet0iGRgECAwEAAaMoMCYwFgYDVR0RBA8wDYELbWlrZUB3My5vcmcwDAYD VR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAhVW69qYOxsmrAkY0LdS/MgsvFF+k+t+hE vh3qMUhmJ9yHhKOd+7kQtunbmwGXTAQv8itCvRQQq6rE9tcT0CkaZJeScsvu0soLUt1mmGv6 +CbJUfdah6OQcIqT1LmX+HgJ+pl6HW7+AXDC0jLi2MF7t3THyTMP9JrrhtIzF2T8ADCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTla MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0D viv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTAS BgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREE IjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEA SIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggJRMIICTQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQXRcIAGXOAeTpdpc5klZeMTAJBgUrDgMCGgUA oIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDEyNjA3 NTk1NFowIwYJKoZIhvcNAQkEMRYEFBFX8qQ6avhgoU6c4rx2ZGivT811MFIGCSqGSIb3DQEJ DzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAEELUhRJYOIdgFweKjWW73hk B1Uz/7tD+wAlAJFCbFkYqVAFfg6iX2QNvIq9Q7NRxjAjDr6sQTR+NwLFuMKFfdVAkw2wunIR 0aAApEvrBCTx8n/+B6SbpAEghIH+8PcqegoIPi85H/maCw6HdIMjI08QIQiEYwwG2BSLsQBN 6V6/Aqz9Ng0VOR0z+6eJdRIcou40421551gutTEvA2zttb7hqOql5nj4pSpUORO7RA/oXg2y M5W1HVPzS0v8mIvnOS9kgvo701hbrRF5r4bIWSepqX7ZGsscP26dJqunnxsOWDVGXB8Fz7ni gFDfcbqpCu8++W5KfXHKcqIKtLvCeG4= --7mIJwGTFTwAlEXlA--