Minor fixes

Author: Jihye Hong

index.bs

@@ -206,10 +206,10 @@ See [[#events-nav-type]] for details about the various events.
         <figcaption>Moving focus to the hidden element in the <a>spatial navigation focus container</a>.</figcaption>
     </figure>
 
-    On the left of figure 3, under "Box 3", there isn't any visible element in the scrollort.
+    On the left of figure 3, under "Box 3", there isn't any visible element in the <a>scrollport</a>.
     Therefore, the effect of pressing the <code class=key>ArrowDown</code> is to scrolls down, as shown in the middle.
-    Once "Box 4" comes in to view, the next press of the <code class=key>ArrowDown</code> key
-    will focus it, as shown on the right,
+    Once "Box 4" comes into view, the next press of the <code class=key>ArrowDown</code> key
+    will focus it, as shown on the right.
 
     This example uses the markup as follows:
     <pre class="lang-css">
@@ -480,7 +480,7 @@ The <a event>navbeforescroll</a> event occurs before spatial navigation triggers
             <th>Attributes of the event
                 <td><dl>
                     <dt>{{NavigationEvent}}.{{NavigationEvent/relatedTarget}}
-                    <dd>The element that will be scrolled if the event is not cancelled
+                    <dd>The element that will be scrolled if the event is not canceled
 
                     <dt>{{NavigationEvent}}.{{NavigationEvent/dir}}
                     <dd>The direction of the navigation as requested by the user
@@ -799,7 +799,7 @@ the following steps are run to <dfn>react to key presses</dfn>.
     in the <code>forward</code> direction if {{KeyboardEvent/shiftKey}} is <code>false</code>
     or in the <code>backward</code> direction if it is <code>true</code>,
     then return
-11. Else, if the {{KeyboardEvent/key}} is one of <code class=key>ArrowUp</code>,<code class=key>ArrowDown</code>, <code class=key>ArrowLeft</code>, or <code class=key>ArrowRight</code>:
+11. Else, if the {{KeyboardEvent/key}} is one of <code class=key>ArrowUp</code>, <code class=key>ArrowDown</code>, <code class=key>ArrowLeft</code>, or <code class=key>ArrowRight</code>:
     1. Let <var>dir</var> be:
         * <code>up</code>    if the {{KeyboardEvent/key}} is <code class=key>ArrowUp</code>
         * <code>down</code>  if the {{KeyboardEvent/key}} is <code class=key>ArrowDown</code>
@@ -821,13 +821,13 @@ the following steps are run to <dfn>react to key presses</dfn>.
         where there is no unusual setting of the 'overflow' property on these elements,
         and where no element in particular was focused and
         <var>eventTarget</var> was set to <a>the body element</a> or the <a>document element</a> of the <a>top-level browsing context</a> in steps 1 &amp; 2,
-        the condition of this step is not mached,
+        the condition of this step is not matched,
         and we fallback to the next step.
     4. Else, if spatial navigation is <a for=spatnav>active</a> on <var>eventTarget</var>
         run the <a>navigation steps</a> on <var>eventTarget</var> in direction <var>dir</var> from <var>startingPoint</var>,
         then return
     5. Else, let <var>ancestor</var> be the nearest ancestor of <var>startingPoint</var> that is a <a>scroll container</a> that <a>can be scrolled manually</a>,
-        including in <a>ancestor browsing contexts</a>,
+        including in an <a>ancestor browsing contexts</a>,
         or <code>null</code> if no such element can be found.
 
         If <var>ancestor</var> is <code>null</code>,
@@ -838,7 +838,7 @@ the following steps are run to <dfn>react to key presses</dfn>.
         Issue: This is how Chrome and Safari do it.
         Firefox only looks at the first ancestor of <var>startingPoint</var>,
         and if that cannot be manually scrolled,
-        it stops there rather than look further up the ancestry chain.
+        it stops there rather than looking further up the ancestry chain.
 
 </div>