Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The unknown-prop warning will fire if you attempt to render a DOM element with a prop that is not recognized by React as a legal DOM attribute/property. You should ensure that your DOM elements do not have spurious props floating around.
There are a couple of likely reasons this warning could be appearing:
Are you using {...this.props}
or cloneElement(element, this.props)
? Your component is transferring its own props directly to a child element (eg. transferring props). When transferring props to a child component, you should ensure that you are not accidentally forwarding props that were intended to be interpreted by the parent component.
You are using a non-standard DOM attribute on a native DOM node, perhaps to represent custom data. If you are trying to attach custom data to a standard DOM element, consider using a custom data attribute as described on MDN.
React does not yet recognize the attribute you specified. This will likely be fixed in a future version of React. However, React currently strips all unknown attributes, so specifying them in your React app will not cause them to be rendered.
You are using a React component without an upper case. React interprets it as a DOM tag because React JSX transform uses the upper vs. lower case convention to distinguish between user-defined components and DOM tags.
To fix this, composite components should "consume" any prop that is intended for the composite component and not intended for the child component. Example:
Bad: Unexpected layout
prop is forwarded to the div
tag.
Good: The spread syntax can be used to pull variables off props, and put the remaining props into a variable.
Good: You can also assign the props to a new object and delete the keys that you're using from the new object. Be sure not to delete the props from the original this.props
object, since that object should be considered immutable.
Note:
React.PropTypes
has moved into a different package since React v15.5. Please use theprop-types
library instead.We provide a codemod script to automate the conversion.
In a future major release of React, the code that implements PropType validation functions will be stripped in production. Once this happens, any code that calls these functions manually (that isn't stripped in production) will throw an error.
The normal usage of PropTypes is still supported:
Nothing changes here.
Using PropTypes in any other way than annotating React components with them is no longer supported:
If you depend on using PropTypes like this, we encourage you to use or create a fork of PropTypes (such as these two packages).
If you don't fix the warning, this code will crash in production with React 16.
Inspect the stack trace produced by the warning. You will find the component definition responsible for the PropTypes direct call. Most likely, the issue is due to third-party PropTypes that wrap React’s PropTypes, for example:
In this case, ThirdPartyPropTypes.deprecated
is a wrapper calling PropTypes.bool
. This pattern by itself is fine, but triggers a false positive because React thinks you are calling PropTypes directly. The next section explains how to fix this problem for a library implementing something like ThirdPartyPropTypes
. If it's not a library you wrote, you can file an issue against it.
If you are an author of a third party PropTypes library and you let consumers wrap existing React PropTypes, they might start seeing this warning coming from your library. This happens because React doesn't see a "secret" last argument that it passes to detect manual PropTypes calls.
Here is how to fix it. We will use deprecated
from react-bootstrap/react-prop-types as an example. The current implementation only passes down the props
, propName
, and componentName
arguments:
In order to fix the false positive, make sure you pass all arguments down to the wrapped PropType. This is easy to do with the ES6 ...rest
notation:
This will silence the warning.
Most props on a JSX element are passed on to the component, however, there are two special props (ref
and key
) which are used by React, and are thus not forwarded to the component.
For instance, attempting to access this.props.key
from a component (i.e., the render function or propTypes) is not defined. If you need to access the same value within the child component, you should pass it as a different prop (ex: <ListItemWrapper key={result.id} id={result.id} />
). While this may seem redundant, it's important to separate app logic from reconciling hints.
Excerpt
The intent of this Success Criterion is to ensure that when users navigate sequentially through content, they encounter information in an order that is consistent with the meaning of the content and can be operated from the keyboard. This reduces confusion by letting users form a consistent mental model of the content. There may be different orders that reflect logical relationships in the content. For example, moving through components in a table one row at a time or one column at a time both reflect the logical relationships in the content. Either order may satisfy this Success Criterion.
The intent of this Success Criterion is to ensure that when users navigate sequentially through content, they encounter information in an order that is consistent with the meaning of the content and can be operated from the keyboard. This reduces confusion by letting users form a consistent mental model of the content. There may be different orders that reflect logical relationships in the content. For example, moving through components in a table one row at a time or one column at a time both reflect the logical relationships in the content. Either order may satisfy this Success Criterion.
The way that sequential navigation order is determined in Web content is defined by the technology of the content. For example, simple HTML defines sequential navigation via the notion of tabbing order. Dynamic HTML may modify the navigation sequence using scripting along with the addition of a tabindex attribute to allow focus to additional elements. If no scripting or tabindex attributes are used, the navigation order is the order that components appear in the content stream. (See HTML 4.01 Specification, section 17.11, "Giving focus to an element").
An example of keyboard navigation that is not the sequential navigation addressed by this Success Criterion is using arrow key navigation to traverse a tree component. The user can use the up and down arrow keys to move from tree node to tree node. Pressing the right arrow key may expand a node, then using the down arrow key, will move into the newly expanded nodes. This navigation sequence follows the expected sequence for a tree control - as additional items get expanded or collapsed, they are added or removed from the navigation sequence.
The focus order may not be identical to the programmatically determined reading order (see Success Criterion 1.3.2) as long as the user can still understand and operate the Web page. Since there may be several possible logical reading orders for the content, the focus order may match any of them. However, when the order of a particular presentation differs from the programmatically determined reading order, users of one of these presentations may find it difficult to understand or operate the Web page. Authors should carefully consider all these users as they design their Web pages.
For example, a screen reader user interacts with the programmatically determined reading order, while a sighted keyboard user interacts with the visual presentation of the Web page. Care should be taken so that the focus order makes sense to both of these sets of users and does not appear to either of them to jump around randomly.
For clarity:
Focusable components need to receive focus in an order that preserves meaning and operability only when navigation sequences affect meaning and operability.
In those cases where it is required, there may be more than one order that will preserve meaning and operability.
If there is more than one order that preserves meaning and operability, only one of them needs to be provided.
These techniques benefit keyboard users who navigate documents sequentially and expect the focus order to be consistent with the sequential reading order.
People with mobility impairments who must rely on keyboard access for operating a page benefit from a logical, usable focus order.
People with disabilities that make reading difficult can become disoriented when tabbing takes focus someplace unexpected. They benefit from a logical focus order.
People with visual impairments can become disoriented when tabbing takes focus someplace unexpected or when they cannot easily find the content surrounding an interactive element.
Only a small portion of the page may be visible to an individual using a screen magnifier at a high level of magnification. Such a user may interpret a field in the wrong context if the focus order is not logical.
On a web page that contains a tree of interactive controls, the user can use the up and down arrow keys to move from tree node to tree node. Pressing the right arrow key expands a node, then using the down arrow key moves into the newly expanded nodes.
A Web page implements modeless dialogs via scripting. When the trigger button is activated, a dialog opens. The interactive elements in the dialog are inserted in the focus order immediately after the button. When the dialog is open, the focus order goes from the button to the elements of the dialog, then to the interactive element following the button. When the dialog is closed, the focus order goes from the button to the following element.
A Web page implements modal dialogs via scripting. When the trigger button is activated, a dialog opens and focus is set to the first interactive element in the dialog. As long as the dialog is open, focus is limited to the elements of the dialog. When the dialog is dismissed, focus returns to the button or the element following the button.
An HTML Web page is created with the left hand navigation occurring in the HTML after the main body content, and styled with CSS to appear on the left hand side of the page. This is done to allow focus to move to the main body content first without requiring tabIndex attributes or JavaScript.
Note
While this example passes the Success Criterion, it is not necessarily true that all CSS positioning would. More complex positioning examples may or may not preserve meaning and operability
The following example fails to meet the Success Criterion:
A company's Web site includes a form that collects marketing data and allows users to subscribe to several newsletters published by the company. The section of the form for collecting marketing data includes fields such as name, street address, city, state or province, and postal code. Another section of the form includes several checkboxes so that users can indicate newsletters they want to receive. However, the tab order for the form skips between fields in different sections of the form, so that focus moves from the name field to a checkbox, then to the street address, then to another checkbox.
Giving focus to elements in an order that follows sequences and relationships within the content using one of the following techniques:
Changing a Web page dynamically using one of the following techniques:
The following are common mistakes that are considered failures of this Success Criterion by the WCAG Working Group.
assistive technology
Note
functionality provided by assistive technology includes alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).
Note
Assistive technologies often communicate data and messages with mainstream user agents by using and monitoring APIs.
Note
The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles.
Assistive technologies that are important in the context of this document include the following:
screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc. in order to improve the visual readability of rendered text and images;
screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;
text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
speech recognition software, which may be used by people who have some physical disabilities;
alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices.);
alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
keyboard interface
interface used by software to obtain keystroke input
Note
A keyboard interface allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.
A touchscreen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from an external keyboard or from other applications that provide simulated keyboard output, such as handwriting interpreters or speech-to-text applications with "keyboard emulation" functionality.
Note
Operation of the application (or parts of the application) through a keyboard-operated mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface, not through its keyboard interface.
navigated sequentially
user agent
any software that retrieves and presents Web content for users
web page
Note
Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.
Note
For the purposes of conformance with these guidelines, a resource must be "non-embedded" within the scope of conformance to be considered a Web page.
A Web resource including all embedded images and media.
A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://example.com/mail, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the inbox, contacts, or calendar to display, but do not change the URI of the page as a whole.
A customizable portal site, where users can choose content to display from a set of different content modules.
When you enter "http://shopping.example.com/" in your browser, you enter a movie-like interactive shopping environment where you visually move around in a store dragging products off of the shelves around you and into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside. This might be a single-page Web site or just one page within a Web site.
Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see , particularly the "Other Techniques" section.
hardware and/or software that acts as a , or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents
navigated in the order defined for advancing focus (from one element to the next) using a
Web browsers, media players, plug-ins, and other programs — including — that help in retrieving, rendering, and interacting with Web content.
a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a
Excerpt
The aria-labelledby attribute identifies the element (or elements) that labels the element it is applied to.
Accessible Rich Internet Applications (ARIA) is a set of attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to people with disabilities.
It supplements HTML so that interactions and widgets commonly used in applications can be passed to assistive technologies when there is not otherwise a mechanism. For example, ARIA enables accessible JavaScript widgets, form hints and error messages, live content updates, and more.
Warning: Many of these widgets were later incorporated into HTML5, and developers should prefer using the correct semantic HTML element over using ARIA, if such an element exists. For instance, native elements have built-in keyboard accessibility, roles and states. However, if you choose to use ARIA, you are responsible for mimicking the equivalent browser behavior in script.
The first rule of ARIA use is "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."
Note: There is a saying "No ARIA is better than bad ARIA." In WebAim's survey of over one million home pages, they found that Home pages with ARIA present averaged 41% more detected errors than those without ARIA. While ARIA is designed to make web pages more accessible, if used incorrectly, it can do more harm than good.
Here's the markup for a progress bar widget:
This progress bar is built using a <div>
, which has no meaning. We include ARIA roles and properties to add meaning. In this example, the role="progressbar"
attribute informs the browser that this element is actually a JavaScript-powered progress bar widget. The aria-valuemin
and aria-valuemax
attributes specify the minimum and maximum values for the progress bar, and the aria-valuenow
describes the current state of it and therefore must be kept updated with JavaScript.
Along with placing them directly in the markup, ARIA attributes can be added to the element and updated dynamically using JavaScript code like this:
All content that is available to non-assistive technology users must be made available to assistive technologies. Similarly, no features should be included targeting assistive technology users that aren't also accessible to those not using assistive technologies. The above progressbar needs to be styled to make it look like a progressbar.
It would have been much simpler to use the native <progress>
element instead:
Note: The min
attribute is not allowed for the <progress>
element; its minimum value is always 0
.
Note: HTML landmark elements (<main>
, <header>
, <nav>
etc.) have built-in implicit ARIA roles, so there is no need to duplicate them.
Like any other web technology, there are varying degrees of support for ARIA. Support is based on the operating system and browser being used, as well as the kind of assistive technology interfacing with it. In addition, the version of the operating system, browser, and assistive technology are contributing factors. Older software versions may not support certain ARIA roles, have only partial support, or misreport its functionality.
It is also important to acknowledge that some people who rely on assistive technology are reluctant to upgrade their software, for fear of losing the ability to interact with their computer and browser. Because of this, it is important to use semantic HTML elements whenever possible, as semantic HTML has far better support for assistive technology.
It is also important to test your authored ARIA with actual assistive technology. Much as how browser emulators and simulators are not an effective solution for testing full support, proxy assistive technology solutions aren't sufficient to fully guarantee functionality.
The purpose of this spreadsheet is to allow values to be changed in lower environments. After EVERY deployment, the lower environments (Test, QA, etc) have their master databases restored from Production. That is great news that most of the conten is fresh but one issue is that any values that are hard coded for production, are also hard coded for the lower environments. There needs to be a way to modify these "production" values to their lower environment equivalents. That is where this spreadsheet comes in. This spreadsheet is used against each new database restore to update the production values to their lower environmetn equivalents. |
---|
Item - The full sitecore path to the item that needs to be modified.
GUID - The GUID to the item that needs to be modified.
Field - The name of the field on that item that needs to be modified. If you specify the value of DELETEME, this item will be DELETED from Sitecore.
Dev, Test, UAT, HotFix, QA, PFT - Each of these columns contains the change that is need for that specific environment. This is the REPLACEMENT value.
Prod - The value that is being search for which will be replaced by one of the lower environment column valued.
So how does this work? If you have a value that needs to be updated, you will need to add a row and specify ALL the values. ALL the columns are required. In many instanced, the column values may be the same (for instance, Test and UAT and Hotfix may be all the same).
Now here is the caveat. The contents of the Prod column is the driver. That value MUST exist in the lower environments field that is to be replaced (or it will not update). Also, this column value DOES NOT have to be the complete value for the Production field. Only the value that needs to be replaced. Ok, so that is confusing so lets show a couple of examples.
Example 1:
There is a field "Google Analytics Body Code" that contains this complete value:
<!-- Google Tag Manager (noscript) retainstyle--> <noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-N6GDT9" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript> <!-- End Google Tag Manager (noscript)-->
We need to have the value in Test/UAT/Hotfix modified to this:
<!-- Google Tag Manager (noscript) --> <noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-N6GDT9>m_auth=3voUst9VwgohH28csS13-g>m_preview=env-1559>m_cookies_win=x" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript> <!-- End Google Tag Manager (noscript) -->
If you look at the entire value, there is only one change. The value of id=GTM-N6GDT9 has come content appended to it. So in the spreadsheet, the Prod column should specify:
id=GTM-N6GDT9
And the Test and UAT and Hotfix columns should specify:
id=GTM-N6GDT9>m_auth=3voUst9VwgohH28csS13-g>m_preview=env-1559>m_cookies_win=x
There is no need to specify the entire contents. Just specify the value that needs to be change and then the value to be changed to.
Example 2:
There is a field "Link URL" that contains this complete value:
<link text="Register Now" linktype="external" url="https://progress-energy.com/app/LoginRegistration/register.aspx?RC=progress-energy.com%2Fapp%2FUtilityConsultant%2Flist.aspx" anchor="" target="" />
We need to have the value in Test/UAT/Hotfix modified to this:
<link text="Register Now" linktype="external" url="https://dev.progress-energy.com/app/LoginRegistration/register.aspx?RC=dev.progress-energy.com%2Fapp%2FUtilityConsultant%2Flist.aspx" anchor="" target="" />
If you look at the entire value, there is only one change. The value of the url:
"https://progress-energy.com/app/LoginRegistration/register.aspx?RC=progress-energy.com%2Fapp%2FUtilityConsultant%2Flist.aspx
And the Test and UAT and Hotfix columns should specify:
There is no need to specify the entire contents. Just specify the value that needs to be change and then the value to be changed to.
The ability to only need to specify what needs to be changed vs the entire field is quite noticeable on certain very large fields (Rich Text).
Understanding Techniques for WCAG Success Criteria
Excerpt
The Website of the World Wide Web Consortium’s Web Accessibility Initiative.
Page Contents
The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.
Thus the impact of disability is radically changed on the Web because the Web removes barriers to communication and interaction that many people face in the physical world. However, when websites, applications, technologies, or tools are badly designed, they can create barriers that exclude people from using the Web.
Accessibility is essential for developers and organizations that want to create high-quality websites and web tools, and not exclude people from using their products and services.
Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can:
perceive, understand, navigate, and interact with the Web
contribute to the Web
Web accessibility encompasses all disabilities that affect access to the Web, including:
auditory
cognitive
neurological
physical
speech
visual
Web accessibility also benefits people without disabilities, for example:
people using mobile phones, smart watches, smart TVs, and other devices with small screens, different input modes, etc.
older people with changing abilities due to ageing
people with “temporary disabilities” such as a broken arm or lost glasses
people with “situational limitations” such as in bright sunlight or in an environment where they cannot listen to audio
people using a slow Internet connection, or who have limited or expensive bandwidth
For a 7-minute video with examples of how accessibility is essential for people with disabilities and useful for everyone in a variety of situations, see: Web Accessibility Perspectives Video (YouTube)
The Web is an increasingly important resource in many aspects of life: education, employment, government, commerce, health care, recreation, and more. It is essential that the Web be accessible in order to provide equal access and equal opportunity to people with diverse abilities. Access to information and communications technologies, including the Web, is defined as a basic human right in the United Nations Convention on the Rights of Persons with Disabilities (UN CRPD).
The Web offers the possibility of unprecedented access to information and interaction for many people with disabilities. That is, the accessibility barriers to print, audio, and visual media can be much more easily overcome through web technologies.
Accessibility supports social inclusion for people with disabilities as well as others, such as:
older people
people in rural areas
people in developing countries
There is also a strong business case for accessibility. As shown in the previous section, accessible design improves overall user experience and satisfaction, especially in a variety of situations, across different devices, and for older users. Accessibility can enhance your brand, drive innovation, and extend your market reach.
Web accessibility is required by law in many situations.
Web accessibility depends on several components working together, including web technologies, web browsers and other "user agents", authoring tools, and websites.
The W3C Web Accessibility Initiative (WAI) develops technical specifications, guidelines, techniques, and supporting resources that describe accessibility solutions. These are considered international standards for web accessibility; for example, WCAG 2.0 is also an ISO standard: ISO/IEC 40500.
Many aspects of accessibility are fairly easy to understand and implement. Some accessibility solutions are more complex and take more knowledge to implement.
It is most efficient and effective to incorporate accessibility from the very beginning of projects, so you don’t need go back and to re-do work.
When developing or redesigning a website, evaluate accessibility early and throughout the development process to identify accessibility problems early, when it is easier to address them. Simple steps, such as changing settings in a browser, can help you evaluate some aspects of accessibility. Comprehensive evaluation to determine if a website meets all accessibility guidelines takes more effort.
There are evaluation tools that help with evaluation. However, no tool alone can determine if a site meets accessibility guidelines. Knowledgeable human evaluation is required to determine if a site is accessible.
Images should include equivalent alternative text (alt text) in the markup/code.
If alt text isn’t provided for images, the image information is inaccessible, for example, to people who cannot see and use a screen reader that reads aloud the information on a page, including the alt text for the visual image.
When equivalent alt text is provided, the information is available to people who are blind, as well as to people who turn off images (for example, in areas with expensive or low bandwidth). It’s also available to technologies that cannot see images, such as search engines.
Some people cannot use a mouse, including many older users with limited fine motor control. An accessible website does not rely on the mouse; it makes all functionality available from a keyboard. Then people with disabilities can use assistive technologies that mimic the keyboard, such as speech input.
Just as images aren’t available to people who can’t see, audio files aren’t available to people who can’t hear. Providing a text transcript makes the audio information accessible to people who are deaf or hard of hearing, as well as to search engines and other technologies that can’t hear.
It’s easy and relatively inexpensive for websites to provide transcripts. There are also transcription services that create text transcripts in HTML format.
W3C WAI provides a wide range of resources on different aspects of web accessibility standards, education, testing/evaluation, project management, and policy. We encourage you to explore this website, or look through the WAI Resources list.
Excerpt
WCAG 2.1 guidelines and success criteria are designed to be broadly applicable to current and future web technologies, including dynamic applications, mobile, digital television, etc. They are stable and do not change.
WCAG 2.1 guidelines and success criteria are designed to be broadly applicable to current and future web technologies, including dynamic applications, mobile, digital television, etc. They are stable and do not change.
Specific guidance for authors and evaluators on meeting the WCAG success criteria is provided in techniques, which include code examples, resources, and tests. W3C's Techniques for WCAG 2.1 document is updated periodically, about twice per year, to cover more current best practices and changes in technologies and tools.
The three types of guidance in Techniques for WCAG 2.1 are explained below:
Sufficient techniques
Advisory techniques
Failures
Also explained below:
General and technology-specific techniques - which can be sufficient or advisory
Other techniques - beyond what is in W3C's published document
Technique tests
User agent and assistive technology support
Using the techniques - with important considerations
Understanding Conformance provides related information, including on understanding accessibility support.
Techniques are informative—that means they are not required. The basis for determining conformance to WCAG 2.1 is the success criteria from the WCAG 2.1 standard—not the techniques.
Note 1: W3C cautions against requiring W3C's sufficient techniques. The only thing that should be required is meeting the WCAG 2.1 success criteria. To learn more, see:
Note 2: Techniques for WCAG 2.1 uses the words "must" and "should" only to clarify guidance within the techniques, not to convey requirements for WCAG.
Sufficient techniques are reliable ways to meet the success criteria.
From an author's perspective: If you use the sufficient techniques for a given criterion correctly and it is accessibility-supported for your users, you can be confident that you met the success criterion.
From an evaluator's perspective: If web content implements the sufficient techniques for a given criterion correctly and it is accessibility-supported for the content's users, it conforms to that success criterion. (The converse is not true; if content does not implement these sufficient techniques, it does not necessarily fail the success criteria, as explained in Testing Techniques below.)
There may be other ways to meet success criteria besides the sufficient techniques in W3C's Techniques for WCAG 2.1 document, as explained in Other Techniques below. (See also Techniques are Informative above.)
The W3C-documented sufficient techniques are provided in a numbered list where each list item provides a technique or combination of techniques that can be used to meet the success criterion. Where there are multiple techniques on a numbered list item connected by "AND" then all of the techniques must be used to be sufficient. For example, Sufficient Techniques for 1.3.1 has: "G115: Using semantic elements to mark up structure AND H49: Using semantic markup to mark emphasized or special text (HTML)".
Advisory techniques are suggested ways to improve accessibility. They are often very helpful to some users, and may be the only way that some users can access some types of content.
Advisory techniques are not designated as sufficient techniques for various reasons such as:
they may not be sufficient to meet the full requirements of the success criteria;
they may be based on technology that is not yet stable;
they may not be accessibility supported in many cases (for example, assistive technologies do not work with them yet);
they may not be testable;
in some circumstances they may not be applicable or practical, and may even decrease accessibility for some users while increasing it for others;
they may not address the success criterion itself, and instead provide related accessibility benefits.
Authors are encouraged to apply all of the techniques where appropriate to best address the widest range of users' needs.
Failures are things that cause accessibility barriers and fail specific success criteria. The documented failures are useful for:
Authors to know what to avoid,
Evaluators to use for checking if content does not meet WCAG success criteria.
Content that has a failure does not meet WCAG success criteria, unless an alternate version is provided without the failure.
If anyone identifies a situation where a documented failure is not correct, please report the situation as a WCAG comment so that it can be corrected or deleted as appropriate.
General techniques describe basic practices that apply to all technologies. Technology-specific techniques apply to a specific technology.
Some success criteria do not have technology-specific techniques and are covered only with general techniques. Therefore, both the general techniques and the relevant technology-specific techniques should be considered.
Publication of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG 2.1 success criteria and conformance requirements. Developers need to be aware of the limitations of specific technologies and provide content in a way that is accessible to people with disabilities.
In addition to the techniques in W3C's Techniques for WCAG 2.1 document, there are other ways to meet WCAG success criteria. W3C's techniques are not comprehensive and may not cover newer technologies and situations.
Web content does not have to use W3C's published techniques in order to conform to WCAG 2.1.__(See also Techniques are Informative above.)
Content authors can develop different techniques. For example, an author could develop a technique for HTML5, WAI-ARIA, or other new technology. Other organizations may develop sets of techniques to meet WCAG 2.1 success criteria.
Any techniques can be sufficient if:
they satisfy the success criterion, and
all of the WCAG 2.1 conformance requirements are met.
The WCAG Working Group encourages people to submit new techniques so that they can be considered for inclusion in updates of the Techniques for WCAG 2.1 document. Please submit techniques for consideration using the Techniques Submission Form.
Each technique has tests that help:
authors verify that they implemented the technique properly, and
evaluators determine if web content meets the technique.
The tests are only for a technique, they are not tests for conformance to WCAG success criteria.
Failing a technique test does not necessarily mean failing WCAG, because the techniques are discrete (that is, they address one specific point) and they are not required.
Content can meet WCAG success criteria in different ways other than W3C's published sufficient techniques.
Content that passes the sufficient techniques for a specific technology does not necessarily meet all WCAG success criteria. Some success criteria have only general techniques, not technology-specific techniques.
The content must be accessibility supported for the content's users. Some sufficient techniques require browser, assistive technology, or other support that some users might not have.
Thus while the techniques are useful for evaluating content, evaluations must go beyond just checking the sufficient technique tests in order to evaluate how content conforms to WCAG success criteria.
Failures are particularly useful for evaluations because they do indicate non-conformance (unless an alternate version is provided without the failure).
Some techniques require that web content users have specific browsers or assistive technologies in order for the technique to be accessibility-supported. The User Agent and Assistive Technology Support Notes sections of individual techniques include some information to help determine accessibility support.
As time passes, the versions of user agents (browsers, etc.) or assistive technologies listed may not be the current versions. The Working Group may not update most of these notes as new versions are released. Authors should test techniques with the user agents and assistive technologies currently available to their users. See also Understanding Accessibility Support.
Techniques for WCAG 2.1 is not intended to be used as a stand-alone document. Instead, it is expected that content authors will usually use How to Meet WCAG 2.1: A customizable quick reference to read the WCAG success criteria, and follow links from there to specific topics in Understanding WCAG 2.1 and to specific techniques.
Some techniques describe how to provide alternate ways for users to get content. For example, G73: Providing a long description in another location with a link to it that is immediately adjacent to the non-text content mentions a transcript as an alternative for an audio file. Some alternatives must also conform to WCAG. For example, the transcript itself must meet all relevant success criteria.
The code examples in the techniques are intended to demonstrate only the specific point discussed in the technique. They might not demonstrate best practice for other aspects of accessibility, usability, or coding not related to the technique. They are not intended to be copied and used as the basis for developing web content.
Many techniques point to "working examples" that are more robust and may be appropriate for copying and integrating into web content.
The HTML autocomplete
attribute lets web developers specify what if any permission the user agent has to provide automated assistance in filling out form field values, as well as guidance to the browser as to the type of information expected in the field.
It is available on <input>
elements that take a text or numeric value as input, <textarea>
elements, <select>
elements, and <form>
elements.
The source of the suggested values is generally up to the browser; typically values come from past values entered by the user, but they may also come from pre-configured values. For instance, a browser might let the user save their name, address, phone number, and email addresses for autocomplete purposes. Perhaps the browser offers the ability to save encrypted credit card information, for autocompletion following an authentication procedure.
If an <input>
, <select>
or <textarea>
element has no autocomplete
attribute, then browsers use the autocomplete
attribute of the element's form owner, which is either the <form>
element that the element is a descendant of, or the <form>
whose id
is specified by the form
attribute of the element.
For more information, see the autocomplete
attribute in <form>
.
Note: In order to provide autocompletion, user-agents might require <input>
/<select>
/<textarea>
elements to:
Have a name
and/or id
attribute
Be descendants of a <form>
element
The form to have a submit button
"off
"
The browser is not permitted to automatically enter or select a value for this field. It is possible that the document or application provides its own autocomplete feature, or that security concerns require that the field's value not be automatically entered.
Note: In most modern browsers, setting autocomplete
to "off
" will not prevent a password manager from asking the user if they would like to save username and password information, or from automatically filling in those values in a site's login form. See the autocomplete attribute and login fields.
"on
"
The browser is allowed to automatically complete the input. No guidance is provided as to the type of data expected in the field, so the browser may use its own judgement.
"name
"
The field expects the value to be a person's full name. Using "name
" rather than breaking the name down into its components is generally preferred because it avoids dealing with the wide diversity of human names and how they are structured; however, you can use the following autocomplete
values if you do need to break the name down into its components:
"honorific-prefix
"
The prefix or title, such as "Mrs.", "Mr.", "Miss", "Ms.", "Dr.", or "Mlle.".
"given-name
"
The given (or "first") name.
"additional-name
"
The middle name.
"family-name
"
The family (or "last") name.
"honorific-suffix
"
The suffix, such as "Jr.", "B.Sc.", "PhD.", "MBASW", or "IV".
"nickname
"
A nickname or handle.
"email
"
An email address.
"username
"
A username or account name.
"new-password
"
A new password. When creating a new account or changing passwords, this should be used for an "Enter your new password" or "Confirm new password" field, as opposed to a general "Enter your current password" field that might be present. This may be used by the browser both to avoid accidentally filling in an existing password and to offer assistance in creating a secure password (see also Preventing autofilling with autocomplete="new-password").
"current-password
"
The user's current password.
"one-time-code
"
A one-time code used for verifying user identity.
"organization-title
"
A job title, or the title a person has within an organization, such as "Senior Technical Writer", "President", or "Assistant Troop Leader".
"organization
"
A company or organization name, such as "Acme Widget Company" or "Girl Scouts of America".
"street-address
"
A street address. This can be multiple lines of text, and should fully identify the location of the address within its second administrative level (typically a city or town), but should not include the city name, ZIP or postal code, or country name.
"address-line1
", "address-line2
", "address-line3
"
Each individual line of the street address. These should only be present if the "street-address
" is not present.
"address-level4
"
The finest-grained administrative level, in addresses which have four levels.
"address-level3
"
The third administrative level, in addresses with at least three administrative levels.
"address-level2
"
The second administrative level, in addresses with at least two of them. In countries with two administrative levels, this would typically be the city, town, village, or other locality in which the address is located.
"address-level1
"
The first administrative level in the address. This is typically the province in which the address is located. In the United States, this would be the state. In Switzerland, the canton. In the United Kingdom, the post town.
"country
"
A country or territory code.
"country-name
"
A country or territory name.
"postal-code
"
A postal code (in the United States, this is the ZIP code).
"cc-name
"
The full name as printed on or associated with a payment instrument such as a credit card. Using a full name field is preferred, typically, over breaking the name into pieces.
"cc-given-name
"
A given (first) name as given on a payment instrument like a credit card.
"cc-additional-name
"
A middle name as given on a payment instrument or credit card.
"cc-family-name
"
A family name, as given on a credit card.
"cc-number
"
A credit card number or other number identifying a payment method, such as an account number.
"cc-exp
"
A payment method expiration date, typically in the form "MM/YY" or "MM/YYYY".
"cc-exp-month
"
The month in which the payment method expires.
"cc-exp-year
"
The year in which the payment method expires.
"cc-csc
"
The security code for the payment instrument; on credit cards, this is the 3-digit verification number on the back of the card.
"cc-type
"
The type of payment instrument (such as "Visa" or "Master Card").
"transaction-currency
"
The currency in which the transaction is to take place.
"transaction-amount
"
The amount, given in the currency specified by "transaction-currency
", of the transaction, for a payment form.
"language
"
A preferred language, given as a valid BCP 47 language tag.
"bday
"
A birth date, as a full date.
"bday-day
"
The day of the month of a birth date.
"bday-month
"
The month of the year of a birth date.
"bday-year
"
The year of a birth date.
"sex
"
A gender identity (such as "Female", "Fa'afafine", "Male"), as freeform text without newlines.
"tel
"
A full telephone number, including the country code. If you need to break the phone number up into its components, you can use these values for those fields:
"tel-country-code
"
The country code, such as "1" for the United States, Canada, and other areas in North America and parts of the Caribbean.
"tel-national
"
The entire phone number without the country code component, including a country-internal prefix. For the phone number "1-855-555-6502", this field's value would be "855-555-6502".
"tel-area-code
"
The area code, with any country-internal prefix applied if appropriate.
"tel-local
"
The phone number without the country or area code. This can be split further into two parts, for phone numbers which have an exchange number and then a number within the exchange. For the phone number "555-6502", use "tel-local-prefix
" for "555" and "tel-local-suffix
" for "6502".
"tel-extension
"
A telephone extension code within the phone number, such as a room or suite number in a hotel or an office extension in a company.
"impp
"
A URL for an instant messaging protocol endpoint, such as "xmpp:username@example.net".
"url
"
A URL, such as a home page or company web site address as appropriate given the context of the other fields in the form.
"photo
"
The URL of an image representing the person, company, or contact information given in the other fields in the form.
See the WHATWG Standard for more detailed information.
Note: The autocomplete
attribute also controls whether Firefox will — unlike other browsers — persist the dynamic disabled state and (if applicable) dynamic checkedness of an <input>
element, <textarea>
element, or entire <form>
across page loads. The persistence feature is enabled by default. Setting the value of the autocomplete
attribute to off
disables this feature. This works even when the autocomplete
attribute would normally not apply by virtue of its type
. See bug 654072.
The four administrative level fields (address-level1
through address-level4
) describe the address in terms of increasing levels of precision within the country in which the address is located. Each country has its own system of administrative levels, and may arrange the levels in different orders when addresses are written.
address-level1
always represents the broadest administrative division; it is the least-specific portion of the address short of the country name.
Given that different countries write their address in different ways, with each field in different places within the address, and even different sets and numbers of fields entirely, it can be helpful if, when possible, your site is able to switch to the layout expected by your users when presenting an address entry form, given the country the address is located within.
The way each administrative level is used will vary from country to country. Below are some examples; this is not meant to be an exhaustive list.
United States
A typical home address within the United States looks like this:
432 Anywhere St Exampleville CA 95555
In the United States, the least-specific portion of the address is the state, in this case "CA" (the official US Postal Service shorthand for "California"). Thus address-level1
is the state, or "CA" in this case.
The second-least specific portion of the address is the city or town name, so address-level2
is "Exampleville" in this example address.
United States addresses do not use levels 3 and up.
United Kingdom
Address input forms in the UK should contain one address level and one, two or three address lines, depending on the address. A complete address would look like so:
103 Frogmarch Street Upper-Wapping Winchelsea TN99 8ZZ
The address levels are:
address-level1
: The post town — "Winchelsea" in this case.
address-line2
: The locality — "Upper-Wapping" in this case.
address-line1
: The house/street particulars — "103 Frogmarch Street"
The postcode is separate. Note that you can actually use just the postcode and address-line1
to successfully deliver mail in the UK, so they should be the only mandatory items, but usually people tend to provide more details.
China
China can use as many as three administrative levels: the province, the city, and the district.
The 6 digit postal code is not always needed but when supplied it is placed separately with a label for clarity. For example:
北京市东城区建国门北大街 8 号华润大厦 17 层 1708 单元 邮编:100005
Japan
An address in Japan is typically written in one line, in an order from the least-specific to more-specific portions (in reverse order to the United States). There are two or three administrative levels in an address. Additional line can be used to show building names and room numbers. The postal code is separate. For example:
〒 381-0000 長野県長野市某町 123
"〒" and following seven digits shows the postal code.
address-level1
is used for prefectures or the Tokyo Metropolis; "長野県" (Nagano Prefecture) is in this case. address-level2
is typically used for cities, counties, towns and villages; "長野市" (Nagano City) in this case. "某町 123" is address-line1
which consists of an area name and a lot number.
Report problems with this compatibility data on GitHub
Full support
Full support
No support
No support
Compatibility unknown
Compatibility unknown
See implementation notes.
The compatibility table on this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.
The <input>
element.
The <select>
element.
The <textarea>
element.
The <form>
element.
All global attributes.
Specification |
---|
[HTML Standard
# attr-fe-autocomplete](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-autocomplete)
You probably came here because your code is calling your component as a plain function call. This is now deprecated:
React components can no longer be called directly like this. Instead you can use JSX.
If you don't want to, or can't use JSX, then you'll need to wrap your component in a factory before calling it:
This is an easy upgrade path if you have a lot of existing function calls.
If you get a component class from a dynamic source, then it might be unnecessary to create a factory that you immediately invoke. Instead you can just create your element inline: