Add a section about why this extension needs to exist

Issue #4

index.src.html

@@ -73,18 +73,35 @@
    <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>
-
-    <li><a href="acknowledgements">Acknowledgements</a></li>
+        <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="#acknowledgements">Acknowledgements</a></li>
    </ul>
   </section>
 
+  <section id="why"><h2>Rationale for this extension</h2>
+    <p>The current HTML accesskey definition is an improvement on the HTML 4 specification, allowing for multiple keys to cope with different user environments. However, there are still a number of problems:</p>
+    <dl>
+      <dt>Conflict resolution</dt>
+        <dd>The current specification allows for the User Agent determining "what keys are available", of 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 accesskeys 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 shied away from making user interface requirements, it should at least be clear when there is a need for <em>some</em> 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 keyboard shortcuts</h3>
 
   <section><h4 id="introduction-9">5.5.1 Introduction</h4>