The following article shows what you need to consider when designing a barrier-free web page, and how you can improve their usability by optimizing the keyboard operation.
Subject Focus
Changes to the context are often not easy for keyboard users, or they are difficult to capture, especially if they can not fully perceive the screen due to blindness or visual impairment. For example, if a user fills a field for a postcode, and the focus automatically jumps to the Location field after five characters, without a keyboard user being aware of it. Therefore, the issue has also been found in the Web Content Accessibility Guidelines (WCAG) 2.0, where several requirements for predictability are formulated.
Topic Operation
The central aspect when using the computer with the keyboard is the system focus. The focus on the focus should always be left to the user. In other words, if the focus is moved by the user anywhere on a Web page using the tab key, you can not expect the Web developer to be able to activate a link or control a control. While pressing the input or empty key implies that, as with a mouse click, the user can expect a change to the page contents, the window, or the application, when a member is simply focused, such a significant and non-controllable change may result in a non-operable web page
Suggestions for usability optimizations
The same applies to the selection in forms and widgets, which are mainly made by arrow keys. Significant changes can be different. On the one hand it is about the exchange of content, which gives the site a different meaning. On the other hand, there are various circumstances, such as the automatic sending of a form, the display of a new window or the focus manipulation. In most cases, it is crucial that the keyboard focus stays where the user expects it.
In order to meet user expectations, functionality is being tested for mouse users and, in the meantime, touch screen users too, but keyboard users remain way too often out of the line. As a result, some websites do not work for the users or can not be foreseen. For keyboard users the focus is sacred. Typically, the focus from active element to active element (usually links or form controls) is moved with the tab key. Because the focus triggers an event, developers in their scripts need to ensure that the focus does not change the context alone. Contextual changes should be reserved for mouse clicks and the pressing of input and / or blank buttons.
In the tab panel, a mouse click on a tab causes the tab to be exchanged via JavaScript. A keyboard user should focus the register page, make a selection with the arrow keys, and trigger the display of the corresponding register page with the empty key. What should not happen is that the user focuses the first tab and, after pressing the tab key, focusses the second tab and the tab page is automatically replaced.
The right Customer Experience create
With this behavior, only the last register page could always be served if only the keyboard is available as input. The tabs can only be controlled once with the Tab key. When the active tab is focussed and the Tab button is pressed again, the focus on the next focusable item below the tabs must be changed. This means, the selection of the tabs with arrow keys must be provided by the web development.
The keyboard control is the responsibility of the developer as soon as more complex UI components such as register avalanches are used. The use of JavaScript libraries like jQuery, Dojo or MooTools allows a barrier-free implementation, but does not guarantee it. Especially with widgets, you should lean with the exact key assignment to common recommendations as in the "Authoring Practices" to the WAI-ARIA specification
Many of the problems with keyboard operation are much more trivial. Maybe it's just a misfortune, but the focus is much too often used to trigger actions. With niples like menu item 1 a> some pages are completely unusable, including an onclick event handler and an onfocus event handler Behaves independently of the device in the case of links and form controls, ie, it is also triggered by the input and the empty key.
Also the loss of the focus can greatly affect the operation with the keyboard. Sometimes, web developers tend to remove the focus of focused elements with small code snippets like onfocus = "this.blur (), for probably aesthetic reasons, which is a real vulgarity against keyboard users and causes an element not to be focused and focused You can not navigate to the top of the Breadcrumb navigation, and then you are done, and you can not access the links in the content from the keyboard
IT Security Code for Companies
Of course, there are also positive examples of focus manipulation. After calling google.com, the cursor already flashes in the input field when JavaScript is activated. However, use this technique with extreme caution. Only if it is assumed that practically all users want to use this one function, the manipulation of the focus is justified. On most websites - especially those with dynamic content - it is about the keyboard control in addition to take into account and avoid focus losses. In the case of error handling in forms, the controlled setting of the focus in an incorrectly filled input field can also promote the usability of the form.
Changes to the context affect not only the focus, but also the operation of control elements. There are several examples on the web, which can be made more easily available for keyboard users, especially screen readers. For some dynamic situations, an indication of the dynamics should be sufficient, but in others it is more appropriate to provide a button for submitting the form. You can, of course, also control the keyboard control with JavaScript.
The classic case of changing the context is a quick launcher: A user opens the selection list with the mouse and is immediately redirected to a new page by clicking on one of the entries. For keyboard users the sequence is somewhat different: first the selection list is focused with the Tab key, then the arrow keys are used to move through the entries, and finally a selection is made with the
Reduce Planning Complexity
When passing the options, the forwarding can not be triggered. You can catch such inconvenience for keyboard users by JavaScript by first checking the input or blank key in the executing script.
In addition, not only input and empty keys must be considered. Browsers usually provide keyboard control for HTML controls, but JavaScript can help you get rid of this functionality. For example, with a Quick launcher, you can use the arrow keys to make a selection.
Changes to the context are often a tightrope walk between usability and accessibility. There are many situations that generally work well for keyboard users, but not specifically for blind users. The following two examples are about switching from one form control to the next. On the screen, the functionality is quickly apparent, but not in a screenreader. In the example in Fig. 5, the focus is automatically set to the next input field if there are three characters in the first field or eight characters in the second field. The minimum requirement for accessibility in this example is that the dynamic
Behavior is announced.
Context-dependent selection lists are similar: If you select an entry in a first selection list, the list is closed and deactivated, the next selection list is displayed, and the focus is placed in the second selection list. This procedure is repeated for the following selection lists until the last possible selection is made.
When switching the focus from one to the next selection list, the label of the next control element should be read by the screenreader, but this is not mandatory, so it can happen that a screenreader does not know that the focus is in a new selection list. An announcement - as shown in Fig. 6 - allows blind users to anticipate the dynamic. Incorrectly chosen selection can be easily reversed in this example.
The usability is much too often adjusted to mouse and, in the meantime, touch screen users. If you want to match your website to keyboard users, this does not mean that you are not allowed to use JavaScript. The goal of improved usability for keyboard users can not be to do without dynamic effects. The goal must rather be to optimize the keyboard-specific events with the same intensity as the mouse-dependent events. Where the best keyboard operation is, depends on the specific situation as always.
No comments:
Post a Comment