doc(cb-a11y): Labelling form controls: content

Author: AlmeroSteyn

public/docs/_examples/cb-a11y/ts/app/a11y-index.component.html

@@ -1,7 +1,7 @@
 <nav role="navigation">
     <ol>
         <li>
-            <a href="" [routerLink]="['FormControls']"><h2>Accessible form control labels</h2></a>
+            <a [routerLink]="['FormControls']"><h2>Accessible form control labels</h2></a>
         </li>
     </ol>
-</nav>
+</nav>

public/docs/ts/latest/cookbook/a11y.jade

@@ -36,7 +36,8 @@ include ../_util-fns
 
 .l-sub-section
   :marked
-    `ARIA`, or `Accessible Rich Internet Applications` refers to bringing `a11y` concepts into
+    `ARIA`, or `Accessible Rich Internet Applications` refers to a standard set of attributes for adding accessibility 
+    information to `HTML` and `SVG`. This allows us to bring `a11y` concepts into
     internet applications like those we are building with Angular 2.
 
 :marked
@@ -112,7 +113,7 @@ include ../_util-fns
 
   [Component that knows its own role](#component-roles)
 
-  [Managing focus](#managin-focus)
+  [Managing focus](#managing-focus)
 
 .l-sub-section
   :marked
@@ -134,7 +135,7 @@ include ../_util-fns
   A nightmare right? Users will leave so fast the bouncerate counter will be able to power a small town it will be
   spinning *THAT* fast.
 
-  We can avoid this from ever happening by simply adding a label for each field. Generaly this is not out problem,
+  We can avoid this from ever happening by simply adding a label for each field. Generally this is not our problem,
   however the users of our website may not always be able to see or recognise these labels without assistance.
 
   For this reason it is not only important to visually mark any form component, or as they are sometimes called,
@@ -247,7 +248,7 @@ code-example(language="html" escape="html").
   The answer is no. But does that mean we get away with not labelling those fields at all?
 
   Once again the answer is no.
-
+  
   So how do we solve it?
 
   We can either use an `explicitly labelled` input and hide the label with style, or we can use the `aria-label`, which
@@ -283,9 +284,33 @@ code-example(language="html" escape="html").
 .l-sub-section
   :marked
     So why not simply always use `aria-label`? This is because adding the `label` element not only provides the visual
-    label, but linking a `label` to a `form control` also means that clicking on the `label` will select the 
+    label, but linking a `label` to a `native form control` also means that clicking on the `label` will select the 
     `form control` itself. This touches on another area of `a11y`, as this also assists users with motor disabilites 
     to more easily select them.  
+    
+:marked
+  Lets have a look at a quick comparison between using this method as opposed to not taking `a11y` into account at all. 
+  
+  Here is what happens if we have an `input` for filtering criteria that does not take any `a11y` into account. We will 
+  use the accessibility tools in the newest development version of `Chrome`, although you can use one of various internal
+  and external web browser tools to test accessibility. This is the information that assistive technologies will
+  use when reading our field out:
+
+figure.image-display
+  img(src="/resources/images/cookbooks/a11y/invisible-label-input-not-labelled.png" alt="Input with invisible label not labelled correctly")
+
+:marked
+  We can clearly see that the only description a user with a screen reader will get is **Enter a value**. What value? 
+  
+  Just imagine if there are more than one input on the same page with the same placeholder. Utter chaos!
+  
+  Now lets put our `a11y` info back and look at the same input again:
+  
+figure.image-display
+  img(src="/resources/images/cookbooks/a11y/invisible-label-input-labelled.png" alt="Input with invisible label labelled correctly")  
+  
+:marked
+  Immediately it is clear what this `input` field is and what the user is supposed to enter in it!
 
 :marked
   ### Labelling custom form controls
@@ -296,7 +321,7 @@ code-example(language="html" escape="html").
 
   How would you go about making these custom form controls accessible?
 
-  Fear not, there is a way! We introduce the next addition to our `ARIA` toolkit, and that is `aria-labeledby`. 
+  Fear not, there is a way! We introduce the next addition to our `ARIA` toolkit, and that is `aria-labelledby`. 
 
   Why do we need this? Because the native `a11y` function of the `label` element is only recognised when used with 
   native `HTML` form control elements such as `input` and `textarea`. To label anything else, like a `div` or a