Using comprehensive keyboard support to enhance web application accessibility. You'll learn how to ensure inclusive user interactions no matter what your disability may be. Learn about keyboard commands, focus visibility, and accessible forms to make your application universally accessible.

Ensuring Inclusive User Experience with Keyboard Accessibility in Web Applications

Explore key strategies to enhance keyboard accessibility in web applications. You will acquire the skills necessary to design universally navigable and inclusive user experiences.

Keyboard support is one of the most important accessibility parts that every application should include. We must ensure every user interaction including people with disabilities. It is important that every part of our application can be used through the keyboard as well. In previous blog articles, we got acquainted with accessibility standards and how to design and develop with accessibility in mind. In my last blog article in the series of digital accessibility, I wanted to discuss keyboard support for our application.
<h2>Types of Disabilities</h2>
Our application should be operable by keyboard users. Who are keyboard users?
<ul>
<li>Persons with physical disabilities who have limitations in the use of their arms. They use a specially designed keyboard, but can't use a mouse. They don't use any other assistive technology and can't use a website if they need a mouse.</li>
<li>Persons who are legally blind. They use a screen reader to browse a website. It's a text to speech program that reads out the content of the website. They operate websites using the keyboard alone as they can't see the screen and use a mouse.</li>
<li>Persons who use a mouse with lowered hand dexterity. They find it difficult to click on small items or may accidentally click the wrong item if buttons are put too close together. They struggle with the use of mouse and keyboard more.</li>
<li>Persons with situation disabilities. In cases of e.g. arm injury,&nbsp; you may use the keyboard more than usual, or you are trying to shop online while eating. There are a lot of reasons people do not use a keyboard.</li>
</ul>
<h2>Keyboard Commands</h2>
When you operate a website with a keyword, there are just a few basic commands that you need to know. There are various elements on the page that could be operated like input controls, links. These are called focusable elements. Pressing TAB on the keyboard moves the keyboard focus to the next focus element, pressing SHIFT + TAB moves backwards. Pressing the TAB through the IM site, you can see the slight outline showing the time moving. To move back press SHIFT and TAB. To navigate to the link in the menu item, press ENTER. It will activate a link or submit a form.
<table border="0">
<tbody>
<tr>
<td>Keyboard command</td>
<td>Description </td>
</tr>
<tr>
<td>TAB</td>
<td>Move between focusable elements</td>
</tr>
<tr>
<td>SHIFT+TAB</td>
<td>Back to previous focusable element</td>
</tr>
<tr>
<td>ENTER</td>
<td>Submit a form or active link</td>
</tr>
<tr>
<td>SPACE</td>
<td>Toggle a checkbox or open a select control.</td>
</tr>
<tr>
<td>ARROW KEY </td>
<td>Scroll up and down on the page</td>
</tr>
</tbody>
</table>
<h2>Keyboard Focus Visibility</h2>
When tabbing through different elements of the page with keyboard focus, a color outline is needed. Without the outline the user will not see what the element is focused on and it will be impossible to browse a site. It&rsquo;s like using a mouse without seeing the cursor. Focus should be improved using a focus selector.
<pre>button:focus{
&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;styles&nbsp;here
}
</pre>
The default focus works well in most cases. The only occasion where you could change it is if you have a background or color that is a similar shade of color and the outline is not clear. There are a few techniques how you can improve focus indicators:
<ol>
<li>Change the color of the outline 
<pre>.form&nbsp;.btn{
&nbsp;&nbsp;&nbsp;&nbsp;outline-color:&nbsp;#000;
&nbsp;&nbsp;&nbsp;&nbsp;outline-width:&nbsp;1px;
&nbsp;&nbsp;&nbsp;&nbsp;outline-style:&nbsp;solid;
}
</pre>
</li>
<li>Change the color of the entire element 
<pre>.form&nbsp;.btn{
&nbsp;&nbsp;&nbsp;&nbsp;background-color:&nbsp;#fff;
&nbsp;&nbsp;&nbsp;&nbsp;color:&nbsp;#000;
}
</pre>
</li>
<li>Style of hyperlinks can be improved. Default outline around links can look a bit clunky.
<pre>a:focus{
&nbsp;&nbsp;&nbsp;&nbsp;outline:none;
&nbsp;&nbsp;&nbsp;&nbsp;text-decoration:&nbsp;underline;
}
</pre>
</li>
</ol>
Using focus within you can make the form itself stand out visually in addition to style applied to the individual focused input. This can help the perceptibility of focus overall.
<pre>forms:focus-within{
&nbsp;&nbsp;&nbsp;&nbsp;border:&nbsp;1px&nbsp;solid&nbsp;blue;
}
</pre>
<h2>Keyboard Focus Order</h2>
WCAG 2.3.4 Focus order-level A criteria &ndash; Focus elements must receive focus in an order that preserves meaning and operability. Focus of the element should flow in a way that users expect. We should avoid jumping between sections.
<img src="https://pnzdemostorageaccount.blob.core.windows.net/app/b1eebb8a568a4542a16bf759d2fdd975.jpg" alt="Graphical interface keyboard focus order." />
For example, users expect to read the page from left to right end from top to bottom. Users will expect the first focus element to be the logo then the navigation menu.
Using tabindext attribute you can control keyboard focus.
<pre>&lt;button&nbsp;tabindex="3"&gt;Search&lt;/button&gt;
</pre>
Tab index can have 3 values:
<ul>
<li>-1 &ndash; Element is not in the tab order.</li>
<li>0 &ndash; You can tab to an element but the focus order is determined by the order of the HTML.</li>
<li>1+ - Any positive number indicates that you can tab to an element and the focus order is determined by the value of the attribute. Can be between 1 and 32.767.</li>
</ul>
<h2>Accessible Forms</h2>
Every application consists of different forms where we request an engagement. Forms should be clear, logical and easy to use.
<h3>Labelling a Form</h3>
Screen readers have forms mode where there is read out text directly associated with an input element. It&rsquo;s important to name those properties in a proper way.
With each input element, we need to associate the corresponding name. The best way is to use label elements along with the input field. Labels are preferred because they solve two problems at once, the name of the element rendered visually and the name of the element in the accessibility tree. If we use labels and input elements those elements need to be connected.
<pre>&lt;label&gt;Password&lt;/label&gt;
&lt;input&nbsp;type="password"&gt;
</pre>
This example doesn&rsquo;t connect those elements. There are two ways to solve this problem:
<ol>
<li>Wrap the input inside the label. 
<pre>&lt;label&gt;Password
&nbsp;&nbsp;&nbsp;&nbsp;&lt;input&nbsp;type="password"&gt;
&lt;/label&gt;
</pre>
</li>
<li>Set input ID and use for attribute in the label. 
<pre>&lt;label&nbsp;for="password"&gt;Password&lt;/label&gt;
&lt;input&nbsp;type="password"&nbsp;id="password"&gt;
</pre>
</li>
</ol>
Another great usability improvement with this approach is if you can click to label in order to select a field.
<h3>ARIA Labelling</h3>
Sometimes there is a need for an input field without a form label. One of the most common scenarios is search input inside the navigation header. Adding aria-label attribute screen readers will read out while this attribute will not be visible.
<pre>&lt;input&nbsp;type="search"&nbsp;aria-label="Search"&nbsp;id="search"&gt;
</pre>
If there is an input field along with the button you can associate input with button text in the following way:
<pre>&lt;input&nbsp;type="search"&nbsp;aria-describedby="btn-search"&nbsp;id="search"&gt;
&lt;button&nbsp;id="btn-search"&gt;Search&lt;/button&gt;
</pre>
<h3>Additional Description</h3>
Screen readers only see the labels and if you need to provide additional text or description for the input element you need to add an additional aria attribute.
<pre>&lt;label&nbsp;for="password"&gt;Password&lt;/label&gt;
&lt;input&nbsp;type="password"&nbsp;id="password"&nbsp;aria-describedby="password-rule"&gt;
&lt;span&nbsp;id="password-rule"&gt;Must&nbsp;be&nbsp;at&nbsp;least&nbsp;3&nbsp;characters&nbsp;long&lt;/span&gt;
</pre>
Now the screen reader will read the label and additional description described by the associated element.
<h3>Disabled vs Read-only Fields</h3>
When you use disabled or read-only field you have to use the correct method to meet WCAG. Adding disabled or read-only attributes makes a special type of field which doesn&rsquo;t take a value. Difference between disable and read-only field:
<table border="0">
<tbody>
<tr>
<td>Disabled</td>
<td>Read-only</td>
</tr>
<tr>
<td>Greyed-out appearance</td>
<td>Greyed-out appearance</td>
</tr>
<tr>
<td>Can't click into field</td>
<td>Can't click into field</td>
</tr>
<tr>
<td>Can't edit the value</td>
<td>Can't edit the value</td>
</tr>
<tr>
<td>Value not submitted to server</td>
<td>Value is submitted to server</td>
</tr>
<tr>
<td>Don't receive keyboard focus</td>
<td>Receive keyboard focus</td>
</tr>
</tbody>
</table>
<h3>Field Types</h3>
HTML 5 introduced a lot of new types of form input such as search, email, date etc. They can help in adding context for users and improve the experience. A different keyboard will be displayed on mobile when entering a telephone number versus an email.
<h3>Form Validation</h3>
You should always state which fields are optional and which are required. It could be a very bad experience if the user has to guess validation and after submitting the form to come back and re-enter data. Using an asterisk, the user sees which fields are required. Screen readers don&rsquo;t recognize asterisk as a required field and a note in the HTML needs to be added.
Adding required attributes would cause the screen reader to announce it as a required field. Another good advantage is that browsers will pick up attributes and add validation with a little popup message.
<pre>&lt;input&nbsp;type="text"&nbsp;required&gt;
</pre>
If you don&rsquo;t want to have browser validation which can be in conflict with your javascript validation, use the aria required attribute instead.
<pre>&lt;input&nbsp;type="text"&nbsp;aria-required="true"&gt;
</pre>
Now screen readers will read that out as required field:
<h3>Validation Messages</h3>
Adding aria-invalid to the field using javascript after failing validation will tell screen readers that there is a problem with the field. If you hit the submit button or populate the input field with wrong data additional validation messages will appear.
<pre>&lt;input&nbsp;type="password"&nbsp;id="password"&nbsp;aria-required="true"&gt;
&lt;span&gt;This&nbsp;filed&nbsp;is&nbsp;required.&lt;/span&gt;
</pre>
The main problem is that screen readers are not informed of this validation message since this validation is not linked to the field in any way. Adding the aria-invalid attribute will inform the screen reader that the field is not valid. Using aria-describedby will read out associate error messages so that the user knows what the issue is.
<pre>&lt;input&nbsp;type="password"&nbsp;aria-required="true"&nbsp;aria-invalid="true"&nbsp;aria-describedby="password-rule"&gt;&lt;span&nbsp;id="password-rule"&gt;This&nbsp;filed&nbsp;is&nbsp;required.&lt;/span&gt;</pre>
<h3>Validation Summary</h3>
Adding a validation summary on the top of the form makes it much clearer when errors occur and guide the user towards those errors. When the user hits the submit button and if issues are found, the script will set keyboard focus to the validation summary. This jumps the user right back to the start of the form to explain there is a problem. <img src="https://pnzdemostorageaccount.blob.core.windows.net/app/34e757beeee34627930c600a4e885158.jpg" alt="text" />
Status messages must be identified programmatically so that assistive technologies can announce them. This rule is according to WCAG 4.1.3 Status Messages &ndash; Level AA criteria. There are two ways that you can announce a status message.
<ol>
<li>Set keyboard focus to the validation summary. Keyboard focus will bring screen user attention to the issues.</li>
<li>Use live region recommended in WCAG 4.1 which uses aria attribute to mark validation summary live region. Live region announces messages to the user even if they don&rsquo;t receive keyboard focus. Adding the role attribute of alert informs the screen reader that they need to pay attention to this element because all changes need to be announced to the user. 
<pre>&lt;div&nbsp;id="validation-summary"&gt;&lt;/div&gt;

&lt;div&nbsp;id="validation-summary"&nbsp;role="alert"&gt;&lt;/div&gt;
</pre>
 This informs screen readers that they need to pay attention to this element because all changes need to be announced.</li>
</ol>
<h2>Conclusion</h2>
In this blog article, we have seen how we can make our application keyboard accessible. How to design and validate form when users interact with it. A form is a complex element that manages a lot of information and we have to make sure that everything is clear and understandable for all users. Following this guide makes your application supported by keyboard and accessible for screen readers and ensures that users with or without a disability have a good user experience.

Revolutionize Your Application with Enhanced Keyboard Accessibility

Digital Assets Management

Content Hub

Resources

Company