Examples of such issues include automatically setting focus to other page areas after onfocus and onblur are triggered, trapping the user inside a form control, dynamically revealing form controls immediately upon a user leaving (blurring) a form input, etc. The actions that are performed as a result of these event handlers must be analyzed to determine if they cause accessibility problems, especially if they are modifying the default behavior of the web browser or are interfering with keyboard navigation within the web page. onblur is triggered when the cursor leaves a form element or the user 'tabs' away from it.īoth of these event handlers are device independent, meaning that they can be performed with the mouse, touch, keyboard, or other assistive technology. onfocus is triggered when the cursor is placed on or within a specific form element, or when a user 'tabs' to the element using the keyboard. These event handlers are typically used with form inputs, such as text fields, radio buttons, and submit buttons, but can also be used with links or perhaps ARIA widgets. One might use onfocus (or focus or focusin events) and onblur (or blur or focusout events) when the keyboard is used to navigate to and from an element. While not exactly the same interaction that mouse users may choose, such alternatives are often more intuitive and friendly. These links would take the user to secondary pages that provides links to additional pages provided through the complex menu (e.g., a Products landing page that has links to the various product categories). Instead, standard links would provide functionality on the top-level menu item (e.g., "Products"). For example, instead of forcing users to navigate through a complex and lengthy navigation menu, you could instead ensure that the sub-menu items are NOT directly keyboard accessible (nor read by a screen reader). While these can be made technically keyboard accessible, sometimes an accessible alternative approach may be more friendly. Sometimes scripting is used to present complex mouse interactions, such as a drop-down or fly-out menu. However, for sighted keyboard-only users, there must be a mechanism for them to access and view the newly revealed content or functionality. For screen reader users (who very often use a keyboard for navigation), the additional content might be provided directly in an accessible way, such as via alternative text, through an ARIA label or description, or perhaps through off-screen text.
If the mouse interaction presents additional information or content, such as a tooltip, a navigation menu, etc., then this content will not be accessible to anyone not using a mouse. If the mouse interaction is purely cosmetic (such as the addition of a glow or drop shadow), there are likely no accessibility issues, so long as the style change does not indicate some function (such as to indicate that an element is clickable). onmouseover, and its companion, onmouseout (and related mouseout and mouseleave events), may be used, as long as any important content or functionality is also available without using the mouse. As its name implies, onmouseover requires the use of a mouse, thus it is a device dependent event handler and may introduce accessibility issues. The onmouseover event handler (and related mouseover and mouseenter events) is triggered when the mouse cursor is placed over an item.
0 kommentar(er)
