-
Notifications
You must be signed in to change notification settings - Fork 2
/
index.src.html
320 lines (242 loc) · 27.7 KB
/
index.src.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
<!DOCTYPE html>
<html>
<head>
<title>Accesskey replacement proposal</title>
<meta charset='utf-8'>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
async class='remove'></script>
<script class='remove'>
var respecConfig = {
noTOC: "true",
// specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
specStatus: "unofficial",
// the specification's short name, as in http://www.w3.org/TR/short-name/
// shortName: "xxx-xxx",
// if you wish the publication date to be other than the last modification, set this
// publishDate: "2009-08-06",
// if the specification's copyright date is a range of years, specify
// the start date here:
// copyrightStart: "2005"
// previousPublishDate: "1977-03-15",
// previousMaturity: "WD",
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "http://chaals.github.io/accesskey/index.src.html",
// editors, add as many as you like
// only "name" is required
editors: [
{
name: "Chaals"
// , url: "http://yandex.com/"
// , mailto: "[email protected]"
, company: "Yandex / Яндекс"
, companyURL: "http://yandex.com/"
},
],
// name of the WG
wg: "In Charge Of This Document Working Group",
// URI of the public WG page
wgURI: "http://example.org/really-cool-wg",
// name (without the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-html-a11y",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "",
// !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
};
</script>
</head>
<body>
<section id='abstract'>
<p>This document proposes a replacement specification of the HTML accesskey attribute, to improve the possibilities for Web applications that want user interaction to trigger functionality.</p>
</section>
<section id='sotd'>
<p>This is a draft proposal to replace the "accesskey" section of the W3C's HTML specification. in order to . It is <a href="http://discourse.wicg.io/t/user-interaction-with-web-apps/1177/">under discussion in the Web Incubator Community Group</a> for adoption as a proposed change to the HTML specification. The topic has also been <a href="http://www.w3.org/WAI/PF/HTML/wiki/Keyboard">discussed in the HTML accessibility Task Force</a></p>
<p><a href="http://github.com/chaals/accesskey/issues">Issues for this document</a> are tracked on github, and anyone should feel welcome to raise issues there. The repository also includes <a href="http://chaals.github.io/accesskey/tests/">test cases and result information</a>. Direct proposals for change in the form of Pull Requests are welcome, preferably with reference to an issue that explains the change, unless it is something simple like a typo.</p>
</section>
<section id="TOC">
<h2>Contents</h2>
<ul>
<li><a href="#sotd">Status of this document</a></li>
<li><a href="#why">Extension rationale</a></li>
<li><a href="#proposal">Proposed replacement of current HTML 5 specification</a><ul>
<li><a href="#assigning-keyboard-shortcuts">5.5 Assigning Keyboard Shortcuts</a>
<ul>
<li><a href="#introduction-9">5.5.1 Introduction</a></li>
<li><a href="#the-accesskey-attribute">5.5.2 The <dfn><code>accesskey</code></dfn> attribute</a></li>
<li><a href="processing-model-7">5.5.3 Processing model</a></li>
</ul></li>
</ul></li>
<li><a href="#changes">Changes from the HTML5 definition</a></li>
<li><a href="#acknowledgements">Acknowledgements</a></li>
</ul>
</section>
<section id="why"><h2>Rationale for this extension</h2>
<p>The <a href="http://www.w3.org/TR/html5/editing.html#the-accesskey-attribute">definition of <code>accesskey</code> in HTML5</a> is a clear improvement on the <a href="http://www.w3.org/TR/1998/REC-html40-19980424/interact/forms.html#adef-accesskey">HTML 4 </code>accesskey</code> definition</a>, for example allowing for multiple keys to cope with different user environments. However, there are still a number of problems:</p>
<dl>
<dt>Implementation</dt>
<dd>Few browsers, given a value for the attribute that is larger than a single character, assign any shortcut activation at all. Few if any assign one in the case where multiple characters are used. Only Firefox implements the DOM <code>accessKeyLabel</code> attribute, and that implementation is both fragile and not according to the HTML5 specification.</dd>
<dt>Javascript shortcuts break user expectations</dt>
<dd>Because implementation of <code>accesskey</code> in browsers has been of poor quality, for many years the most common approach to providing shortcuts has been to use javascript to trap user Interface events. This is <em>worse</em> than the problem it attempts to resolve:
<ul>
<li>it interferes with normal user agent behaviour, unpleasantly surprising some users</li>
<li>there is no discoverability mechanism for javascript-based activations. This is a particular problem when combining javascript libraries and/or browser extensions</li>
</ul>Improving <code>accesskey</code> to the extent that it can easily replace the benefits of the javascript approach, while mitigating its drawbacks, is a major motivation for this extension.</dd>
<dt>Conflict resolution</dt>
<dd>The current specification allows the User Agent to determine "what keys are available", from the author's suggested values for accesskey. However, its algorithm is too limiting, failing to take into account the point that the "first available key" may not be the one most appropriate for the user.</dd>
<dt>Discoverability</dt>
<dd>In the current HTML specification there is no requirement for discoverability. This is a major problem with existing implementations, very few of which provide a means for the user to discover that <code>accesskey</code>s have been assigned. Instead the current specification <strong>assumes</strong> that authors will somehow present the required information to the user. For a browser-mediated interaction, this is inappropriate, placing the burden of work in the wrong part of the "hierarchy of needs" and making it less likely to be done, or done effectively. While the HTML specification has rightly shied away from specifying user interfaces, it should at least be clear when there is a need for user interface if a functionality is going to work.</dd>
<dt>Ecosystem requirements</dt>
<dd>The current HTML specification assumes all shortcuts assigned will be key combinations. This does not meet the reality of deployed platforms, many of which either do not have a keyboard or also permit other activations more appropriate for a shortcut.</dd>
<dd>In addition, the current HTML specification fails to provide sufficient context to motivate the use of a shortcut, including when it is not useful, or when another method may be more appropriate.</dd>
</dl>
</section>
<h2 id="proposal">Proposed Replacement Section 5.5:</h2>
<section><h3 id="assigning-keyboard-shortcuts">5.5 Assigning activation shortcuts</h3>
<section><h4 id="introduction-9">5.5.1 Introduction</h4>
<p><i>This section is non-normative.</i></p>
<p>Some common browsing functions have multiple "shortcut" activations: going back in history, following a link or selecting an item in a form menu may be done through "pressing" an onscreen button, a keystroke, a gesture, or other command. Likewise, in many web apps, especially those that users interact with often such as webmail, applications for work, or common recreational sites, it is helpful to provide activation that minimises the amount of physical work a user needs to do. Typically, these are features remembered by frequent use, but it is important that users can discover them and that they meet the particular needs of a user, in order to be a genuine shortcut.</p>
<p>HTML lets authors request shortcut activations for any element that can receive focus or be activated, using the <code id="introduction-9:the-accesskey-attribute"><a href="#the-accesskey-attribute">accesskey</a></code> attribute. Authors can provide several suggestions for shortcuts in the <code id="introduction-9:the-accesskey-attribute-3"><a href="#the-accesskey-attribute">accesskey</a></code> attribute.</p>
<p class="note">Authors <em class="rfc2119">should not</em> request shortcuts for normal browser function. Where HTML already provides a way to indicate something the browser can act on, such as using <code>rel="help"</code> to identify a link to a help interface, it is better to use these features than to assign an <code>accesskey</code> attribute.</p>
<p class="issue">Currently the <code>rel</code> attribute only applies to <code>a</code>, <code>area</code>, and <code>link</code> elements. Should it be extended to cover e.g. elements with <code>role="link"</code> or interactive elements which can take on the functionalities of a link defined with <code>a role="…"</code>?</p>
<p>The actual shortcut(s) assigned, such as a key combination or direct access voice command, is determined by the user agent, using information about the user's preferences, keyboard, what shortcuts exist on the platform, and what other shortcuts have been specified on the page, as well as the information provided in the <code id="introduction-9:the-accesskey-attribute-2"><a href="#the-accesskey-attribute">accesskey</a></code> attribute.</p>
<div class="example">
<p>In this example, an author has provided a button and requested a shortcut activation. The author has suggested the russian word "<span lang="ru">Написать</span>", the latin keys "w" and "c", and the number "1" as useful hints for what makes sense as shortcut activations.</p>
<pre><code><input type="button" value="Написать" onclick="compose()"
<strong>accesskey="Написать С W 1"</strong> id="Написать"></code></pre>
<p>A browser might apply this by adding a voice command "Написать" to a grammar of expected commands for which an event can be fired, by listening for keypresses of the Cyrillic letters "<span lang="ru">Н</span>" (equivalent to the latin "n") or "П" (equivalent to latin "P") or one of the letters proposed by the author, perhaps with a standard modifier.</p>
</div>
<p>The user agent is best-placed to inform the user that there are shortcut activations for the page, and explain the particular activation shortcuts and what they will do. But HTML also provides an <code>accessKeyLabel</code> DOM attribute, which is text created by the user agent describing the shortcut. Applications can use this to <strong>reinforce</strong> the information that a shortcut is available.</p>
<div class="example">
<p>To tell the user what the shortcut key is, this script explicitly adds the browser-described shortcut activation to the button's label:</p>
<pre><code>function addShortcutKeyLabel(button) {
<strong> if (button.accessKeyLabel != '')
button.value += ' (' + button.accessKeyLabel + ')';</strong>
}
addShortcutKeyLabel(document.getElementById('c'));</code></pre>
<p>Different browsers on different platforms can show different labels, even for the same key combination.For example, if the activation shortcut is the Control key, the Shift key, and the letter C, a Windows browser might display "<samp>Ctrl+Shift+C</samp>", whereas a Mac browser might display "<samp>^⇧C</samp>", and an Emacs browser might just display "<samp>C-C</samp>". Where a voice command enabled, the value might be "<samp>^⇧C or say "compose"</samp>.</p>
<p>It is therefore unwise to attempt to parse the value returned from the <code id="introduction-9:dom-accesskeylabel-2"><a href="#dom-accesskeylabel">accessKeyLabel</a></code> IDL attribute.</p>
<p class="issue"><a href="https://github.com/chaals/accesskey/issues/16">Given a standard microsyntax for commands, accessKeyLabel would be parseable. In any event, there is currently only one implementation - is it consistent across platforms?</a></p>
<p class="issue">For gestures, it is useful to present an animation of the gesture. Can we enable this?</p>
</div></section>
<section><h4 id="the-accesskey-attribute">5.5.2 The <dfn><code>accesskey</code></dfn> attribute</h4>
<p>All <a href="infrastructure.html#html-elements" id="the-accesskey-attribute:html-elements">HTML elements</a> may have the <code id="the-accesskey-attribute:the-accesskey-attribute"><a href="#the-accesskey-attribute">accesskey</a></code>
content attribute set. The <code id="the-accesskey-attribute:the-accesskey-attribute-2"><a href="#the-accesskey-attribute">accesskey</a></code> attribute's value is used
by the user agent as a guide for creating a shortcut that activates or focuses the
element.</p>
<p>If specified, the value <em class="rfc2119">must</em> be a potentially empty <a href="infrastructure.html#ordered-set-of-unique-space-separated-tokens" id="the-accesskey-attribute:ordered-set-of-unique-space-separated-tokens">ordered set of unique space-separated tokens</a>
that are <a href="infrastructure.html#case-sensitive" id="the-accesskey-attribute:case-sensitive">case-sensitive</a>.</p>
<p>Authors <em class="rfc2119">should</em> give a value to the accesskey attribute, that is a single character, for backward compatibility.</p>
<p>At the time of writing, if the value is more than a single character many browsers will not provide <strong>any</strong> shortcut, therefore <strong>reducing</strong> accessibiltiy and usability of the author's application.</p>
<div class="example">
<p>In the following example, a set of links are given <code>accesskey</code>s so that users
familiar with the site can quickly navigate to relevant pages:</p>
<pre><code><nav>
<p>
<a accesskey="Activity a" href="/Consortium/activities">Activities</a> |
<a accesskey="TR" href="/TR/">Technical Reports</a> |
<a accesskey="S" href="/Consortium/siteindex">Site Index</a> |
<a accesskey="B" href="/Consortium/">About Consortium</a> |
<a accesskey="C" href="/Consortium/contact">Contact</a>
</p>
</nav></code></pre>
</div>
<div class="example">
<p>In the following example, a search field is identified using the standard HTML technique <code>input type="search"</code>. A link to an advanced interface is available, but there is no standard HTML technique for identifying a "more advanced" version. Assuming that advanced search is a relatively common user interaction on this site, an <code>accesskey</code> attribute is present to request an activation shortcut, and the application has suggested three possible access keys, "advanced", "s" and "9" in that order. A user agent on a device with a "QWERTY" keyboard might pick the combination <kbd><kbd>Ctrl</kbd>+<kbd>Alt</kbd>+<kbd>A</kbd></kbd> as the shortcut if it is available, first falling back to <kbd><kbd>Ctrl</kbd>+<kbd>Alt</kbd>+<kbd>S</kbd></kbd> and then <kbd><kbd>Ctrl</kbd>+<kbd>Alt</kbd>+<kbd>9</kbd></kbd>. A user agent on a small device with a telephone keypad might pick just the plain unadorned key <kbd>9</kbd>:</p>
<pre><code><form action="/search">
<label>Search: <input type="search" name="q"></label>
<a href="advanced.html" accesskey="advanced s 9"
<input type="submit">
</form></code></pre>
</div>
<p>User agents <em class="rfc2119">should</em> indicate whether a page has shortcuts assigned, and if so <em class="rfc2119">should</em> provide users with a list of the current shortcuts for a page. The <code id="introduction-9:dom-accesskeylabel"><a href="#dom-accesskeylabel">accessKeyLabel</a></code> IDL attribute returns a
string representing the actual shortcut assigned by the user agent.</p>
<p class="note">There are a variety of interaction strategies that could be used to meet this requirement. Opera 12, and Opera mini, enabled a menu that presented the activation shortcuts enabled and what they did. iCab and many old phone browsers added icons to the screen. The excesskey extension for Opera added an icon and menu to the browsers User Interface alerting users to the fact that shortcuts were enabled. Some screenreaders announce a shortcut verbally. This specification does not recommend a specific user interface, because that inherently depends on the nature of the user agent.</p>
<div class="example">
<p>In the following example, a button has possible access keys described. A script then tries to
update the button's label to advertise the shortcut the user agent selected.</p>
<pre><code><input id="compose" type=submit accesskey="N @ 1"
title="write a new email message" value="Compose">
<!-- ... -->
<script>
function labelButton(button) {
if (button.accessKeyLabel)
button.value += ' (' + button.accessKeyLabel + ')';
}
var inputs = document.getElementsByTagName('input');
for (var i = 0; i < inputs.length; i += 1) {
if (inputs[i].type == "submit")
labelButton(inputs[i]);
}
</script></code></pre>
</div></section>
<section><h4 id="processing-model-7">5.5.3 Processing model</h4>
<p>An element's <dfn id="assigned-access-key">assigned shortcut</dfn>(s) are user behaviours, determined by the user agent. They are derived from the presence of an <a href="#the-accesskey-attribute">accesskey</a></code> attribute, and normally take into account the content of that attribute.</p>
<p>User agents <em class="rfc2119">must</em> maintain a list of <dfn id="possible-shortcuts">possible shortcuts</dfn>, which are input behaviour it can recognise. These can be gestures, a grammar of commands, a set of key combinations, or combinations of these and any other input behaviour the user agent can recognise. This list <em class="rfc2119">should</em> be configurable by users.</p>
<p class="example">For example, by default a user agent may define the letters a-z, the cyrillic letters а-я, and the greek letters α-ω, each in combination with the "shift" and "alt" keys, as </var>possible shortcuts</var>.</p>
<p>User agents <em class="rfc2119">should</em> maintain a list of <dfn id="assigned-shortcuts">currently assigned shortcuts</dfn>.</p>
<p>Whenever an element's <code id="processing-model-7:the-accesskey-attribute-2"><a href="#the-accesskey-attribute">accesskey</a></code> attribute is set, changed,
or removed, the user agent must update the element's <a href="#assigned-access-key" id="processing-model-7:assigned-access-key-2">assigned access key</a> by running
the following steps:</p>
<p class="note">This algorithm is intended to ensure that when shortcuts are requested a shortcut is assigned if possible. Shortcuts are assigned with user preference having higher priority than browser default behaviour, and author suggestion having lower priority. Multiple shortcuts <em class="rfc2119">may</em> be assigned, and the same shortcut <em class="rfc2119">may</em> be assigned to multiple elements.</p>
<ol>
<li><p>If the element has no <code id="processing-model-7:the-accesskey-attribute-3"><a href="#the-accesskey-attribute">accesskey</a></code> attribute, stop.</p></li>
<li><p>If the user agent has a default interaction assigned to focus or activate the element, it <em class="rfc2119">may</em> stop processing.</p>
<p class="note">For example, if the element has an assigned shortcut based on a <code>rel</code> attribute value, the user agent is <em class="rfc2119">not required</em> to assign a further shortcut.</p></li>
<li><p>If the user agent has a stored user preference for activation of the element, let <var>keys</var> be the value of that preference and skip to the <i>assign</i> step below.</p></li>
<li><p>Otherwise, let <var>keys</var> be <samp>null</samp>, <a href="infrastructure.html#split-a-string-on-spaces" id="processing-model-7:split-a-string-on-spaces">split the attribute's value on spaces</a>, and let <var>tokens</var> be the resulting tokens.</p></li>
<li><p>Process each value in <var>tokens</var>, in the order they appeared in the
attribute's value, according to the following substeps:
<ol>
<li><p>if the value corresponds to a <var>possible shortcut</var>:</p>
<p class="note">What values <dfn id=corresponding-shortcuts">correspond</dfn> to a <var>possible shortcut</var> is left as an implementation detail. If the <var>possible shortcuts</var> include the 26 letters of the english/latin alphabet, each in combination with the modifier keys "Control" and "Shift" and "alt", then the values "a", "adjust", and "A" <em class="rfc2119">may</em> correspond to the shortcut "ctrl-shift-alt-a". The value "ф" (a cyrillic character usually transliterated to latin as "f" <em class="rfc2119">may</em> correspond to a value of "a", since on a qwerty keyboard it corresponds to the same physical key. The token values "ñ", "ж" and "語" are unlikely to correspond to a "possible shortcut" value of "a".</p>
<ol>
<li><p>if the value corresponds to an <var>assigned shortcut</var>, the user agent <em class="rfc2119">may</em> continue processing tokens.</p>
<p class="note">This enables the user agent to avoid assigning the same shortcut twice</p></li>
<li><p>Otherwise add the value to <var>keys</var>. The user agent <em class="rfc2119">may</em> continue processing <var>tokens</var>.</p>
<p class="note">This allows the user agent to assign only a single shortcut - although that is also possible through the requirements in the "assign" step.</p></li></ol></li>
<li><p>Otherwise, continue processing the <var>tokens</var></p></li>
</ol></li>
<li><p><i>assign</i>: If the value of <var>keys</var> is not <samp>null</samp>, assign one or more of the corresponding <var>possible shortcuts</var>.</p>
<p class="note">The user agent is not required to assign more than a single shortcut to a given element.</p>
<p class="issue">What happens if the user agent runs out of shortcuts?</p></li>
<li><p><i>Fallback</i>: The user agent <em class="rfc2119">should</em> assign a <var>possible shortcut</var>.</p></li>
<li><p>If this step is reached, the element has no <a href="#assigned-access-key" id="processing-model-7:assigned-access-key-5">assigned shortcut</a>.</p></li></ol>
<p>Once a user agent has selected and assigned a shortcut activation for an element, the user agent should
not change the element's <a href="#assigned-access-key" id="processing-model-7:assigned-access-key-6">assigned shortcut</a> unless the <code id="processing-model-7:the-accesskey-attribute-4"><a href="#the-accesskey-attribute">accesskey</a></code> content attribute is changed or the element is moved to
another <code id="processing-model-7:document"><a href="dom.html#document">Document</a></code>.</p>
<p>When the user triggers the behaviour corresponding to the <a href="#assigned-access-key" id="processing-model-7:assigned-access-key-7">assigned shortcut</a>
for an element, for example by making a gesture or pressing a key combination, the
command's <a href="semantics.html#command-facet-hiddenstate" id="processing-model-7:command-facet-hiddenstate">Hidden State</a> facet is false (visible),
the command's <a href="semantics.html#command-facet-disabledstate" id="processing-model-7:command-facet-disabledstate">Disabled State</a> facet is also false
(enabled), the element is <a href="infrastructure.html#in-a-document" id="processing-model-7:in-a-document">in a <code>Document</code></a> that has an associated
<a href="browsers.html#browsing-context" id="processing-model-7:browsing-context">browsing context</a>, and neither the element nor any of its ancestors has a <code id="processing-model-7:the-hidden-attribute"><a href="editing.html#the-hidden-attribute">hidden</a></code> attribute specified, then the user agent <em class="rfc2119">must</em> move the focus to the element with a corresponding assigned shortcut.</p>
<p>If the element <a href="semantics.html#concept-command" id="processing-model-7:concept-command">defines a command</a>, and the <a href="#assigned-access-key" id="processing-model-7:assigned-access-key-7">assigned shortcut</a> is unique to that command, the user agent <em class="rfc2119">should</em> trigger the <a href="semantics.html#command-facet-action" id="processing-model-7:command-facet-action">Action</a> of the command.</p>
<p class="issue"><a href="https://github.com/chaals/accesskey/issues/15">Issue #15 - why not <em>require</em> activation?</a></p>
<hr>
<p>The <dfn id="dom-accesskey"><code>accessKey</code></dfn> IDL attribute must
<a href="infrastructure.html#reflect" id="processing-model-7:reflect">reflect</a> the <code id="processing-model-7:the-accesskey-attribute-6"><a href="#the-accesskey-attribute">accesskey</a></code> content attribute.</p>
<p>The <dfn id="dom-accesskeylabel"><code>accessKeyLabel</code></dfn> IDL attribute <em class="rfc2119">should</em> return a string that represents the element's <a href="#assigned-access-key" id="processing-model-7:assigned-access-key-8">assigned shortcut(s)</a>, if any. If the element has none, then the IDL attribute must return the empty string.</p></section></section>
<section id="changes">
<h2>Changes from the HTML 5 definition</h2>
<p>This specification introduces a number of changes to the HTML5 definition of <code>accesskey</code>:</p>
<ul>
<li>It is possible to specify tokens that are longer than a single character</li>
<li>Authors are advised to provide a single key value, for compatibility with browsers</li>
<li>It is valid for an author to request an accesskey without providing a proposed value</li>
<li>If an element has a predefined activation, the user agent <em class="rfc2119">may</em> choose not to define a further shortcut</li>
<li>User agents are free to define the shortcut activation as they choose<br>
<li>Shortcuts are not required to be keys or key combinations</li>
<li>An explicit request for user agents to provide discoverability</li>
<li>User agents <em class="rfc2119">must</em> maintain a list of <var>possible shortcuts</var></li>
</ul>
</section>
<section class='appendix' id="acknowledgements">
<h2>Acknowledgements</h2>
<p>Many thanks to Robin Berjon for making spec editing easier with Respec.</p>
<p>This is a piece of work that has developed over almost two decades, and a great many people have made important contributions. As well as all the the people who worked on the original <code>accesskey</code> specification in HTML 4 and the <code>access</code> element proposed for XHTML2, and many people who deserve a mention but are not noted here, the editor owes explicit thanks to Cynthia Shelly, David MacDonald, Deborah Kaplan, Dominic Mazzoni, Earl Johnson, Emmanuelle Gutiérrez y Restrepo, Ian Hickson, Johannes Wilm, John Foliot, Jonathan Avila, Judy Brewer, Jukka Korpela, Léonie Watson, Philippe le Hégaret, Rafael Romero, Richard Schwerdtfeger, Rodney Rehm, Ryosuke Niwa, Shane McCarron, Simon Pieters, Stuart P Bentley, Taylor Hunt, and the Paris Web community for direct contributions that have improved this document.</p>
</section>
</body>
</html>