Michael(tm) Smith wrote: > > Jerason Banes <[EMAIL PROTECTED]>, 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.
But that's precisely the problem: accesskey= *can't* be consistent and interoperable across UAs, or even across browsers, because browsers compete (amongst other things) on their user interfaces, and therefore they have different user interfaces, and therefore they conflict with different values of accesskey=. If that problem had a good solution, removing the attribute would not have been necessary. The specification could include an explicit statement of the form "UAs must ignore the accesskey= attribute", but any such statement would be in the yet-to-be-written "Rendering" section. >... > 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. >... Since most pages that contain links don't also use accesskey=, handset vendors should find a way to allow easy navigation of links regardless of whether the attribute is present. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
