diff --git a/webaim/tecnicas/javascript/index.md b/webaim/tecnicas/javascript/index.md new file mode 100644 index 0000000..9a5a731 --- /dev/null +++ b/webaim/tecnicas/javascript/index.md @@ -0,0 +1,434 @@ +--- +layout: translation +date: 2013-10-24 # Data de ultima atualização do original +title: "Accessible Javascript" # Titulo traduzido +description: "JavaScript allows developers to add increased interaction, information processing, and control in web-based content. However, JavaScript can also introduce accessibility issues." + +copyright: 'Copyright WebAIM' # Quem tem direitos de cópia +license: null # Caso seja uma licença padrão (MIT, GPL...) por aqui +license-custom: null # Caso a licença não seja uma padrão, por uma descrição curta dela aqui +authors: [{ + name: "WebAIM", + link: "http://webaim.org/" +}] +translators: [{ + name: "Emerson Rocha Luiz", + link: "http://twitter.com/fititnt" +}] +reviewers: [] +discussion: https://github.com/webiwg/acessibilidade-web-pt/issues/22 +original: { + title: "Accessible Javascript", # Titulo original, no idioma origial + link: "http://webaim.org/techniques/javascript/", # Link para documento original + dateOfTranslation: "2016-10-04" # Data em que a tradução foi finalizada +} +isDraft: true +isReleaseCandidate: false +--- + + +Accessible Javascript +===================== + +JavaScript Accessibility Issues +------------------------------- + +JavaScript allows developers to add increased interaction, information +processing, and control in web-based content. However, JavaScript can also +introduce accessibility issues. These issues may include: + +- **Navigation.** Inability or difficulty navigating using a keyboard or + assistive technology. +- **Hidden content.** Presentation of content or functionality that is not + accessible to assistive technologies. +- **User control.** Lack of user control over automated content changes. +- **Confusion/Disorientation.** Altering or disabling the normal functionality + of the user agent (browser) or triggering events that the user may not be + aware of. + +A web page containing JavaScript will typically be fully accessible if the +functionality of the script is device independent (does not require only a mouse +or only a keyboard) and the information (content) is available to assistive +technologies. Unfortunately, there is no easy fix that can be applied to solve +all accessibility problems associated with JavaScript. The only way to ensure +JavaScript accessibility is by evaluating each pages that utilizes scripting and +devising a unique solution to any accessibility problem found. + +### JavaScript that does not impact accessibility + +Just because JavaScript is utilized on a page does not mean that the page is +inaccessible. In many cases, JavaScript can be used to increase accessibility. +Additional information, warnings, or instructions can be given to users through +JavaScript prompts. For instance, under the [Section 508 guidelines of United +States law](/standards/508/checklist) and the [Web Content Accessibility +Guidelines](/standards/wcag/checklist), a user must be notified when a timed +response is required and given sufficient time to indicate more time is +required. Such functionality would be difficult with HTML alone. + +JavaScript is sometimes used to create visual interface elements that do not +affect accessibility. JavaScript is commonly used for image rollovers or other +visual-only modifications, where one image is replaced with another when the +mouse is placed above it; for example, when a navigation item changes to display +a shadow, glow, or highlight when the user mouses over it. + +Such uses of JavaScript do not need additional accessibility features +incorporated because important content is not displayed or functionality +introduced by such scripting. + +JavaScript Reliance +------------------- + +It is a common misconception that people with disabilities don't have or 'do' +JavaScript, and thus, that it's acceptable to have inaccessible scripted +interfaces, so long as it is accessible with JavaScript disabled. A 2012 survey +by WebAIM of screen reader users found that [98.6% of respondents had JavaScript +enabled](/projects/screenreadersurvey4/#javascript). The numbers are even higher +for users with [low vision](http://webaim.org/projects/lowvisionsurvey/#javascript) or [motor +disabilities](projects/motordisabilitysurvey/#javascript). In short, people with +disabilities will experience scripting, so scripted content must be made +natively accessible. + +Accessibility guidelines also require scripted interfaces to be accessible. +While WCAG 1.0 from 1999 required that pages be functional and accessible with +scripting disabled, WCAG 2.0 and all other modern guidelines allow you to +require JavaScript, but the scripted content or interactions must be compliant +with the guidelines. + +It is important to keep in mind, however, that some users do disable JavaScript +or may be using technologies that don't support or fully support scripting. If +your web page or application requires scripting, ensure that you account for +users without JavaScript. While this does not necessarily mean that all +functionality must work without scripting (though this would clearly be +optimal), if it does not work without scripting, you must avoid a confusing or +non-functional presentation that may appear to function, but does not because of +lack of JavaScript support. + +JavaScript Event Handlers +======================================================= + +Overview +-------- + +Event handlers accompany existing HTML code or dynamically generated content and +are triggered by a browser or user event - such as when the page loads, when the +user clicks the mouse, or when the time is 8 p.m. Some event handlers are +dependent upon use of a mouse or keyboard. These are called **device dependent** +event handlers. Other event handlers are **device independent** and are +triggered by both the mouse and keyboard or by other means. + +Important + +To ensure accessibility, use either a device independent event handler (one that +works with both the mouse and the keyboard) or use both mouse dependent *and* +keyboard dependent event handlers. + +`onMouseOver` and `onMouseOut` +------------------------------ + +The `onMouseOver` event handler is triggered when the mouse cursor is placed +over an item. As its name implies, `onMouseOver` requires the use of a mouse, +thus it is a device dependent event handler and may cause accessibility issues. +`onMouseOver`, and its companion, `onMouseOut`, may be used, as long as any +important content or functionality is also available without using the 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). + +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. Additional considerations are necessary for +accessibility. + +For screen reader users, the additional content might be provided directly in an +accessible way, such as through alternative text, through an ARIA label or +description, or perhaps through off-screen text. However, for sighted +keyboard-only users, there must be a mechanism for them to access and view the +newly revealed content or functionality. + +In addition to `onMouseOver` and `onMouseOut`, use `onFocus` and `onBlur`. These +actions are triggered when the keyboard is used to navigate to and from an +element. Of course these can only be triggered on keyboard-navigable elements - +links and form controls (or perhaps elements with +[tabindex](http://webaim.org/techniques/keyboard/tabindex)). Simply triggering the change with a +standard link and using both mouse and keyboard dependent event handlers will +help ensure accessibility. + +Sometimes scripting is used to present complex interactions, such as a drop-down +or fly-out menu. While these can be made technically accessible, sometimes an +accessible alternative approach may be more friendly. For example, instead of +forcing users to navigate through a complex and lengthy navigation menu, you +could instead ensure that the menu system is NOT directly keyboard accessible +(nor read by a screen reader), but provide standard link functionality on the +top-level menu item (e.g., "Products"). This link would take the user to a +secondary page that provides standard links to the pages provided through the +complex menu (e.g., a Products landing page that has links to the various +product categories). While not exactly the same interaction that mouse users may +choose, such alternatives are often more intuitive and friendly for all users. + +`onFocus` and `onBlur` +---------------------- + +These event handlers are typically used with form elements, such as text fields, +radio buttons, and submit buttons, but can also be used with links. `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. `onBlur` is triggered when +the cursor leaves a form element or the user 'tabs' away from it. + +Both of these event handlers are device independent, meaning that they can be +performed with the mouse, keyboard, or other assistive technology. The actions +that are performed as a result of these event handlers must be analyzed to +determine if they cause accessibility problems. Typically, these events do not +cause accessibility issues unless they are modifying the default behavior of the +web browser or are interfering with keyboard navigation within the web page. +Examples of such issues might be automatically setting focus to other page areas +with `onFocus` and `onBlur`, trapping the user inside a form control, +dynamically revealing form controls immediately upon a user leaving (blurring) a +form control, etc. Keyboard and screen reader testing will be necessary to +ensure these interactions are built in an accessible manner. + +`onClick` and `onDblClick` +-------------------------- + +The `onClick` event handler is triggered when the mouse is pressed when over an +HTML element. `onClick` is intended to be a mouse dependent event handler. +However, if the `onClick` event handler is used with keyboard-navigable links or +form controls, then most major browsers and assistive technologies trigger +`onClick` if the Enter key is pressed when the link +or control has focus. In these cases, `onClick` is a device independent event +handler. + +Nevertheless, the Enter key will not always trigger +the `onClick` event if it is used with non-link and non-control elements, such +as plain text, table cells, or `
` elements, even if they made keyboard +navigable using tabindex or are focused using scripting. In these cases, it will +be necessary to detect the Enter and Space key presses while focus is placed on them. + +The `onDblClick` event handler is associated with the double click of a mouse on +a selected HTML element. There is no device independent or keyboard equivalent +to `onDblClick`, so it must be avoided. + +`onChange` and `onSelect` +------------------------- + +The `onChange` event handler is triggered when a form element is selected and +changed, for example, when a radio button is initially selected, when the text +changes within a text box or text area, or when the active item in a select menu +changes. Although these event handlers are device independent and can be +activated using the mouse, keyboard, or other device, the actions that are +performed as a result of these event handlers must be analyzed to determine if +they cause accessibility problems. + +A common use of `onChange` is on select menus to trigger navigation when the +active option within the menu is changed. These menus can cause keyboard +accessibility issues because you cannot scroll through the list using a keyboard +without selecting one of the options, and thus triggering the `onChange` event. +Some browsers (including Firefox) override these jump menus so they are not +activated on keyboard change, but only after you either select an item using a +mouse or press Enter if using the keyboard. However, these types of JavaScript +'jump' menus can be made keyboard accessible by removing `onChange` and +providing a submit button separate from the list of choices that activates the +currently selected item. + +Using Device Independent Event Handlers +--------------------------------------- + +Several event handlers are device independent, including `onFocus`, `onBlur`, +`onSelect`, `onChange`, and `onClick` (when `onClick` is used with link or form +elements). When possible, use device independent event handlers. Other event +handlers are device dependent, meaning that they rely wholly upon a certain type +of input. For instance, `onMouseOver`, `onMouseOut`, and `onDblClick` rely upon +the use of a mouse. There are also some event handlers that are dependent upon +use of the keyboard (`onKeyDown`, `onKeyUp`, etc.). Multiple device dependent +event handlers can be used together to allow both mouse and keyboard activation +of JavaScript, but this requires testing across different browsers and assistive +technologies to ensure that accessibility is not limited in any way. + +Other Issues +========================================== + +Dynamic Content and Accessibility +--------------------------------- + +CSS and JavaScript are sometimes used to display, hide, or move information +based upon input from the user or pre-programmed commands. This is sometimes +called Dynamic HTML (DHTML). Most drop-down or fly-out menus or other types of +rich interactions involve scripting. Because most of these elements are modified +based upon mouse input, they are typically inaccessible to users who do not use +a mouse. When dynamic content and interactions is used, two items must be +evaluated to determine its impact on accessibility: + +1. Is the event used to trigger a change device independent? If the mouse is + required, then it is not fully accessible. +2. Is the dynamic content or functionality itself accessible? If assistive + technologies cannot adequately access dynamically triggered content or + functionality, then it is not fully accessible. + +JavaScript Generated Content +---------------------------- + +Content generated by JavaScript, such as through `document.write` or other +functions is generally accessible to assistive technologies. In some cases, +however, if the dynamic content is constantly changing or if it changes while +the user is reading it or has set focus to it, this can interfere with +navigation or browser functionality and cause accessibility problems. For +example, if an element that has keyboard focus is significantly changed, hidden, +or removed from the page, keyboard focus may revert to the very beginning of the +page. + +When using dynamic information, you must first ask yourself if it is necessary +and vital to the function or content of the page. If so, there is often a way to +provide the content without using inaccessible JavaScript. For instance, +ensuring that the dynamic content is generated via user command or interaction, +rather than automatically or randomly, can ensure that the content does not +change when it is focused or being read. + +Additionally, sometimes dynamic content needs to receive keyboard focus. For +example, a dialog box that appears will likely need to be given focus (using +JavaScript `focus()`) after it appears to ensure it is navigated or read +immediately. Additional techniques may be necessary to ensure accessibility for +such dynamic elements - a modal dialog, for example, may need to be programmed +to maintain keyboard focus (rather than allowing focus into other parts of the +page that are not available). + +Pop-up Windows +-------------- + +Pop-up windows provide a unique accessibility concern. First of all, most +usability experts would argue against the use of pop-up windows except in +extreme cases. For a visual user, it may be difficult to notice and navigate to +the new window or tab. For someone who is using assistive technologies, the new +window may be annoying and confusing because the default behavior for the link +has been modified. JavaScript implementation may make the new window difficult +or impossible to resize or scale for someone using a screen enlarger. For +someone who is blind, there is typically an indication that a new window has +opened, but it may be burdensome to then return back to the original page. When +the screen reader user attempts to return to the previous page by selecting the +back button, it may be confusing to find that this does not work. + +When using JavaScript to open new windows, you can modify the size and position +of the new window. You can also add or remove functionality of the window, such +as the ability to resize, display scroll bars, show tool bars, etc. Be very +careful when changing the default behavior of the browser window. If a user has +low vision and must enlarge the content, a small window that cannot be enlarged +and does not display scroll bars would be very inaccessible. Someone with a +motor disability may rely upon large tool bars to accurately control the web +browser, so removing or modifying them may introduce difficulties for this user. + +As you can see, there are many difficulties in both usability and accessibility +that arise through the use of pop-up windows. Care must be taken in making the +decision to use them. If they are used, thorough user testing of your +implementation is vital to ensure accessibility. It is generally best to alert +the user to the fact that a pop-up window will be opened. + +Redirecting and Refreshing Browser Windows +------------------------------------------ + +When the page the browser is viewing suddenly changes or refreshes, the person +viewing that page may become disoriented or confused, especially if that person +is using an assistive technology. This is commonly done with page redirects when +page content has been moved or updated, or with scripting or `` tags to +refresh pages automatically. Accessibility guidelines requires that users be +given control over time sensitive content changes. Do not automatically change +or refresh the browser window without first alerting the user that the change +will occur and giving him/her the ability to disable or postpone the change, or +even better, give the user full control over the page change or redirect. + +Using Pure CSS as a JavaScript Alternative +------------------------------------------ + +As mentioned previously, Cascading Style Sheet (CSS) parameters are often +modified using JavaScript to create dynamically changing content. However, much +of the dynamic functionality often controlled with JavaScript is now available +directly within the specifications for CSS itself. This allows the construction +of interactive and dynamic navigation and layout elements without the need for +JavaScript events. You can create drop-down menus, interactive images, +animation, and other exciting features in web sites without worrying about +device dependent event handlers. + +It's important to note that CSS is intended for visual styling. As such, screen +readers largely ignore CSS. It should not generally be used to present content +or functionality, at least not without ensuring the content or functionality is +fully accessible. Using CSS alone to produce dynamic content should only +employed with much testing in a variety of browsers and screen readers. + +JavaScript Alternatives +===================================================== + +Introduction +------------ + +Whenever JavaScript cannot be made directly accessible, an accessible +alternative must be provided. Also, some user agents, such as web-enabled cell +phones, tablets, and other mobile devices, do not yet fully utilize JavaScript. +There are several ways you can provide accessible alternatives when the +scripting cannot be made accessible or when the end user does not have +JavaScript enabled. + +Server-side Processing +---------------------- + +In many cases, the functionality provided by JavaScript can or should be +duplicated by server-side scripting. For example, JavaScript is often used to +validate form elements before a form is posted. Instead of implementing such +JavaScript programming and its accompanying accessibility techniques, you could +use a server-side script to validate the form elements. Because scripting can +always be disabled or modified by the end user, it should never be relied on for +critical form validation or other functions. JavaScript is often used to write +dynamic information to a web page, such as the current date and/or time. Again, +using a server script or include negates the need for additional accessibility +implementation. + +Progressive Enhancement +----------------------- + +Progressive enhancement is the technique of using scripting to enhance the +functionality or behavior of content and functionality that is already +sufficient without scripting. An example might be adding client-side [form +validation and error recovery](/techniques/formvalidation/) to a form that +already has server-side validation. The form still functions fine without +scripting, but the scripting progressively enhances the form to make it more +usable and accessible. This is an excellent approach to developing accessible +scripted interfaces - first start with accessible markup and core HTML (and +perhaps server-side) functionality, then add accessible scripting to make it +more efficient, friendly, and accessible. + +`