diff --git "a/processed/scraped.csv" "b/processed/scraped.csv"
new file mode 100644--- /dev/null
+++ "b/processed/scraped.csv"
@@ -0,0 +1,67 @@
+,fname,text
+0,dequeuniversity.comvideo caption.txt,"dequeuniversity.comvideo caption.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    <video> elements must have captions Rule ID: video-caption Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), Section 508     Accessibility testing for dev teams - No experience required  Find and fix up to 80% of accessibility issues with axe DevTools Pro. Get started with your free trial today. No credit card needed.   Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Deaf  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A)Section 508 WCAG Success Criteria [WCAG 2.1 (A)]1.2.2: MUST: Captions (Prerecorded)WCAG Success Criteria [WCAG 2.0 (A)]1.2.2: MUST: Captions (Prerecorded)Section 508 Guidelines1194.22: MUST: Web based intranet and Internet Information & Applications1194.22 (a): MUST: A text equivalent for every non-text element shall be provided (e.g., via ""alt"", ""longdesc"", or in element content)  How to Fix the Problem  Ensure all video elements have a caption using the track element with caption attribute. Ensure the caption conveys all meaningful information in the video element; this includes, but is not limited to, dialogue, musical cues, and sound effects.  Good captions not only include dialogue, but also identify who is speaking and include non-speech information conveyed through sound, including meaningful sound effects.  The following code shows how to add two different tracks - one in English and one in Spanish: <video width=""300"" height=""200"">  <source src=""myVideo.mp4"" type=""video/mp4"">  <track src=""captions_en.vtt"" kind=""captions"" srclang=""en"" label=""english_captions"">  <track src=""captions_es.vtt"" kind=""captions"" srclang=""es"" label=""spanish_captions""> </video> Note:  Captions and subtitles are not the same thing. Captions are necessary for  deaf viewers to understand the content. Captions include a text description  of all important background noises and other sounds, in addition to the text  of all dialog and narration. Subtitles are generally language translations,  to help listeners understand content presented in a language they don't  understand. A Spanish video file could contain English subtitles, for  example. Subtitles generally include only dialog and narration.   Given these differences, you should specify kind=""captions"" for  deaf access, and not kind=""subtitles"".  The src attribute gives the name of the track file. The kind attribute describes the contents of the file. The srclang attribute specifies the language of the track file using the appropriate HTML language code. The label attribute provides a name for the track. None of these attributes, aside from src, are required. Nevertheless, they are highly recommended because they increase clarity.  Youtube offers automatic captioning as a somewhat experimental feature. The automatic captions tend to be too inaccurate to use without some editing, but it gets rid of quite a bit of work. Another useful feature offered by YouTube is the ability to synchronize a transcript with the video automatically. You type up a transcript, upload it to YouTube, and YouTube processes the video and transcript together, using voice recognition to synchronize the transcript with the video. This feature tends to be entirely accurate. In some cases, no additional editing is necessary. In other cases, you need to tweak the timing a bit, but at least you don't have to do all the work manually. Why it Matters  If a video has no caption, deaf users have limited or no access to the information contained in it. Even if a captions track is available, ensure that it contains all meaningful information in the video, not just dialogue.  Deaf viewers can see everything in the video but are not able to hear any of it without captions. Without a caption track, deaf viewers do not have a way of knowing the dialog, narration, or the essential sounds not spoken by people, such as ""dramatic instrumental music,"" applause, screams, or other sounds that set the scene, provide context, or give meaning to the video. Rule Description  An HTML5 video element must include a track element with kind=""captions"" set as a property. The captions should convey all meaningful auditory information in the video including dialogue, musical cues, sound effects, and other relevant information for deaf users. The Algorithm (in simple terms) Ensures video elements have captions. Resources Deque University Deque University Course Pages (subscription required) Open Captions versus Closed CaptionsLive EventsPrerecorded MultimediaVisual CustomizabilityWhat to Include in CaptionsVisual Presentation of CaptionsCaption File Format  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. G87: Providing closed captionsG93: Providing open (always visible) captions Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/video-caption"
+1,developer.chrome.comerrors in console.txt,"developer.chrome.comerrors in console.txt. Browser errors were logged to the console - Chrome DevelopersSkip to content  Home Docs Blog Articles  Home Docs Blog Articles Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsHow the Lighthouse browser error audit failsHow to fix browser errorsResourcesThanks for tuning in to Google I/O. Watch the Chrome content on-demand. Watch now. DismissDocumentation Lighthouse Best Practices Audits Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsHow the Lighthouse browser error audit failsHow to fix browser errorsResourcesBrowser errors were logged to the consolePublished on Thursday, May 2, 2019 • Updated on Wednesday, August 28, 2019 Translated to: Español, Português, 한국어, 中文Table of contents How the Lighthouse browser error audit failsHow to fix browser errorsResourcesMost browsers ship with built-in developer tools. These developer tools usually include a console. The console gives you information about the page that's currently running.Messages logged in the console come from either the web developers who built the page or the browser itself. All console messages have a severity level: Verbose, Info, Warning, or Error. An Error message means there's a problem on your page that you need to resolve.# How the Lighthouse browser error audit failsLighthouse flags all browser errors logged to the console:Each Best Practices audit is weighted equally in the Lighthouse Best Practices Score. Learn more in The Best Practices score.# How to fix browser errorsFix each browser error that Lighthouse reports to ensure that your page runs as expected for all your users.Chrome DevTools includes a couple tools to help you track down the cause of errors:Below the text of each error, the DevTools Console shows the call stack that caused the problematic code to execute.A link at the top-right of each error shows you the code that caused the error.For example, this screenshot shows a page with two errors:In the example above, the first error comes from a web developer via a call to console.error(). The second error comes from the browser and indicates that a variable used in one of the page's scripts does not exist.Below the text of each error, the DevTools Console indicates the call stack in which the error appears. For example, for the first error the Console indicates that an (anonymous) function called the init function, which called the doStuff function. Clicking the pen.js:9 link in the top-right of that error shows you the relevant code.Reviewing the relevant code for each error in this way can help you identify and resolve possible problems.If you can't figure out the cause of an error, try entering the error text into a search engine. If you can't find solutions to your problem, try asking a question on Stack Overflow.If you can't fix an error, consider wrapping it in a try…catch statement to explicitly indicate in the code that you're aware of the issue. You can also use the catch block to handle the error more gracefully.# ResourcesSource code for Browser errors were logged to the console auditConsole OverviewStack Overflowtry…catchUpdated on Wednesday, August 28, 2019 • Improve article Table of contentsHow the Lighthouse browser error audit failsHow to fix browser errorsResourcesFollow us Contribute File a bug View source Related content web.dev Case studies Podcasts Connect Twitter YouTube GitHub Chrome Firebase All products Privacy TermsContent available under the CC-BY-SA-4.0 licenseThis site uses cookies to deliver and enhance the quality of its services and to analyze traffic. If you agree, cookies are also used to serve advertising and to personalize the content and advertisements that you see. Learn more about our use of cookies. Agree No Thanks URL of this webpage is: https://developer.chrome.com/docs/lighthouse/best-practices/errors-in-console"
+2,support.google.com911220.txt,"support.google.com911220.txt. Sorry, this page can't be found. - Search Console Help Skip to main content Search Console HelpSign inGoogle HelpHelp CenterSearch ConsolePrivacy PolicyTerms of ServiceSubmit feedback Send feedback on...This help content & informationGeneral Help Center experienceNextSearch Console  Sorry, this page can't be found. This page doesn't exist in Search Console Help. It may be deleted because the feature doesn't exist anymore, or the URL may be incorrect. Get Search Console Help Search on Google   ©2023 Google Privacy Policy Terms of Service  dansk‎Deutsch‎español‎français‎Indonesia‎italiano‎magyar‎Nederlands‎polski‎português (Brasil)‎suomi‎svenska‎Tiếng Việt‎Türkçe‎čeština‎русский‎‏עברית‏العربيةहिन्दी‎ไทย‎中文（简体）‎中文（繁體）‎日本語‎한국어‎ English‎   Enable Dark Mode Send feedback on... This help content & information General Help Center experience  SearchClear searchClose searchGoogle appsMain menu     false  Search Help Center true true true  true true 83844       false URL of this webpage is: https://support.google.com/webmasters/answer/911220"
+3,web.dev never use the unload eve.txt,"web.dev never use the unload eve.txt. Back/forward cacheSkip to content Open menu  About Blog Learn Explore Patterns Case studies Close Thanks for tuning in to Google I/O. Watch the Chrome content on-demand.On this page Browser compatibilitybfcache basicsHow the ""cache"" worksAPIs to observe bfcacheOptimize your pages for bfcacheNever use the unload eventMinimize use of Cache-Control: no-storeUpdate stale or sensitive data after bfcache restoreAvoid window.opener referencesAlways close open connections before the user navigates awayTest to ensure your pages are cacheableHow bfcache affects analytics and performance measurementMeasuring your bfcache hit ratioPerformance measurementImpact on Core Web VitalsAdditional Resources Home All articles Back/forward cacheOptimize your pages for instant loads when using the browser's back and forward buttons.Nov 10, 2020 — Updated May 25, 2023 Available in: English, Русский, 日本語, and 한국어  Philip Walton TwitterGitHubHomepage Barry Pollard TwitterGitHubHomepageOn this page Browser compatibilitybfcache basicsHow the ""cache"" worksAPIs to observe bfcacheOptimize your pages for bfcacheNever use the unload eventMinimize use of Cache-Control: no-storeUpdate stale or sensitive data after bfcache restoreAvoid window.opener referencesAlways close open connections before the user navigates awayTest to ensure your pages are cacheableHow bfcache affects analytics and performance measurementMeasuring your bfcache hit ratioPerformance measurementImpact on Core Web VitalsAdditional ResourcesBack/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation. It significantly improves the browsing experience for users—especially those with slower networks or devices.As web developers, it's critical to understand how to optimize your pages for bfcache across all browsers, so your users can reap the benefits.Browser compatibility #bfcache has been supported in both Firefox and Safari for many years, across desktop and mobile.Starting in version 86, Chrome enabled bfcache for cross-site navigations on Android for a small percentage of users. In subsequent releases, additional support slowly rolled out. Since version 96, bfcache is enabled for all Chrome users across desktop and mobile.bfcache basics #bfcache is an in-memory cache that stores a complete snapshot of a page (including the JavaScript heap) as the user is navigating away. With the entire page in memory, the browser can quickly and easily restore it if the user decides to return.How many times have you visited a website and clicked a link to go to another page, only to realize it's not what you wanted and click the back button? In that moment, bfcache can make a big difference in how fast the previous page loads:Without bfcache enabledA new request is initiated to load the previous page, and, depending on how well that page has been optimized for repeat visits, the browser might have to re-download, re-parse, and re-execute some (or all) of resources it just downloaded.With bfcache enabledLoading the previous page is essentially instant, because the entire page can be restored from memory, without having to go to the network at allCheck out this video of bfcache in action to understand the speed up it can bring to navigations: In the video above, the example with bfcache is quite a bit faster than the example without it.bfcache not only speeds up navigation, it also reduces data usage, since resources do not have to be downloaded again.Chrome usage data shows that 1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. With bfcache enabled, browsers could eliminate the data transfer and time spent loading for billions of web pages every single day!How the ""cache"" works #The ""cache"" used by bfcache is different from the HTTP cache (which is also useful in speeding up repeat navigations). The bfcache is a snapshot of the entire page in memory (including the JavaScript heap), whereas the HTTP cache contains only the responses for previously made requests. Since it's quite rare that all requests required to load a page can be fulfilled from the HTTP cache, repeat visits using bfcache restores are always faster than even the most well-optimized non-bfcache navigations.Creating a snapshot of a page in memory, however, involves some complexity in terms of how best to preserve in-progress code. For example, how do you handle setTimeout() calls where the timeout is reached while the page is in the bfcache?The answer is that browsers pause running any pending timers or unresolved promises—essentially all pending tasks in the JavaScript task queues—and resume processing tasks when (or if) the page is restored from the bfcache.In some cases this is fairly low-risk (for example, timeouts or promises), but in other cases it might lead to very confusing or unexpected behavior. For example, if the browser pauses a task that's required as part of an IndexedDB transaction, it can affect other open tabs in the same origin (since the same IndexedDB databases can be accessed by multiple tabs simultaneously). As a result, browsers will generally not attempt to cache pages in the middle of an IndexedDB transaction or using APIs that might affect other pages.For more details on how various API usage affects a page's bfcache eligibility, see Optimize your pages for bfcache below.APIs to observe bfcache #While bfcache is an optimization that browsers do automatically, it's still important for developers to know when it's happening so they can optimize their pages for it and adjust any metrics or performance measurement accordingly.The primary events used to observe bfcache are the page transition events—pageshow and pagehide—which have been around as long as bfcache has and are supported in pretty much all browsers in use today.The newer Page Lifecycle events—freeze and resume—are also dispatched when pages go in or out of the bfcache, as well as in some other situations. For example when a background tab gets frozen to minimize CPU usage. Note, the Page Lifecycle events are currently only supported in Chromium-based browsers.Observe when a page is restored from bfcache #The pageshow event fires right after the load event when the page is initially loading and any time the page is restored from bfcache. The pageshow event has a persisted property which will be true if the page was restored from bfcache (and false if not). You can use the persisted property to distinguish regular page loads from bfcache restores. For example:window.addEventListener('pageshow', (event) => { if (event.persisted) { console.log('This page was restored from the bfcache.'); } else { console.log('This page was loaded normally.'); }}); In browsers that support the Page Lifecycle API, the resume event will also fire when pages are restored from bfcache (immediately before the pageshow event), though it will also fire when a user revisits a frozen background tab. If you want to restore a page's state after it's frozen (which includes pages in the bfcache), you can use the resume event, but if you want to measure your site's bfcache hit rate, you'd need to use the pageshow event. In some cases, you might need to use both.See Implications for performance and analytics for more details on bfcache measurement best practices.Observe when a page is entering bfcache #The pagehide event is the counterpart to the pageshow event. The pageshow event fires when a page is either loaded normally or restored from the bfcache. The pagehide event fires when the page is either unloaded normally or when the browser attempts to put it into the bfcache.The pagehide event also has a persisted property, and if it's false then you can be confident a page is not about to enter the bfcache. However, if the persisted property is true, it doesn't guarantee that a page will be cached. It means that the browser intends to cache the page, but there may be factors that make it impossible to cache.window.addEventListener('pagehide', (event) => { if (event.persisted) { console.log('This page *might* be entering the bfcache.'); } else { console.log('This page will unload normally and be discarded.'); }}); Similarly, the freeze event will fire immediately after the pagehide event (if the event's persisted property is true), but again that only means the browser intends to cache the page. It may still have to discard it for a number of reasons explained below.Optimize your pages for bfcache #Not all pages get stored in bfcache, and even when a page does get stored there, it won't stay there indefinitely. It's critical that developers understand what makes pages eligible (and ineligible) for bfcache to maximize their cache-hit rates.The following sections outline the best practices to make it as likely as possible that the browser can cache your pages.Never use the unload event #The most important way to optimize for bfcache in all browsers is to never use the unload event. Ever!The unload event is problematic for browsers because it predates bfcache and many pages on the internet operate under the (reasonable) assumption that a page will not continue to exist after the unload event has fired. This presents a challenge because many of those pages were also built with the assumption that the unload event would fire any time a user is navigating away, which is no longer true (and hasn't been true for a long time).So browsers are faced with a dilemma, they have to choose between something that can improve the user experience—but might also risk breaking the page.On desktop, Chrome and Firefox have chosen to make pages ineligible for bfcache if they add an unload listener, which is less risky but also disqualifies a lot of pages. Safari will attempt to cache some pages with an unload event listener, but to reduce potential breakage it will not run the unload event when a user is navigating away, which makes the event very unreliable.On mobile, Chrome and Safari will attempt to cache pages with an unload event listener since the risk of breakage is lower due to the fact that the unload event has always been extremely unreliable on mobile. Firefox treats pages that use unload as ineligible for the bfcache, except on iOS, which requires all browsers to use the WebKit rendering engine, and so it behaves like Safari.Instead of using the unload event, use the pagehide event. The pagehide event fires in all cases where the unload event currently fires, and it also fires when a page is put in the bfcache.In fact, Lighthouse has a no-unload-listeners audit, which will warn developers if any JavaScript on their pages (including that from third-party libraries) adds an unload event listener.WarningNever add an unload event listener! Use the pagehide event instead. Adding an unload event listener will make your site slower in Firefox, and the code won't even run most of the time in Chrome and Safari.Only add beforeunload listeners conditionally #The beforeunload event will not make your pages ineligible for bfcache in Chrome or Safari, but it will make them ineligible in Firefox, so avoid using it unless absolutely necessary.Unlike the unload event, however, there are legitimate uses for beforeunload. For example, when you want to warn the user that they have unsaved changes they'll lose if they leave the page. In this case, it's recommended that you only add beforeunload listeners when a user has unsaved changes and then remove them immediately after the unsaved changes are saved.Don'twindow.addEventListener('beforeunload', (event) => { if (pageHasUnsavedChanges()) { event.preventDefault(); return event.returnValue = 'Are you sure you want to exit?'; }}); The code above adds a beforeunload listener unconditionally.Dofunction beforeUnloadListener(event) { event.preventDefault(); return event.returnValue = 'Are you sure you want to exit?';};// A function that invokes a callback when the page has unsaved changes.onPageHasUnsavedChanges(() => { window.addEventListener('beforeunload', beforeUnloadListener);});// A function that invokes a callback when the page's unsaved changes are resolved.onAllChangesSaved(() => { window.removeEventListener('beforeunload', beforeUnloadListener);}); The code above only adds the beforeunload listener when it's needed (and removes it when it's not).Minimize use of Cache-Control: no-store #Cache-Control: no-store is an HTTP header web servers can set on responses that instructs the browser not to store the response in any HTTP cache. This should be used for resources containing sensitive user information, for example pages behind a login.Though bfcache is not an HTTP cache, historically, when Cache-Control: no-store is set on the page resource itself (as opposed to any subresource), browsers have chosen not to store the page in bfcache. There is work currently underway to change this behavior for Chrome in a privacy-preserving manner, but at present any pages using Cache-Control: no-store will not be eligible for bfcache.Since Cache-Control: no-store restricts a page's eligibility for bfcache, it should only be set on pages that contain sensitive information where caching of any sort is never appropriate.For pages that wish to always serve up-to-date content—and that content does not contain sensitive information—use Cache-Control: no-cache or Cache-Control: max-age=0. These directives instruct the browser to revalidate the content before serving it, and they do not affect a page's bfcache eligibility.Note that when a page is restored from bfcache, it is restored from memory, not from the HTTP cache. As a result, directives like Cache-Control: no-cache or Cache-Control: max-age=0 are not taken into account, and no revalidation occurs before the content is displayed to the user.This is still likely a better user experience, however, as bfcache restores are instant and—since pages do not stay in the bfcache for very long—it's unlikely that the content is out of date. However, if your content does change minute-by-minute, you can fetch any updates using the pageshow event, as outlined in the next section.Update stale or sensitive data after bfcache restore #If your site keeps user state—especially any sensitive user information—that data needs to be updated or cleared after a page is restored from bfcache.For example, if a user navigates to a checkout page and then updates their shopping cart, a back navigation could potentially expose out-of-date information if a stale page is restored from bfcache.Another, more critical example is if a user signs out of a site on a public computer and the next user clicks the back button. This could potentially expose private data that the user assumed was cleared when they logged out.To avoid situations like this, it's good to always update the page after a pageshow event if event.persisted is true.The following code checks for the presence of a site-specific cookie in the pageshow event and reloads if the cookie is not found:window.addEventListener('pageshow', (event) => { if (event.persisted && !document.cookie.match(/my-cookie/)) { // Force a reload if the user has logged out. location.reload(); }}); Avoid window.opener references #In some browsers (including Chromium-based browsers) if a page was opened using window.open() or (in Chromium-based browsers prior to version 88) from a link with target=_blank—without specifying rel=""noopener""—then the opening page will have a reference to the window object of the opened page.In addition to being a security risk, a page with a non-null window.opener reference cannot safely be put into the bfcache because that could break any pages attempting to access it.As a result, it's best to avoid creating window.opener references. You can do this by using rel=""noopener"" whenever possible. If your site requires opening a window and controlling it through window.postMessage() or directly referencing the window object, neither the opened window nor the opener will be eligible for the bfcache.Always close open connections before the user navigates away #As mentioned above, when a page is put into the bfcache all scheduled JavaScript tasks are paused and then resumed when the page is taken out of the cache.If these scheduled JavaScript tasks are only accessing DOM APIs—or other APIs isolated to just the current page—then pausing these tasks while the page is not visible to the user is not going to cause any problems.However, if these tasks are connected to APIs that are also accessible from other pages in the same origin (for example: IndexedDB, Web Locks, WebSockets, etc.) this can be problematic because pausing these tasks may prevent code in other tabs from running.As a result, some browsers will not attempt to put a page in bfcache in the following scenarios:Pages with an open IndexedDB connectionPages with in-progress fetch() or XMLHttpRequestPages with an open WebSocket or WebRTC connectionIf your page is using any of these APIs, it's best to always close connections and remove or disconnect observers during the pagehide or freeze event. That will allow the browser to safely cache the page without the risk of it affecting other open tabs.Then, if the page is restored from the bfcache, you can re-open or re-connect to those APIs (in the pageshow or resume event).The following example shows how to ensure your pages are eligible for bfcache when using IndexedDB by closing an open connection in the pagehide event listener:let dbPromise;function openDB() { if (!dbPromise) { dbPromise = new Promise((resolve, reject) => {  const req = indexedDB.open('my-db', 1);  req.onupgradeneeded = () => req.result.createObjectStore('keyval');  req.onerror = () => reject(req.error);  req.onsuccess = () => resolve(req.result); }); } return dbPromise;}// Close the connection to the database when the user is leaving.window.addEventListener('pagehide', () => { if (dbPromise) { dbPromise.then(db => db.close()); dbPromise = null; }});// Open the connection when the page is loaded or restored from bfcache.window.addEventListener('pageshow', () => openDB()); Test to ensure your pages are cacheable #Chrome DevTools can help you test your pages to ensure they're optimized for bfcache, and identify any issues that may be preventing them from being eligible.To test a particular page, navigate to it in Chrome and then in DevTools go to Application > Back-forward Cache. Next click the Run Test button and DevTools will attempt to navigate away and back to determine whether the page could be restored from bfcache.The Back/forward Cache feature in DevTools is currently in active development. We strongly encourage developers to test their pages in Chrome Canary to ensure they're running the latest version of DevTools and getting the most up-to-date bfcache recommendations.If successful, the panel will report ""Restored from back-forward cache"":If unsuccessful, the panel will indicate the page was not restored and list the reason why. If the reason is something you as a developer can address, that will also be indicated:In the screenshot above, the use of an unload event listener is preventing the page from being eligible for bfcache. You can fix that by switching from unload to using pagehide instead:Don'twindow.addEventListener('unload', ...); Dowindow.addEventListener('pagehide', ...); Lighthouse 10.0 also added a bfcache audit, which performs a similar test to the one DevTools does, and also provides reasons why the page is ineligible if the audit fails. Take a look at the bfcache audit's docs for more information.How bfcache affects analytics and performance measurement #If you track visits to your site with an analytics tool, you will likely notice a decrease in the total number of pageviews reported as Chrome continues to enable bfcache for more users.In fact, you're likely already underreporting pageviews from other browsers that implement bfcache since most of the popular analytics libraries do not track bfcache restores as new pageviews.If you don't want your pageview counts to go down due to Chrome enabling bfcache, you can report bfcache restores as pageviews (recommended) by listening to the pageshow event and checking the persisted property.The following example shows how to do this with Google Analytics; the logic should be similar for other analytics tools:// Send a pageview when the page is first loaded.gtag('event', 'page_view');window.addEventListener('pageshow', (event) => { // Send another pageview if the page is restored from bfcache. if (event.persisted) { gtag('event', 'page_view'); }}); Measuring your bfcache hit ratio #You may also wish to track whether the bfcache was used, to help identify pages that are not utilizing the bfcache. For example, with an event:window.addEventListener('pageshow', (event) => { // You can measure bfcache hit rate by tracking all bfcache restores and // other back/forward navigations via a separate event. const navigationType = performance.getEntriesByType('navigation')[0].type; if (event.persisted || navigationType == 'back_forward' ) { gtag('event', 'back_forward_navigation', {  'isBFCache': event.persisted, }); }}); It is important to realize that there are a number of scenarios, outside of the site owners control, when a Back/Forward navigation will not use the bfcache, including:when the user quits the browser and starts it againwhen the user duplicates a tabwhen the user closes a tab and uncloses itEven without those exclusions the bfcache will be discarded after a period to conserve memory.So, website owners should not be expecting a 100% bfcache hit ratio for all back_forward navigations. However, measuring their ratio can be useful to identify pages where the page itself is preventing bfcache usage for a high proportion of back and forward navigations.The Chrome team is working on a NotRestoredReasons API to help expose the reasons why the bfcache was not used to help developers understand the reasoning the cache was not used and if this is something they can work on to improve for their sites.Performance measurement #bfcache can also negatively affect performance metrics collected in the field, specifically metrics that measure page load times.Since bfcache navigations restore an existing page rather than initiate a new page load, the total number of page loads collected will decrease when bfcache is enabled. What's critical, though, is that the page loads being replaced by bfcache restores would likely have been some of the fastest page loads in your dataset. This is because back and forward navigations, by definition, are repeat visits, and repeat page loads are generally faster than page loads from first time visitors (due to HTTP caching, as mentioned earlier).The result is fewer fast page loads in your dataset, which will likely skew the distribution slower—despite the fact that the performance experienced by the user has probably improved!There are a few ways to deal with this issue. One is to annotate all page load metrics with their respective navigation type: navigate, reload, back_forward, or prerender. This will allow you to continue to monitor your performance within these navigation types—even if the overall distribution skews negative. This approach is recommended for non-user-centric page load metrics like Time to First Byte (TTFB).For user-centric metrics like the Core Web Vitals, a better option is to report a value that more accurately represents what the user experiences.CautionThe back_forward navigation type in the Navigation Timing API is not to be confused with bfcache restores. The Navigation Timing API only annotates page loads, whereas bfcache restores are re-using a page loaded from a previous navigation.Impact on Core Web Vitals #Core Web Vitals measure the user's experience of a web page across a variety of dimensions (loading speed, interactivity, visual stability), and since users experience bfcache restores as faster navigations than traditional page loads, it's important that the Core Web Vitals metrics reflect this. After all, a user doesn't care whether or not bfcache was enabled, they just care that the navigation was fast!Tools like the Chrome User Experience Report, that collect and report on the Core Web Vitals metrics treat bfcache restores as separate page visits in their dataset.And while there aren't (yet) dedicated web performance APIs for measuring these metrics after bfcache restores, their values can be approximated using existing web APIs.For Largest Contentful Paint (LCP), you can use the delta between the pageshow event's timestamp and the timestamp of the next painted frame (since all elements in the frame will be painted at the same time). Note that in the case of a bfcache restore, LCP and FCP will be the same.For First Input Delay (FID), you can re-add the event listeners (the same ones used by the FID polyfill) in the pageshow event, and report FID as the delay of the first input after the bfcache restore.For Cumulative Layout Shift (CLS), you can continue to keep using your existing Performance Observer; all you have to do is reset the current CLS value to 0.For more details on how bfcache affects each metric, refer to the individual Core Web Vitals metric guides pages. And for a specific example of how to implement bfcache versions of these metrics in code, refer to the PR adding them to the web-vitals JS library.As of v1, the web-vitals JavaScript library supports bfcache restores in the metrics it reports. Developers using v1 or greater should not need to update their code.Additional Resources #Firefox Caching (bfcache in Firefox)Page Cache (bfcache in Safari)Back/forward cache: web exposed behavior (bfcache differences across browsers)bfcache tester (test how different APIs and events affect bfcache in browsers)Performance Game Changer: Browser Back/Forward Cache (a case study from Smashing Magazine showing dramatic Core Web Vitals improvements by enabling bfcache)PerformanceWeb VitalsLast updated May 25, 2023 — Improve article Return to all articles Share We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.Contribute File a bug View source Related content developer.chrome.com Chrome updates Case studies Podcasts Shows Connect Twitter YouTube Chrome Firebase Google Cloud Platform All products Dark theme Terms & Privacy Community Guidelines Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. By Chrome DevRel URL of this webpage is: https://web.dev/bfcache/#never-use-the-unload-even"
+4,dequeuniversity.comdocument title.txt,"dequeuniversity.comdocument title.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Documents must have <title> element to aid in navigation Rule ID: document-title Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Accessibility testing for dev teams - No experience required  Find and fix up to 80% of accessibility issues with axe DevTools Pro. Get started with your free trial today. No credit card needed.   Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]2.4.2: MUST: Page TitledWCAG Success Criteria [WCAG 2.0 (A)]2.4.2: MUST: Page Titled  How to Fix the Problem  Add an informative title to the document using the title element with meaningful text.  Ensure that the document's title contains short, descriptive text summarizing the page's contents.  Add a title to the document using the title tag. You can do this as follows: 	<html> 		<title> A brief, clear, informative, and unique title</title> 		<!-- the rest of the page content --> 	</html>  A good title is brief, clear, informative, and unique. Ensure that the document's title contains short, descriptive text summarizing the page's contents. To pass this rule, it’s not sufficient to simply have a title element; the element must also contain meaningful text.  Be sure to follow these best practices when writing a title:  Replace placeholder titles such as “untitled page” with a more appropriate  phrase   Make each title unique - don’t duplicate titles across pages, even if they  are similar.   Put all unique information first. If you want to include the company’s name  or brand in the title, this information should go after the unique content.  Otherwise, users of screen readers will have to listen to this information  over and over as they search for the page that interests them.   Make the page title match the top heading (ideally labelled as h1) on your  page. These don’t need to be identical, but it often makes sense to make  them very similar, since the title and h1 elements  serve essentially the same purpose.  In addition to making the page more accessible, titles have other benefits, since search engines use titles when filtering, ordering, and displaying results. Improving the accessibility of your site can also have the effect of making your page more findable. Why it Matters  Screen reader users use page titles to get an overview of the contents of the page. Navigating through pages can quickly become difficult and confusing for screen reader users if the pages are not marked with a title. The page title element is the first thing screen reader users hear when first loading a web page.  The title is the first thing that screen reader users hear when they arrive at a page. If there is no title or if the title is not descriptive and unique, screen reader users must read through the page to determine its contents and purpose. Rule Description  The HTML document must have a title element to provide users with an overview of its content, and when present, it must not be empty. The Algorithm (in simple terms) Ensures that each HTML document contains a title. Resources Deque University Deque University Course Pages (subscription required) Page Title  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. H25: Providing a title using the title element Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/document-title"
+5,web.devlong tasks devtools.txt,"web.devlong tasks devtools.txt. Are long JavaScript tasks delaying your Time to Interactive?Skip to content Open menu  About Blog Learn Explore Patterns Case studies Close Thanks for tuning in to Google I/O. Watch the Chrome content on-demand.On this page What are Long Tasks?Are there Long Tasks in my page that could delay interactivity?What is causing my Long Tasks?What are common ways to optimize Long Tasks? Home All articles Are long JavaScript tasks delaying your Time to Interactive?Learn to diagnose costly work preventing user interaction.May 29, 2019 — Updated Nov 30, 2022 Available in: English, Español, Português, Русский, 中文, 日本語, and 한국어  Addy Osmani TwitterGitHubOn this page What are Long Tasks?Are there Long Tasks in my page that could delay interactivity?What is causing my Long Tasks?What are common ways to optimize Long Tasks?Long Tasks can keep the main thread busy, delaying user interaction. Chrome DevTools can now visualize Long Tasks, making it easier to see tasks to optimize.If you use Lighthouse to audit your pages, you may be familiar with Time to Interactive, a metric representing when users can interact with your page and get a response. But did you know Long (JavaScript) Tasks can contribute heavily to a poor TTI?What are Long Tasks? #A Long Task is JavaScript code that monopolizes the main thread for extended periods of time, causing the UI to ""freeze"".While a web page is loading, Long Tasks can tie up the main thread and make the page unresponsive to user input even if it looks ready. Clicks and taps often don't work because event listeners, click handlers etc have not yet been attached.CPU-heavy Long Tasks occur due to complex work that takes longer than 50ms. Why 50ms? The RAIL model suggests you process user input events in 50ms to ensure a visible response within 100ms. If you don't, the connection between action and reaction is broken.ImportantWhile the RAIL model suggests providing a visual response to user input within 100 ms, the Interaction to Next Paint (INP) metric's thresholds allow for up to 200 ms in order to set more easily achievable expectations, especially for slower devices.Are there Long Tasks in my page that could delay interactivity? #Until now, you've needed to manually look for ""long yellow blocks"" of script over 50ms long in Chrome DevTools or use the Long Tasks API to figure out what tasks were delaying interactivity. This could be a little cumbersome.To help ease your performance auditing workflow, DevTools now visualizes Long Tasks. Tasks (shown in gray) have red flags if they are Long Tasks.Record a trace in the Performance panel of loading up a web page.Look for a red flag in the main thread view. You should see tasks are now gray (""Task"").Hovering over a bar will let you know the duration of the task and if it was considered ""long"".What is causing my Long Tasks? #To discover what is causing a long task, select the gray Task bar. In the drawer beneath, select Bottom-Up and Group by Activity. This allows you to see what activities contributed the most (in total) to the task taking so long to complete. Below, it appears to be a costly set of DOM queries.What are common ways to optimize Long Tasks? #Large scripts are often a major cause of Long Tasks so consider splitting them up. Also keep an eye on third-party scripts; their Long Tasks can delay primary content from getting interactive.Break all your work into small chunks (that run in < 50ms) and run these chunks at the right place and time; the right place may even be off the main thread, in a worker. Phil Walton's Idle Until Urgent is a good read on this topic. See also the optimize long tasks article for general strategies for managing and breaking up long tasks.Keep your pages responsive. Minimizing Long Tasks is a great way to ensure your users have a delightful experience when they visit your site. For more on Long Tasks, check out User-centric Performance Metrics.PerformanceLast updated Nov 30, 2022 — Improve article Return to all articles Share We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.Contribute File a bug View source Related content developer.chrome.com Chrome updates Case studies Podcasts Shows Connect Twitter YouTube Chrome Firebase Google Cloud Platform All products Dark theme Terms & Privacy Community Guidelines Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. By Chrome DevRel URL of this webpage is: https://web.dev/long-tasks-devtools"
+6,dequeuniversity.commeta viewport.txt,"dequeuniversity.commeta viewport.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Zooming and scaling must not be disabled Rule ID: meta-viewport Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (AA), WCAG 2.0 (AA)     Accessibility testing for dev teams - No experience required  Find and fix up to 80% of accessibility issues with axe DevTools Pro. Get started with your free trial today. No credit card needed.   Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Low Vision  Standard(s) WCAG 2.1 (AA)WCAG 2.0 (AA) WCAG Success Criteria [WCAG 2.1 (AA)]1.4.4: MUST: Resize textWCAG Success Criteria [WCAG 2.0 (AA)]1.4.4: MUST: Resize text  How to Fix the Problem  Remove the user-scalable=""no"" parameter from the content attribute of the <meta name=""viewport""> element in order to allow zooming and ensure the maximum-scale parameter is not less than 2.  A meta viewport element tells the browser how to control the page's dimensions and to scale, but the ability to zoom can be disabled as a result of its use. Note:  The browser's viewport focus does not affect the programmatic focus, but  when the window is small, the area will only include a small part of the  page, and the programmable focus will not follow the viewport.  Remove the user-scalable=""no"" parameter from the content attribute of the <meta name=""viewport""> element in order to allow zooming. Why it Matters  The user-scalable=""no"" parameter inside the content attribute of <meta name=""viewport""> element disables zooming on a page. The maximum-scale parameter limits the amount the user can zoom. This is problematic for people with low vision who rely on screen magnifiers to properly see the contents of a web page.  Users with partial vision and low vision often choose to enlarge the fonts on their browser to make text on the web easier to read. The browser's viewport focus is everything visible in the browser window at a given moment. Maximizing the browser to full size on a high-resolution monitor creates a large the viewport focus area and may include the entire web page.  If the browser window is small, the viewport focus area only includes a small part of the web page. The browser's viewport focus does not affect the programmatic focus. Users can scroll up and down the web page, but the programmatic focus does not follow the viewport. The Web Content Accessibility Guidelines calls for developers to design pages so that they support resize up to 200%.  Ensures that the user-scalable=""no"" parameter is not present in the <meta name=""viewport""> element and the maximum-scale parameter is not less than 2. Rule Description  The document must not use the user-scalable=""no"" parameter in the <meta name=""viewport""> element because it disables text scaling and zooming which is essential to users with low vision. The Algorithm (in simple terms)  Ensures that the user-scalable=""no"" parameter is not present in the <meta name=""viewport""> element and the maximum-scale parameter is not less than 2.  Resources Deque University Deque University Course Pages (subscription required) Allowing Mobile ZoomText Resize/ZoomLinear Text ReflowMagnification Visual Quality  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. W3C Understanding Success Criterion 1.4.4: Resize text Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/meta-viewport"
+7,dequeuniversity.comaria command name.txt,"dequeuniversity.comaria command name.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    ARIA commands must have an accessible name Rule ID: aria-command-name Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)         Learn Web Accessibility   										Subscribe to our extensive curriculum of online self-paced courses 									 Learn More about Deque University   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Low Vision Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, Value  How to Fix the Problem Correct markup solutions  The aria-command-name rule has four markup patterns that pass  test criteria: <div role=""link"" id=""al"" aria-label=""Name""></div> <div role=""button"" id=""alb"" aria-labelledby=""labeldiv""></div> <div role=""menuitem"" id=""combo"" aria-label=""Aria Name"">Name</div> <div role=""link"" id=""title"" title=""Title""></div>   Ensure that each element with role=""link"",  role=""button"", or role=""menuitem"" has one of the  following characteristics:  Inner text that is discernible to screen reader users. Non-empty aria-label attribute. aria-labelledby pointing to element with text which is   discernible to screen reader users.   Incorrect markup solutions  The aria-command-name rule has four markup patterns that fail  testing criteria: <div role=""link"" id=""empty""></div> <div role=""button"" id=""alempty"" aria-label=""""></div> <div role=""menuitem"" id=""albmissing"" aria-labelledby=""nonexistent""></div> <div role=""link"" id=""albempty"" aria-labelledby=""emptydiv""></div> <div id=""emptydiv""></div> Why it Matters  Screen reader users are not able to discern the purpose of elements with role=""link"", role=""button"", or role=""menuitem"" that do not have an accessible name. Rule Description  ARIA command elements must have discernible text that clearly describes the destination, purpose, function, or action for screen reader users. The Algorithm (in simple terms)  Checks all elements with role=""link"", role=""button"", or role=""menuitem"" to ensure that they have a discernable, accessible name.  Resources Deque University Deque University Course Pages (subscription required) 						No related course information available. 					  Deque University  Contribute to axe-core on GitHub Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-command-name"
+8,developers.google.combudgets.txt,"developers.google.combudgets.txt. Use Lighthouse for performance budgetsSkip to content Open menu  About Blog Learn Explore Patterns Case studies Close Thanks for tuning in to Google I/O. Watch the Chrome content on-demand.On this page Install LighthouseCreate a BudgetRun LighthouseView the Results Home All articles Use Lighthouse for performance budgetsJun 14, 2019 — Updated Apr 3, 2020 Available in: English, Español, Português, Русский, 中文, 日本語, and 한국어 Appears in: Fast load times Katie Hempenius TwitterGitHubGlitchHomepageOn this page Install LighthouseCreate a BudgetRun LighthouseView the ResultsLighthouse now supports performance budgets. This feature, known as LightWallet, can be set up in under five minutes and provides feedback on performance metrics and the size and quantity of page resources.ImportantWhile Lighthouse is an excellent tool for identifying performance improvement opportunities, it can't be stressed enough that Lighthouse is a tool that relies on lab data. While lab data is an integral part of any performance improvement effort, comparing and contrasting that data with field data collected from your website's actual users is key. Doing so will help you understand how the changes you make to your website affect real users.Install Lighthouse #LightWallet is available in the command line version of Lighthouse v5+.To get started, install Lighthouse:npm install -g lighthouse Create a Budget #Create a file named budget.json. In this file add the following JSON:[ { ""path"": ""/*"", ""timings"": [  {  ""metric"": ""interactive"",  ""budget"": 3000  },  {  ""metric"": ""first-meaningful-paint"",  ""budget"": 1000  } ], ""resourceSizes"": [  {  ""resourceType"": ""script"",  ""budget"": 125  },  {  ""resourceType"": ""total"",  ""budget"": 300  } ], ""resourceCounts"": [  {  ""resourceType"": ""third-party"",  ""budget"": 10  } ] }] This example budget.json file sets five separate budgets:A budget of 3000ms for Time to Interactive.A budget of 1000ms for First Meaningful PaintA budget of 125 KB for the total amount of JavaScript on the page.A budget of 300 KB for the overall size of the page.A budget of 10 requests for the number of requests made to third-party origins.For a complete list of supported performance metrics and resource types, refer to the Performance Budgets section of the Lighthouse docs.Run Lighthouse #Run Lighthouse using the --budget-path flag. This flag tells Lighthouse the location of your budget file.lighthouse https://example.com --budget-path=./budget.json Note: A budget file does not have to be named budget.json.View the Results #If LightWallet has been configured correctly, the Lighthouse report will contain a Budgets section within the Performance category.In the JSON version of the Lighthouse report, Lightwallet results can be found within the audit findings for the performance-budget audit.PerformanceLast updated Apr 3, 2020 — Improve article Return to all articles Share We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.Contribute File a bug View source Related content developer.chrome.com Chrome updates Case studies Podcasts Shows Connect Twitter YouTube Chrome Firebase Google Cloud Platform All products Dark theme Terms & Privacy Community Guidelines Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. By Chrome DevRel URL of this webpage is: https://developers.google.com/web/tools/lighthouse/audits/budgets"
+9,dequeuniversity.comdefinition list.txt,"dequeuniversity.comdefinition list.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    <dl> elements must only directly contain properly-ordered <dt> and <dd> groups, <script>, <template> or <div> elements Rule ID: definition-list Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Start building more accessible experiences  Axe DevTools Pro helps dev teams find and fix up to 80% of accessibility issues while coding. No experience required. Get started with your free trial today.  Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]1.3.1: MUST: Info and RelationshipsWCAG Success Criteria [WCAG 2.0 (A)]1.3.1: MUST: Info and Relationships  How to Fix the Problem  Check that your definition list has only dt and dd elements. Furthermore, make sure these are properly ordered, dt should precede dd elements.  Definition list items require dl elements around the list, dt elements for each term, and dd elements for each definition. Each set of dt elements must be followed by one or more dd elements. Ensure that your definition lists follow these specifications and mimic the example below. Example <dl>  <dt>Coffee</dt>   <dd>Black hot drink</dd>  <div>   <dt>Milk</dt>    <dd>White cold drink</dd>  </div> </dl> Why it Matters  Screen readers have a specific way of announcing definition lists. When such lists are not properly marked up, this creates the opportunity for confusing or inaccurate screen reader output.  A definition list is used to provide the definitions of words or phrases. The Definition List is marked up using the dl element. Within the list, each term is put in a separate dt element, and its definition goes in the dd element directly following it. Rule Description  Definition lists (dl) must contain only properly-ordered dt and dd groups, div, script, or template elements. The Algorithm (in simple terms) Ensures that all dl elements are structured correctly. Resources Deque University Deque University Course Pages (subscription required) Semantic Markup for Lists  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. H40: Using description listsH48: Using ol, ul and dl for lists or groups of links Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/definition-list"
+10,dequeuniversity.comtd headers attr.txt,"dequeuniversity.comtd headers attr.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Table cells that use the headers attribute must only refer to cells in the same table Rule ID: td-headers-attr Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), Section 508     Accessibility testing for dev teams - No experience required  Find and fix up to 80% of accessibility issues with axe DevTools Pro. Get started with your free trial today. No credit card needed.   Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A)Section 508 WCAG Success Criteria [WCAG 2.1 (A)]1.3.1: MUST: Info and RelationshipsWCAG Success Criteria [WCAG 2.0 (A)]1.3.1: MUST: Info and RelationshipsSection 508 Guidelines1194.22: MUST: Web based intranet and Internet Information & Applications1194.22 (g): MUST: Row and column headers shall be identified for data tables.” and “(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.  How to Fix the Problem  To fix the problem, ensure that each cell in a table using headers refers to another cell in the same table by creating a scope attribute value on each th element within tr elements. This rule checks that references to header columns and rows connect to specific td elements.  The scope attribute tells the browser and screen reader that everything under the column is related to the header at the top, and everything to the right of the row header is related to that header. Applying the scope attribute to our table the markup now looks like this: Example <table> <caption><strong>Greensprings Running Club Personal Bests</strong></caption> <thead>  <tr>  <th scope=""col"">Name</th>  <th scope=""col"">1 mile</th>  <th scope=""col"">5 km</th>  <th scope=""col"">10 km</th>  </tr> </thead> <tbody>  <tr>  <th scope=""row"">Mary</th>  <td>8:32</td>  <td>28:04</td>  <td>1:01:16</td>  </tr>  <tr>  <th scope=""row"">Betsy</th>  <td>7:43</td>  <td>26:47</td>  <td>55:38</td>  </tr>  <tr>  <th scope=""row"">Matt</th>  <td>7:55</td>  <td>27:29</td>  <td>57:04</td>  </tr>  <tr>  <th scope=""row"">Todd</th>  <td>7:01</td>  <td>24:21</td>  <td>50:35</td>  </tr> </tbody> </table>  See Using id and headers attributes to associate data  cells with header cells in data tables for a specific example connecting data cells to one ore more header cell within a data table.  Note that the top headers for Name, 1 mile, 5 km and 10 km are all marked up with th elements, as are the row headers for Mary, Betsy, Matt and Todd. Each of these header cell have also been given the scope attribute values of col or row depending on whether they are column or row header cells.  One more method to associating header cells with data cells uses the colgroup and rowgroup values of the scope attribute. This markup technique is use to indicate headers spanning multiple columns or rows. Consider the following table from Mozilla's Learn HTML Developer Docs:  Items Sold August 2016  Clothes Accessories  Trousers Skirts Dresses Bracelets Rings Belgium Antwerp 56 22 43 72 23 Gent 46 18 50 61 15 Brussels 51 27 38 69 28 The Netherlands Amsterdam 89 34 69 85 38 Utrecht 80 12 43 36 19   Example including scope=""colgroup"" and  scope=""rowgroup"" values on th elements <table> <caption>Items Sold August 2016</caption> <tbody>  <tr>  <td></td>  <td></td>  <th colspan=""3"" scope=""colgroup"">Clothes</th>  <th colspan=""2"" scope=""colgroup"">Accessories</th>  </tr>  <tr>  <td></td>  <td></td>  <th scope=""col"">Trousers</th>  <th scope=""col"">Skirts</th>  <th scope=""col"">Dresses</th>  <th scope=""col"">Bracelets</th>  <th scope=""col"">Rings</th>  </tr>  <tr>  <th rowspan=""3"" scope=""rowgroup"">Belgium</th>  <th scope=""row"">Antwerp</th>  <td>56</td>  <td>22</td>  <td>43</td>  <td>72</td>  <td>23</td>  </tr>  <tr>  <th scope=""row"">Gent</th>  <td>46</td>  <td>18</td>  <td>50</td>  <td>61</td>  <td>15</td>  </tr>  <tr>  <th scope=""row"">Brussels</th>  <td>51</td>  <td>27</td>  <td>38</td>  <td>69</td>  <td>28</td>  </tr>  <tr>  <th rowspan=""2"" scope=""rowgroup"">The Netherlands</th>  <th scope=""row"">Amsterdam</th>  <td>89</td>  <td>34</td>  <td>69</td>  <td>85</td>  <td>38</td>  </tr>  <tr>  <th scope=""row"">Utrecht</th>  <td>80</td>  <td>12</td>  <td>43</td>  <td>36</td>  <td>19</td>  </tr> </tbody> </table>  Why it Matters  Screen readers have a specific way of announcing tables. When tables are not properly marked up, this creates the opportunity for confusing or inaccurate screen reader output.  Sighted users can usually tell at a glance what the table's headers are and what their relationship to the data is. For non-sighted users this must be done in the markup.  When a data table is designed with accessibility in mind, the user enters into table navigation mode, which allows the user to navigate from cell to cell within the table while hearing the screen reader announce the corresponding table headers for the data cells. Hearing the table headers is especially helpful when navigating through large data tables, or when cells contain similar-sounding data that could be easily confused.  Table navigation mode is not useful, though, if the table lacks accessibility features. Rule Description  Data table markup can be tedious and confusing. Markup tables semantically and with the correct header structure. Screen readers have features to ease table navigation, but tables must be marked up accurately for these features to work correctly. The Algorithm (in simple terms)  Checks that data tables are marked up semantically and have the correct header structure.  Resources Deque University Deque University Course Pages (subscription required) Table caption/nameTable HeadersSimple Header AssociationsGrouped Header AssociationsComplex Header Associations  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. Tables ConceptsH43: Using id and headers attributes to associate data cells with header cells in data tablesH51: Using table markup to present tabular informationH63: Using the scope attribute to associate header cells and data cells in data tablesH73: Using the summary attribute of the table element to give an overview of data tables Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/td-headers-attr"
+11,dequeuniversity.comduplicate id aria.txt,"dequeuniversity.comduplicate id aria.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    IDs used in ARIA and labels must be unique Rule ID: duplicate-id-aria Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Start building more accessible experiences  Axe DevTools Pro helps dev teams find and fix up to 80% of accessibility issues while coding. No experience required. Get started with your free trial today.  Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Blind Deafblind  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.1: MUST: ParsingWCAG Success Criteria [WCAG 2.0 (A)]4.1.1: MUST: Parsing  How to Fix the Problem Rename any duplicate ID values. Duplicate IDs are common validation errors that may break the accessibility of labels, e.g., form fields, table header cells.  To fix the problem, change an ID value if it is used more than once to be sure each is unique. Unique ID's differentiate each element from another and prevent invalid markup, wherein only the first instance gets acted upon by client-side scripting, or where assistive technologies typically only reference the first one accurately. Why it Matters  Duplicate IDs are common validation errors that may break the accessibility of labels, e.g., ARIA elements, form fields, table header cells.  Unique ID's differentiate each element from another and prevent invalid markup, wherein only the first instance gets acted upon by client-side scripting, or where assistive technologies typically only reference the first one accurately. Rule Description  The value assigned to an id attribute used in ARIA or in form labels must be unique to prevent the second instance from being overlooked by assistive technology. Put another way; ID values used in ARIA and in labels may not be used more than once in the same document to differentiate each element from another. The Algorithm (in simple terms)  Ensures every ID used in ARIA attributes and for attribute on a label is unique  Resources Deque University Deque University Course Pages (subscription required) Parsing and ValidityConflicts and duplicates  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. F77: Failure of Success Criterion 4.1.1 due to duplicate values of type ID Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/duplicate-id-aria"
+12,dequeuniversity.comaria hidden focus.txt,"dequeuniversity.comaria hidden focus.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    ARIA hidden element must not be focusable or contain focusable elements Rule ID: aria-hidden-focus Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Accessibility testing for dev teams - No experience required  Find and fix up to 80% of accessibility issues with axe DevTools Pro. Get started with your free trial today. No credit card needed.   Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Low Vision Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, Value  How to Fix the Problem  Fix the issue by ensuring the value inside each attribute is spelled correctly and corresponds to a valid value. Use appropriate ARIA roles, states, and properties.  The following examples PASS the aria-hidden=""true"" elements do not contain focusable elements rule: Content not focusable by default. <p aria-hidden=""true"">Some text</p> Content hidden through CSS. <div aria-hidden=""true"">  <a href=""/"" style=""display:none"">Link</a> </div> Content made unfocusable through tabindex. <div aria-hidden=""true""> 	<button tabindex=""-1"">Some button</button> </div> Content made unfocusable through disabled. <input disabled aria-hidden=""true"" /> aria-hidden can’t be reset once set to true on an ancestor.  <div aria-hidden=""true"">  <div aria-hidden=""false"">   <button tabindex=""-1"">Some button</button>  </div> </div>  The following examples FAIL the aria-hidden=""true"" elements do not contain focusable elements rule: Focusable off screen link. <div aria-hidden=""true""> 	<a href=""/"" style=""position:absolute; top:-999em"">Link</a> </div> Focusable form field, incorrectly disabled. <div aria-hidden=""true""> 	<input aria-disabled=""true"" /> </div> aria-hidden can’t be reset once set to true on an ancestor.  <div aria-hidden=""true"">  <div aria-hidden=""false"">   <button>Some button</button>  </div> </div> Focusable content through tabindex. <p tabindex=""0"" aria-hidden=""true"">Some text</p> Focusable summary element. <details aria-hidden=""true"">  <summary>Some button</summary>  <p>Some details</p> </details>  Why it Matters  Using the aria-hidden=""true"" attribute on an element removes the element and ALL of its child nodes from the accessibility API making it completely inaccessible to screen readers and other assistive technologies. Aria-hidden may be used with extreme caution to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. If aria-hidden is used to hide visible content from screen readers, the identical or equivalent meaning and functionality must be exposed to assistive technologies. Note: Using aria-hidden=""false"" on content that is a descendent of an element that is hidden using aria-hidden=""true"" will NOT expose that content to the accessibility API and it will not be accessible to screen readers or other assistive technologies.  The rule applies to any element with an aria-hidden=""true"" attribute.  By adding aria-hidden=""true"" to an element, content authors ensure that assistive technologies will ignore the element. This can be used to hide decorative parts of a web page, such as icon fonts - that are not meant to be read by assistive technologies.  A focusable element with aria-hidden=""true"" is ignored as part of the reading order, but still part of the focus order, making it’s state of visible or hidden unclear.  https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html  https://www.w3.org/TR/wai-aria-1.1/#aria-hidden  https://www.w3.org/TR/html/editing.html#can-be-focused  Rule Description  This rule checks aria-hidden elements do not contain focusable elements. The Algorithm (in simple terms)  For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.  Resources Deque University Deque University Course Pages (subscription required) Web Accessibility, Part 9: Custom JavaScript/ARIA WidgetsARIA Concepts  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. W3C WAI-ARIA 1.1 States and Properties - aria-hidden Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-hidden-focus"
+13,web.dev images without dimension.txt,"web.dev images without dimension.txt. Optimize Cumulative Layout ShiftSkip to content Open menu  About Blog Learn Explore Patterns Case studies Close Thanks for tuning in to Google I/O. Watch the Chrome content on-demand.On this page Understanding where your shifts are coming fromCLS in lab tools versus fieldIdentifying load CLS issuesIdentifying post-load CLS issuesMeasuring CLS elements in the fieldCommon causes of CLSImages without dimensionsAds, embeds, and other late-loaded contentAnimationsWeb fontsReduce CLS by ensuring pages are eligible for the bfcacheConclusion Home All articles Optimize Cumulative Layout ShiftLearn how to avoid sudden layout shifts to improve user-experienceMay 5, 2020 — Updated May 4, 2023 Available in: English, Español, Português, Русский, 中文, 日本語, and 한국어 Appears in: Fast load times | Core Web Vitals Barry Pollard TwitterGitHubHomepage Addy Osmani TwitterGitHubOn this page Understanding where your shifts are coming fromCLS in lab tools versus fieldIdentifying load CLS issuesIdentifying post-load CLS issuesMeasuring CLS elements in the fieldCommon causes of CLSImages without dimensionsAds, embeds, and other late-loaded contentAnimationsWeb fontsReduce CLS by ensuring pages are eligible for the bfcacheConclusion""I was about to click that! Why did it move? 😭""Cumulative Layout Shift (CLS) is one of the three Core Web Vitals metrics, and it measures the instability of content by summing shift scores across layout shifts that don't occur within 500 milliseconds of user input. It looks at how much visible content shifted in the viewport as well as the distance the elements impacted were shifted.Layout shifts can be distracting to users. Imagine you've started reading an article when all of a sudden elements shift around the page, throwing you off and requiring you to find your place again. This is very common on the web, including when reading the news, or trying to click those 'Search' or 'Add to Cart' buttons. Such experiences are visually jarring and frustrating. They're often caused when visible elements are forced to move because another element was suddenly added to the page or resized.To provide a good user experience, sites should strive to have a CLS of 0.1 or less for at least 75% of page visits.Unlike the other Core Web Vitals, which are time-based values measured in seconds or milliseconds, the CLS score is a unitless value based on a calculation of how much content is shifting and by how far.In this guide, we'll cover optimizing common causes of layout shifts.The most common causes of a poor CLS are:Images without dimensionsAds, embeds, and iframes without dimensionsDynamically injected content such as ads, embeds, and iframes without dimensionsWeb fontsFor a visual overview of some of the content presented in this guide, see the Optimize for Core Web Vitals video from Google I/O 2020: Understanding where your shifts are coming from #Before we start looking at solutions to common CLS issues, it's always important to understand your CLS score and where the shifts are coming from. A big part of the problem is understanding your CLS score—the fix afterwards is often the easier part!CLS in lab tools versus field #It is quite common to hear developers think the CLS measured by the Chrome UX Report (CrUX) is incorrect as it does not match the CLS they measure using Chrome DevTools or other lab tools. Web performance lab tools like Lighthouse may not show the full CLS of a page as they typically do a simple load of the page to measure some web performance metrics and provide some guidance (though Lighthouse user flows do allow you measure beyond the default page load audit).CrUX is the official dataset of the Web Vitals program, and for that, CLS is measured throughout the full life of the page and not just during the initial page load that lab tools typically measure.Layout shifts are very common during page load, as all the necessary resources are fetched to initially render the page, but layout shifts can also happen after the initial load. Many post-load shifts may occur as the result of a user interaction and therefore will be excluded from the CLS score as they are expected shifts—as long as they occur within 500 milliseconds of that interaction.However, other post-load shifts that are unexpected by the user may be included where there was no qualifying interaction—for example, if you scroll down the page and lazy-loaded content is loaded and that causes shifts. Other common causes of post-load CLS are on interactions of transitions, for example on Single Page Apps, which take longer than the 500 millisecond grace period.PageSpeed Insights will show both the user-perceived CLS from a URL where it exists in the ""Discover what your real users are experiencing"" section, and also the lab-based load CLS in the ""Diagnose performance issues"" section beneath. If you see a difference between these, this is likely caused by post-load CLS.PageSpeed Inights will show URL-level data where it exists, and attempt to fall back to origin-level data where this does not exist. Always check what data is showing to ensure you do not waste time trying to track down a CLS issue that actually exists on other pages on your origin! In the above example you can see this is URL-level data as shown in the top right of the image.Identifying load CLS issues #When the CrUX and Lighthouse CLS scores of PageSpeed Insights are broadly in line, this usually indicates there is a load CLS issue that was detected by Lighthouse. In this case Lighthouse will help with two audits to provide more information on images causing CLS due to missing width and height, and also list all the elements that shifted for the page load along with their CLS contribution. You can see these audits by filtering on the CLS audits:Lighthouse will identify the elements that were shifted, but often these are the ones impacted rather than the elements causing the CLS. For example, if a new element is inserted into the DOM, the elements that are beneath it will show in this audit, but the root cause is the addition of the new element above. However, the shifted element should be sufficient to help you identify and resolve the root cause.The Performance panel in DevTools also highlights layout shifts in the Experience section. The Summary view for a Layout Shift record includes the cumulative layout shift score as well as a rectangle overlay showing the affected regions. This is particularly helpful to get more detail on load CLS issues since this is easily replicated with a reload performance profile.After recording a new trace in the Performance panel, the Experience section of the results is populated with a red-tinted bar displaying a Layout Shift record. Clicking the record allows you to drill down into impacted elements (e.g. note the moved from/to entries).Identifying post-load CLS issues #When the CrUX and Lighthouse CLS scores of PageSpeed Insights are not in line, then this likely indicates post-load CLS. Without field data helping to identify the reason (that we will cover next), these can be more tricky to track down.The Web Vitals Chrome extension can be used to monitor CLS as you interact with a page, either in a heads up display, or in the console—where you can get more details above the elements shifted.As an alternative to using the extension, you can browse your web page while recording layout shifts using a Performance Observer pasted into the console.Once you are monitoring shifts you can try to replicate any post-load CLS issues. Scolling down a page is a common place for CLS to occur if content is lazy loaded and does not have space reserved for it. Content shifting on hover is another common post-load CLS cause. Both of these ""interactions"" are ineligible for the 500 milliseconds grace period as CLS during these periods are seen as being ""unexpected shifts"", despite the user interaction, as they should not cause content to shift. Other interactions—such as clicks or taps—do have that grace period, but a common reason for CLS in these cases is taking longer than that 500 milliseconds to move or add content.We have a more detailed posted on debugging layout shifts for more information.Once you have identified any common causes of CLS, the timespans user flow mode of Lighthouse can also be used to ensure typical user flows do not regress by introducing layout shifts.Measuring CLS elements in the field #It is also recommended to monitor CLS in the field. This can be used to measure both the CLS and—perhaps more importantly—the elements impacting your CLS score in the field and feed them back to your analytics service.This can be invaluable in pointing you in the right direction of where the issue is as it can remove much of the guess work discribed above when you are trying to understand under what circumstances CLS is occuring. Again, be aware that this will measure the elements that shifted, rather than the root causes of those shifts, but this is often sufficient to identify the cause or at least to narrow down the problem.Measuring CLS in the field can also be used to rank the issues in order of importance based on most frequently experienced issues.The attribution functionality of the web-vitals library allows this additional information to be collected. Read our Debug performance in the field post for more information on how to do this. Other RUM providers have also started collecting and presenting this data similarly.RUM solutions that measure CLS in the field, including the web-vitals library, may show differences that CrUX data as explained in the Why is CrUX data different from my RUM data? post. In particular, CLS that happens in iframes is not measurable from Web APIs but is visible to the user, and is therefore included in CrUX. So while field data can be invaluable for identifying CLS issues, be aware that it may be incomplete in certain scenarios.Common causes of CLS #Once you have identified the causes of CLS, you can start working on fixing the issues. In this section we will show some of the more common reasons for CLS, and what you can do to avoid them.Images without dimensions #Always include width and height size attributes on your images and video elements. Alternatively, reserve the required space with CSS aspect-ratio or similar. This approach ensures that the browser can allocate the correct amount of space in the document while the image is loading. Images without width and height specified. Images with width and height specified.Lighthouse 6.0 impact of setting image dimensions on CLS.History of width and height attributes on images #In the early days of the web, developers would add width and height attributes to their &LTimg> tags to ensure sufficient space was allocated on the page before the browser started fetching images. This would minimize reflow and re-layout.<img src=""puppy.jpg"" width=""640"" height=""360"" alt=""Puppy with balloons""> You may notice width and height above do not include units. These ""pixel"" dimensions would ensure a 640x360 area would be reserved. The image would stretch to fit this space, regardless of whether the true dimensions matched or not.When Responsive Web Design was introduced, developers began to omit width and height and started using CSS to resize images instead:img { width: 100%; /* or max-width: 100%; */ height: auto;} A downside to this approach is space could only be allocated for an image once it began to download and the browser could determine its dimensions. As images loaded in, the page would reflow as each image appeared on screen. It became common for text to suddenly pop down the screen. This wasn't a great user experience at all.This is where aspect ratio comes in. The aspect ratio of an image is the ratio of its width to its height. It's common to see this expressed as two numbers separated by a colon (for example 16:9 or 4:3). For an x:y aspect ratio, the image is x units wide and y units high.This means if we know one of the dimensions, the other can be determined. For a 16:9 aspect ratio:If puppy.jpg has a 360px height, width is 360 x (16 / 9) = 640pxIf puppy.jpg has a 640px width, height is 640 x (9 / 16) = 360pxKnowing the aspect ratio allows the browser to calculate and reserve sufficient space for the height and associated area.Modern best practice for setting image dimensions #Modern browsers now set the default aspect ratio of images based on an image's width and height attributes so developers just need to set these, and include the above CSS, to prevent layout shifts:<!-- set a 640:360 i.e a 16:9 aspect ratio --><img src=""puppy.jpg"" width=""640"" height=""360"" alt=""Puppy with balloons""> All browsers will then add a default aspect ratio based on the element's existing width and height attributes.This calculates an aspect ratio based on the width and height attributes before the image has loaded. It provides this information at the very start of layout calculation. As soon as an image is told to be a certain width (for example width: 100%), the aspect ratio is used to calculate the height.This aspect-ratio value is calculated by major browsers as the HTML is processed, rather than with a default User Agent stylesheet (see this post for a deep dive into why), so the value is displayed a little differently. For example, Chrome displays it like this in the Styles section of the Element panel:img[Attributes Style] { aspect-ratio: auto 640 / 360;} Safari behaves similarly by using a HTML Attributes style source. Firefox does not currently display this calculated aspect-ratio at all in it's Inspector panel, but does use it for layout.The auto part of the above code is important as it causes the 640 / 360 to be overriden with the image dimensions once the image is downloaded. If the image dimensions are different this will still cause some layout shift after the image loads, but this ensures the image aspect ratio is still used ultimately when it becomes available—as it was in the past—in case the HTML is incorrect. Plus, the shift is likely to be a lot smaller than the 0x0 default image size when dimensions are not provided!Tip: If you're having a hard time understanding aspect ratio, a handy calculator is available to help.For a fantastic deep-dive into aspect ratio with further thinking around responsive images, see jank-free page loading with media aspect ratios.If your image is in a container, you can use CSS to resize the image to the width of this container. We set height: auto; to avoid the image height being a fixed value (for example 360px).img { height: auto; width: 100%;} What about responsive images? #When working with responsive images, srcset defines the images you allow the browser to select between and what size each image is. To ensure &LTimg> width and height attributes can be set, each image should use the same aspect ratio.<img width=""1000"" height=""1000"" src=""puppy-1000.jpg"" srcset=""puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"" alt=""Puppy with balloons""/> What about art direction?Pages may wish to include a cropped shot of an image on narrow viewports with the full image displayed on desktop.<picture> <source media=""(max-width: 799px)"" srcset=""puppy-480w-cropped.jpg"" /> <source media=""(min-width: 800px)"" srcset=""puppy-800w.jpg"" /> <img src=""puppy-800w.jpg"" alt=""Puppy with balloons"" /></picture> It's very possible these images could have different aspect ratios. Chrome, Firefox, and Safari now support setting width and height on the source children of the picture element:<picture> <source media=""(max-width: 799px)"" srcset=""puppy-480w-cropped.jpg"" width=480 height=400/> <source media=""(min-width: 800px)"" srcset=""puppy-800w.jpg"" width=800 height=400/> <img src=""puppy-800w.jpg"" alt=""Puppy with balloons"" width=800 height=400/></picture> Ads, embeds, and other late-loaded content #As we have seen, images have special considerations. However, images are not the only type of content that can cause layout shifts. Ads, embeds, iframes, and other dynamically injected content can all cause content after these to shift down, increasing your CLS.Ads are one of the largest contributors to layout shifts on the web. Ad networks and publishers often support dynamic ad sizes. Ad sizes increase performance/revenue due to higher click rates and more ads competing in the auction. Unfortunately, this can lead to a suboptimal user experience due to ads pushing visible content you're viewing down the page.Embeddable widgets allow you to include portable web content in your page, such as videos from YouTube, maps from Google Maps, and social media posts. These widgets often aren't aware in advance just how large their contents will be. For example, in the case of a social media post, it might have an embedded image, video, multiple rows of text, or a number of other unpredictable factors. As a result, platforms offering embeds do not always reserve space for their widgets and so cause layout shifts when they finally load.The techniques for dealing with these are all similar. The major differences are how much control you have over the content that will be inserted. If this is inserted by a third-party like an ad partner, you may not know the exact size of content that will be inserted, nor be able to control any layout shifts happening within those embeds.Statically reserve space for late-loading content #When placing late-loading content in the content flow, layout shifts can be avoided by reserving the space for them in the initial layout.This can be as simple as adding a min-height styling to reserve space or, for responsive content such as ads, using the new aspect-ratio CSS property in a similar manner to the way browsers automatically use this for images with dimensions provided.Reserving space for ads can prevent layout shiftsYou may need to account for subtle differences in ad or placeholder sizes across form factors using media queries.For content that may not have a fixed height—like ads—you may not be able to reserve the exact amount of space needed to eliminate the layout shift entirely. If a smaller ad is served, a publisher can style the (larger) container to avoid layout shifts, or choose the most likely size for the ad slot based on historical data. The downside to this approach is that it will increase the amount of blank space, so keep in mind the trade-off here.Alternatively, set the initial size to the smallest size that will be used, and accept some level of shift for larger content. Using min-height, as suggested above, will allow the parent element to grow as necessary. This will not fully eliminate CLS, but will hopefully reduce the impact of it to a more managable level. The default size of an empty element is 0px which gives maximum CLS, so any size is better than that!Try to avoid collapsing the reserved space if, for example, there is no ad returned, by showing a placeholder. Removing the space set aside for elements can cause just as much CLS as inserting content!Avoid placing late-loading content near the top of the viewport #Dynamically injected content near the top of the viewport may cause a greater layout shift than those at the middle. This is because elements inserted at the top generally have more content lower down, meaning more elements move when the late-loading content causes a shift.Conversely, dynamically injected content near the middle of the viewport may not shift as many elements as the content above it is less likely to move, but will still cause some CLS. Even content injected at the bottom of the screen will cause CLS as the content it replace is moved off-screen.The ideal scenario is not to shift any other content so reserving the appropriate space is preferred. Where this is not possible, minimizing the shifts can at least reduce the impact—both to your users and your CLS scores.Avoid inserting new content without a user interaction #You've probably experienced layout shifts due to UI that pops-in at the top or bottom of the viewport when you're trying to load a site. Similar to ads, this often happens with banners and forms that shift the rest of the page's content:""Sign-up to our newsletter!"" (whoa, slow down! we just met!)""Related content""""Install our [iOS/Android] app""""We're still taking orders""""GDPR notice"" Dynamic content without space reserved.If you need to display these types of UI affordances, reserve sufficient space in the viewport for it in advance (for example, using a placeholder or skeleton UI) so that when it loads, it does not cause content in the page to surprisingly shift around. Alternatively, ensure the element is not part of the document flow by overlaying the content where this makes sense. See the Best practices for cookie notices post for more recommendations on these types of components.In some cases adding content dynamically is an important part of user experience. For example, when loading more products to a list of items or when updating live feed content. There are several ways to avoid unexpected layout shifts in those cases:Replace the old content with the new content within a fixed size container or use a carousel and remove the old content after the transition. Remember to disable any links and controls until the transition has completed to prevent accidental clicks or taps while the new content is coming in.Have the user initiate the load of new content, so they are not surprised by the shift (for example with a ""Load more"" or ""Refresh"" button). It's recommended to prefetch the content before the user interaction so that it shows up immediately. As a reminder, layout shifts that occur within 500 milliseconds of user input are not counted towards CLS.Seamlessly load the content offscreen and overlay a notice to the user that it's available (for example, with a ""Scroll up"" button).Examples of dynamic content loading without causing unexpected layout shifts. Left: Live feed content loading on Twitter. Right: ""Load More"" example on Chloé website. Check out how the YNAP team optimized for CLS when loading more content.If content is likely to take more than 500 milliseconds—for example it requires a network fetch—then reserving the expected space within that 500 millisecond timeframe and taking the impact of any future shift up front allows you to ensure any shifts will not be included in the CLS score.Animations #Changes to CSS property values can require the browser to react to these changes. A number of values trigger re-layout, paint, and composite such as box-shadow and box-sizing. Try to avoid animating these.A number of CSS properties can be changed in a much more performant manner. For example, transform animations can be used to translate, scale, rotate, or skew without triggering a re-layout and so completely avoiding layout shifts.When animations are instead done by changing top and left CSS properties instead of using translate, layout shifts occur. This happens even when the element being moved is in it's own layer and so does not cause shifts to other elements. Composited animations via translate are exempt from CLS as they cannot impact other elements. There are also other considerable performance benefits of using non-composited animations since they do no cause re-layout and therefore are much less work for the browser.To learn more about what CSS properties trigger layout see High-performance animations.Web fonts #Downloading and rendering web fonts is typically handled in one of two ways before the web font is downloaded:The fallback font is swapped with the web font (FOUT—flash of unstyled text)""Invisible"" text is displayed using the fallback font until a web font is available and the text is made visible (FOIT—flash of invisible text)It is important to understand that both of these can cause layout shifts. Even though the text is invisible, it is laid out using the fallback font. This means the text block using the font, and the surrounding content, shifts when the web font loads—in the exact same way as for the visible font for FOUT.The following tools can help you minimize this:font-display: optional can avoid a re-layout as the web font is only used if it is available by the time of initial layout.Ensure the appropriate fallback font is used. For example, using font-family: ""Google Sans"", sans-serif; will ensure the browser's sans-serif fallback font is used while ""Google Sans"" is loaded. Not specifying a fallback font using just font-family: ""Google Sans"" will mean the default font is used, which on Chrome is ""Times""—a serif font which is a worse match than the default sans-serif font.Minimize the size differences between the fallback font and the web font using the new size-adjust, ascent-override, descent-override, and line-gap-override APIs as detailed in the Improved font fallbacks post.The Font Loading API can reduce the time it takes to get necessary fonts.Load critical web fonts as early as possible using &LTlink rel=preload>. A preloaded font will have a higher chance to meet the first paint, in which case there's no layout shifting.Read Best practices for fonts for other font best practices.Reduce CLS by ensuring pages are eligible for the bfcache #A highly effective technique for keeping CLS scores low is to ensure your web pages are eligible for the back/forward cache (bfcache).The bfcache keeps pages in browsers memory for a short period after you navigate away so if you return to them, then they will be restored exactly as you left them. This means the fully loaded page is instantly available—without any shifts which may be normally seen during load due to any of the reasons above.While this does potentially still mean the initial page load encounters layout shifts, when a user goes back through pages they are not seeing the same layout shifts repeatedly. You should always aim to avoid the shifts even on the initial load, but where that is more tricky to resolve fully, you can at least reduce the impact by avoiding them on any bfcache navigations.Back and forward navigations are common on many sites. For example, returning to a contents page, or a category page, or search results.When this was rolled out to Chrome, we saw noticeable improvements in CLS.The bfcache is used by default by all browsers, but some sites are ineligible for the bfcache due to a variety of reasons. Read the bfcache article for more details on how to test and identify any issues preventing bfcache usage to ensure you are making full use of this feature to help your overall CLS score for your site.Conclusion #There are a number of techniques to identify and improve CLS as detailed above. There are allowances built into Core Web Vitals, so even if you cannot eliminate CLS completely, using some of these techniques should allow you to reduce the impact. This will be better for your users and hopefully allow you to stay within those limits.That's it for this guide. We hope it helps keep your pages just a little less shifty :)PerformanceWeb VitalsLast updated May 4, 2023 — Improve article Return to all articles Share We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.Contribute File a bug View source Related content developer.chrome.com Chrome updates Case studies Podcasts Shows Connect Twitter YouTube Chrome Firebase Google Cloud Platform All products Dark theme Terms & Privacy Community Guidelines Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. By Chrome DevRel URL of this webpage is: https://web.dev/optimize-cls/#images-without-dimension"
+14,developers.google.comreduce the scope and comp.txt,"developers.google.comreduce the scope and comp.txt. Reduce the scope and complexity of style calculationsSkip to content Open menu  About Blog Learn Explore Patterns Case studies Close Thanks for tuning in to Google I/O. Watch the Chrome content on-demand.On this page SummaryStyle recalculation time and interaction latencyReduce the complexity of your selectorsReduce the number of elements being styledMeasure your style recalculation costUse Block, Element, ModifierResources Home All articles Reduce the scope and complexity of style calculationsJavaScript is often the trigger for visual changes. Sometimes that's directly through style manipulations, and sometimes it's calculations that will result in visual changes, like searching or sorting some data. Badly-timed or long-running JavaScript can be a common cause of performance issues, and you should look to minimize its impact where you can.Mar 20, 2015 — Updated May 9, 2023 Appears in: How to Optimize Interaction to Next Paint (INP) Paul Lewis Twitter Jeremy Wagner TwitterGitHubHomepageOn this page SummaryStyle recalculation time and interaction latencyReduce the complexity of your selectorsReduce the number of elements being styledMeasure your style recalculation costUse Block, Element, ModifierResourcesChanging the DOM, through adding and removing elements, changing attributes, classes, or through animation, will all cause the browser to recalculate element styles and, in many cases, layout (or reflow) the page, or parts of it. This process is called computed style calculation.The first part of computing styles is to create a set of matching selectors, which is essentially the browser figuring out which classes, pseudo-selectors, and IDs apply to any given element.The second part of the process involves taking all the style rules from the matching selectors and figuring out what final styles the element has.Roughly half of the time used in Blink (the rendering engine used in Chromium and derived browsers) to calculate the computed style for an element is used to match selectors, and the other half of the time is used to construct the RenderStyle (computed style representation) from the matched rules. Rune Lillesveen, Opera / Style Invalidation in BlinkSummary #How reducing style calculation costs can lower interaction latency.Reduce the complexity of your selectors; use a class-centric methodology (BEM, for example).Reduce the number of elements on which style calculation must be calculated.Style recalculation time and interaction latency #The Interaction to Next Paint (INP) is a user-centric runtime performance metric that assesses a page's overall responsiveness to user input. When interaction latency is assessed by this metric, it measures the time starting from when the user interacts with the page, up until the browser paints the next frame showing the corresponding visual updates made to the user interface.A significant component of an interaction is the time it takes to paint the next frame. Rendering work done to present the next frame is made up of many parts, including calculation of page styles that occur just prior to layout, paint, and compositing work. While this article focuses solely on style calculation costs, it's important to emphasize that reducing any part of the rendering phase inherent to interaction will reduce its total latency—style calculation included.Reduce the complexity of your selectors #In the simplest case, you can reference an element in your CSS with just a class:.title { /* styles */} But, as any project grows, it will likely result in more complex CSS, such that you may end up with selectors that look like this:.box:nth-last-child(-n+1) .title { /* styles */} In order to know how these styles apply to the page, the browser has to effectively ask ""is this an element with a class of title which has a parent who happens to be the minus nth child plus 1 element with a class of box?"" Figuring this out can take a lot of time, depending on the selector used as well as the browser in question. The intended behavior of the selector could instead be changed to a class:.final-box-title { /* styles */} You can take issue with the name of the class, but the job just got a lot simpler for the browser. In the previous version, in order to know, for example, that the element is the last of its type, the browser must first know everything about all the other elements and whether the are any elements that come after it that would be the nth-last-child, which is potentially more expensive than simply matching up the selector to the element because its class matches.Reduce the number of elements being styled #Another performance consideration—which is typically the more important factor for many style updates—is the sheer volume of work that needs to be carried out when an element changes.In general terms, the worst case cost of calculating the computed style of elements is the number of elements multiplied by the selector count, because each element needs to be at least checked once against every style to see if it matches.It used to be the case that if you changed a class on—say—the body element, that all the children in the page would need to have their computed styles recalculated. Thankfully that is no longer the case; some browsers instead maintain a small collection of rules unique to each element that, if changed, cause the element's styles to be recalculated. That means that an element may or may not need to be recalculated depending on where it is in the tree, and what specifically got changed.Style calculations can often be targeted to a few elements directly rather than invalidating the page as a whole. In modern browsers, this tends to be less of an issue because the browser doesn't necessarily need to check all the elements potentially affected by a change. Older browsers, on the other hand, aren't necessarily as optimized for such tasks. Where you can, you should reduce the number of invalidated elements.If you're into Web Components, it's worth noting that style calculations here are a little different, since by default styles do not cross the Shadow DOM boundary, and are scoped to individual components rather than the tree as a whole. Overall, however, the same concept still applies: smaller trees with simpler rules are more efficiently processed than larger trees with more complex rules.Measure your style recalculation cost #One way to measure the cost of style recalculations is to use the performance panel in Chrome DevTools. To begin, open DevTools, go to the tab labeled Performance, hit record, and interact with the page. When you stop recording, you'll see something like the image below:The strip at the top is a miniature flame chart that also plots frames per second. The closer the activity is to the bottom of the strip, the faster frames are being painted by the browser. If you see the flame chart leveling out at the top with red strips above it, then you have work that's causing long running frames.If you have a long running frame during an interaction like scrolling, then it bears further scrutiny. If you have a large purple block, zoom in on the activity and select any work labeled Recalculate Style to get more information on potentially expensive style recalculation work.In this grab there is long-running style recalculation work that is taking just over 25ms.If you click the event itself, you are given a call stack. If the rendering work was due to a user interaction, the place in your JavaScript that is responsible for triggering the style change will be called out. In addition to that, you also get the number of elements that have been affected by the change—just over 900 elements in this case—and how long it took to do the style calculation work. You can use this information to start trying to find a fix in your code.Use Block, Element, Modifier #Approaches to coding like BEM (Block, Element, Modifier) actually bake in the selector matching performance benefits above, because it recommends that everything has a single class, and, where you need hierarchy, that gets baked into the name of the class as well:.list { /* Styles */}.list__list-item { /* Styles */} If you need some modifier, like in the above where we want to do something special for the last child, you can add that like so:.list__list-item--last-child { /* Styles */} If you're looking for a good way to organize your CSS, BEM is a good starting point, both from a structure point-of-view, and also because of the simplifications of style lookup the methodology promotes.If you don't like BEM, there are other ways to approach your CSS, but the performance considerations should be assessed alongside the ergonomics of the approach.Resources #Style invalidation in BlinkBEM (Block, Element, Modifier)Hero image from Unsplash, by Markus Spiske.PerformanceWeb VitalsLast updated May 9, 2023 — Improve article Return to all articles Share We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.Contribute File a bug View source Related content developer.chrome.com Chrome updates Case studies Podcasts Shows Connect Twitter YouTube Chrome Firebase Google Cloud Platform All products Dark theme Terms & Privacy Community Guidelines Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. By Chrome DevRel URL of this webpage is: https://developers.google.com/web/fundamentals/performance/rendering/reduce-the-scope-and-complexity-of-style-calculations"
+15,web.dev optimize when the resour.txt,"web.dev optimize when the resour.txt. Optimize Largest Contentful PaintSkip to content Open menu  About Blog Learn Explore Patterns Case studies Close Thanks for tuning in to Google I/O. Watch the Chrome content on-demand.On this page LCP breakdownOptimal sub-part timesHow to optimize each part1. Eliminate resource load delay2. Eliminate element render delay3. Reduce resource load time4. Reduce time to first byteMonitor LCP breakdown in JavaScriptMonitor LCP breakdown via the Web Vitals extensionSummary Home All articles Optimize Largest Contentful PaintA step-by-step guide on how to break down LCP and identify key areas to improve.May 5, 2020 — Updated May 4, 2023 Available in: English, Español, Português, Русский, 中文, 日本語, and 한국어 Appears in: Fast load times | Core Web Vitals Philip Walton TwitterGitHubHomepage Barry Pollard TwitterGitHubHomepageOn this page LCP breakdownOptimal sub-part timesHow to optimize each part1. Eliminate resource load delay2. Eliminate element render delay3. Reduce resource load time4. Reduce time to first byteMonitor LCP breakdown in JavaScriptMonitor LCP breakdown via the Web Vitals extensionSummaryLargest Contentful Paint (LCP) is one of the three Core Web Vitals metrics, and it represents how quickly the main content of a web page is loaded. Specifically, LCP measures the time from when the user initiates loading the page until the largest image or text block is rendered within the viewport.To provide a good user experience, sites should strive to have an LCP of 2.5 seconds or less for at least 75% of page visits.There are a number of factors that can affect how quickly the browser is able to load and render a web page, and blockage or delays across any of them can have a significant impact on LCP.It's rare that a quick fix to a single part of a page will result in a meaningful improvement to LCP. To improve LCP you have to look at the entire loading process and make sure every step along the way is optimized.Optimizing for LCP is a complex task, and with complex tasks it's generally better to break them down into smaller, more manageable tasks and address each separately. This guide will present a methodology for how to break down LCP into its most critical sub-parts and then present specific recommendations and best practices for how to optimize each part.For a visual overview of the context presented in this guide, see A Deep Dive into Optimizing LCP from Google I/O '22: LCP breakdown #Most page loads typically include a number of network requests, but for the purposes of identifying opportunities to improve LCP, you should start by looking at just two:The initial HTML documentThe LCP resource (if applicable)While other requests on the page can affect LCP, these two requests—specifically the times when the LCP resource begins and ends—reveal whether or not your page is optimized for LCP.To identify the LCP resource, you can use developer tools (such as Chrome DevTools or WebPageTest) to determine the LCP element, and from there you can match the URL (again, if applicable) loaded by the element on a network waterfall of all resources loaded by the page.For example, the following visualization shows these resources highlighted on a network waterfall diagram from a typical page load, where the LCP element requires an image request to render.For a well-optimized page, you want your LCP resource request to start loading as early as it can, and you want the LCP element to render as quickly as possible after the LCP resource finishes loading. To help visualize whether or not a particular page is following this principle, you can break down the total LCP time into the following sub-parts:This table explains each of these LCP sub-parts in more detail:LCP sub-partDescriptionTime to first byte (TTFB)The time from when the user initiates loading the page until when the browser receives the first byte of the HTML document response. (See the TTFB metric doc for more details.)Resource load delayThe delta between TTFB and when the browser starts loading the LCP resource. *Resource load timeThe time it takes to load the LCP resource itself. *Element render delayThe delta between when the LCP resource finishes loading until the LCP element is fully rendered.* If the LCP element does not require a resource load to render (for example, if the element is a text node rendered with a system font), this time will be 0.Every single page can have its LCP value broken down into these four sub-parts. There is no overlap or gap between them, and collectively they add up to the full LCP time.When optimizing LCP, it's helpful to try to optimize these sub-parts individually. But it's also important to keep in mind that you need to optimize all of them. In some cases, an optimization applied to one part will not improve LCP, it will just shift the time saved to another part.For example, in the earlier network waterfall, if you reduced the file size of our image by compressing it more or switching to a more optimal format (such as AVIF or WebP), that would reduce the resource load time, but it would not actually improve LCP because the time would just shift to the element render delay sub-part:The reason this happens is because, on this page, the LCP element is hidden until the JavaScript code finishes loading, and then everything is revealed at once.This example helps illustrate the point that you need to optimize all of these sub-parts in order to achieve the best LCP outcomes.Optimal sub-part times #In order to optimize each sub-part of LCP, it's important to understand what the ideal breakdown of these sub-parts is on a well-optimized page.Of the four sub-parts, two have the word ""delay"" in their names. That is a clue that you want to get these times as close to zero as possible. The other two parts involve network requests, which by their very nature take time.LCP sub-part% of LCPTime to first byte (TTFB)~40%Resource load delay&LT10%Resource load time~40%Element render delay&LT10%TOTAL100%Note that these time breakdowns are not strict rules, they're guidelines. If the LCP times on your pages are consistently within 2.5 seconds, then it doesn't really matter what the relative proportions are. But if you're spending a lot of unnecessary time in either of the ""delay"" portions, then it will be very difficult to constantly hit the 2.5 second target.A good way to think about the breakdown of LCP time is:The vast majority of the LCP time should be spent loading the HTML document and LCP source.Any time before LCP where one of these two resources is not loading is an opportunity to improve.WarningGiven the 2.5 second target for LCP, it may be tempting to try to convert these percentages into absolute numbers, but that is not recommended. These sub-parts are only meaningful relative to each other, so it's best to always measure them that way.How to optimize each part #Now that you understand how each of the LCP sub-part times should break down on a well-optimized page, you can start optimizing your own pages.The next four sections will present recommendations and best practices for how to optimize each part. They're presented in order, starting with the optimizations that are likely to have the biggest impact.1. Eliminate resource load delay #The goal in this step is to ensure the LCP resource starts loading as early as possible. While in theory the earliest a resource could start loading is immediately after TTFB, in practice there is always some delay before browsers actually start loading resources.A good rule of thumb is that your LCP resource should start loading at the same time as the first resource loaded by that page. Or, to put that another way, if the LCP resource starts loading later than the first resource, then there's opportunity for improvement.Generally speaking, there are two factors that affect how quickly an LCP resource can be loading:When the resource is discovered.What priority the resource is given.Optimize when the resource is discovered #To ensure your LCP resource starts loading as early as possible, it's critical that the resource is discoverable in the initial HTML document response by the browser's preload scanner. For example, in the following cases, the browser can discover the LCP resource by scanning the HTML document response:The LCP element is an &LTimg> element, and its src or srcset attributes are present in the initial HTML markup.The LCP element requires a CSS background image, but that image is preloaded via &LTlink rel=""preload""> in the HTML markup (or via a Link header).The LCP element is a text node that requires a web font to render, and the font is loaded via &LTlink rel=""preload""> in the HTML markup (or via a Link header).Here are some examples where the LCP resource cannot be discovered from scanning the HTML document response:The LCP element is an &LTimg> that is dynamically added to the page via JavaScript.The LCP element is lazily loaded with a JavaScript library that hides its src or srcset attributes (often as data-src or data-srcset).The LCP element requires a CSS background image.In each of these cases, the browser needs to run the script or apply the stylesheet—which usually involves waiting for network requests to finish—before it can discover the LCP resource and could start loading it. This is never optimal.To eliminate unnecessary resource load delay, your LCP resource should always be discoverable from the HTML source. In cases where the resource is only referenced from an external CSS or JavaScript file, then the LCP resource should be preloaded, with a high fetch priority (more on fetch priority in the next section); for example:<!-- Load the stylesheet that will reference the LCP image. --><link rel=""stylesheet"" href=""/path/to/styles.css""><!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. --><link rel=""preload"" fetchpriority=""high"" as=""image"" href=""/path/to/hero-image.webp"" type=""image/webp""> WarningOn most pages, ensuring that the LCP resource starts loading at the same time as the first resource is good enough, but be aware that it is possible to construct a page where none of the resources are discovered early and all of them start loading significantly later than TTFB. So while comparing with the first resource is a good way to identify opportunities to improve, it may not be sufficient in some cases, so it's still important to measure this time relative to TTFB and ensure it remains small.Optimize the priority the resource is given #Even if the LCP resource is discoverable from the HTML markup, it still may not start loading as early as the first resource. This can happen if the browser preload scanner's priority heuristics do not recognize that the resource is important, or if it determines that other resources are more important.For example, you can delay your LCP image via HTML if you set loading=""lazy"" on your &LTimg> element. Using lazy loading means that the resource will not be loaded until after layout confirms the image is in the viewport and so may begin loading later than it otherwise would.WarningNever lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.Even without lazy loading, images are not initially loaded with the highest priority by browsers as they are not render-blocking resources. You can hint to the browser as to which resources are most important via the fetchpriority attribute for resources that could benefit from a higher priority:<img fetchpriority=""high"" src=""/path/to/hero-image.webp""> It's a good idea to set fetchpriority=""high"" on an &LTimg> element if you think it's likely to be your page's LCP element—but limit this to just one or two images (based on common desktop and mobile viewport sizes), otherwise the signal becomes meaningless. You can also lower the priority of images that may be early in the document response, but isn't visible due to styling, such as images in carousel slides that are not visible at startup:<img fetchpriority=""low"" src=""/path/to/carousel-slide-3.webp""> Deprioritizing certain resources can afford more bandwidth to resources that need it more—but be careful. Always check resource priority in DevTools and test changes with lab and field tools.After you have optimized your LCP resource priority and discovery time, your network waterfall should look like this (with the LCP resource starting at the same time as the first resource):ImportantAnother reason your LCP resource may not start loading as early as possible—even when it's discoverable from the HTML source—is if it's hosted on a different origin, as these requests require the browser to connect to that origin before the resource can start loading. When possible, it's a good idea to host critical resources on the same origin as your HTML document resource because then those resources can save time by reusing the existing connection (more on this point later).2. Eliminate element render delay #The goal in this step is to ensure the LCP element can render immediately after its resource has finished loading, no matter when that happens.The primary reason the LCP element wouldn't be able to render immediately after its resource finishes loading is if rendering is blocked for some other reason:Rendering of the entire page is blocked due to stylesheets or synchronous scripts in the &LThead> that are still loading.The LCP resource has finished loading, but the LCP element has not yet been added to the DOM (it's waiting for some JavaScript code to load).The element is being hidden by some other code, such as an A/B testing library that's still determining what experiment the user should be in.The main thread is blocked due to long tasks, and rendering work needs to wait until those long tasks complete.The following sections explain how to address the most common causes of unnecessary element render delay.Reduce or inline render-blocking stylesheets #Stylesheets loaded from the HTML markup will block rendering of all content that follows them, which is good, since you generally do not want to render unstyled HTML. However, if the stylesheet is so large that it takes significantly longer to load than the LCP resource, then it will prevent the LCP element from rendering—even after its resource has finished loading, as shown in this example:To fix this, your options are to either:inline the stylesheet into the HTML to avoid the additional network request; or,reduce the size of the stylesheet.In general, inlining your stylesheet is only recommended if your stylesheet is small since inlined content in the HTML cannot benefit from caching in subsequent page loads. If a stylesheet is so large that it takes longer to load than the LCP resource, then it's unlikely to be a good candidate for inlining.In most cases, the best way to ensure the stylesheet does not block rendering of the LCP element is to reduce its size so that it's smaller than the LCP resource. This should ensure it's not a bottleneck for most visits.Some recommendations to reduce the size of the stylesheet are:Remove unused CSS: use Chrome DevTools to find CSS rules that aren't being used and can potentially be removed (or deferred).Defer non-critical CSS: split your stylesheet out into styles that are required for initial page load and then styles that can be loaded lazily.Minify and compress CSS: for styles that are critical, make sure you're reducing their transfer size as much as possible.Defer or inline render-blocking JavaScript #It is almost never necessary to add synchronous scripts (scripts without the async or defer attributes) to the &LThead> of your pages, and doing so will almost always have a negative impact on performance.In cases where JavaScript code needs to run as early as possible in the page load, it's best to inline it so rendering isn't delayed waiting on another network request. As with stylesheets, though, you should only inline scripts if they're very small.Don't<head> <script src=""/path/to/main.js""></script></head> Do<head> <script> // Inline script contents directly in the HTML. // IMPORTANT: only do this for very small scripts. </script></head> Use server-side rendering #Server-side rendering (SSR) is the process of running your client-side application logic on the server and responding to HTML document requests with the full HTML markup.From the perspective of optimizing LCP, there are two primary advantage of SSR:Your image resources will be discoverable from the HTML source (as discussed in step 1 earlier).Your page content will not require additional JavaScript requests to finish before it can render.The main downside of SSR is it requires additional server processing time, which can slow down your TTFB. This trade-off is usually worth it though because server processing times are within your control, whereas the network and device capabilities of your users are not.A similar option to SSR is called static site generation (SSG) or prerendering. This is the process of generating your HTML pages in a build step rather than on-demand. If prerendering is possible with your architecture, it's generally a better choice for performance.Break up long tasks #Even if you've followed the above advice, and your JavaScript code is not render-blocking nor is it responsible for rendering your elements, it can still delay LCP.The most common reason this happens is when pages load large JavaScript files, which need to be parsed and executed on the browser's main thread. This means that, even if your image resource is fully downloaded, it may still have to wait until an unrelated script finishes executing before it can render.All browsers today render images on the main thread, which means anything that blocks the main thread can also lead to unnecessary element render delay.3. Reduce resource load time #The goal of this step is to reduce the time spent transferring the bytes of the resource over the network to the user's device. In general, there are three ways to do that:Reduce the size of the resource.Reduce the distance the resource has to travel.Reduce contention for network bandwidth.Eliminate the network time entirely.Reduce the size of the resource #The LCP resource of a page (if it has one) will either be an image or a web font. The following guides go into great detail about how to reduce the size of both:Serve the optimal image sizeUse modern image formatsCompress imagesReduce web font sizeReduce the distance the resource has to travel #In addition to reducing the size of a resource, you can also reduce the load times by getting your servers as geographically close to your users as possible. And the best way to do that is to use a content delivery network (CDN).In fact, image CDNs in particular are a great choice because they not only reduce the distance the resource has to travel, but they also generally reduce the size of the resource—automatically implementing all of the size-reduction recommendations from earlier for you.ImportantWhile image CDNs are a great way to reduce resource load times, using a third-party domain to host your images comes with an additional connection cost. While preconnecting to the origin can mitigate some of this cost, the best option is to serve images from the same origin as your HTML document. Many CDNs allow you to proxy requests from your origin to theirs, which is a great option to look into if available.Reduce contention for network bandwidth #Even if you've reduced the size of your resource and the distance it has to travel, a resource can still take a long time to load if you're loading many other resources at the same time. This problem is known as network contention.If you've given your LCP resource a high fetchpriority and started loading it as soon as possible then the browser will do its best to prevent lower-priority resources from competing with it. However, if you're loading many resources with high fetchpriority, or if you're just loading a lot of resources in general, then it could affect how quickly the LCP resource loads.Eliminate the network time entirely #The best way to reduce resource load times is to eliminate the network entirely from the process. If you serve your resources with an efficient cache-control policy, then visitors who request those resources a second time will have them served from the cache—bringing the resource load time to essentially zero!And if your LCP resource is a web font, in addition to reducing web font size, you should also consider whether you need to block rendering on the web font resource load. If you set a font-display value of anything other than auto or block, then text will always be visible during load, and LCP will not be blocked on an additional network request.Finally, if your LCP resource is small, it may make sense to inline the resources as a data URL, which will also eliminate the additional network request. However, using data URLs comes with caveats because then the resources cannot be cached and in some cases can lead to longer render delays because of the additional decode cost.4. Reduce time to first byte #The goal of this step is to deliver the initial HTML as quickly as possible. This step is listed last because it's often the one developers have the least control over. However, it's also one of the most important steps because it directly affects every step that comes after it. Nothing can happen on the frontend until the backend delivers that first byte of content, so anything you can do to speed up your TTFB will improve every other load metric as well.For specific guidance on this topic, see Optimize TTFB.Monitor LCP breakdown in JavaScript #The timing information for all of the LCP sub-parts discussed above is available to you in JavaScript through a combination of the following performance APIs:Largest Contentful Paint APINavigation Timing APIResource Timing APIThe benefit to computing these timing values in JavaScript is it allows you to send them to an analytics provider or log them to your developer tools to help with debugging and optimizing.For example, the following screenshot uses the performance.measure() method from the User Timing API to add bars to the Timings track in the Chrome DevTools Performance panel.Visualizations in the timings track are particularly helpful when looked at alongside the Network and Main thread tracks, because you can see at a glance what else is happening on the page during these timespans.In addition to visualizing the LCP sub-parts in the timings track, you can also use JavaScript to compute what percentage each sub-part is of the total LCP time. With that information, you can determine whether your pages are meeting the recommended percentage breakdowns described earlier.This screenshot shows an example that logs the total time of each LCP sub-part, as well as its percentage of the total LCP time to the console.Both of these visualizations were created with the following code:const LCP_SUB_PARTS = [ 'Time to first byte', 'Resource load delay', 'Resource load time', 'Element render delay',];new PerformanceObserver((list) => { const lcpEntry = list.getEntries().at(-1); const navEntry = performance.getEntriesByType('navigation')[0]; const lcpResEntry = performance .getEntriesByType('resource') .filter((e) => e.name === lcpEntry.url)[0]; // Ignore LCP entries that aren't images to reduce DevTools noise. // Comment this line out if you want to include text entries. if (!lcpEntry.url) return; // Compute the start and end times of each LCP sub-part. // WARNING! If your LCP resource is loaded cross-origin, make sure to add // the `Timing-Allow-Origin` (TAO) header to get the most accurate results. const ttfb = navEntry.responseStart; const lcpRequestStart = Math.max( ttfb, // Prefer `requestStart` (if TOA is set), otherwise use `startTime`. lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0 ); const lcpResponseEnd = Math.max( lcpRequestStart, lcpResEntry ? lcpResEntry.responseEnd : 0 ); const lcpRenderTime = Math.max( lcpResponseEnd, // Use LCP startTime (which is the final LCP time) as sometimes // slight differences between loadTime/renderTime and startTime // due to rounding precision. lcpEntry ? lcpEntry.startTime : 0 ); // Clear previous measures before making new ones. // Note: due to a bug this does not work in Chrome DevTools. LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part)); // Create measures for each LCP sub-part for easier // visualization in the Chrome DevTools Performance panel. const lcpSubPartMeasures = [ performance.measure(LCP_SUB_PARTS[0], {  start: 0,  end: ttfb, }), performance.measure(LCP_SUB_PARTS[1], {  start: ttfb,  end: lcpRequestStart, }), performance.measure(LCP_SUB_PARTS[2], {  start: lcpRequestStart,  end: lcpResponseEnd, }), performance.measure(LCP_SUB_PARTS[3], {  start: lcpResponseEnd,  end: lcpRenderTime, }), ]; // Log helpful debug information to the console. console.log('LCP value: ', lcpRenderTime); console.log('LCP element: ', lcpEntry.element, lcpEntry.url); console.table( lcpSubPartMeasures.map((measure) => ({  'LCP sub-part': measure.name,  'Time (ms)': measure.duration,  '% of LCP': `${  Math.round((1000 * measure.duration) / lcpRenderTime) / 10  }%`, })) );}).observe({type: 'largest-contentful-paint', buffered: true}); You can use this code as-is for local debugging, or modify it to send this data to an analytics provider so you can get a better understanding of what the breakdown of LCP is on your pages for real users.The above code works for standard navigations, but extra consideration must be taken for prerendered pages, which should be measured from the activation start time but which has been kept out of this code for simplicity.The web-vitals library includes this breakdown in the attribution build, and includes these considerations.For those looking to implement their own solution, the code for this is open source and is similar to above but with extra lofic for activation start.Monitor LCP breakdown via the Web Vitals extension #The Web Vitals extension will log the LCP time, LCP element, and these four sub-parts in the console logging, to easily allow you to see this breakdown.Summary #LCP is complex, and its timing can be affected by a number of factors. But if you consider that optimizing LCP is primarily about optimizing the load of the LCP resource, it can significantly simplify things.At a high level, optimizing LCP can be summarized in four steps:Ensure the LCP resource starts loading as early as possible.Ensure the LCP element can render as soon as its resource finishes loading.Reduce the load time of the LCP resource as much as you can without sacrificing quality.Deliver the initial HTML document as fast as possible.If you’re able to follow these steps on your pages, then you should feel confident that you’re delivering an optimal loading experience to your users, and you should see that reflected in your real-world LCP scores.PerformanceWeb VitalsLast updated May 4, 2023 — Improve article Return to all articles Share We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.Contribute File a bug View source Related content developer.chrome.com Chrome updates Case studies Podcasts Shows Connect Twitter YouTube Chrome Firebase Google Cloud Platform All products Dark theme Terms & Privacy Community Guidelines Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. By Chrome DevRel URL of this webpage is: https://web.dev/optimize-lcp/#optimize-when-the-resource-is-discovered"
+16,web.devpreload optional fonts.txt,"web.devpreload optional fonts.txt. Prevent layout shifting and flashes of invisible text (FOIT) by preloading optional fontsSkip to content Open menu  About Blog Learn Explore Patterns Case studies Close Thanks for tuning in to Google I/O. Watch the Chrome content on-demand.On this page Browser compatibilityFont renderingOptional fontsConclusion Home All articles Prevent layout shifting and flashes of invisible text (FOIT) by preloading optional fontsStarting in Chrome 83, link rel=""preload"" and font-display: optional can be combined to remove layout jank completelyMar 18, 2020 Available in: English, Español, Português, Русский, 中文, and 한국어  Houssein Djirdeh TwitterGitHubGlitchHomepageOn this page Browser compatibilityFont renderingOptional fontsConclusionIn Chrome 83, new font loading improvements have been made to completely eliminate layout shifting and flash of invisible text (FOIT) when optional fonts are preloaded.By optimizing rendering cycles, Chrome 83 eliminates layout shifting when preloading optional fonts. Combining &LTlink rel=""preload""> with font-display: optional is the most effective way to guarantee no layout jank when rendering custom fonts.Browser compatibility #Check out MDN's data for up-to-date cross-browser support information:&LTlink rel=""preload"">font-displayFont rendering #Layout shifting, or re-layout, occurs when a resource on a web page changes dynamically, resulting in a ""shift"" of content. Fetching and rendering web fonts can directly cause layout shifts in one of two ways:A fallback font is swapped with a new font (""flash of unstyled text"")""Invisible"" text is shown until a new font is rendered into the page (""flash of invisible text"")The CSS font-display property provides a way to modify rendering behavior of custom fonts through a range of different supported values (auto, block, swap, fallback, and optional). Choosing which value to use depends on the preferred behavior for asynchronously loaded fonts. However, every one of these supported values can trigger re-layout in one of the two ways listed above, until now!The Cumulative Layout Shift metric makes it possible to measure the layout instability on a web page.Optional fonts #The font-display property uses a timeline of three periods to handle fonts that need to be downloaded before they can be rendered:Block: Render ""invisible"" text, but switch to the web font as soon as it finishes loading.Swap: Render text using a fallback system font, but switch to the web font as soon as it finishes loading.Fail: Render text using a fallback system font.Previously, fonts designated with font-display: optional had a 100ms block period and no swap period. This means that ""invisible"" text is displayed very briefly before switching to a fallback font. If the font is not downloaded within 100ms, then the fallback font is used and no swapping occurs.Previous font-display: optional behavior in Chrome when font is downloaded after the 100ms block periodHowever, in the case that the font is downloaded before the 100ms block period completes, the custom font is rendered and used on the page.Previous font-display: optional behavior in Chrome when font is downloaded before the 100ms block periodChrome re-renders the page twice in both instances, regardless of whether the fallback font is used or if the custom font finishes loading in time. This causes a slight flicker of invisible text and, in cases when a new font is rendered, layout jank that moves some of the page's content. This occurs even if the font is stored in the browser's disk cache and can load well before the block period is complete.Optimizations have landed in Chrome 83 to entirely remove the first render cycle for optional fonts that are preloaded with &LTlink rel=""preload'>. Instead, rendering is blocked until the custom font has finished loading or a certain period of time has passed. This timeout period is currently set at 100ms, but may possibly change in the near future to optimize performance.New font-display: optional behavior in Chrome when fonts are preloaded and font is downloaded after the 100ms block period (no flash of invisible text)New font-display: optional behavior in Chrome when fonts are preloaded and font is downloaded before the 100ms block period (no flash of invisible text)Preloading optional fonts in Chrome removes the possibility of layout jank and flash of unstyled text. This matches the required behavior as specified in CSS Fonts Module Level 4 where optional fonts should never cause re-layout and user agents can instead delay rendering for a suitable period of time.Although it is not necessary to preload an optional font, it greatly improves the chance for it to load before the first render cycle, especially if it is not yet stored in the browser's cache.Conclusion #The Chrome team is interested to hear your experiences preloading optional fonts with these new optimizations in place! File an issue if you experience any problems or would like to drop any feature suggestions.PerformanceFontsLast updated Mar 18, 2020 — Improve article Return to all articles Share We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.Contribute File a bug View source Related content developer.chrome.com Chrome updates Case studies Podcasts Shows Connect Twitter YouTube Chrome Firebase Google Cloud Platform All products Dark theme Terms & Privacy Community Guidelines Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. By Chrome DevRel URL of this webpage is: https://web.dev/preload-optional-fonts"
+17,dequeuniversity.comaria meter name.txt,"dequeuniversity.comaria meter name.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    ARIA meter nodes must have an accessible name Rule ID: aria-meter-name Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)         Learn Web Accessibility   										Subscribe to our extensive curriculum of online self-paced courses 									 Learn More about Deque University   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Low Vision Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]1.1.1: MUST: Non-text ContentWCAG Success Criteria [WCAG 2.0 (A)]1.1.1: MUST: Non-text Content  How to Fix the Problem Correct markup solutions  The aria-meter-name rule has three markup patterns that pass  test criteria: <div role=""meter"" id=""alb"" aria-labelledby=""labeldiv""></div> <div role=""meter"" id=""combo"" aria-label=""Aria Name"">Name</div> <div role=""meter"" id=""title"" title=""Title""></div>   Ensure that each element with role=""meter"" has one of the  following characteristics:  Non-empty aria-label attribute. aria-labelledby pointing to element with text which is   discernible to screen reader users.   Incorrect markup solutions  The aria-meter-name rule has four markup patterns that fail  testing criteria: <div role=""meter"" id=""empty""></div> <div role=""meter"" id=""alempty"" aria-label=""""></div> <div role=""meter"" id=""albmissing"" aria-labelledby=""nonexistent""></div> <div role=""meter"" id=""albempty"" aria-labelledby=""emptydiv""></div> <div id=""emptydiv""></div> Why it Matters  Screen reader users are not able to discern the purpose of elements with role=""meter"" that do not have an accessible name. Rule Description  Aria meter elements must have discernible text that clearly describes the destination, purpose, function, or action for screen reader users. The Algorithm (in simple terms)  Checks all elements with role=""meter"" to ensure that they have a discernable, accessible name.  Resources Deque University Deque University Course Pages (subscription required) 						No related course information available. 					  Deque University  Contribute to axe-core on GitHub Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-meter-name"
+18,dequeuniversity.comth has data cells.txt,"dequeuniversity.comth has data cells.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Table headers in a data table must refer to data cells Rule ID: th-has-data-cells Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), Section 508     Need accessibility training?  Deque University offers an extensive curriculum of self-guided online courses for every skillset and experience level.  Start learning today   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A)Section 508 WCAG Success Criteria [WCAG 2.1 (A)]1.3.1: MUST: Info and RelationshipsWCAG Success Criteria [WCAG 2.0 (A)]1.3.1: MUST: Info and RelationshipsSection 508 Guidelines1194.22: MUST: Web based intranet and Internet Information & Applications1194.22 (g): MUST: Row and column headers shall be identified for data tables.” and “(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.  How to Fix the Problem  Ensure that each table header in a data table refers to data cells so that each header cell that is used is actually a header of something.  In other words, the th element must have associated data cells.  If header attributes exist, ensure that they reference elements with text available to screen readers.  The th element must not use the headers attribute  th elements should only be used when there is a single row and  single column of headers th elements must use the scope attribute  Bad Example: <th> with set to  scope=""row"" instead of  scope=""col""  Notice the <th> elements are scoped to  row when they should be scoped to col in the  following table:   Teddy bear collectors:  Last Name First Name City Phoenix Imari Henry Zeki Rome Min Apirka Kelly Brynn <table> <caption>Teddy bear collectors:</caption> <tr>  <th scope=""row"">Last Name</th>  <th scope=""row"">First Name</th>  <th scope=""row"">City</th> </tr> <tr>  <td>Phoenix</td>  <td>Imari</td>  <td>Henry</td> </tr> <tr>  <td>Zeki</td>  <td>Rome</td>  <td>Min</td> </tr> <tr>  <td>Apirka</td>  <td>Kelly</td>  <td>Brynn</td> </tr> </table>  Following is the corrected code for associating column headers with table content in the previous example: ... <th scope=""col"">Last Name</th> <th scope=""col"">First Name</th> <th scope=""col"">City</th> ... Why it Matters  Screen readers have a specific way of announcing tables. When tables are not properly marked up, this creates the opportunity for confusing or inaccurate screen reader output.  When tables are not marked up semantically and do not have the correct header structure, screen reader users cannot correctly perceive the relationships between the cells and their contents visually. Rule Description  Data table markup can be tedious and confusing. Markup tables semantically and with the correct header structure. Screen readers have features to ease table navigation, but tables must be marked up accurately for these features to work correctly. The Algorithm (in simple terms)  Checks data tables markup, ensuring each header cell is referenced as a header of a column or row.  Resources Deque University Deque University Course Pages (subscription required) Table caption/nameTable HeadersGrouped Header AssociationsComplex Header Associations  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. Tables ConceptsH43: Using id and headers attributes to associate data cells with header cells in data tablesH51: Using table markup to present tabular informationH63: Using the scope attribute to associate header cells and data cells in data tablesH73: Using the summary attribute of the table element to give an overview of data tables Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/th-has-data-cells"
+19,web.devoptimize cls.txt,"web.devoptimize cls.txt. Optimize Cumulative Layout ShiftSkip to content Open menu  About Blog Learn Explore Patterns Case studies Close Thanks for tuning in to Google I/O. Watch the Chrome content on-demand.On this page Understanding where your shifts are coming fromCLS in lab tools versus fieldIdentifying load CLS issuesIdentifying post-load CLS issuesMeasuring CLS elements in the fieldCommon causes of CLSImages without dimensionsAds, embeds, and other late-loaded contentAnimationsWeb fontsReduce CLS by ensuring pages are eligible for the bfcacheConclusion Home All articles Optimize Cumulative Layout ShiftLearn how to avoid sudden layout shifts to improve user-experienceMay 5, 2020 — Updated May 4, 2023 Available in: English, Español, Português, Русский, 中文, 日本語, and 한국어 Appears in: Fast load times | Core Web Vitals Barry Pollard TwitterGitHubHomepage Addy Osmani TwitterGitHubOn this page Understanding where your shifts are coming fromCLS in lab tools versus fieldIdentifying load CLS issuesIdentifying post-load CLS issuesMeasuring CLS elements in the fieldCommon causes of CLSImages without dimensionsAds, embeds, and other late-loaded contentAnimationsWeb fontsReduce CLS by ensuring pages are eligible for the bfcacheConclusion""I was about to click that! Why did it move? 😭""Cumulative Layout Shift (CLS) is one of the three Core Web Vitals metrics, and it measures the instability of content by summing shift scores across layout shifts that don't occur within 500 milliseconds of user input. It looks at how much visible content shifted in the viewport as well as the distance the elements impacted were shifted.Layout shifts can be distracting to users. Imagine you've started reading an article when all of a sudden elements shift around the page, throwing you off and requiring you to find your place again. This is very common on the web, including when reading the news, or trying to click those 'Search' or 'Add to Cart' buttons. Such experiences are visually jarring and frustrating. They're often caused when visible elements are forced to move because another element was suddenly added to the page or resized.To provide a good user experience, sites should strive to have a CLS of 0.1 or less for at least 75% of page visits.Unlike the other Core Web Vitals, which are time-based values measured in seconds or milliseconds, the CLS score is a unitless value based on a calculation of how much content is shifting and by how far.In this guide, we'll cover optimizing common causes of layout shifts.The most common causes of a poor CLS are:Images without dimensionsAds, embeds, and iframes without dimensionsDynamically injected content such as ads, embeds, and iframes without dimensionsWeb fontsFor a visual overview of some of the content presented in this guide, see the Optimize for Core Web Vitals video from Google I/O 2020: Understanding where your shifts are coming from #Before we start looking at solutions to common CLS issues, it's always important to understand your CLS score and where the shifts are coming from. A big part of the problem is understanding your CLS score—the fix afterwards is often the easier part!CLS in lab tools versus field #It is quite common to hear developers think the CLS measured by the Chrome UX Report (CrUX) is incorrect as it does not match the CLS they measure using Chrome DevTools or other lab tools. Web performance lab tools like Lighthouse may not show the full CLS of a page as they typically do a simple load of the page to measure some web performance metrics and provide some guidance (though Lighthouse user flows do allow you measure beyond the default page load audit).CrUX is the official dataset of the Web Vitals program, and for that, CLS is measured throughout the full life of the page and not just during the initial page load that lab tools typically measure.Layout shifts are very common during page load, as all the necessary resources are fetched to initially render the page, but layout shifts can also happen after the initial load. Many post-load shifts may occur as the result of a user interaction and therefore will be excluded from the CLS score as they are expected shifts—as long as they occur within 500 milliseconds of that interaction.However, other post-load shifts that are unexpected by the user may be included where there was no qualifying interaction—for example, if you scroll down the page and lazy-loaded content is loaded and that causes shifts. Other common causes of post-load CLS are on interactions of transitions, for example on Single Page Apps, which take longer than the 500 millisecond grace period.PageSpeed Insights will show both the user-perceived CLS from a URL where it exists in the ""Discover what your real users are experiencing"" section, and also the lab-based load CLS in the ""Diagnose performance issues"" section beneath. If you see a difference between these, this is likely caused by post-load CLS.PageSpeed Inights will show URL-level data where it exists, and attempt to fall back to origin-level data where this does not exist. Always check what data is showing to ensure you do not waste time trying to track down a CLS issue that actually exists on other pages on your origin! In the above example you can see this is URL-level data as shown in the top right of the image.Identifying load CLS issues #When the CrUX and Lighthouse CLS scores of PageSpeed Insights are broadly in line, this usually indicates there is a load CLS issue that was detected by Lighthouse. In this case Lighthouse will help with two audits to provide more information on images causing CLS due to missing width and height, and also list all the elements that shifted for the page load along with their CLS contribution. You can see these audits by filtering on the CLS audits:Lighthouse will identify the elements that were shifted, but often these are the ones impacted rather than the elements causing the CLS. For example, if a new element is inserted into the DOM, the elements that are beneath it will show in this audit, but the root cause is the addition of the new element above. However, the shifted element should be sufficient to help you identify and resolve the root cause.The Performance panel in DevTools also highlights layout shifts in the Experience section. The Summary view for a Layout Shift record includes the cumulative layout shift score as well as a rectangle overlay showing the affected regions. This is particularly helpful to get more detail on load CLS issues since this is easily replicated with a reload performance profile.After recording a new trace in the Performance panel, the Experience section of the results is populated with a red-tinted bar displaying a Layout Shift record. Clicking the record allows you to drill down into impacted elements (e.g. note the moved from/to entries).Identifying post-load CLS issues #When the CrUX and Lighthouse CLS scores of PageSpeed Insights are not in line, then this likely indicates post-load CLS. Without field data helping to identify the reason (that we will cover next), these can be more tricky to track down.The Web Vitals Chrome extension can be used to monitor CLS as you interact with a page, either in a heads up display, or in the console—where you can get more details above the elements shifted.As an alternative to using the extension, you can browse your web page while recording layout shifts using a Performance Observer pasted into the console.Once you are monitoring shifts you can try to replicate any post-load CLS issues. Scolling down a page is a common place for CLS to occur if content is lazy loaded and does not have space reserved for it. Content shifting on hover is another common post-load CLS cause. Both of these ""interactions"" are ineligible for the 500 milliseconds grace period as CLS during these periods are seen as being ""unexpected shifts"", despite the user interaction, as they should not cause content to shift. Other interactions—such as clicks or taps—do have that grace period, but a common reason for CLS in these cases is taking longer than that 500 milliseconds to move or add content.We have a more detailed posted on debugging layout shifts for more information.Once you have identified any common causes of CLS, the timespans user flow mode of Lighthouse can also be used to ensure typical user flows do not regress by introducing layout shifts.Measuring CLS elements in the field #It is also recommended to monitor CLS in the field. This can be used to measure both the CLS and—perhaps more importantly—the elements impacting your CLS score in the field and feed them back to your analytics service.This can be invaluable in pointing you in the right direction of where the issue is as it can remove much of the guess work discribed above when you are trying to understand under what circumstances CLS is occuring. Again, be aware that this will measure the elements that shifted, rather than the root causes of those shifts, but this is often sufficient to identify the cause or at least to narrow down the problem.Measuring CLS in the field can also be used to rank the issues in order of importance based on most frequently experienced issues.The attribution functionality of the web-vitals library allows this additional information to be collected. Read our Debug performance in the field post for more information on how to do this. Other RUM providers have also started collecting and presenting this data similarly.RUM solutions that measure CLS in the field, including the web-vitals library, may show differences that CrUX data as explained in the Why is CrUX data different from my RUM data? post. In particular, CLS that happens in iframes is not measurable from Web APIs but is visible to the user, and is therefore included in CrUX. So while field data can be invaluable for identifying CLS issues, be aware that it may be incomplete in certain scenarios.Common causes of CLS #Once you have identified the causes of CLS, you can start working on fixing the issues. In this section we will show some of the more common reasons for CLS, and what you can do to avoid them.Images without dimensions #Always include width and height size attributes on your images and video elements. Alternatively, reserve the required space with CSS aspect-ratio or similar. This approach ensures that the browser can allocate the correct amount of space in the document while the image is loading. Images without width and height specified. Images with width and height specified.Lighthouse 6.0 impact of setting image dimensions on CLS.History of width and height attributes on images #In the early days of the web, developers would add width and height attributes to their &LTimg> tags to ensure sufficient space was allocated on the page before the browser started fetching images. This would minimize reflow and re-layout.<img src=""puppy.jpg"" width=""640"" height=""360"" alt=""Puppy with balloons""> You may notice width and height above do not include units. These ""pixel"" dimensions would ensure a 640x360 area would be reserved. The image would stretch to fit this space, regardless of whether the true dimensions matched or not.When Responsive Web Design was introduced, developers began to omit width and height and started using CSS to resize images instead:img { width: 100%; /* or max-width: 100%; */ height: auto;} A downside to this approach is space could only be allocated for an image once it began to download and the browser could determine its dimensions. As images loaded in, the page would reflow as each image appeared on screen. It became common for text to suddenly pop down the screen. This wasn't a great user experience at all.This is where aspect ratio comes in. The aspect ratio of an image is the ratio of its width to its height. It's common to see this expressed as two numbers separated by a colon (for example 16:9 or 4:3). For an x:y aspect ratio, the image is x units wide and y units high.This means if we know one of the dimensions, the other can be determined. For a 16:9 aspect ratio:If puppy.jpg has a 360px height, width is 360 x (16 / 9) = 640pxIf puppy.jpg has a 640px width, height is 640 x (9 / 16) = 360pxKnowing the aspect ratio allows the browser to calculate and reserve sufficient space for the height and associated area.Modern best practice for setting image dimensions #Modern browsers now set the default aspect ratio of images based on an image's width and height attributes so developers just need to set these, and include the above CSS, to prevent layout shifts:<!-- set a 640:360 i.e a 16:9 aspect ratio --><img src=""puppy.jpg"" width=""640"" height=""360"" alt=""Puppy with balloons""> All browsers will then add a default aspect ratio based on the element's existing width and height attributes.This calculates an aspect ratio based on the width and height attributes before the image has loaded. It provides this information at the very start of layout calculation. As soon as an image is told to be a certain width (for example width: 100%), the aspect ratio is used to calculate the height.This aspect-ratio value is calculated by major browsers as the HTML is processed, rather than with a default User Agent stylesheet (see this post for a deep dive into why), so the value is displayed a little differently. For example, Chrome displays it like this in the Styles section of the Element panel:img[Attributes Style] { aspect-ratio: auto 640 / 360;} Safari behaves similarly by using a HTML Attributes style source. Firefox does not currently display this calculated aspect-ratio at all in it's Inspector panel, but does use it for layout.The auto part of the above code is important as it causes the 640 / 360 to be overriden with the image dimensions once the image is downloaded. If the image dimensions are different this will still cause some layout shift after the image loads, but this ensures the image aspect ratio is still used ultimately when it becomes available—as it was in the past—in case the HTML is incorrect. Plus, the shift is likely to be a lot smaller than the 0x0 default image size when dimensions are not provided!Tip: If you're having a hard time understanding aspect ratio, a handy calculator is available to help.For a fantastic deep-dive into aspect ratio with further thinking around responsive images, see jank-free page loading with media aspect ratios.If your image is in a container, you can use CSS to resize the image to the width of this container. We set height: auto; to avoid the image height being a fixed value (for example 360px).img { height: auto; width: 100%;} What about responsive images? #When working with responsive images, srcset defines the images you allow the browser to select between and what size each image is. To ensure &LTimg> width and height attributes can be set, each image should use the same aspect ratio.<img width=""1000"" height=""1000"" src=""puppy-1000.jpg"" srcset=""puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"" alt=""Puppy with balloons""/> What about art direction?Pages may wish to include a cropped shot of an image on narrow viewports with the full image displayed on desktop.<picture> <source media=""(max-width: 799px)"" srcset=""puppy-480w-cropped.jpg"" /> <source media=""(min-width: 800px)"" srcset=""puppy-800w.jpg"" /> <img src=""puppy-800w.jpg"" alt=""Puppy with balloons"" /></picture> It's very possible these images could have different aspect ratios. Chrome, Firefox, and Safari now support setting width and height on the source children of the picture element:<picture> <source media=""(max-width: 799px)"" srcset=""puppy-480w-cropped.jpg"" width=480 height=400/> <source media=""(min-width: 800px)"" srcset=""puppy-800w.jpg"" width=800 height=400/> <img src=""puppy-800w.jpg"" alt=""Puppy with balloons"" width=800 height=400/></picture> Ads, embeds, and other late-loaded content #As we have seen, images have special considerations. However, images are not the only type of content that can cause layout shifts. Ads, embeds, iframes, and other dynamically injected content can all cause content after these to shift down, increasing your CLS.Ads are one of the largest contributors to layout shifts on the web. Ad networks and publishers often support dynamic ad sizes. Ad sizes increase performance/revenue due to higher click rates and more ads competing in the auction. Unfortunately, this can lead to a suboptimal user experience due to ads pushing visible content you're viewing down the page.Embeddable widgets allow you to include portable web content in your page, such as videos from YouTube, maps from Google Maps, and social media posts. These widgets often aren't aware in advance just how large their contents will be. For example, in the case of a social media post, it might have an embedded image, video, multiple rows of text, or a number of other unpredictable factors. As a result, platforms offering embeds do not always reserve space for their widgets and so cause layout shifts when they finally load.The techniques for dealing with these are all similar. The major differences are how much control you have over the content that will be inserted. If this is inserted by a third-party like an ad partner, you may not know the exact size of content that will be inserted, nor be able to control any layout shifts happening within those embeds.Statically reserve space for late-loading content #When placing late-loading content in the content flow, layout shifts can be avoided by reserving the space for them in the initial layout.This can be as simple as adding a min-height styling to reserve space or, for responsive content such as ads, using the new aspect-ratio CSS property in a similar manner to the way browsers automatically use this for images with dimensions provided.Reserving space for ads can prevent layout shiftsYou may need to account for subtle differences in ad or placeholder sizes across form factors using media queries.For content that may not have a fixed height—like ads—you may not be able to reserve the exact amount of space needed to eliminate the layout shift entirely. If a smaller ad is served, a publisher can style the (larger) container to avoid layout shifts, or choose the most likely size for the ad slot based on historical data. The downside to this approach is that it will increase the amount of blank space, so keep in mind the trade-off here.Alternatively, set the initial size to the smallest size that will be used, and accept some level of shift for larger content. Using min-height, as suggested above, will allow the parent element to grow as necessary. This will not fully eliminate CLS, but will hopefully reduce the impact of it to a more managable level. The default size of an empty element is 0px which gives maximum CLS, so any size is better than that!Try to avoid collapsing the reserved space if, for example, there is no ad returned, by showing a placeholder. Removing the space set aside for elements can cause just as much CLS as inserting content!Avoid placing late-loading content near the top of the viewport #Dynamically injected content near the top of the viewport may cause a greater layout shift than those at the middle. This is because elements inserted at the top generally have more content lower down, meaning more elements move when the late-loading content causes a shift.Conversely, dynamically injected content near the middle of the viewport may not shift as many elements as the content above it is less likely to move, but will still cause some CLS. Even content injected at the bottom of the screen will cause CLS as the content it replace is moved off-screen.The ideal scenario is not to shift any other content so reserving the appropriate space is preferred. Where this is not possible, minimizing the shifts can at least reduce the impact—both to your users and your CLS scores.Avoid inserting new content without a user interaction #You've probably experienced layout shifts due to UI that pops-in at the top or bottom of the viewport when you're trying to load a site. Similar to ads, this often happens with banners and forms that shift the rest of the page's content:""Sign-up to our newsletter!"" (whoa, slow down! we just met!)""Related content""""Install our [iOS/Android] app""""We're still taking orders""""GDPR notice"" Dynamic content without space reserved.If you need to display these types of UI affordances, reserve sufficient space in the viewport for it in advance (for example, using a placeholder or skeleton UI) so that when it loads, it does not cause content in the page to surprisingly shift around. Alternatively, ensure the element is not part of the document flow by overlaying the content where this makes sense. See the Best practices for cookie notices post for more recommendations on these types of components.In some cases adding content dynamically is an important part of user experience. For example, when loading more products to a list of items or when updating live feed content. There are several ways to avoid unexpected layout shifts in those cases:Replace the old content with the new content within a fixed size container or use a carousel and remove the old content after the transition. Remember to disable any links and controls until the transition has completed to prevent accidental clicks or taps while the new content is coming in.Have the user initiate the load of new content, so they are not surprised by the shift (for example with a ""Load more"" or ""Refresh"" button). It's recommended to prefetch the content before the user interaction so that it shows up immediately. As a reminder, layout shifts that occur within 500 milliseconds of user input are not counted towards CLS.Seamlessly load the content offscreen and overlay a notice to the user that it's available (for example, with a ""Scroll up"" button).Examples of dynamic content loading without causing unexpected layout shifts. Left: Live feed content loading on Twitter. Right: ""Load More"" example on Chloé website. Check out how the YNAP team optimized for CLS when loading more content.If content is likely to take more than 500 milliseconds—for example it requires a network fetch—then reserving the expected space within that 500 millisecond timeframe and taking the impact of any future shift up front allows you to ensure any shifts will not be included in the CLS score.Animations #Changes to CSS property values can require the browser to react to these changes. A number of values trigger re-layout, paint, and composite such as box-shadow and box-sizing. Try to avoid animating these.A number of CSS properties can be changed in a much more performant manner. For example, transform animations can be used to translate, scale, rotate, or skew without triggering a re-layout and so completely avoiding layout shifts.When animations are instead done by changing top and left CSS properties instead of using translate, layout shifts occur. This happens even when the element being moved is in it's own layer and so does not cause shifts to other elements. Composited animations via translate are exempt from CLS as they cannot impact other elements. There are also other considerable performance benefits of using non-composited animations since they do no cause re-layout and therefore are much less work for the browser.To learn more about what CSS properties trigger layout see High-performance animations.Web fonts #Downloading and rendering web fonts is typically handled in one of two ways before the web font is downloaded:The fallback font is swapped with the web font (FOUT—flash of unstyled text)""Invisible"" text is displayed using the fallback font until a web font is available and the text is made visible (FOIT—flash of invisible text)It is important to understand that both of these can cause layout shifts. Even though the text is invisible, it is laid out using the fallback font. This means the text block using the font, and the surrounding content, shifts when the web font loads—in the exact same way as for the visible font for FOUT.The following tools can help you minimize this:font-display: optional can avoid a re-layout as the web font is only used if it is available by the time of initial layout.Ensure the appropriate fallback font is used. For example, using font-family: ""Google Sans"", sans-serif; will ensure the browser's sans-serif fallback font is used while ""Google Sans"" is loaded. Not specifying a fallback font using just font-family: ""Google Sans"" will mean the default font is used, which on Chrome is ""Times""—a serif font which is a worse match than the default sans-serif font.Minimize the size differences between the fallback font and the web font using the new size-adjust, ascent-override, descent-override, and line-gap-override APIs as detailed in the Improved font fallbacks post.The Font Loading API can reduce the time it takes to get necessary fonts.Load critical web fonts as early as possible using &LTlink rel=preload>. A preloaded font will have a higher chance to meet the first paint, in which case there's no layout shifting.Read Best practices for fonts for other font best practices.Reduce CLS by ensuring pages are eligible for the bfcache #A highly effective technique for keeping CLS scores low is to ensure your web pages are eligible for the back/forward cache (bfcache).The bfcache keeps pages in browsers memory for a short period after you navigate away so if you return to them, then they will be restored exactly as you left them. This means the fully loaded page is instantly available—without any shifts which may be normally seen during load due to any of the reasons above.While this does potentially still mean the initial page load encounters layout shifts, when a user goes back through pages they are not seeing the same layout shifts repeatedly. You should always aim to avoid the shifts even on the initial load, but where that is more tricky to resolve fully, you can at least reduce the impact by avoiding them on any bfcache navigations.Back and forward navigations are common on many sites. For example, returning to a contents page, or a category page, or search results.When this was rolled out to Chrome, we saw noticeable improvements in CLS.The bfcache is used by default by all browsers, but some sites are ineligible for the bfcache due to a variety of reasons. Read the bfcache article for more details on how to test and identify any issues preventing bfcache usage to ensure you are making full use of this feature to help your overall CLS score for your site.Conclusion #There are a number of techniques to identify and improve CLS as detailed above. There are allowances built into Core Web Vitals, so even if you cannot eliminate CLS completely, using some of these techniques should allow you to reduce the impact. This will be better for your users and hopefully allow you to stay within those limits.That's it for this guide. We hope it helps keep your pages just a little less shifty :)PerformanceWeb VitalsLast updated May 4, 2023 — Improve article Return to all articles Share We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.Contribute File a bug View source Related content developer.chrome.com Chrome updates Case studies Podcasts Shows Connect Twitter YouTube Chrome Firebase Google Cloud Platform All products Dark theme Terms & Privacy Community Guidelines Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. By Chrome DevRel URL of this webpage is: https://web.dev/optimize-cls"
+20,dequeuniversity.comaria valid attr value.txt,"dequeuniversity.comaria valid attr value.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    ARIA attributes must conform to valid values Rule ID: aria-valid-attr-value Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Start building more accessible experiences  Axe DevTools Pro helps dev teams find and fix up to 80% of accessibility issues while coding. No experience required. Get started with your free trial today.  Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, Value  How to Fix the Problem  Ensure the value inside each attribute is spelled correctly and corresponds to a valid value.  For example, aria-hidden=""true"" would pass, but aria-hidden=""rtue"" would fail, as would aria-hidden=""pizza"".  As another example, the checkbox role only has three possible values: true, false, or mixed. Using any value other than one of those three will prevent the checkbox from being functional. Note:  Particular caution must be used when specifying values for ARIA attributes,  as factors such as the distinction between states and properties, role  inheritance, undefined and default values can be confusing.  Value Types It is useful to take into consideration the following allowed state or property value types: true/false  Value representing either true or false, with a default ""false"" value. tristate  Value representing true or false, with an intermediate ""mixed"" value.  Default value is ""false"" unless otherwise specified.  true/false/undefined  Value representing true or false, with a default ""undefined"" value  indicating the state or property is not relevant. ID reference  Reference to the ID of another  element  in the same document ID reference list A list of one or more ID references. integer A numerical value without a fractional component. number Any real numerical value. string Unconstrained value type. token One of a limited set of allowed values. token list A list of one or more tokens. Undefined Value: The ""undefined"" value, when allowed on a state or property, is an explicit indication that the state or property is not set. The value is used on states and properties that support tokens, and the ""undefined"" value is a string that is one of the allowed tokens. It is also used on some states and properties that accept true/false values, when ""undefined"" has a different meaning than ""false"".  These are generic types for states and properties, but do not define specific representation. See State and Property Attribute Processing for details on how these values are expressed and handled in host languages. Default Value and Implicit Value for Role: Many states and properties have default values. Occasionally, the default value when used on a given role should be different from the usual default. Roles that require a state or property to have a non-standard default value indicate this in the ""Implicit Value for Role"". This is expressed in the form ""state or property name is new default value"". Roles that define this have the new default value for the state or property if the author does not provide an explicit value. State and Property Values Reference: For complete information about allowed values, refer to the table of characteristics for each individual attribute at W3C WAI-ARIA 1.1 Supported States and Properties. Why it Matters  ARIA attributes (i.e. starting with aria-) must contain valid values. These values must be spelled correctly and correspond to values that make sense for a particular attribute to perform the intended accessibility function.  Many ARIA attributes accept a specific set of values. Allowed values, acceptable ""undefined"" values, and acceptable ""default"" values are required. Failure to comply with allowed values results in content that is not accessible to assistive technology users. Rule Description  ARIA attributes starting with aria- must contain valid values. These values must be spelled correctly and correspond to values that make sense for a particular attribute in order to perform the intended accessibility function. The Algorithm (in simple terms)  Checks all elements that contain WAI-ARIA attributes to ensure that the values of the attributes are valid.  Resources Deque University Deque University Course Pages (subscription required) Landmark RolesWidget RolesPseudo HTML RolesThe Document RoleThe Application RoleThe Presentation RoleThe Math RoleThe Definition RoleThe Note RoleThe Directory RoleAbstract Roles  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. Accessible Rich Internet Applications (WAI-ARIA) 1.1 - Supported States and Properties Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-valid-attr-value"
+21,dequeuniversity.comaria valid attr.txt,"dequeuniversity.comaria valid attr.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    ARIA attributes must conform to valid names Rule ID: aria-valid-attr Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Start building more accessible experiences  Axe DevTools Pro helps dev teams find and fix up to 80% of accessibility issues while coding. No experience required. Get started with your free trial today.  Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, Value  How to Fix the Problem  This rule checks for the presence of an unrecognized ARIA attribute, which prevents the attribute from functioning as intended.  Ensure all ARIA attributes (as opposed to the values inside of them) used are spelled correctly and correspond to valid ARIA attribute names.  For example, aria-hidden=""true"" would pass, while aria-visible=""rute"" would fail. Authoring Tools: Using authoring and debugging tools that compare attributes for widget roles, states, and properties to those supported in WAI-ARIA may check the validity of ARIA attributes automatically during development, but they cannot reliably eliminate the need for testing. Related WAI-ARIA 1.1 W3C Recommendation Sections: To be certain you are using recognized attribute names and that they are spelled correctly, refer to the following sections for complete details of each ARIA attribute: Widget Attributes Live Region Attributes Drag-and-Drop Attributes Relationship Attributes Definitions of States and Properties (all aria-* attributes) Role Attribute State and Property Attributes State and Property Attribute Processing WAI-ARIA Attributes Module WAI-ARIA Attributes XML Schema Module  Why it Matters  If the developer uses a non-existent or misspelled ARIA attribute, the attribute will not be able to perform the accessibility function intended by the developer.  In order to allow assistive technologies to convey appropriate information to persons with disabilities, user interface elements intended to improve the accessibility and interoperability of web and application content must conform to properly spelled and current ARIA attributes.  When developers do not use attributes defined in the WAI-ARIA 1.1 W3C Recommendation, they do not properly convey user interface behaviors and structural information to assistive technologies in document-level markup. Rule Description  ARIA attributes starting with aria- must have valid names. Referring to a misspelled attribute or to one that does not exist will result in an invalid attribute and thus failure of this rule. The Algorithm (in simple terms)  Checks all elements that contain WAI-ARIA attributes to ensure that the attributes are valid attributes.  Resources Deque University Deque University Course Pages (subscription required) Landmark RolesWidget RolesPseudo HTML RolesThe Document RoleThe Application RoleThe Presentation RoleThe Math RoleThe Definition RoleThe Note RoleThe Directory RoleAbstract Roles  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. Accessible Rich Internet Applications (WAI-ARIA) 1.1 - Supported States and Properties Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-valid-attr"
+22,dequeuniversity.comdlitem.txt,"dequeuniversity.comdlitem.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    <dt> and <dd> elements must be contained by a <dl> Rule ID: dlitem Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Accessibility testing for dev teams - No experience required  Find and fix up to 80% of accessibility issues with axe DevTools Pro. Get started with your free trial today. No credit card needed.   Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]1.3.1: MUST: Info and RelationshipsWCAG Success Criteria [WCAG 2.0 (A)]1.3.1: MUST: Info and Relationships  How to Fix the Problem  Wrap the list item in parent dl elements to ensure the list follows the proper hierarchy. Furthermore, make sure that the dt and dd elements are in the proper order.  This rule checks for the valid hierarchical use of definition list elements to help screen reader users know what they are listening to, and what to expect as they listen to definition lists with regard to the organizational relationship of parent and child items. For example, if you have the following code causing an error: <dt>Coffee</dt> <dd>Black hot drink</dd> <dt>Milk</dt> <dd>White cold drink</dd> Wrap it in the <dl> element: <dl> <dt>Coffee</dt>  <dd>Black hot drink</dd> <dt>Milk</dt>  <dd>White cold drink</dd> </dl> Why it Matters  A definition list item must be wrapped in parent dl elements, otherwise it will be invalid.  A definition list must follow a specific hierarchy. A list is defined using the dl element. What follows are alternating sets of dt and dd elements, starting with the dt element. dt elements define a term while dd elements denote a term's description. Each set of dt elements must have a corresponding set of dd elements. Only dt and dd elements are allowed in definition list. If this hierarchy is not followed, the list will be invalid. Rule Description  Definition list items (dt and/or dd) must be wrapped in parent dl elements to be valid. This enables screen reader users to understand the proper hierarchy of information in the list. The Algorithm (in simple terms)  Ensures that all child dd and dt elements have a dl as a parent.  Resources Deque University Deque University Course Pages (subscription required) Semantic Markup for Lists  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. H40: Using description listsH48: Using ol, ul and dl for lists or groups of links Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/dlitem"
+23,dequeuniversity.comcolor contrast.txt,"dequeuniversity.comcolor contrast.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Elements must meet minimum color contrast ratio thresholds Rule ID: color-contrast Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (AA), WCAG 2.0 (AA)     Start building more accessible experiences  Axe DevTools Pro helps dev teams find and fix up to 80% of accessibility issues while coding. No experience required. Get started with your free trial today.  Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Low Vision Colorblindness  Standard(s) WCAG 2.1 (AA)WCAG 2.0 (AA) WCAG Success Criteria [WCAG 2.1 (AA)]1.4.3: MUST: Contrast (Minimum)WCAG Success Criteria [WCAG 2.0 (AA)]1.4.3: MUST: Contrast (Minimum)  How to Fix the Problem  Ensure all text elements have sufficient color contrast between the text in the foreground and background color behind it. Success Criterion: Ensure color contrast of at least 4.5:1 for small text or 3:1 for large text, even if text is part of an image. Large text has been defined in the requirements as 18pt (24 CSS pixels) or 14pt bold (19 CSS pixels). Note: Elements found to have a 1:1 ratio are considered ""incomplete"" and require a manual review.  Use the color contrast analyzer below to find colors that pass the guidelines.  Image – + Fit Drag image here, or Upload an Image   Color Contrast Analysis Tools: Below are links to tools that will analyze color contrast ratios against guidelines: axe DevTools Browser Extensions  — Deque's enterprise product, axe DevTools HTML, enables development  groups to integrate accessibility testing into existing automated testing  processes and is used by customers in conjunction with Deque's  axe Monitor accessibility  monitoring and reporting product. In addition to providing a code library  for integration in many programming languages, axe DevTools also includes  web accessibility analysis extensions for Google Chrome and Mozilla Firefox,  enabling enterprise front-end developers to run a quick accessibility test  at any time. Analysis tools return detailed information on accessibility  violations and instructions to fix issues with including links to more  in-depth knowledge.  axe-core — The axe  accessibility engine is an open-source JavaScript accessibility rules  library that is fast, returns no false positive errors or duplicate results,  and is available as a GitHub repository, browser plugin, or framework  integration.  Why it Matters  Some people with low vision experience low contrast, meaning that there aren't very many bright or dark areas. Everything tends to appear about the same brightness, which makes it hard to distinguish outlines, borders, edges, and details. Text that is too close in luminance (brightness) to the background can be hard to read.  There are nearly three times more individuals with low vision than those with total blindness. One in twelve people cannot see the average full spectrum of colors - about 8% of men and 0.4% of women in the US. A person with low vision or color blindness is unable to distinguish text against a background without sufficient contrast. Color transparency and opacity is taken into account in the background. Color transparency and opacity in the foreground is more difficult to detect and account for due to: 1:1 colors in foreground and background. CSS background gradients. Background colors in CSS pseudo-elements. Background colors created with CSS borders.  Overlap by another element in the foreground - this sometimes comes up with  tricky positioning. Elements moved outside the viewport via CSS. Rule Description  All text elements must have sufficient contrast between text in the foreground and background colors behind it in accordance with WCAG 2 AA contrast ratio thresholds. The Algorithm (in simple terms)  Checks all text elements to ensure that the contrast between the foreground text and the background colors meet the WCAG 2 AA contrast ratio thresholds. Note:  This rule will not report on text elements that have a  background-image, are obscured by other elements or are images  of text.  This also checks for child elements of disabled buttons so they can be ignored to avoid a false value.  Resources Deque University Deque University Course Pages (subscription required) SC 1.4.3 Contrast (Minimum)ColorContrast  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the textW3C Understanding Success Criterion 1.4.3: Contrast (Minimum) Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/color-contrast"
+24,dequeuniversity.comtabindex.txt,"dequeuniversity.comtabindex.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Elements should not have tabindex greater than zero Rule ID: tabindex Ruleset: axe-core 4.7 User Impact: Serious Guidelines: Deque Best Practice     Need accessibility training?  Deque University offers an extensive curriculum of self-guided online courses for every skillset and experience level.  Start learning today   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) Deque Best Practice   How to Fix the Problem  There are two main ways to avoid using tabindex with a value greater than 0. The first method is to change the tabindex to 0. Note that this may change the order in which the user tabs through the elements. The second method is to remove the tabindex entirely and modify the structure of the page so that a user tabbing through elements reach them in the order initially desired.  A third method is to change the tabindex to tabindex=""-1"" and add Javascript. This removes the element from the tab order until you use Javascript changes the ""-1"" to a ""0"".  Adding Items to the Tab Order Using tabindex=""0"" or tabindex=""-1"" + JavaScript  Only links and form elements can receive the tab focus under normal conditions. Most of the time it is best to not add other items (such as <p>, <th>, <span>, etc.) to the tab flow, but under some exceptional circumstances — such as some kinds of complex interactive JavaScript widgets — it can make sense to add items to the tab flow that would not normally receive the tab focus. There are two ways to accomplish this: tabindex=""0"" tabindex=""-1"" + JavaScript  Methods for allowing items to receive tab focus  Method Effect tabindex=""0"" Puts the item in the normal tab flow. tabindex=""-1"" + JavaScript   Keeps the item out of the normal tab flow until a JavaScript method   allows tab focus and changes the value (i.e. by changing the   tabindex value to 0 or a positive number)    Regardless of the fix you choose, be sure that the resulting tab order follows a pattern that is logical from the user’s perspective. Remember that tab order is determined by order of elements in the DOM, as opposed to how they visual positioning. Remember that Default Tab Order = Source Code Order = The Order With Styles Turned  Off. Caution: The following CSS styles can change the order in which elements are visually positioned and can thus cause a confusing tab order: position: absolute; position: relative; float: left; float: right; Why it Matters  Using tabindex with a value greater than 0 can create as many problems as it solves. It creates an unexpected tab order, which makes the page less intuitive and can give the appearance of skipping certain elements entirely.  Here are some of the problems that tabindex (with a value of 1 or greater) causes: Unexpected tab order: From the perspective of the user,  tabindex changes the default tab order in unexpected ways,  possibly causing disorientation.  Items can appear to be skipped entirely: Items appear in  the tab order only once. If a user tabs past the tabindex items  and continues through the rest of the web page, at some point the user  arrives at the location of the tabindex items, but the tabbing  process skips over these links, because the user already tabbed through them  at the beginning of the cycle. Incorrect tab orders are frustrating when  users are unable access items, and may not know that (s)he needs to cycle  through the entire set of links on the page to reaccess those links.  All tabindex items are tabbed to before any non-tabindex  items.  If you want to change the tab order of the first items AND of a section  later in the page, you would need to set the tabindex value for  every single item through to the end of the modified section. Taken to a bit  of an extreme, if you have 20 links on a page, and if you set the  tabindex of one of those links to tabindex=""100"",  the user tabs to that link first, even though there are fewer than 100 links  on the page. There is no way to modify the tab order of sections later in  the page unless you manually set the tab order of all the links before that  section.  Rule Description  A tabindex attribute must never have a value greater than 0 to prevent an unexpected tab order that can give the appearance of skipping some elements entirely. The Algorithm (in simple terms)  Ensures that explicit tabindex attributes that are greater than 0 are never used  Resources Deque University Deque University Course Pages (subscription required) Reading Order, Focus OrderTab FocusabilityTab OrderTab/Reading OrderUsing tabindex Correctly  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. F44: Failure of Success Criterion 2.4.3 due to using tabindex to create a tab order that does not preserve meaning and operability Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/tabindex"
+25,developer.chrome.com.txt,"developer.chrome.com.txt. Reduce JavaScript execution time - Chrome DevelopersSkip to content  Home Docs Blog Articles  Home Docs Blog Articles Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsHow the Lighthouse JavaScript execution time audit failsHow to speed up JavaScript executionResourcesThanks for tuning in to Google I/O. Watch the Chrome content on-demand. Watch now. DismissDocumentation Lighthouse Performance Audits Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsHow the Lighthouse JavaScript execution time audit failsHow to speed up JavaScript executionResourcesReduce JavaScript execution timePublished on Thursday, May 2, 2019 • Updated on Friday, October 4, 2019 Translated to: Español, Português, 한국어, 中文, Pусский, 日本語MemoryTable of contents How the Lighthouse JavaScript execution time audit failsHow to speed up JavaScript executionResourcesWhen your JavaScript takes a long time to execute, it slows down your page performance in several ways:Network costMore bytes equals longer download times.Parse and compile costJavaScript gets parsed and compiled on the main thread. When the main thread is busy, the page can't respond to user input.Execution costJavaScript is also executed on the main thread. If your page runs a lot of code before it's really needed, that also delays your Time To Interactive, which is one of the key metrics related to how users perceive your page speed.Memory costIf your JavaScript holds on to a lot of references, it can potentially consume a lot of memory. Pages appear janky or slow when they consume a lot of memory. Memory leaks can cause your page to freeze up completely.# How the Lighthouse JavaScript execution time audit failsLighthouse shows a warning when JavaScript execution takes longer than 2 seconds. The audit fails when execution takes longer than 3.5 seconds:To help you identify the biggest contributors to execution time, Lighthouse reports the time spent executing, evaluating, and parsing each JavaScript file that your page loads.See the Lighthouse performance scoring post to learn how your page's overall performance score is calculated.# How to speed up JavaScript executionOnly send the code that your users need by implementing code splitting.Minify and compress your code.Remove unused code.Reduce network trips by caching your code with the PRPL pattern.For other ways to improve page load, check out the Performance audits landing page.# ResourcesSource code for Reduce JavaScript execution time auditUpdated on Friday, October 4, 2019 • Improve article Table of contentsHow the Lighthouse JavaScript execution time audit failsHow to speed up JavaScript executionResourcesFollow us Contribute File a bug View source Related content web.dev Case studies Podcasts Connect Twitter YouTube GitHub Chrome Firebase All products Privacy TermsContent available under the CC-BY-SA-4.0 licenseThis site uses cookies to deliver and enhance the quality of its services and to analyze traffic. If you agree, cookies are also used to serve advertising and to personalize the content and advertisements that you see. Learn more about our use of cookies. Agree No Thanks URL of this webpage is: https://developer.chrome.com/docs/lighthouse/performance/bootup-time/"
+26,dequeuniversity.comframe title.txt,"dequeuniversity.comframe title.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Frames must have an accessible name Rule ID: frame-title Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), Section 508     Need accessibility training?  Deque University offers an extensive curriculum of self-guided online courses for every skillset and experience level.  Start learning today   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A)Section 508 WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, ValueSection 508 Guidelines1194.22: MUST: Web based intranet and Internet Information & Applications1194.22 (i): MUST: Frames shall be titled with text that facilitates frame identification and navigation.  How to Fix the Problem  Ensure all frame and iframe elements have valid title attribute values. You can add a title attribute to a frame element as follows: <iframe ... title=""myFrame""> frame body </iframe> Additionally, best practice is to give the enclosed document a title element with content identical to the title attribute. Some screen readers will replace the contents of the title attribute on the frame with the contents of the title element inside the frame. As a result, it’s safest and most accessible to have the same text in both locations.  A good title is brief, clear, informative, and unique. Ensure that the document's title contains short, descriptive text summarizing the page's contents. To pass this rule, it’s not sufficient to simply have a title element; the element must also contain meaningful text. Best practices when writing frame titles  Replace placeholder titles such as untitled page with a more  appropriate phrase   Make each title unique - don’t duplicate titles across pages, even if they  are similar.   Put all unique information first. If you want to include the company’s name  or brand in the title, this information should go after the unique content.  Otherwise, users of screen readers will have to listen to this information  over and over as they search for the page that interests them.   Make the page title match the top heading (ideally labeled as  h1) on your page. These don’t need to be identical, but it  often makes sense to make them very similar, since the  title and h1 elements serve essentially the same  purpose.  Why it Matters  Screen reader users rely on a frame title to describe the contents of the frame. Navigating through frame and iframe elements quickly becomes difficult and confusing for users of this technology if the markup does not contain a title attribute.  Screen reader users have the option to pull up a list of titles for all frames on a page. Adding descriptive, unique titles allows users to quickly find the frame they need. If no titles are present, navigating through frames can quickly become difficult and confusing. If no title is listed, screen readers will instead give information like “frame,” “JavaScript,” the filename, or the URL. In most cases, this information won’t be very helpful. Rule Description  All frame or iframe elements in the document must have a title that is not empty to describe their contents to screen reader users. The Algorithm (in simple terms)  Ensure that all iframe and frame elements contain a unique and non-empty title attribute.  Resources Deque University Deque University Course Pages (subscription required) Frame titlesSemantic structure across iframesHiding iframes that don’t contain meaningful content  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. H64: Using the title attribute of the frame and iframe elements Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/frame-title"
+27,dequeuniversity.comaria treeitem name.txt,"dequeuniversity.comaria treeitem name.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    ARIA treeitem nodes should have an accessible name Rule ID: aria-treeitem-name Ruleset: axe-core 4.7 User Impact: Serious Guidelines: Deque Best Practice         Learn Web Accessibility   										Subscribe to our extensive curriculum of online self-paced courses 									 Learn More about Deque University   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Low Vision Mobility  Standard(s) Deque Best Practice   How to Fix the Problem Correct markup solutions  The aria-treeitem-name rule has four markup patterns that pass  test criteria: <div role=""treeitem"" id=""al"" aria-label=""Name""></div> <div role=""treeitem"" id=""alb"" aria-labelledby=""labeldiv""></div> <div role=""treeitem"" id=""combo"" aria-label=""Aria Name"">Name</div> <div role=""treeitem"" id=""title"" title=""Title""></div>   Ensure that each element with role=""treeitem"" has one of the  following characteristics:  Inner text that is discernible to screen reader users. Non-empty aria-label attribute. aria-labelledby pointing to element with text which is   discernible to screen reader users.   Incorrect markup solutions  The aria-treeitem-name rule has four markup patterns that fail  testing criteria: <div role=""treeitem"" id=""empty""></div> <div role=""treeitem"" id=""alempty"" aria-label=""""></div> <div role=""treeitem"" id=""albmissing"" aria-labelledby=""nonexistent""></div> <div role=""treeitem"" id=""albempty"" aria-labelledby=""emptydiv""></div> <div id=""emptydiv""></div> Why it Matters  Screen reader users are not able to discern the purpose of elements with role=""treeitem"" that do not have an accessible name. Rule Description  Aria treeitem elements must have discernible text that clearly describes the destination, purpose, function, or action for screen reader users. The Algorithm (in simple terms)  Checks all elements with role=""treeitem"" to ensure that they have a discernable, accessible name.  Resources Deque University Deque University Course Pages (subscription required) 						No related course information available. 					  Deque University  Contribute to axe-core on GitHub Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-treeitem-name"
+28,developer.chrome.comefficient animated conten.txt,"developer.chrome.comefficient animated conten.txt. Use video formats for animated content - Chrome DevelopersSkip to content  Home Docs Blog Articles  Home Docs Blog Articles Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsWhy you should replace animated GIFs with videoCreate MPEG videosCreate WebM videosReplace the GIF image with a videoUse a service that converts GIFs to HTML5 videosStack-specific guidanceAMPResourcesThanks for tuning in to Google I/O. Watch the Chrome content on-demand. Watch now. DismissDocumentation Lighthouse Performance Audits Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsWhy you should replace animated GIFs with videoCreate MPEG videosCreate WebM videosReplace the GIF image with a videoUse a service that converts GIFs to HTML5 videosStack-specific guidanceAMPResourcesUse video formats for animated contentPublished on Thursday, May 2, 2019 • Updated on Friday, October 4, 2019 Translated to: Español, PortuguêsTable of contents Why you should replace animated GIFs with videoCreate MPEG videosCreate WebM videosReplace the GIF image with a videoUse a service that converts GIFs to HTML5 videosStack-specific guidanceAMPResourcesThe Opportunities section of your Lighthouse report lists all animated GIFs, along with estimated savings in seconds achieved by converting these GIFs to video:See the Lighthouse performance scoring post to learn how your page's overall performance score is calculated.# Why you should replace animated GIFs with videoLarge GIFs are inefficient for delivering animated content. By converting large GIFs to videos, you can save big on users' bandwidth. Consider using MPEG4/WebM videos for animations and PNG/WebP for static images instead of GIF to save network bytes.# Create MPEG videosThere are a number of ways to convert GIFs to video. FFmpeg is the tool used in this guide. To use FFmpeg to convert the GIF, my-animation.gif to an MP4 video, run the following command in your console:ffmpeg -i my-animation.gif my-animation.mp4This tells FFmpeg to take my-animation.gif as the input, signified by the -i flag, and to convert it to a video called my-animation.mp4.# Create WebM videosWebM videos are much smaller than MP4 videos, but not all browsers support WebM, so it makes sense to generate both.To use FFmpeg to convert my-animation.gif to a WebM video, run the following command in your console:ffmpeg -i my-animation.gif -c vp9 -b:v 0 -crf 41 my-animation.webm# Replace the GIF image with a videoAnimated GIFs have three key traits that a video needs to replicate:They play automatically.They loop continuously (usually, but it is possible to prevent looping).They're silent.Luckily, you can recreate these behaviors using the <video> element.<video autoplay loop muted playsinline> <source src=""my-animation.webm"" type=""video/webm"" /> <source src=""my-animation.mp4"" type=""video/mp4"" /></video># Use a service that converts GIFs to HTML5 videosMany image CDNs support GIF to HTML5 video conversion. You upload a GIF to the image CDN, and the image CDN returns an HTML5 video.# Stack-specific guidance# AMPFor animated content, use amp-anim to minimize CPU usage when the content is offscreen.# ResourcesSource code for Use video formats for animated content auditReplace animated GIFs with video for faster page loadsReplace GIFs with video codelabUpdated on Friday, October 4, 2019 • Improve article Table of contentsWhy you should replace animated GIFs with videoCreate MPEG videosCreate WebM videosReplace the GIF image with a videoUse a service that converts GIFs to HTML5 videosStack-specific guidanceAMPResourcesFollow us Contribute File a bug View source Related content web.dev Case studies Podcasts Connect Twitter YouTube GitHub Chrome Firebase All products Privacy TermsContent available under the CC-BY-SA-4.0 licenseThis site uses cookies to deliver and enhance the quality of its services and to analyze traffic. If you agree, cookies are also used to serve advertising and to personalize the content and advertisements that you see. Learn more about our use of cookies. Agree No Thanks URL of this webpage is: https://developer.chrome.com/docs/lighthouse/performance/efficient-animated-content"
+29,dequeuniversity.comobject alt.txt,"dequeuniversity.comobject alt.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    <object> elements must have alternate text Rule ID: object-alt Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), Section 508     Accessibility testing for dev teams - No experience required  Find and fix up to 80% of accessibility issues with axe DevTools Pro. Get started with your free trial today. No credit card needed.   Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A)Section 508 WCAG Success Criteria [WCAG 2.1 (A)]1.1.1: MUST: Non-text ContentWCAG Success Criteria [WCAG 2.0 (A)]1.1.1: MUST: Non-text ContentSection 508 Guidelines1194.22: MUST: Web based intranet and Internet Information & Applications1194.22 (a): MUST: A text equivalent for every non-text element shall be provided (e.g., via ""alt"", ""longdesc"", or in element content)  How to Fix the Problem  Add alternative text to all embedded <object> elements using either aria-label, aria-labelledby, or title attributes.  The object-alt rule has six examples that pass analysis: <object data=""path/to/content"" title=""This object has text""></object> <object data=""path/to/content"" aria-label=""this object has text""></object> <span id=""label1"">this object has text</span> <object data=""path/to/content"" aria-labelledby=""label1""></object> <object data=""path/to/content"" role='presentation'></object> <object data=""path/to/content"" role='none'></object>   The object-alt rule has three examples that fail analysis: <object data=""path/to/content""></object> <object data=""path/to/content""><div> </div></object> <object data=""path/to/content"">This object has no alternative text.</object>  Why it Matters  Screen readers have no way of translating non-text content into text announced to users. Instead, they read out alternative text. For screen reader users to obtain the information contained in embedded object elements which must contain short, descriptive alternative text.  The object element defines an embedded object within a document. It is used to embed multimedia (audio, video, applets, etcetera.) or another web page into the document. The object element needs a text alternative so that users of screen readers know the contents of the object.  When writing a text alternative, keep in mind that the purpose of the alternative text is to relay information to blind users about the image’s contents and purpose - blind users should be able to get as much information from alternative text as a sighted user gets from the image. Alternative text should give the intent, purpose, and meaning of the image.  When writing alternative text, it’s helpful to keep the following questions in mind: Why is the non-text content here? What information is it presenting? What purpose does it fulfill?  If I could not use the non-text content, what words would I use to convey  the same information or function?  Be sure that all text contained in this attribute is useful. Words like “chart”, “image”, “diagram”, or image file names tend not to be very useful. Rule Description  All embedded objects must have text alternatives to be read out to screen reader users. The Algorithm (in simple terms) Ensures that every object element has a text alternative. Resources Deque University Deque University Course Pages (subscription required) Advanced Alt Text and Extended DescriptionsImage Alt TextWhat Does Accessible Mean?  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. H53: Using the body of the object element Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/object-alt"
+30,dequeuniversity.comheading order.txt,"dequeuniversity.comheading order.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Heading levels should only increase by one Rule ID: heading-order Ruleset: axe-core 4.7 User Impact: Moderate Guidelines: Deque Best Practice     Start building more accessible experiences  Axe DevTools Pro helps dev teams find and fix up to 80% of accessibility issues while coding. No experience required. Get started with your free trial today.  Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Moderate▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) Deque Best Practice   How to Fix the Problem  Ensure headings are in a logical order. For example, check that all headings are marked with h1 through h6 elements and that these are ordered hierarchically. For example, the heading level following an h1 element should be an h2 element, not an h3 element. Finally, don't use heading mark up on text that isn't actually a heading.  To ensure you are writing effective headings, read through the headings on the page and ask yourself if you get a general sense of the page’s contents based only on the information provided by the headings. If the answer is “no”, consider rewriting your headings. While you are at it, be sure that you are using the heading markup (h1 through h6's) if and only if you are writing a heading. While applying such markup is a quick way to make text stand out, using it for anything other than headings will make navigating a web page more confusing for users of assistive technology. Example If you were to create a web page about setting the exposure manually on a camera, you could simplify the steps into an outline as follows:  Setting the Exposure Manually on a Camera  Set the ISO Choose an aperture Set a shutter speed  You would need to fill in the details of each item in this list, but that's a pretty good overview of the main steps or parts of the process, so we can use these list items as the basis for our heading structure. In this example, the first item would be marked as h1 element and the remaining items would be marked as h2 elements: <h1>Setting the Exposure Manually on a Camera</h1>  <p>Put text here...</p> <h2>Set the ISO</h2>  <p>Put text here...</p> <h2>Choose an aperture</h2>  <p>Put text here...</p> <h2>Choose a shutter speed</h2>  <p>Put text here...</p> Best Practice: Start the Main Content with a h1 element: Usually, the best practice is to start the main content of a web page with a level 1 heading element (h1), with no other headings before this high-level heading. Markup the sub-sections of the page as level 2 heading elements (h2). If there are sub-sections within the level 2 sections, mark these sections as level 3 heading elements (h3) and so on. Anything that comes before the main content of the page should not be marked up with any headings at all, though this is not an iron-clad rule. One of the main reasons that the h1 element should appear at the beginning of the main content is because screen reader users can use keyboard shortcuts to navigate directly to the first h1 element, which, in principle, should allow them to jump directly to the main content of the web page. If there is no h1 element, or if the h1 element appears somewhere other than at the start of the main content, screen reader users will have to listen to additional web page content to understand the page structure, wasting valuable time.  As with all best practice recommendations, there will be exceptions in which it doesn't make sense to start the content with <h1>, or when it may be best to put other headings before the content, but the exceptions do not apply to the vast majority of web pages. Why it Matters  The underlying purpose of headers is to convey the structure of the page. For sighted users, the same purpose is achieved using different sizes of text. Text size, however, is not helpful for users of screen readers, because a screen reader identifies a header only if it is properly marked-up. When heading elements are applied correctly, the page becomes much easier to navigate for screen reader users and sighted users alike.  In the same way that sighted users can glance at a page and get a sense of its contents, users of screen readers can do the same by navigating through headings. Well written and properly ordered headings can save users, especially those who use screen readers, a lot of time and frustration.  The purpose of headings is to describe the structure of the webpage, not just highlight important text. They should be brief, clear, unique, and marked with h1 through h6 elements applied in hierarchical order. All of these qualities make headings valuable tools for screen reader users. Similar to the way sighted users can glance at a page and get a sense of its contents, screen reader users can navigate through headings. Well written and properly ordered headings can save screen reader time and frustration.  In addition to making the page more accessible, headings have other benefits since search engines use headings when filtering, ordering, and displaying results. Improving the accessibility of your site can also have the effect of making your page more findable. Rule Description  Headings must be in a valid logical order, meaning h1 through h6 element tags must appear in a sequentially-descending order. The Algorithm (in simple terms) Ensures the order of headings is semantically correct. Resources Deque University Deque University Course Pages (subscription required) Headings  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. Heading Tags Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/heading-order"
+31,dequeuniversity.combypass.txt,"dequeuniversity.combypass.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Page must have means to bypass repeated blocks Rule ID: bypass Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), Section 508     Need accessibility training?  Deque University offers an extensive curriculum of self-guided online courses for every skillset and experience level.  Start learning today   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A)Section 508 WCAG Success Criteria [WCAG 2.1 (A)]2.4.1: MUST: Bypass BlocksWCAG Success Criteria [WCAG 2.0 (A)]2.4.1: MUST: Bypass BlocksSection 508 Guidelines1194.22: MUST: Web based intranet and Internet Information & Applications1194.22 (o): MUST: A method shall be provided that permits users to skip repetitive navigation links.  How to Fix the Problem  Ensure each page has a main landmark to provide a mechanism to bypass repeated blocks of content or interface elements (like header and navigation) and quickly arrive at the main content.  Landmarks SHOULD be used to designate pre-defined parts of the layout such as the main content section. A page SHOULD NOT contain more than one instance of the main landmark. HTML5 vs. ARIA:  As a general rule, it is usually best to use native HTML elements rather  than their ARIA equivalents whenever possible. Therefore, even though the  ARIA Role role=""main"" is listed among landmarks by most screen  readers, use the the corresponding main HTML5 element instead.  Good Example: Using Appropriate Landmarks  In this example, all content is inside of a landmark, and landmarks are used  to properly identify the various types of content.  Begin code: <header> <div>This is the header.</div> </header> <nav> <div>This is the navigation.</div> </nav> <main> <div>This is the main content.</div> <section>  <div>This is a section.</div> </section> <article>  <div>This is an article.</div> </article> <aside>  <div>This is an aside.</div> </aside> </main> <footer> <div>This is the footer.</div> </footer> End code. Why it Matters  Since web sites often display secondary, repeated content on multiple pages (such as navigation links, heading graphics, and advertising frames), keyboard-only users benefit from faster, more direct access to the primary content on a page. This reduces keystrokes and minimizes associated physical pain.  For users who cannot use a mouse, navigating with a keyboard is more difficult and time-consuming when the interface does not include methods to make keyboard navigation easier. For example, to activate a link in the middle of a web page, a keyboard user may have to tab through a large number of links and buttons in the header and main navigation of the page.  At the extreme end, users with severe motor limitations might require several minutes to tab through all of those elements, and can lead to fatigue and possible physical pain for some users. Even users with less severe constraints will require longer than mouse users, who can click on the desired link in a second or two. Rule Description  Each page must have a main landmark to provide a mechanism to bypass repeated blocks of content or interface elements (like header and navigation) and quickly arrive at the main content. The Algorithm (in simple terms) Checks for least one of the following features: an internal skip link a heading a landmark region  Resources Deque University Deque University Course Pages (subscription required) LandmarksLinksNavigation Within PagesNavigation Between Pages  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. G1: Adding a link at the top of each page that goes directly to the main content areaWCAG ARIA11: Using ARIA landmarks to identify regions of a pageH69: Providing heading elements at the beginning of each section of content Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/bypass"
+32,dequeuniversity.comaria tooltip name.txt,"dequeuniversity.comaria tooltip name.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    ARIA tooltip nodes must have an accessible name Rule ID: aria-tooltip-name Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)         Learn Web Accessibility   										Subscribe to our extensive curriculum of online self-paced courses 									 Learn More about Deque University   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Low Vision Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, Value  How to Fix the Problem Correct markup solutions  The aria-tooltip-name rule has four markup patterns that pass  test criteria: <div role=""tooltip"" id=""al"" aria-label=""Name""></div> <div role=""tooltip"" id=""alb"" aria-labelledby=""labeldiv""></div> <div role=""tooltip"" id=""combo"" aria-label=""Aria Name"">Name</div> <div role=""tooltip"" id=""title"" title=""Title""></div>   Ensure that each element with role=""tooltip"" has one of the  following characteristics:  Inner text that is discernible to screen reader users. Non-empty aria-label attribute. aria-labelledby pointing to element with text which is   discernible to screen reader users.   Incorrect markup solutions  The aria-tooltip-name rule has four markup patterns that fail  testing criteria: <div role=""tooltip"" id=""empty""></div> <div role=""tooltip"" id=""alempty"" aria-label=""""></div> <div role=""tooltip"" id=""albmissing"" aria-labelledby=""nonexistent""></div> <div role=""tooltip"" id=""albempty"" aria-labelledby=""emptydiv""></div> <div id=""emptydiv""></div> Why it Matters  Screen reader users are not able to discern the purpose of elements with role=""tooltip"" that do not have an accessible name. Rule Description  Aria tooltip elements must have discernible text that clearly describes the destination, purpose, function, or action for screen reader users. The Algorithm (in simple terms)  Checks all elements with role=""tooltip"" to ensure that they have a discernable, accessible name.  Resources Deque University Deque University Course Pages (subscription required) 						No related course information available. 					  Deque University  Contribute to axe-core on GitHub Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-tooltip-name"
+33,dequeuniversity.comaria toggle field name.txt,"dequeuniversity.comaria toggle field name.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    ARIA toggle fields must have an accessible name Rule ID: aria-toggle-field-name Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)         Learn Web Accessibility   										Subscribe to our extensive curriculum of online self-paced courses 									 Learn More about Deque University   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, Value  How to Fix the Problem Correct markup solutions  The aria-toggle-field-name contains five markup patterns that  pass testing criteria: <!-- checkbox --> <div id=""pass1"" role=""checkbox"">Newspaper</div> <!-- menuitemcheckbox --> <ul role=""menu"">  <li id=""pass2""   role=""menuitemcheckbox""   aria-label=""Word wrap""   aria-checked=""true""></li> </ul> <!-- menuitemradio --> <p id=""pass3Label"">Sans-serif</p> <ul role=""menu"">  <li id=""pass3""   role=""menuitemradio""   aria-labelledby=""pass3Label""   aria-checked=""true""></li> </ul> <!-- radio --> <div role=""radiogroup"">  <div id=""pass4""   role=""radio""   aria-checked=""false""   tabindex=""0""   title=""Regular Crust""></div> </div> <!-- switch --> <div id=""pass5""  role=""switch""  aria-checked=""true""  aria-label=""Toggle blue light:"">  <span>off</span>  <span>on</span> </div> Incorrect markup solutions  The aria-toggle-field-label contains five markup patterns that  fail testing criteria: <!-- checkbox --> <div id=""fail1"" role=""checkbox"" aria-labelledby=""does-not-exist""></div> <!-- menuitemcheckbox --> <ul role=""menu""> 	<li id=""fail2"" role=""menuitemcheckbox"" aria-checked=""true""></li> </ul> #3 <!-- menuitemradio --> <ul role=""menu""> 	<li id=""fail3"" role=""menuitemradio"" aria-checked=""true""></li> </ul> #4 <!-- radio --> <div role=""radiogroup""> 	<div id=""fail4"" role=""radio"" aria-checked=""false"" tabindex=""0""></div> </div> #5 <!-- switch --> <div id=""fail5"" role=""switch"" aria-checked=""true""> 	<span></span> 	<span></span> </div>  Why it Matters  Ensures every element with a semantic role also has an accessible name. Semantic roles include: checkbox menu menuitemcheckbox menuitemradio radio radiogroup switch Rule Description Ensures every ARIA toggle field has an accessible name. The Algorithm (in simple terms) ARIA toggle fields have an accessible name. Resources Deque University Deque University Course Pages (subscription required) 						No related course information available. 					  Deque University  Contribute to axe-core on GitHub Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-toggle-field-name"
+34,web.devpublish modern javascript.txt,"web.devpublish modern javascript.txt. Publish, ship, and install modern JavaScript for faster applicationsSkip to content Open menu  About Blog Learn Explore Patterns Case studies Close Thanks for tuning in to Google I/O. Watch the Chrome content on-demand.On this page Modern JavaScriptLegacy JavaScriptModern JavaScript on npmModern-onlyModern with legacy fallbackModern with legacy fallback and ESM bundler optimizationsModern JavaScript in applicationswebpackOptimize PluginBabelEsmPluginConfigure babel-loader to transpile node_modulesRollup@rollup/plugin-babelAdditional build tools Home All articles Publish, ship, and install modern JavaScript for faster applicationsImprove performance by turning on modern JavaScript dependencies and output.Dec 10, 2020 — Updated Dec 16, 2020 Available in: English, Español, Português, Русский, 中文, and 한국어 Appears in: Fast load times Houssein Djirdeh TwitterGitHubGlitchHomepage Jason Miller TwitterGitHubHomepageOn this page Modern JavaScriptLegacy JavaScriptModern JavaScript on npmModern-onlyModern with legacy fallbackModern with legacy fallback and ESM bundler optimizationsModern JavaScript in applicationswebpackOptimize PluginBabelEsmPluginConfigure babel-loader to transpile node_modulesRollup@rollup/plugin-babelAdditional build toolsOver 90% of browsers are capable of running modern JavaScript, but the prevalence of legacy JavaScript remains a large source of performance problems on the web today.Modern JavaScript #Modern JavaScript is not characterized as code written in a specific ECMAScript specification version, but rather in syntax that is supported by all modern browsers. Modern web browsers like Chrome, Edge, Firefox, and Safari make up more than 90% of the browser market, and different browsers that rely on the same underlying rendering engines make up an additional 5%. This means that 95% of global web traffic comes from browsers that support the most widely used JavaScript language features from the past 10 years, including:Classes (ES2015)Arrow functions (ES2015)Generators (ES2015)Block scoping (ES2015)Destructuring (ES2015)Rest and spread parameters (ES2015)Object shorthand (ES2015)Async/await (ES2017)Features in newer versions of the language specification generally have less consistent support across modern browsers. For example, many ES2020 and ES2021 features are only supported in 70% of the browser market—still the majority of browsers, but not enough that it's safe to rely on those features directly. This means that although ""modern"" JavaScript is a moving target, ES2017 has the widest range of browser compatibility while including most of the commonly used modern syntax features. In other words, ES2017 is the closest to modern syntax today.Legacy JavaScript #Legacy JavaScript is code that specifically avoids using all the above language features. Most developers write their source code using modern syntax, but compile everything to legacy syntax for increased browser support. Compiling to legacy syntax does increase browser support, however the effect is often smaller than we realize. In many cases the support increases from around 95% to 98% while incurring a significant cost:Legacy JavaScript is typically around 20% larger and slower than equivalent modern code. Tooling deficiencies and misconfiguration often widen this gap even further.Installed libraries account for as much as 90% of typical production JavaScript code. Library code incurs an even higher legacy JavaScript overhead due to polyfill and helper duplication that could be avoided by publishing modern code.Modern JavaScript on npm #Recently, Node.js has standardized an ""exports"" field to define entry points for a package:{ ""exports"": ""./index.js""} Modules referenced by the ""exports"" field imply a Node version of at least 12.8, which supports ES2019. This means that any module referenced using the ""exports"" field can be written in modern JavaScript. Package consumers must assume modules with an ""exports"" field contain modern code and transpile if necessary.Modern-only #If you want to publish a package with modern code and leave it up to the consumer to handle transpiling it when they use it as a dependency—use only the ""exports"" field.{ ""name"": ""foo"", ""exports"": ""./modern.js""} CautionThis approach is not recommended. In a perfect world, every developer would have already configured their build system to transpile all dependencies (node_modules) to their required syntax. However, this is not currently the case, and publishing your package using only modern syntax would prevent its usage in applications that would be accessed through legacy browsers.Modern with legacy fallback #Use the ""exports"" field along with ""main"" in order to publish your package using modern code but also include an ES5 + CommonJS fallback for legacy browsers.{ ""name"": ""foo"", ""exports"": ""./modern.js"", ""main"": ""./legacy.cjs""} Modern with legacy fallback and ESM bundler optimizations #In addition to defining a fallback CommonJS entrypoint, the ""module"" field can be used to point to a similar legacy fallback bundle, but one that uses JavaScript module syntax (import and export).{ ""name"": ""foo"", ""exports"": ""./modern.js"", ""main"": ""./legacy.cjs"", ""module"": ""./module.js""} Many bundlers, such as webpack and Rollup, rely on this field to take advantage of module features and enable tree shaking. This is still a legacy bundle that does not contain any modern code aside from import/export syntax, so use this approach to ship modern code with a legacy fallback that is still optimized for bundling.Modern JavaScript in applications #Third-party dependencies make up the vast majority of typical production JavaScript code in web applications. While npm dependencies have historically been published as legacy ES5 syntax, this is no longer a safe assumption and risks dependency updates breaking browser support in your application.With an increasing number of npm packages moving to modern JavaScript, it's important to ensure that the build tooling is set up to handle them. There's a good chance some of the npm packages you depend on are already using modern language features. There are a number of options available to use modern code from npm without breaking your application in older browsers, but the general idea is to have the build system transpile dependencies to the same syntax target as your source code.webpack #As of webpack 5, it is now possible to configure what syntax webpack will use when generating code for bundles and modules. This doesn't transpile your code or dependencies, it only affects the ""glue"" code generated by webpack. To specify the browser support target, add a browserslist configuration to your project, or do it directly in your webpack configuration:module.exports = { target: ['web', 'es2017'],}; It is also possible to configure webpack to generate optimized bundles that omit unnecessary wrapper functions when targeting a modern ES Modules environment. This also configures webpack to load code-split bundles using &LTscript type=""module"">.module.exports = { target: ['web', 'es2017'], output: { module: true, }, experiments: { outputModule: true, },}; There are a number of webpack plugins available that make it possible to compile and ship modern JavaScript while still supporting legacy browsers, such as Optimize Plugin and BabelEsmPlugin.Optimize Plugin #Optimize Plugin is a webpack plugin that transforms final bundled code from modern to legacy JavaScript instead of each individual source file. It's a self-contained setup that allows your webpack configuration to assume everything is modern JavaScript with no special branching for multiple outputs or syntaxes.Since Optimize Plugin operates on bundles instead of individual modules, it processes your application's code and your dependencies equally. This makes it safe to use modern JavaScript dependencies from npm, because their code will be bundled and transpiled to the correct syntax. It can also be faster than traditional solutions involving two compilation steps, while still generating separate bundles for modern and legacy browsers. The two sets of bundles are designed to be loaded using the module/nomodule pattern.// webpack.config.jsconst OptimizePlugin = require('optimize-plugin');module.exports = { // ... plugins: [new OptimizePlugin()],}; Optimize Plugin can be faster and more efficient than custom webpack configurations, which typically bundle modern and legacy code separately. It also handles running Babel for you, and minifies bundles using Terser with separate optimal settings for the modern and legacy outputs. Finally, polyfills needed by the generated legacy bundles are extracted into a dedicated script so they are never duplicated or unnecessarily loaded in newer browsers. Comparison: transpiling source modules twice versus transpiling generated bundles.BabelEsmPlugin #BabelEsmPlugin is a webpack plugin that works along with @babel/preset-env to generate modern versions of existing bundles to ship less transpiled code to modern browsers. It is the most popular off-the-shelf solution for module/nomodule, used by Next.js and Preact CLI.// webpack.config.jsconst BabelEsmPlugin = require('babel-esm-plugin');module.exports = { //... module: { rules: [  // your existing babel-loader configuration:  {  test: /\.js$/,  exclude: /node_modules/,  use: {   loader: 'babel-loader',   options: {   presets: ['@babel/preset-env'],   },  },  }, ], }, plugins: [new BabelEsmPlugin()],}; BabelEsmPlugin supports a wide array of webpack configurations, because it runs two largely separate builds of your application. Compiling twice can take a little bit of extra time for large applications, however this technique allows BabelEsmPlugin to integrate seamlessly into existing webpack configurations and makes it one of the most convenient options available.Configure babel-loader to transpile node_modules #If you are using babel-loader without one of the previous two plugins, there's an important step required in order to consume modern JavaScript npm modules. Defining two separate babel-loader configurations makes it possible to automatically compile modern language features found in node_modules to ES2017, while still transpiling your own first-party code with the Babel plugins and presets defined in your project's configuration. This doesn't generate modern and legacy bundles for a module/nomodule setup, but it does make it possible to install and use npm packages that contain modern JavaScript without breaking older browsers.webpack-plugin-modern-npm uses this technique to compile npm dependencies that have an ""exports"" field in their package.json, since these may contain modern syntax:// webpack.config.jsconst ModernNpmPlugin = require('webpack-plugin-modern-npm');module.exports = { plugins: [ // auto-transpile modern stuff found in node_modules new ModernNpmPlugin(), ],}; Alternatively, you can implement the technique manually in your webpack configuration by checking for an ""exports"" field in the package.json of modules as they are resolved. Omitting caching for brevity, a custom implementation might look like this:// webpack.config.jsmodule.exports = { module: { rules: [  // Transpile for your own first-party code:  {  test: /\.js$/i,  loader: 'babel-loader',  exclude: /node_modules/,  },  // Transpile modern dependencies:  {  test: /\.js$/i,  include(file) {   let dir = file.match(/^.*[/\\]node_modules[/\\](@.*?[/\\])?.*?[/\\]/);   try {   return dir && !!require(dir[0] + 'package.json').exports;   } catch (e) {}  },  use: {   loader: 'babel-loader',   options: {   babelrc: false,   configFile: false,   presets: ['@babel/preset-env'],   },  },  }, ], },}; When using this approach, you'll need to ensure modern syntax is supported by your minifier. Both Terser and uglify-es have an option to specify {ecma: 2017} in order to preserve and in some cases generate ES2017 syntax during compression and formatting.Rollup #Rollup has built-in support for generating multiple sets of bundles as part of a single build, and generates modern code by default. As a result, Rollup can be configured to generate modern and legacy bundles with the official plugins you're likely already using.@rollup/plugin-babel #If you use Rollup, the getBabelOutputPlugin() method (provided by Rollup's official Babel plugin) transforms the code in generated bundles rather than individual source modules. Rollup has built-in support for generating multiple sets of bundles as part of a single build, each with their own plugins. You can use this to produce different bundles for modern and legacy by passing each through a different Babel output plugin configuration:// rollup.config.jsimport {getBabelOutputPlugin} from '@rollup/plugin-babel';export default { input: 'src/index.js', output: [ // modern bundles: {  format: 'es',  plugins: [  getBabelOutputPlugin({   presets: [   [    '@babel/preset-env',    {    targets: {esmodules: true},    bugfixes: true,    loose: true,    },   ],   ],  }),  ], }, // legacy (ES5) bundles: {  format: 'amd',  entryFileNames: '[name].legacy.js',  chunkFileNames: '[name]-[hash].legacy.js',  plugins: [  getBabelOutputPlugin({   presets: ['@babel/preset-env'],  }),  ], }, ],}; Additional build tools #Rollup and webpack are highly-configurable, which generally means each project must update its configuration enable modern JavaScript syntax in dependencies. There are also higher-level build tools that favor convention and defaults over configuration, like Parcel, Snowpack, Vite and WMR. Most of these tools assume npm dependencies may contain modern syntax, and will transpile them to the appropriate syntax level(s) when building for production.In addition to dedicated plugins for webpack and Rollup, modern JavaScript bundles with legacy fallbacks can be added to any project using devolution. Devolution is a standalone tool that transforms the output from a build system to produce legacy JavaScript variants, allowing bundling and transformations to assume a modern output target.PerformanceLast updated Dec 16, 2020 — Improve article CodelabsSee it in actionLearn more and put this guide into action. Serve modern code to modern browsers for faster page loads Return to all articles Share We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.Contribute File a bug View source Related content developer.chrome.com Chrome updates Case studies Podcasts Shows Connect Twitter YouTube Chrome Firebase Google Cloud Platform All products Dark theme Terms & Privacy Community Guidelines Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. By Chrome DevRel URL of this webpage is: https://web.dev/publish-modern-javascript"
+35,developer.chrome.comlighthouse largest conten.txt,"developer.chrome.comlighthouse largest conten.txt. Largest Contentful Paint - Chrome DevelopersSkip to content  Home Docs Blog Articles  Home Docs Blog Articles Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsWhat LCP measuresHow Lighthouse determines your LCP scoreHow to improve your LCP scoreResourcesThanks for tuning in to Google I/O. Watch the Chrome content on-demand. Watch now. DismissDocumentation Lighthouse Performance Audits Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsWhat LCP measuresHow Lighthouse determines your LCP scoreHow to improve your LCP scoreResourcesLargest Contentful PaintPublished on Friday, January 10, 2020 • Updated on Friday, June 4, 2021 Translated to: PусскийTable of contents What LCP measuresHow Lighthouse determines your LCP scoreHow to improve your LCP scoreResourcesLargest Contentful Paint (LCP) is one of the metrics tracked in the Performance section of the Lighthouse report. Each metric captures some aspect of page load speed.Lighthouse displays LCP in seconds:# What LCP measuresLCP measures when the largest content element in the viewport is rendered to the screen. This approximates when the main content of the page is visible to users. See Largest Contentful Paint defined for more details on how LCP is determined.# How Lighthouse determines your LCP scoreLighthouse extracts LCP data from Chrome's tracing tool.The table below shows how to interpret your LCP score:LCP time(in seconds)Color-coding0-2.5Green (fast)2.5-4Orange (moderate)Over 4Red (slow)See the Lighthouse performance scoring post to learn how your page's overall performance score is calculated.# How to improve your LCP scoreIf the LCP is an image, the timing can be broken down into four phases. Knowing which phases take the longest can help you optimize your LCP. Lighthouse will display the LCP element along with the phase breakdown in the ""Largest Contentful Paint element"" diagnostic.LCP phaseDescriptionTime to first byte (TTFB)The time from when the user initiates loading the page until when the browser receives the first byte of the HTML document response. Learn more about TTFB.Load delayThe delta between TTFB and when the browser starts loading the LCP resource.Load timeThe time it takes to load the LCP resource itself.Render delayThe delta between when the LCP resource finishes loading until the LCP element is fully rendered.# ResourcesSource code for Largest Contentful Paint auditLargest Contentful PaintLargest Contentful Paint APIUpdated on Friday, June 4, 2021 • Improve article Table of contentsWhat LCP measuresHow Lighthouse determines your LCP scoreHow to improve your LCP scoreResourcesFollow us Contribute File a bug View source Related content web.dev Case studies Podcasts Connect Twitter YouTube GitHub Chrome Firebase All products Privacy TermsContent available under the CC-BY-SA-4.0 licenseThis site uses cookies to deliver and enhance the quality of its services and to analyze traffic. If you agree, cookies are also used to serve advertising and to personalize the content and advertisements that you see. Learn more about our use of cookies. Agree No Thanks URL of this webpage is: https://developer.chrome.com/docs/lighthouse/performance/lighthouse-largest-contentful-paint"
+36,developers.google.comwhat is mixed content.txt,"developers.google.comwhat is mixed content.txt. What is mixed content?Skip to content Open menu  About Blog Learn Explore Patterns Case studies Close Thanks for tuning in to Google I/O. Watch the Chrome content on-demand.On this page The two types of mixed contentPassive mixed contentActive mixed contentThe mixed content specificationOlder browsers What is mixed content?Sep 7, 2019 — Updated Sep 24, 2020 Available in: English, Español, Português, Русский, 中文, 日本語, and 한국어 Appears in: Safe and secure Jo-el van Bergen Twitter Rachel Andrew TwitterGitHubGlitchHomepageOn this page The two types of mixed contentPassive mixed contentActive mixed contentThe mixed content specificationOlder browsersMixed content occurs when initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, scripts) are loaded over an insecure HTTP connection. This is called mixed content because both HTTP and HTTPS content are being loaded to display the same page, and the initial request was secure over HTTPS.Requesting subresources using the insecure HTTP protocol weakens the security of the entire page, as these requests are vulnerable to on-path attacks, where an attacker eavesdrops on a network connection and views or modifies the communication between two parties. Using these resources, attackers can track users and replace content on a website, and in the case of active mixed content, take complete control over the page, not just the insecure resources.Although many browsers report mixed content warnings to the user, by the time this happens, it is too late: the insecure requests have already been performed and the security of the page is compromised.This is why browsers are increasingly blocking mixed content. If you have mixed content on your site, then fixing it will ensure the content continues to load as browsers become more strict.The two types of mixed content #The two types of mixed content are: active and passive.Passive mixed content refers to content that doesn't interact with the rest of the page, and thus a man-in-the-middle attack is restricted to what they can do if they intercept or change that content. Passive mixed content is defined as images, video, and audio content.Active mixed content interacts with the page as a whole and allows an attacker to do almost anything with the page. Active mixed content includes scripts, stylesheets, iframes, and other code that the browser can download and execute.Passive mixed content #Passive mixed content is seen as less problematic yet still poses a security threat to your site and your users. For example, an attacker can intercept HTTP requests for images on your site and swap or replace these images; the attacker can swap the save and delete button images, causing your users to delete content without intending to; replace your product diagrams with lewd or pornographic content, defacing your site; or replace your product pictures with ads for a different site or product.Even if the attacker doesn't alter the content of your site, an attacker can track users via mixed content requests. The attacker can tell which pages a user visits and which products they view based on images or other resources that the browser loads.If passive mixed content is present most browsers will indicate in the URL bar that the page is not secure, even when the page itself was loaded over HTTPS. You can observe this behavior with this demo that contains examples of passive mixed content.Until recently passive mixed content was loaded in all browsers, as to block it would have broken many websites. This is now beginning to change and so it is vital to update any instances of mixed content on your site.Chrome is currently rolling out automatic upgrading of passive mixed content where possible. Automatic upgrading means that if the asset is available over HTTPS, but has been hardcoded as HTTP, the browser will load the HTTPS version. If no secure version can be found the asset will not load.Whenever it detects mixed content or auto-upgrades passive mixed content, Chrome logs detailed messages to the Issues tab in DevTools to guide you on how to fix the specific issue.Active mixed content #Active mixed content poses a greater threat than passive mixed content. An attacker can intercept and rewrite active content, thereby taking full control of your page or even your entire website. This allows the attacker to change anything about the page, including displaying entirely different content, stealing user passwords or other login credentials, stealing user session cookies, or redirecting the user to a different site entirely.Due to the severity of this threat, most browsers already block this type of content by default to protect users, but functionality varies between browser vendors and versions.This other demo contains examples of active mixed content. Load the example over HTTP to see the content that's blocked when you load the example over HTTPS. Blocked content will also be detailed in the Issues tab.Browsers also highlight blocked content in their DevTools. Blocked content issues are detailed in the Issues tab in Chromium-based browsers. Firefox and Safari log messages in the console.The mixed content specification #Browsers follow the mixed content specification, which defines the optionally blockable content and blockable content categories.From the spec, a resource qualifies as optionally blockable content ""when the risk of allowing its usage as mixed content is outweighed by the risk of breaking significant portions of the web""; this is a subset of the passive mixed content category described above.All content that is not optionally blockable is considered blockable, and should be blocked by the browser.There is a Level 2 of the Mixed Content specification in progress, which will add automatic upgrading to the spec.In recent years, HTTPS usage has risen dramatically, and has become the clear default on the web. This makes it more feasible now for browsers to consider blocking all mixed content, even those subresource types defined in the mixed content specification as optionally blockable. This is why we now see Chrome taking a stricter approach to these subresources.Older browsers #It is important to remember that not every visitor to your website uses the most up-to-date browsers. Different versions from different browser vendors each treat mixed content differently. At worst, older browsers and versions don't block any mixed content at all, which is very unsafe for the user.By fixing your mixed content problems you ensure that your content is visible in new browsers. You also help protect users from dangerous content that isn't blocked by older browsers.SecurityNetworkPrivacyHTMLCSSJavaScriptImagesMediaLast updated Sep 24, 2020 — Improve article Return to all articles Share We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.Contribute File a bug View source Related content developer.chrome.com Chrome updates Case studies Podcasts Shows Connect Twitter YouTube Chrome Firebase Google Cloud Platform All products Dark theme Terms & Privacy Community Guidelines Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. By Chrome DevRel URL of this webpage is: https://developers.google.com/web/fundamentals/security/prevent-mixed-content/what-is-mixed-content"
+37,dequeuniversity.comform field multiple label.txt,"dequeuniversity.comform field multiple label.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English��本語  Set Language    Form field must not have multiple label elements Rule ID: form-field-multiple-labels Ruleset: axe-core 4.7 User Impact: Moderate Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)         Learn Web Accessibility   										Subscribe to our extensive curriculum of online self-paced courses 									 Learn More about Deque University   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Moderate▼  Minor Critical  Disabilities Affected Blind Low Vision Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]3.3.2: MUST: Labels or InstructionsWCAG Success Criteria [WCAG 2.0 (A)]3.3.2: MUST: Labels or Instructions  How to Fix the Problem Ensure that only one label is assigned to a form field. Correct markup solutions  The form-field-multiple-labels rule contains five markup  patterns that pass analysis: <label for=""pass1"">Label</label> <input type=""text"" id=""pass1"" /> <textarea id=""pass2"" title=""Label""></textarea> <label>First Name: <input type=""text"" id=""pass3"" /></label> <label>Choose an option:  <select id=""pass4"">   <option selected=""selected"">Chosen</option>   <option>Not Selected</option>  </select> </label> <label>Enter your comments:  <textarea id=""pass5""></textarea> </label>   Caution: Screen Reader and Browser Combinations Inconsistently Support  Multiple form Element Labels   The following markup examples work across the following screen reader and  browser combinations documented here as of the axe-core 3.4.0 release. See  Multiple Labels on a Single Input  for further information on screen reader and browser testing combinations. <input type=""checkbox"" id=""D"" aria-labelledby=""E""/>  <label for=""D"" aria-hidden=""true"">Please</label>  <label for=""D"" id=""E"">Excuse</label> <input type=""checkbox"" id=""F"" aria-labelledby=""G H""/>  <label for=""F"" id=""G"" aria-hidden=""true"">Please</label>  <label for=""F"" id=""H"">Excuse</label> <input type=""checkbox"" id=""I""/>  <label for=""I"" style=""display:none"">Please</label>  <label for=""I"">Excuse</label>  Confirm the existence of one visible label per form element. to achieve  correct functionality across most screen reader and browser combinations.  Using the aria-hidden attribute alone is not sufficient and you  need to hide additional labels using CSS.  Incorrect markup examples  The form-field-multiple-labels rule contains nine markup  patterns that fail analysis: <label for=""fail1"">Hi</label> <label for=""fail1"">Foo</label> <input type=""text"" id=""fail1"" /> <label for=""fail2"">label one</label> <label for=""fail2"">label two</label> <input type=""checkbox"" id=""fail2"" /> <label for=""fail3"" id=""l1"">label one</label> <label for=""fail3"">label two</label> <input type=""checkbox"" id=""fail3"" aria-labelledby=""l1"" /> <label for=""fail4"">First Name:</label> <label>First Name:  <input type=""text"" id=""fail4"" /> </label> <label for=""fail5"">Choose an option:</label> <label>Choose an option:  <select id=""fail5"">   <option selected=""selected"">Chosen</option>   <option>Not Selected</option>  </select> </label> <label for=""fail6"">Enter your comments:</label> <label>Enter your comments:  <textarea id=""fail6""></textarea> </label> <label>Enter your comments:  <label>Enter your comments:   <textarea id=""fail7""></textarea>  </label> </label> <label>Enter your comments:  <label>Enter your comments:   <label>Enter your comments:    <textarea id=""fail8""></textarea>   </label>  </label> </label> <label for=""fail9"">Enter your comments:</label> <label>Enter your comments:  <label>Enter your comments:   <label>Enter your comments:    <textarea id=""fail9""></textarea>   </label>  </label> </label>  Why it Matters  Assigning multiple labels to the same form field can cause problems for some combinations of screen readers and browsers, and the results are inconsistent from one combination to the next. Some combinations will read the first label. Some will read the last label. Others will read both labels. Rule Description Ensures form field does not have multiple labels. The Algorithm (in simple terms) Ensures form field does not have multiple labels. Resources Deque University Deque University Course Pages (subscription required) SC 3.3.2 — Labels or Instructions3.3.2.a — Visible LabelsLabelsGroup LabelsInstructions and Other Helpful InfoDynamic Forms and Custom WidgetsName  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. 3.3.2 Labels or Instructions Level AUnderstanding Success Criterion 3.3.2: Labels or InstructionsF68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined nameH44: Using label elements to associate text labels with form controlsARIA16: Using aria-labelledby to provide a name for user interface controlsARIA14: Using aria-label to provide an invisible label where a visible label cannot be usedH65: Using the title attribute to identify form controls when the label element cannot be used Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/form-field-multiple-labels"
+38,www.w3.orgqa choosing language tags.txt,"www.w3.orgqa choosing language tags.txt.  Choosing a language tag    Choosing a Language Tag Related Links IANA Language Subtag Registry Subtag search tool BCP 47  Question Which language tag is right for me? How do I choose language and other subtags? In HTML and XML documents a language tag is used to indicate the language of content. A language tag is composed of one or more subtags separated by hyphens. Subtags can be of various types. BCP stands for 'Best Current  Practice', and is a persistent name for a series of RFCs whose numbers change as they are updated. The  latest RFC describing language tag syntax is RFC 5646, Tags for the Identification of  Languages, and it obsoletes the older RFCs 4646 3066 and 1766. Language tag syntax is defined by the IETF's BCP 47. In the past it was necessary to consult lists of codes in various ISO standards to find the right subtags, but  now you only need to look in the IANA Language Subtag Registry. We will describe the new registry below. This article provides advice on how to choose the components of a language tag. For an overview of the concepts defined in BCP 47, see Language tags in HTML and XML. Answer The notes on this page provide guidance that is sufficient for most people wanting to use language tags. There are links to relevant sections of BCP 47 in this margin for people who want to read the full text of the specification. Accessing the subtag registry All the subtags you will need to create a language tag are found in one place, the IANA Language Subtag Registry. The registry is a long text file, containing nearly 8,000 entries. The first (and often only) subtag in a language tag always designates a language. It is referred to in BCP 47 as the primary language subtag. We will use that term in this document to refer to the subtag that represents a language, to more clearly make the distinction from 'language tag', which refers to the whole thing. To find a primary-language subtag, search the page for the name of that language. For example, if you want to label something as French, searching  for 'French' in the registry will bring you to a record that looks like this: Some environments or systems may dictate choices that are different from what you would otherwise expect. For example, in Java you must use iw (deprecated in BCP47) in place of he (recommended in BCP47). %% Type: language Subtag: fr Description: French Added: 2005-10-16 Suppress-Script: Latn %% Your search will have matched against the Description field. Check that the type of this record is language. What you are looking for is the value in the Subtag field, ie. fr. The rest of this article will provide advice for choosing primary language subtags and, where needed, other types of subtag. Note that not all the decisions about how to create a language tag are straightforward. There are circumstances where usage will dictate which of various possibilities you should follow. There are tools available which provide additional help while searching the registry, such as the Language Subtag Lookup tool. Think about letter-case.   By convention, primary language subtags are lowercase, script subtags begin with an uppercase letter, and continue with lowercase, and region subtags are uppercase. This is only a convention, however, and you are free to use whatever letter-casing you like. On the other hand, you may be using language tags in a context where letter-case is important, such as file names on some systems. In such cases, you should ensure that you follow a consistent policy for letter-case; for any new system that is not case-insensitive, it is recommended that you follow the BCP 47 conventions.  Decision 1: The primary language subtag You always start by choosing a primary language subtag, and often this is all you'll need for your language tag. Read more in the BCP 47 spec: 2.2.1 Primary Language Subtag 4.1 Choice of Language Tag Always bear in mind that the golden rule is to keep your language tag as short as possible. Only add further subtags to your language tag if they are needed to distinguish the language from something else in the context where your content is used. When looking for a primary language subtag, there are a number of things to bear in mind. Ensure you have the right language.   Sometimes, it pays to check a few alternatives. Mark Davis, co-author of BCP47, writes ""Often it is not clear which language identifier to use. For example, what most people call Punjabi in Pakistan actually has the code 'lah', and formal name 'Lahnda'. There are many other cases where the same name is used for different languages, or where the name that people search for is not listed in the IANA registry.""   You could look up language information in the SIL Ethnologue and cross-reference that information with Wikipedia. The Ethnologue uses the same three-letter codes as BCP47, but you'll need to convert BCP47 2-letter codes to their ISO 639-3 counterpart to look up a language by code. (The Language Subtag Lookup tool does this for you.) There are a small number of cases where different language codes are available for what many people would regard as the same language, eg. Filipino and Tagalog, or Twi and Akan. There is no indication in the registry as to which you should use, but you should try to ensure that within a single application or context you are consistent. Avoid collections.   If the record you found has a field Scope: collection, this subtag represents a group of languages that are descended from a common ancestor, are spoken in the same geographical area, or are otherwise related.   You should look for a more specific subtag for the language you are interested in. Unfortunately, the subtag registry doesn't provide any pointers for this. You can use these subtags if there is no more specific subtag available, and it is always preferable to use one of these rather than the subtags MUL (multiple languages) or UND (undefined). Use macrolanguages with care.   Some language subtags have a Scope field set to macrolanguage, ie. this primary language subtag encompasses a number of more specific primary language subtags in the registry.   For example, ku (Kurdish) is a macrolanguage that encompasses ckb (Central Kurdish), kmr (Northern Kurdish), and sdh (Southern Kurdish). You can find the more specific (ie. the encompassed) subtags by searching the registry for Macrolanguage: <subtag_name>. Alternatively, the Language Subtag Lookup tool will automatically list these for a given macrolanguage (example). As we recommended for the collection subtags mentioned above, in most cases you should try to use the more specific subtags, but there are a small number of important exceptions. These are situations where you should continue using a macrolanguage subtag for reasons of backward compatibility. For example, although BCP 47 explains that zh (the macrolanguage subtag for Chinese) doesn't actually specify which of the many, sometimes mutually unintelligible, dialects of Chinese is actually meant by this subtag, in practice convention overwhelmingly associates the macrolanguage subtag with the predominant language among the encompassed subtags - in this case, cmn (Mandarin Chinese). If your application identified Mandarin Chinese in the past using the language tag zh-CN (Chinese as used in Mainland China), or even just zh, you can continue to use zh in this way. Using cmn or cmn-CN may cause serious compatibility problems if the software or users expect a tag such as zh. If, on the other hand, you are using zh to refer to another Chinese dialect such as Hakka, you should use the language subtag hak instead. Avoid deprecated subtags.   If the subtag record contains a Deprecated field you shouldn't use this subtag. Usually the registry will indicate which alternative you should use in the Preferred-Value field. For example, the subtag record for iw (Hebrew) contains the two following fields:   Deprecated: 1989-01-01 Preferred-Value: he This indicates that you should use the subtag he for Hebrew instead. In the past, when dealing with lists of ISO codes, there were sometimes multiple codes for a given language - there could be a 2-letter code and one or two 3-letter codes. This ambiguity is resolved by the IANA Subtag Registry: only one code is listed per language. (If an ISO 2-letter code exists, that will be the code, otherwise it will be a three-letter code.) The registry maintainer also coordinates the ongoing evolution of the registry with developments in the ISO world. Decision 2: Extended language subtags The BCP 47 specification allows for an additional, 3-letter subtag immediately after the initial primary language subtag. This is called an extended language subtag (abbreviated to extlang). Only a relatively small number of extended language subtags are defined, and they each need to be used with a specific primary language subtag (given in the Prefix field of the entry for the extended language subtag in the registry). Read more in the BCP 47 spec: 2.2.2 Extended Language Subtags 4.1.2 Using Extended Language Subtags 4.1.1 Tagging Encompassed Languages Currently only seven primary language subtags can be used with extended language subtags. Six of those have a Scope field set to macrolanguage in the registry (ar, kok, ms, sw, uz, and zh), and the other is sgn. Consider the following: Where possible, use a single language subtag, rather than the language+extlang pair.   There is always a 3-letter subtag that is equivalent to any language+extlang pairing, and it is always the same as the extlang subtag. For example, zh-yue (Cantonese Chinese) can also be expressed with the single subtag yue. The only significant exception is where the language+extlang sequence is established practice for the system you are working with; that is, where zh-yue would be preferred rather than yue to maintain backwards compatibility. Take into account legacy usage for predominant languages.   In the section about primary language subtags we talked about the predominant language in the set of languages encompassed by a macrolanguage. We said that, to support legacy usage for a given application, it is generally better to use the macrolanguage subtag for the predominant language, rather than the more specific subtag. For example, in such cases ar (the Arabic macrolanguage subtag) may be more appropriate for Standard Arabic than arb (the more specific, encompassed subtag that means Standard Arabic).   Similarly, when dealing with the predominant language in the set, it is generally better for backwards compatibility if you replace the language+extlang sequence by just dropping the extlang, rather than using the extlang code as a primary language subtag. For example, reducing ms-zsm to ms (Malay macrolanguage subtag) may sometimes be better than replacing it with zsm (Standard Malay). As an example of usage, Unicode's CLDR database uses macrolanguages zh to represent Mandarin Chinese and ku to represent Kurdish. Thus for Mandarin Chinese you would use zh, not cmn, and for Northern Kurdish you would use ku-Latn, not kmr-Latn. The CLDR database, however, does not use extended language subtags, so you would need to use yue for Cantonese, not zh-yue. Decision 3: Script subtags Script subtags should only be used as part of a language tag when the script adds some useful distinguishing information to the tag. Usually this is because a language is written in more than one script or because the content has been transcribed into a script that is unusual to the language (so one might tag Russian transcribed into the Latin script with a tag such as ru-Latn). Read more in the BCP 47 spec: 2.2.3 Script Subtag 4.1 Choice of Language Tag Script subtags are always 4 letters, and must come after any language or extended language subtag, but before any other subtags. Here are things to look out for when choosing a script subtag. Don't automatically use for non-written content.   Content such as audio recordings should not need one of the usual script subtags.	For	example,	a	movie that is subtitled in Uzbek using the Arabic (rather than Latin) script might label the subtitles uz-Arab, but the Arab script subtag would not be relevant for an audio track.   The script subtag Zxxx could be used for non-written content, eg. uz-Zxxx, as Zxxx is the Code for unwritten documents, but again this is only useful if such a distinction has to be made clear. Check for suppress-script fields in the language subtag.   Some language subtags have a Suppress-script field set to a given script subtag. For example, the entry in the registry for en (English) contains:   Suppress-Script: Latn meaning that you should not use the Latn (Latin) script subtag with this language. This is because nearly all English documents are written in the Latin script and it adds no distinguishing information. However, if a document were written in English mixing Latin script with another script such as Braille (Brai), then it might be appropriate to indicate both scripts to aid in content selection (eg. for the application of style rules). Note, however, that not all language subtags that are strongly associated with a given script have suppress-script fields. You should not assume that you need to use a script if a suppress-script field is absent.  Decision 4: Region subtags Region subtags associate the language subtag you have chosen with a particular region of the world. Region subtags must come after any language or script subtags. Like script subtags, you should only use a region subtag if it contributes information needed in a particular context to distinguish this language tag from another one; otherwise leave it out. Read more in the BCP 47 spec: 2.2.4 Region Subtag 4.1 Choice of Language Tag For example, en-GB might be a useful distinction for spell-checking, but the region subtag in ja-JP is unlikely to be useful unless you are intentionally contrasting it with Japanese spoken in other parts of the world. There are two types of region subtag: 2-letter codes and 3-digit codes. The latter tend to identify multinational regions, rather than specific countries. For example, es-ES means Spanish as spoken in Spain, whereas es-419 means Spanish as spoken in Latin America. Avoid deprecated subtags.   Check that the subtag you intend to use isn't deprecated. In the same way as for other types of subtag, the registry will normally tell what the replacement should be via the Preferred-Value field. In some cases there is no Preferred-Value field in a deprecated record, but sometimes the Comments field contains advice. For example, under YU (Yugoslavia) you will find: Deprecated: 2003-07-23 Comments: see BA, HR, ME, MK, RS, or SI  Decision 5: Variant subtags Again, only use variant subtags when there is a need to distinguish this language tag from another similar one in the context in which your content is used. Read more in the BCP 47 spec: 2.2.5 Variant Subtags 4.1 Choice of Language Tag Variant subtags describe additional distinctions not captured by the other subtags. Typically these are dialects, written variations (such as spelling reforms), transcriptions, and the like. A variant subtag is usually five to eight characters long and can contain letters and/or digits. A few four digit subtags (usually representing a year) are also registered. Variant subtags must come after any language, script, and region subtags. The key thing to look out for when using variant subtags is the order in which they are used. Check the context and ordering for variant subtags.   Most variant subtag records in the registry have one or more Prefix fields. The prefixes indicate with which subtags it is usually appropriate to use this variant. For example, pinyin should generally be used in a language tag that also contains either the subtags zh and Latn or the subtags bo and Latn, since the entry for pinyin contains the following: Prefix: zh-Latn Prefix: bo-Latn If you have a good reason, you could use a variant subtag with different subtags, eg. cmn-Latn-pinyin would be a perfectly legal way to say Mandarin Chinese written with pinyin. Although zh, bo and Latn are specified, this is a minimum requirement. It is also possible to include other subtags, such as a region subtag, in the language tag (where appropriate), eg. zh-Latn-CN-pinyin. Amongst other prefix fields, the entry for variant subtag 1994 contains Prefix: sl-rozaj-biske which indicates that it should be used in a language tag that already contains two other variant subtags, rozaj and biske. Any variant subtag specified in a prefix field should come before the variant you have just looked up. There are some variant subtags that have no prefix field, eg. fonipa (International Phonetic Alphabet). Such variants should appear after any other variant subtags with prefix information. If you plan to use more than one variant without a prefix, order them in terms of decreasing significance. If they are equally significant, order them alphabetically. This will aid interoperability.  Decision 6: Extension subtags Read more in the BCP 47 spec: 2.2.6 Extension Subtags 4.1 Choice of Language Tag These single-character subtags allow for extensions to the language tag. To date, only one extension subtag has been registered. The subtag u was registered by the Unicode Consortium to add information about language or locale behavior. Many locale identifiers require additional ""tailorings"" or options for specific values within a language, culture, region, or other variation. This extension provides a mechanism for using these additional tailorings within language tags for general interchange. For example, the following indicates that phonebook collation order should be used by an application, that sorted data in a document is sorted according to this collation, and so on. de-DE-u-co-phonebk The u- extension is defined in RFC 6067, which points to the Unicode Consortium's Common Locale Data Repository (CLDR) for details on the subtags that follow it. It is not defined by BCP 47. Decision 7: Private Use subtags Read more in the BCP 47 spec: 2.2.7 Private Use Subtags 4.1 Choice of Language Tag Private-use subtags do not appear in the subtag registry, and are chosen and maintained by private agreement between the parties that use them. They are introduced by a single letter subtag, or 'singleton'. The singleton for private use is x. Note that any subtags after the singleton can only be 8 characters in length, though you can use multiple subtags. Private use subtags should be used with great care, and avoided whenever possible   , since they interfere with the interoperability that BCP 47 exists to promote. As an example of a private use subtag, en-US-x-twain, may identify a specific type of US English, but only within a closed community. Outside of that private agreement, its meaning cannot be relied upon.  Grandfathered tags Read more in the BCP 47 spec: 4.1 Choice of Language Tag Grandfathered tags are special cases, provided for backwards compatibility. They are tags that were registered before RFC 4646 that cannot be completely composed from the subtags in the current registry, or do not fit the syntax currently defined for language tags. Nearly all grandfathered tags have been superceded by subtags or combinations of subtags in the registry. Such grandfathered tags are now deprecated, and usually contain a Preferred-Value field that indicates how you ought to represent that language instead. For instance, the entry in the registry for the grandfathered tag art-lojban indicates that you should use the jbo language subtag instead. Note that you should not use additional subtags with a grandfathered tag. Further reading  Getting started? Language on the Web Related links, Authoring HTML & CSS Language Choosing language tags Related links, Authoring XML Language Choosing language tags Related links, Authoring SVG Language Choosing language tags   URL of this webpage is: https://www.w3.org/International/questions/qa-choosing-language-tags#questio"
+39,dequeuniversity.comaccesskeys.txt,"dequeuniversity.comaccesskeys.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    accesskey attribute value should be unique Rule ID: accesskeys Ruleset: axe-core 4.7 User Impact: Serious Guidelines: Deque Best Practice     Start building more accessible experiences  Axe DevTools Pro helps dev teams find and fix up to 80% of accessibility issues while coding. No experience required. Get started with your free trial today.  Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Low Vision Mobility  Standard(s) Deque Best Practice   How to Fix the Problem Ensure all accesskey values in the document are unique. Look for and change duplicate accesskey values. Consider the following code: <a href=""google.com"" accesskey=""g"">Link to Google</a> <a href=""github.com"" accesskey=""g"">Link to GitHub</a> change the value of one of the accesskey attributes to remove the duplicated value. An improved version of the above code looks like this: <a href=""google.com"" accesskey=""g"">Link to Google</a> <a href=""github.com"" accesskey=""h"">Link to GitHub</a>  Although the “providing access keys” option exists, we do not  recommend including accesskey attribute values due to  limitations:  Access keys are not supported by every browser. Access keys are not always obvious to the user.  Access keys defined by the developer may conflict with default browser  access keys.    Using a letter from a label element as access key may cause problems when  rendering content in multiple languages   Why it Matters  Specifying a accesskey attribute value for some part of a document allows users to quickly activate or move the focus to a specific element by pressing the specified key (usually in combination with the alt key). Duplicating accesskey values creates unexpected effects that ultimately make the page less accessible.  For each defined accesskey, ensure the value is unique and does not conflict with any default browser and screen reader shortcut keys.  Content is not operable by keyboard users with no or low vision who cannot use devices such as mice that require eye-hand coordination, users who have trouble tracking a pointer, or users who must use alternate keyboards or input devices acting as keyboard emulators. Rule Description  All accesskey attribute values in a document must be unique. Put another way, accesskeys must not be repeated to prevent unexpected effects for keyboard users. The Algorithm (in simple terms)  Ensures that each element on the page with an accesskey attribute has a unique value.  Resources Deque University Deque University Course Pages (subscription required) 						No related course information available. 					  Deque University  Contribute to axe-core on GitHub Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/accesskeys"
+40,dequeuniversity.cominput image alt.txt,"dequeuniversity.cominput image alt.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Image buttons must have alternate text Rule ID: input-image-alt Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), Section 508     Need accessibility training?  Deque University offers an extensive curriculum of self-guided online courses for every skillset and experience level.  Start learning today   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A)Section 508 WCAG Success Criteria [WCAG 2.1 (A)]1.1.1: MUST: Non-text Content4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]1.1.1: MUST: Non-text Content4.1.2: MUST: Name, Role, ValueSection 508 Guidelines1194.22: MUST: Web based intranet and Internet Information & Applications1194.22 (a): MUST: A text equivalent for every non-text element shall be provided (e.g., via ""alt"", ""longdesc"", or in element content)  How to Fix the Problem  Check that the <input type=""image""> has a non-empty alt, aria-label or aria-labelledby attribute.  Image buttons use the alt attribute as the label. The alt attribute value must be provided, and it must be clear and concise and representative of the action performed when the button is activated by the user (not a description of the image itself). Image Button Example <input type=""image"" src=""submit.png"" name=""submit"" height=""36"" width=""113"" alt=""Submit"">  Check that all images used as buttons have accessible alternate text. How to add alt text to an image  Using an alt attribute i.e.  <input type=""image"" alt=""submit button"">  Using an aria-label i.e.  <input type=""image"" aria-label=""submit button"">  Using an aria-labelledby attribute i.e.  <input type=""image"" aria-labelledby=""someElementID"">  If you are using an alt attribute or an aria-label, ensure it is not empty. If you are using an aria-labelledby attribute, ensure that the ID to which it points exists and is accessible to a screen reader (i.e. is not hidden using CSS with display: none or aria-hidden=""true""). Tips on writing alt text When writing the alt text, keep in mind that the purpose of the alt text is to relay information to blind users about the image’s contents and purpose - blind users should be able to get as much information from alt text as a sighted user gets from the image itself. alt text should give the intent, purpose, and meaning of the image.  When writing alt text, it is helpful to keep the following questions in mind: Why is the non-text content here? What information is it presenting? What purpose does it fulfill?  If I could not use the non-text content, what words would I use to convey  the same information or function?  Be sure that all text contained in the alt attribute is useful. Words like ""chart,"" ""image,"" ""diagram,"" or image file names tend not to be very useful and thus should not be used in alt text. Why it Matters  An <input type=""image""> button must have alternate text, otherwise screen reader users will not know the button's purpose. Even if the image contains only text, it still requires alternate text, since a screen reader cannot translate images of words into output. Text Alone Is Not A Label: Just typing text next to the form element is not sufficient to create a true label. Assistive technologies like screen readers require labels in code that can be determined programmatically. Some screen readers are programmed to guess what the label should be, based on the surrounding text, but this method is not fool-proof and can lead to confusion if the screen reader guesses wrong. Rule Description  Ensures <input type=""image""> elements have alternate text. The Algorithm (in simple terms)  Ensures that every <input type=""image""> has an accessible name.  Resources Deque University Deque University Course Pages (subscription required) Advanced Alt Text and Extended DescriptionsImage Alt TextLabelsGroup Labels  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. F65: Failure of Success Criterion 1.1.1 due to omitting the alt attribute or text alternative on img elements, area elements, and input elements of type ""image""H36: Using alt attributes on images used as submit buttons Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/input-image-alt"
+41,dequeuniversity.comaria required parent.txt,"dequeuniversity.comaria required parent.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Certain ARIA roles must be contained by particular parents Rule ID: aria-required-parent Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Start building more accessible experiences  Axe DevTools Pro helps dev teams find and fix up to 80% of accessibility issues while coding. No experience required. Get started with your free trial today.  Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]1.3.1: MUST: Info and RelationshipsWCAG Success Criteria [WCAG 2.0 (A)]1.3.1: MUST: Info and Relationships  How to Fix the Problem  Ensure all ARIA roles are contained by their required parent element, if any.  The relationship properties available in ARIA are the following: aria-activedescendant  aria-controls (used primarily by elements where the role is group, region,  or widget) aria-describedby  aria-flowto (used primarily to provide alternate reading/tab order to skip  past ads or complementary regions) aria-labelledby  aria-owns (used primarily to identify which elements belong to the group) aria-posinset aria-setsize  ARIA allows you to communicate relationship information to screen readers, which specifies relationships between items (for example, aria-owns, aria-controls, both of which describe a kind of parent-child relationship where one item owns or controls another). Why it Matters  For each role, WAI-ARIA explicitly defines which child and parent roles are allowable and/or required. Elements containing ARIA role values missing required parent element role values will not enable assistive technology to function as intended by the developer.  When it is necessary to convey context to the user of assistive technology in the form of hierarchy (for example, the importance of a parent container, item or sibling in a folder tree), and the hierarchy is not the same as the code structure or DOM tree, there is no way to provide the relationship information without the use of ARIA role parent elements. Rule Description  Certain ARIA roles must be contained by particular parent roles in order to perform the intended accessibility functions. The Algorithm (in simple terms)  Checks all elements that contain a WAI-ARIA role to ensure that all required parent roles are present  Resources Deque University Deque University Course Pages (subscription required) ARIA ConceptsRoleARIA Widget Examples  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. WAI-ARIA Roles Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-required-parent"
+42,dequeuniversity.comaria progressbar name.txt,"dequeuniversity.comaria progressbar name.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    ARIA progressbar nodes must have an accessible name Rule ID: aria-progressbar-name Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Start building more accessible experiences  Axe DevTools Pro helps dev teams find and fix up to 80% of accessibility issues while coding. No experience required. Get started with your free trial today.  Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Low Vision Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]1.1.1: MUST: Non-text ContentWCAG Success Criteria [WCAG 2.0 (A)]1.1.1: MUST: Non-text Content  How to Fix the Problem Correct markup solutions  The aria-progressbar-name rule has three markup patterns that  pass test criteria: <div role=""progressbar"" id=""alb"" aria-labelledby=""labeldiv""></div> <div role=""progressbar"" id=""combo"" aria-label=""Aria Name"">Name</div> <div role=""progressbar"" id=""title"" title=""Title""></div>   Ensure that each element with role=""progressbar"" has one of  the following characteristics:  Non-empty aria-label attribute. aria-labelledby pointing to element with text which is   discernible to screen reader users.   Incorrect markup solutions  The aria-progressbar-name rule has four markup patterns that  fail testing criteria: <div role=""progressbar"" id=""empty""></div> <div role=""progressbar"" id=""alempty"" aria-label=""""></div> <div role=""progressbar"" id=""albmissing"" aria-labelledby=""nonexistent""></div> <div role=""progressbar"" id=""albempty"" aria-labelledby=""emptydiv""></div> <div id=""emptydiv""></div> Why it Matters  Screen reader users are not able to discern the purpose of elements with role=""progressbar"" that do not have an accessible name. Rule Description  Aria progressbar elements must have discernible text that clearly describes the destination, purpose, function, or action for screen reader users. The Algorithm (in simple terms)  Checks all elements with role=""progressbar"" to ensure that they have a discernable, accessible name.  Resources Deque University Deque University Course Pages (subscription required) 						No related course information available. 					  Deque University  Contribute to axe-core on GitHub Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-progressbar-name"
+43,dequeuniversity.comhtml has lang.txt,"dequeuniversity.comhtml has lang.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    <html> element must have a lang attribute Rule ID: html-has-lang Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Start building more accessible experiences  Axe DevTools Pro helps dev teams find and fix up to 80% of accessibility issues while coding. No experience required. Get started with your free trial today.  Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind Cognitive  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]3.1.1: MUST: Language of PageWCAG Success Criteria [WCAG 2.0 (A)]3.1.1: MUST: Language of Page  How to Fix the Problem  Add a lang attribute to the html element (e.g. <html lang=""en"">) whose value represents the primary language of document.  Make sure you identify a language in the opening <html> element and spell the attribute correctly. For example, if the primary language of a document is English, you could specify the language as follows: <html lang=""en""> <!--document head and body--> </html>   If you would like, you can even specify some dialects with codes such as ""en-US"" to signify American English or ""fr-CA"" for Canadian French. You can find a list of language and dialect codes on the internet.  If the language changes within a document, you can specify this as follows: <p>Text in one language <span lang=""es"">text in another language</span></p> If you are using a language that is written right to left, be sure to specify this using the dir attribute: <p lang=""ar"" dir=""rtl"">Arabic text here</p> If you would like to specify that a language is written left to right, you can fill the value of the dir attribute with the value ""ltr"". Why it Matters  When configuring a screen reader, users select a default language. If the language of a webpage is not specified, the screen reader assumes the default language set by the user. Language settings become an issue for users who speak multiple languages and access website in more than one language. It is essential to specify a language and ensure that it is valid so website text is pronounced correctly.  Screen readers use different sound libraries for each language, based on the pronunciation and characteristics of that language. Screen readers can switch between these language libraries easily, but only if the documents specify which language(s) to read and when. If the language is not specified, the screen reader reads the document in the user's default language, resulting in a strange accent! It is impossible to understand anything when screen readers are using the wrong language library. Rule Description  The HTML document element must contain a valid lang attribute or must correspond to a valid lang code for multilingual screen reader users who may prefer a language other than the default. The Algorithm (in simple terms) Ensures that every HTML document has a lang attribute Resources Deque University Deque University Course Pages (subscription required) LanguagePrimary Language of PageLanguage Codes  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. H57: Using language attributes on the html element Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/html-has-lang"
+44,dequeuniversity.comaria required children.txt,"dequeuniversity.comaria required children.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Certain ARIA roles must contain particular children Rule ID: aria-required-children Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Start building more accessible experiences  Axe DevTools Pro helps dev teams find and fix up to 80% of accessibility issues while coding. No experience required. Get started with your free trial today.  Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]1.3.1: MUST: Info and RelationshipsWCAG Success Criteria [WCAG 2.0 (A)]1.3.1: MUST: Info and Relationships  How to Fix the Problem  Ensure elements including explicit or implicit ARIA roles include required children elements.  The following attribute values indicate relationships between element that cannot be readily determined from the document structure. The relationships are linked to characteristics tables that list explicit and implicit role attribute values as well as role attribute values inherited by nested children elements. aria-activedescendant aria-controls aria-describedby aria-flowto aria-labelledby aria-owns aria-posinset aria-setsize role=""combobox""  For similar (opposite) information, refer to Certain ARIA roles must be contained by particular parents. Why it Matters  For each role, WAI-ARIA explicitly defines which child and parent roles are allowable and/or required. ARIA roles missing required child roles will not be able to perform the accessibility functions intended by the developer.  Assistive technology needs to convey the context to the user. For example, in a treeitem, it is important to know the parent (container), item, or siblings in the folder. This can be done in two ways: Code order or DOM: The necessary context is often clear  from the code order or DOM.  ARIA: ARIA (such as aria-owns) can be used  provide the relationships when the hierarchy is not the same as the code  structure or DOM tree.  Rule Description  Some ARIA parent role values applied to elements must contain specific child elements and role values to perform intended accessibility function. The Algorithm (in simple terms)  Checks all elements that contain a WAI-ARIA role to ensure that all required children roles are present.  Resources Deque University Deque University Course Pages (subscription required) ARIA ConceptsRoleARIA Widget Examples  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. Accessible Rich Internet Applications (WAI-ARIA) 1.1 - The Roles Model Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-required-children"
+45,dequeuniversity.comimage alt.txt,"dequeuniversity.comimage alt.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Images must have alternate text Rule ID: image-alt Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), Section 508         Learn Web Accessibility   										Subscribe to our extensive curriculum of online self-paced courses 									 Learn More about Deque University   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Blind Deafblind  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A)Section 508 WCAG Success Criteria [WCAG 2.1 (A)]1.1.1: MUST: Non-text ContentWCAG Success Criteria [WCAG 2.0 (A)]1.1.1: MUST: Non-text ContentSection 508 Guidelines1194.22: MUST: Web based intranet and Internet Information & Applications1194.22 (a): MUST: A text equivalent for every non-text element shall be provided (e.g., via ""alt"", ""longdesc"", or in element content)  How to Fix the Problem  Ensure all informative <img> elements have short, descriptive alternate text and all decorative <img> elements have empty alt attributes (e.g. alt=""""). There are three main ways to add alternate text to an image:  Using an alt attribute i.e.  <img alt=""drawing of a cat"" src=""..."">  Using an aria-label i.e.  <img aria-label=""drawing of a cat"" src=""..."">  Using an aria-labelledby attribute i.e.  <img arialabelledby=""someID"" src=""...""> Alt Text Writing Tips When writing alt text, keep in mind that its purpose is to relay information to blind users about the image’s contents and purpose - blind users should be able to get as much information from alt text as a sighted user gets from the image itself. Alt text should give the intent, purpose, and meaning of the image.  When writing alt text, it is helpful to keep the following questions in mind: Why is the non-text content here? What information is it presenting? What purpose does it fulfill?  If I could not use the non-text content, what words would I use to convey  the same information or function?  Be sure that all text contained in the attribute is useful. Words like ""chart,"" ""image,"" ""diagram,"" or image file names tend not to be very useful and thus should not be used in alt text. Decorative Elements Provide ""null"" alt attributes (using alt="""") for images which do not provide information or do not require alternative text because the image is described in the page content. Some developers will mistakenly leave off the alt attribute altogether on images which they deem do not need alternatives. This is not helpful to assistive technology users because the assistive technology, such as screen reader, will often read the source attribute (i.e., file name) as the alternative text. To tell assistive technology to ignore an image, use a ""blank alternative text"" attribute: alt="""". Example: <img src=""line.jpg"" alt=""""> Why it Matters  Screen readers have no way of translating an image into words that gets read to the user, even if the image only consists of text. As a result, it's necessary for images to have short, descriptive alt text so screen reader users clearly understand the image's contents and purpose.  If you can't see, all types of visual information, such as images, are completely useless unless a digital text alternative is provided so that screen readers can convert that text into either sound or braille. The same is true in varying degrees for people with low vision or color-blindness. Rule Description  All images must have alternate text to convey their purpose and meaning to screen reader users. The Algorithm (in simple terms)  Ensures that every <img> element has alternative text and either role=""presentation"" or role=""none"" (ARIA 1.1).  Resources Deque University Deque University Course Pages (subscription required) Advanced Alt Text and Extended DescriptionsImage Alt TextLabelsGroup Labels  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. A Simple Alt Text Decision Tree (HTML5 Specification)F65: Failure of Success Criterion 1.1.1 due to omitting the alt attribute or text alternative on img elements, area elements, and input elements of type ""image""H37: Using alt attributes on img elementsH67: Using null alt text and no title attribute on img elements for images that AT should ignoreARIA10: Using aria-labelledby to provide a text alternative for non-text content Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/image-alt"
+46,hpbn.co.txt,"hpbn.co.txt.  Networking 101: Primer on Latency and Bandwidth - High Performance Browser Networking (O'Reilly)       Menu High Performance Browser   Networking  |  O'Reilly    Primer on Latency and Bandwidth     Table of Contents About the Author     Submit Feedback   Primer on Latency and Bandwidth Networking 101, Chapter 1  §Speed Is a Feature The emergence and the fast growth of the web performance optimization  (WPO) industry within the past few years is a telltale sign of the  growing importance and demand for speed and faster user experiences by  the users. And this is not simply a psychological need for speed  in our ever accelerating and connected world, but a requirement driven by  empirical results, as measured with respect to the bottom-line  performance of the many online businesses:   Faster sites lead to better user engagement.   Faster sites lead to better user retention.   Faster sites lead to higher conversions.  Simply put, speed is a feature. And to deliver it, we need to  understand the many factors and fundamental limitations that are at play.  In this chapter, we will focus on the two critical components that  dictate the performance of all network traffic: latency and bandwidth  (Figure 1-1).   Latency   The time from the source sending a packet to the destination   receiving it   Bandwidth   Maximum throughput of a logical or physical communication path   Figure 1-1. Latency and bandwidth   Armed with a better understanding of how bandwidth and latency work  together, we will then have the tools to dive deeper into the internals  and performance characteristics of TCP, UDP, and all application  protocols above them.   §Decreasing Transatlantic Latency with Hibernia   Express Latency is an important criteria for many high-frequency trading   algorithms in the financial markets, where a small edge of a few   milliseconds can translate to millions in loss or profit.   In September 2015, Hibernia Networks launched a new fiber-optic link   (""Hibernia Express"") specifically designed to ensure the lowest latency   between New York and London by following the great circle route between   the cities. The total cost of the project is estimated to be $300M+ and   the new route boasts 58.95 ms latency between the cities, which gives   it a ~5 millisecond edge compared to all other existing transatlantic   links. This translates to $60M+ per millisecond saved!   Latency is expensive — literally and figuratively.   §The Many Components  of Latency Latency is the time it takes for a message, or a packet, to travel  from its point of origin to the point of destination. That is a simple  and useful definition, but it often hides a lot of useful information —  every system contains multiple sources, or components, contributing to  the overall time it takes for a message to be delivered, and it is  important to understand what these components are and what dictates their  performance.  Let’s take a closer look at some common contributing components for a  typical router on the Internet, which is responsible for relaying a  message between the client and the server:   Propagation delay   Amount of time required for a message to travel from the sender to   receiver, which is a function of distance over speed with which the   signal propagates.   Transmission delay   Amount of time required to push all the packet’s bits into the   link, which is a function of the packet’s length and data rate of the   link.   Processing delay   Amount of time required to process the packet header, check for   bit-level errors, and determine the packet’s destination.   Queuing delay   Amount of time the packet is waiting in the queue until it can be   processed.  The total latency between the client and the server is the sum of all  the delays just listed. Propagation time is dictated by the distance and  the medium through which the signal travels — as we will see, the  propagation speed is usually within a small constant factor of the speed  of light. On the other hand, transmission delay is dictated by the  available data rate of the transmitting link and has nothing to do with  the distance between the client and the server. As an example, let’s  assume we want to transmit a 10 Mb file over two links: 1 Mbps and 100  Mbps. It will take 10 seconds to put the entire file ""on the wire"" over  the 1 Mbps link and only 0.1 seconds over the 100 Mbps link.   Network data rates are typically measured in bits per second (bps),   whereas data rates for non-network equipment are typically shown in   bytes per second (Bps). This is a common source of confusion, pay close   attention to the units.   For example, to put a 10 megabyte (MB) file ""on the wire"" over a   1Mbps link, we will need 80 seconds. 10MB is equal to 80Mb because   there are 8 bits for every byte!  Next, once the packet arrives at the router, the router must examine  the packet header to determine the outgoing route and may run other  checks on the data — this takes time as well. Much of this logic is now  often done in hardware, so the delays are very small, but they do exist.  And, finally, if the packets are arriving at a faster rate than the  router is capable of processing, then the packets are queued inside an  incoming buffer. The time data spends queued inside the buffer is, not  surprisingly, known as queuing delay.  Each packet traveling over the network will incur many instances of  each of these delays. The farther the distance between the source and  destination, the more time it will take to propagate. The more  intermediate routers we encounter along the way, the higher the  processing and transmission delays for each packet. Finally, the higher  the load of traffic along the path, the higher the likelihood of our  packet being queued and delayed inside one or more buffers.   §Bufferbloat in   Your Local Router Bufferbloat is a term that was coined and popularized by   Jim Gettys in 2010, and is a great example of queuing delay affecting   the overall performance of the network.   The underlying problem is that many routers are now shipping with   large incoming buffers under the assumption that dropping packets   should be avoided at all costs. However, this breaks TCP’s congestion   avoidance mechanisms (which we will cover in the next chapter), and   introduces high and variable latency delays into the network.   The good news is that the new CoDel active queue management   algorithm has been proposed to address this problem, and is now   implemented within the Linux 3.5+ kernels. To learn more, refer to   ""Controlling Queue Delay"" in ACM   Queue.   §Speed of  Light and Propagation Latency As Einstein outlined in his theory of special relativity, the speed of  light is the maximum speed at which all energy, matter, and information  can travel. This observation places a hard limit, and a governor, on the  propagation time of any network packet.  The good news is the speed of light is high: 299,792,458 meters per  second, or 186,282 miles per second. However, and there is always a  however, that is the speed of light in a vacuum. Instead, our packets  travel through a medium such as a copper wire or a fiber-optic cable,  which will slow down the signal (Table 1-1). This ratio of the speed of  light and the speed with which the packet travels in a material is known  as the refractive index of the material. The larger the value, the slower  light travels in that medium.  The typical refractive index value of an optical fiber, through which  most of our packets travel for long-distance hops, can vary between 1.4  to 1.6 — slowly but surely we are making improvements in the quality of  the materials and are able to lower the refractive index. But to keep it  simple, the rule of thumb is to assume that the speed of light in fiber  is around 200,000,000 meters per second, which corresponds to a  refractive index of ~1.5. The remarkable part about this is that we are  already within a small constant factor of the maximum speed! An amazing  engineering achievement in its own right.   Route    Distance    Time, light in vacuum    Time, light in fiber    Round-trip time (RTT) in fiber    New York to San Francisco    4,148 km    14 ms    21 ms 42 ms    New York to London    5,585 km    19 ms    28 ms 56 ms    New York to Sydney    15,993 km    53 ms    80 ms 160 ms    Equatorial circumference    40,075 km    133.7 ms    200 ms 200 ms   Table 1-1. Signal latencies in vacuum and   fiber   The speed of light is fast, but it nonetheless takes 160 milliseconds  to make the round-trip (RTT) from New York to Sydney. In fact, the  numbers in Table 1-1 are also unrealistically  optimistic in that they assume that the packet travels over a fiber-optic  cable along the great-circle path (the shortest distance between two  points on the globe) between the cities. In practice, that is rarely the  case, and the packet would take a much longer route between New York and  Sydney. Each hop along this route will introduce additional routing,  processing, queuing, and transmission delays. As a result, the actual RTT  between New York and Sydney, over our existing networks, works out to be  in the 200–300 millisecond range. All things considered, that still seems  pretty fast, right?  We are not accustomed to measuring our everyday encounters in  milliseconds, but studies have shown that most of us will reliably report  perceptible ""lag"" once a delay of over 100–200 milliseconds is introduced  into the system. Once the 300 millisecond delay threshold is exceeded,  the interaction is often reported as ""sluggish,"" and at the 1,000  milliseconds (1 second) barrier, many users have already performed a  mental context switch while waiting for the response — see Speed,  Performance, and Human Perception.  The point is simple, to deliver the best experience and to keep our  users engaged in the task at hand, we need our applications to respond  within hundreds of milliseconds. That doesn’t leave us, and especially  the network, with much room for error. To succeed, network  latency has to be carefully managed and be an explicit design criteria at  all stages of development. Content delivery network (CDN) services provide many benefits, but   chief among them is the simple observation that distributing the   content around the globe, and serving that content from a nearby   location to the client, enables us to significantly reduce the   propagation time of all the data packets.   We may not be able to make the packets travel faster, but we can   reduce the distance by strategically positioning our servers closer to   the users! Leveraging a CDN to serve your data can offer significant   performance benefits.   §Last-Mile Latency Ironically, it is often the last few miles, not the crossing of oceans  or continents, where significant latency is introduced: the infamous  last-mile problem. To connect your home or office to the Internet, your  local ISP needs to route the cables throughout the neighborhood,  aggregate the signal, and forward it to a local routing node. In  practice, depending on the type of connectivity, routing methodology, and  deployed technology, these first few hops alone can take tens of  milliseconds.  According to the annual ""Measuring Broadband America"" reports  conducted by the Federal Communications Commission (FCC), the last-mile  latencies for terrestrial-based broadband (DSL, cable, fiber) within the  United States have remained relatively stable over time: fiber has best  average performance (10-20 ms), followed by cable (15-40 ms), and DSL  (30-65 ms).  In practice this translates into 10-65 ms of latency just to the  closest measuring node within the ISP’s core network, before the packet  is even routed to its destination! The FCC report is focused on the  United States, but last-mile latency is a challenge for all Internet  providers, regardless of geography. For the curious, a simple  traceroute can often tell you volumes about the topology and  performance of your Internet provider.   $> traceroute google.com traceroute to google.com (74.125.224.102), 64 hops max, 52 byte packets 1 10.1.10.1 (10.1.10.1) 7.120 ms 8.925 ms 1.199 ms  2 96.157.100.1 (96.157.100.1) 20.894 ms 32.138 ms 28.928 ms 3 x.santaclara.xxxx.com (68.85.191.29) 9.953 ms 11.359 ms 9.686 ms 4 x.oakland.xxx.com (68.86.143.98) 24.013 ms 21.423 ms 19.594 ms 5 68.86.91.205 (68.86.91.205) 16.578 ms 71.938 ms 36.496 ms 6 x.sanjose.ca.xxx.com (68.86.85.78) 17.135 ms 17.978 ms 22.870 ms 7 x.529bryant.xxx.com (68.86.87.142) 25.568 ms 22.865 ms 23.392 ms 8 66.208.228.226 (66.208.228.226) 40.582 ms 16.058 ms 15.629 ms 9 72.14.232.136 (72.14.232.136) 20.149 ms 20.210 ms 18.020 ms 10 64.233.174.109 (64.233.174.109) 63.946 ms 18.995 ms 18.150 ms 11 x.1e100.net (74.125.224.102) 18.467 ms 17.839 ms 17.958 ms  1st hop: local wireless router    11th hop: Google server   In the previous example, the packet started in the city of Sunnyvale,  bounced to Santa Clara, then Oakland, returned to San Jose, got routed to  the ""529 Bryant"" datacenter, at which point it was routed toward Google  and arrived at its destination on the 11th hop. This entire process took,  on average, 18 milliseconds. Not bad, all things considered, but in the  same time the packet could have traveled across most of the continental  USA!  The last-mile latencies can vary wildly between ISP’s due to the  deployed technology, topology of the network, and even the time of day.  As an end user, and if you are looking to improve your web browsing  speeds, make sure to measure and compare the last-mile latencies of the  various providers available in your area.   Latency, not bandwidth, is the performance bottleneck for most   websites! To understand why, we need to understand the mechanics of TCP   and HTTP protocols — subjects we’ll be covering in subsequent chapters.   However, if you are curious, feel free to skip ahead to More   Bandwidth Doesn’t Matter (Much).   §Measuring   Latency with Traceroute Traceroute is a simple network diagnostics tool for identifying the   routing path of the packet and the latency of each network hop in an IP   network. To identify the individual hops, it sends a sequence of   packets toward the destination with an increasing ""hop limit"" (1, 2, 3,   and so on). When the hop limit is reached, the intermediary returns an   ICMP Time Exceeded message, allowing the tool to measure the latency   for each network hop.   On Unix platforms the tool can be run from the command line via   traceroute, and on Windows it is known as   tracert.   §Bandwidth in Core Networks An optical fiber acts as a simple ""light pipe,"" slightly thicker than  a human hair, designed to transmit light between the two ends of the  cable. Metal wires are also used but are subject to higher signal loss,  electromagnetic interference, and higher lifetime maintenance costs.  Chances are, your packets will travel over both types of cable, but for  any long-distance hops, they will be transmitted over a fiber-optic link.  Optical fibers have a distinct advantage when it comes to bandwidth  because each fiber can carry many different wavelengths (channels) of  light through a process known as wavelength-division multiplexing (WDM).  Hence, the total bandwidth of a fiber link is the multiple of per-channel  data rate and the number of multiplexed channels.  As of early 2010, researchers have been able to multiplex over 400  wavelengths with the peak capacity of 171 Gbit/s per channel, which  translates to over 70 Tbit/s of total bandwidth for a single fiber link!  We would need thousands of copper wire (electrical) links to match this  throughput. Not surprisingly, most long-distance hops, such as subsea  data transmission between continents, is now done over fiber-optic links.  Each cable carries several strands of fiber (four strands is a common  number), which translates into bandwidth capacity in hundreds of terabits  per second for each cable.  §Bandwidth at the  Network Edge The backbones, or the fiber links, that form the core data paths of  the Internet are capable of moving hundreds of terabits per second.  However, the available capacity at the edges of the network is much, much  less, and varies wildly based on deployed technology: dial-up, DSL,  cable, a host of wireless technologies, fiber-to-the-home, and even the  performance of the local router. The available bandwidth to the user is a  function of the lowest capacity link between the client and the  destination server (Figure 1-1).  Akamai Technologies operates a global CDN, with servers positioned  around the globe, and provides free quarterly reports at Akamai’s website on average broadband speeds,  as seen by their servers. Table 1-2 captures the macro trends as  of late 2015.   Rank    Country    Average Mbps    Year-over-year change    -    Global    5.1 14%    1    South Korea    20.5 -19%    2    Sweden    17.4 23%    3    Norway    16.4 44%    4    Switzerland    16.2 12%    5    Hong Kong    15.8 -2.7%    …                21    United States    12.6 9.4%   Table 1-2. Average bandwidth speeds as   seen by Akamai servers in Q3 2015   The preceding data excludes traffic from mobile carriers, a topic we  will come back to later to examine in closer detail. For now, it should  suffice to say that mobile speeds are highly variable and generally  slower. However, even with that in mind, the average global broadband  bandwidth in late 2015 was just 5.1 Mbps! South Korea led the world with  a 20.5 Mbps average throughput, and United States came in 21st place with  12.6 Mbps.  As a reference point, streaming an HD video can require anywhere from  2 to 10 Mbps depending on resolution and the codec. So an average user  within the United States can stream a high-resolution video at the  network edge, but doing so would also consume much of their link capacity  — not a very promising story for a household with multiple users.  Figuring out where the bandwidth bottleneck is for any given user is  often a nontrivial but important exercise. Once again, for the curious,  there are a number of online services, such as speedtest.net operated by Ookla (Figure 1-2), which provide upstream and  downstream tests against a nearby server — we will see why picking a  local server is important in our discussion on TCP. Running a test on one  of these services is a good way to check that your connection meets the  advertised speeds of your local ISP.   Figure 1-2. Upstream and downstream test   (speedtest.net)   However, while a high-bandwidth link to your ISP is desirable, it is  also not a guarantee of end-to-end performance; just because a bandwidth  test promises high data rates does not mean that you can or should expect  same performance from other remote servers. The network could be  congested at any intermediate node due to high demand, hardware failures,  a concentrated network attack, or a host of other reasons. High  variability of throughput and latency performance is an inherent property  of our data networks — predicting, managing, and adapting to the  continuously changing ""network weather"" is a complex task.  §Delivering Higher Bandwidth and Lower Latencies Our demand for higher bandwidth is growing fast, in large part due to  the rising popularity of streaming video, which is now responsible for  well over half of all Internet traffic. The good news is, while it may  not be cheap, there are multiple strategies available for us to grow the  available capacity: we can add more fibers into our fiber-optic links, we  can deploy more links across the congested routes, or we can improve the  WDM techniques to transfer more data through existing links.  TeleGeography, a telecommunications market research and consulting  firm, estimates that as of 2011, we are using, on average, just 20% of  the available capacity of the deployed subsea fiber links. Even more  importantly, between 2007 and 2011, more than half of all the added  capacity of the trans-Pacific cables was due to WDM upgrades: same fiber  links, better technology on both ends to multiplex the data. Of course,  we cannot expect these advances to go on indefinitely, as every medium  reaches a point of diminishing returns. Nonetheless, as long as economics  of the enterprise permit, there is no fundamental reason why bandwidth  throughput cannot be increased over time — if all else fails, we can add  more fiber links.  Improving latency, on the other hand, is a very different story. The  quality of the fiber links could be improved to get us a little closer to  the speed of light: better materials with lower refractive index and  faster routers along the way. However, given that our current speeds are  already within ~2/3 of the speed of light, the most we can expect from  this strategy is just a modest 30% improvement. Unfortunately, there is  simply no way around the laws of physics: the speed of light places a  hard limit on the minimum latency.  Alternatively, since we can’t make light travel faster, we can make  the distance shorter — the shortest distance between any two points on  the globe is defined by the great-circle path between them. However,  laying new cables is also not always possible due to the constraints  imposed by the physical terrain, social and political reasons, and of  course, the associated costs.  As a result, to improve performance of our applications, we need to  architect and optimize our protocols and networking code with explicit  awareness of the limitations of available bandwidth and the speed of  light: we need to reduce round trips, move the data closer to the client,  and build applications that can hide the latency through caching,  pre-fetching, and a variety of similar techniques, as explained in  subsequent chapters.       « Back to the Table of Contents Copyright © 2013 Ilya Grigorik. Published by O'Reilly Media, Inc. Licensed under  CC BY-NC-ND  4.0.  URL of this webpage is: https://hpbn.co/primer-on-latency-and-bandwidth/"
+47,dequeuniversity.comaria hidden body.txt,"dequeuniversity.comaria hidden body.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    aria-hidden='true' must not be present on the document body Rule ID: aria-hidden-body Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Start building more accessible experiences  Axe DevTools Pro helps dev teams find and fix up to 80% of accessibility issues while coding. No experience required. Get started with your free trial today.  Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Blind  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, Value  How to Fix the Problem  Remove the aria-hidden=""true"" attribute from the document body element. Caution: aria-hidden=""false"" is known to work inconsistently  when used in conjunction with styles or attributes that have historically  prevented rendering in all modalities, such as display: none,  visibility: hidden in CSS, or the hidden attribute in HTML5.  Use caution and test thoroughly before relying on this approach.  Reconsider the location of the hidden content to determine whether you can relocate it to an area of the page other than the body element. Typically, content is hidden from screen readers to reduce the unnecessary information that screen reader users would tend to skip (redundant or extraneous content). Why it Matters  When <body aria-hidden=""true"", content is not accessible to assistive technology.  Applying aria-hidden=""true"" to otherwise accessible objects: A web page is designed to be fully accessible, and it would be accessible if elements do not contain the aria-hidden=""true"" attribute value. Screen readers do not read content marked with the aria-hidden=""true"" attribute value. Users can still tab to focusable elements in the hidden objects, but screen readers remain silent.  Any content or interface elements intentionally hidden from users — e.g., inactive dialogs, collapsed menus — must also be hidden from screen reader users. When items are available to sighted users — such as when they activate a button or expand a menu item — the same items must be available to screen reader users. The goal is to provide screen reader users an equivalent user experience to sighted users. If there is a compelling reason to hide content from sighted users, there is usually a compelling reason also to hide that content from blind users. Further, when content is made available to sighted users, it makes sense to make it available to blind users as well. Rule Description  Document content is not accessible to assistive technology if <body aria-hidden=""true"">. The Algorithm (in simple terms)  Checks for the presence of the aria-hidden=""true"" attribute the document's body element and alerts with a pass or fail message accordingly.  Resources Deque University Deque University Course Pages (subscription required) Web Accessibility, Part 9: Custom JavaScript/ARIA WidgetsARIA Concepts  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. W3C WAI-ARIA 1.1 States and Properties - aria-hidden Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-hidden-body"
+48,dequeuniversity.combutton name.txt,"dequeuniversity.combutton name.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Buttons must have discernible text Rule ID: button-name Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), Section 508     Accessibility testing for dev teams - No experience required  Find and fix up to 80% of accessibility issues with axe DevTools Pro. Get started with your free trial today. No credit card needed.   Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Blind Deafblind  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A)Section 508 WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, ValueSection 508 Guidelines1194.22: MUST: Web based intranet and Internet Information & Applications1194.22 (a): MUST: A text equivalent for every non-text element shall be provided (e.g., via ""alt"", ""longdesc"", or in element content)  How to Fix the Problem Correct markup solutions  The button-name rule has five markup patterns that pass test  criteria: <button id=""text"">Name</button> <button id=""al"" aria-label=""Name""></button> <button id=""alb"" aria-labelledby=""labeldiv""></button> <div id=""labeldiv"">Button label</div> <button id=""combo"" aria-label=""Aria Name"">Name</button> <button id=""buttonTitle"" title=""Title""></button>   Ensure that each button element and elements with  role=""button"" have one of the following characteristics:  Inner text that is discernible to screen reader users. Non-empty aria-label attribute. aria-labelledby pointing to element with text which is   discernible to screen reader users.   role=""presentation"" or role=""none"" (ARIA 1.1)   and is not in tab order (tabindex=""-1"").    Incorrect markup solutions  The button-name rule has six markup patterns that fail testing  criteria: <button id=""empty""></button> <button id=""val"" value=""Button Name""></button> <button id=""alempty"" aria-label=""""></button> <button id=""albmissing"" aria-labelledby=""nonexistent""></button> <button id=""albempty"" aria-labelledby=""emptydiv""></button> <div id=""emptydiv""></div> <button id=""buttonvalue"" value=""foo"" tabindex=""-1""></button> Why it Matters  Screen reader users are not able to discern the purpose of elements with role=""link"", role=""button"", or role=""menuitem"" that do not have an accessible name. Rule Description  Buttons must have discernible text that clearly describes the destination, purpose, function, or action for screen reader users.  The input-button-name rule separates functionality from the button-name rule to ensure that input buttons have discernible text; advise relevant to input button names was incorrect for button elements. The Algorithm (in simple terms)  Checks all buttons to ensure that they have a discernable, accessible name.  Resources Deque University Deque University Course Pages (subscription required) LabelsGroup LabelsInstructions and Other Helpful InfoInstructions for Inputs  Deque University  Contribute to axe-core on GitHub Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/button-name"
+49,dequeuniversity.comaria input field name.txt,"dequeuniversity.comaria input field name.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    ARIA input fields must have an accessible name Rule ID: aria-input-field-name Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Need accessibility training?  Deque University offers an extensive curriculum of self-guided online courses for every skillset and experience level.  Start learning today   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, Value  How to Fix the Problem Correct markup solutions  The aria-input-field-label rule includes six markup patterns  that pass testing criteria: <!-- combobox --> <div id=""pass1"" aria-label=""country"" role=""combobox"">England</div> <!-- Select a color: --> <div id=""pass2"" role=""listbox"" aria-labelledby=""pass2Label"">  <div role=""option"">Orange</div> </div> <!-- searchbox --> <p id=""pass3Label"">Search currency pairs:</p> <div id=""pass3""  role=""searchbox""  contenteditable=""true""  aria-labelledby=""pass3Label""></div> <!-- slider --> <div id=""pass4""  role=""slider""  aria-label=""Choose a value""  aria-valuemin=""1""  aria-valuemax=""7""  aria-valuenow=""2""></div> <!-- spinbutton --> <div id=""pass5""  role=""spinbutton""  aria-valuemin=""0""  aria-valuemax=""10""  aria-valuenow=""8""  aria-label=""Enter quantity:""></div> <!-- textbox --> <label id=""foo"">  foo  <div id=""pass6"" role=""textbox"" aria-labelledby=""foo""></div> </label> Incorrect markup solutions  The aria-input-field-label rule includes ten markup patterns  that fail testing criteria: <!-- aria-label with empty text string --> <div id=""fail1"" aria-label="" "" role=""combobox"">England</div> <!-- The label does not exist. --> <div id=""fail2"" aria-labelledby=""non-existing"" role=""combobox"">England</div> <!-- The implicit label is not supported on div elements. --> <label>  first name  <div id=""fail3"" role=""textbox""></div> </label> <!-- explicit label not supported on div elements --> <label for=""fail4"">first name</label> <div role=""textbox"" id=""fail4""></div> <!-- combobox --> <div id=""fail5"" role=""combobox"">England</div> <!-- listbox --> <div id=""fail6"" role=""listbox"" aria-labelledby=""label-does-not-exist"">  <div role=""option"">Orange</div> </div> <!-- searchbox --> <div id=""fail7""  role=""searchbox""  contenteditable=""true""  aria-labelledby=""unknown-label""></div>  <!-- slider --> <div id=""fail8""  role=""slider""  aria-valuemin=""1""  aria-valuemax=""7""  aria-valuenow=""2""></div> <!-- spinbutton --> <div id=""fail9""  role=""spinbutton""  aria-valuemin=""0""  aria-valuemax=""10""  aria-valuenow=""8""></div> <!-- textbox --> <label>foo  <div id=""fail10"" role=""textbox""></div> </label>  Why it Matters  This new rule ensures every ARIA input field has an accessible name. Accessible names must exist for the following input field roles: combobox listbox searchbox slider spinbutton textbox Rule Description Ensures every ARIA input field has an accessible name. The Algorithm (in simple terms) ARIA input fields must have an accessible name. Resources Deque University Deque University Course Pages (subscription required) 						No related course information available. 					  Deque University  Contribute to axe-core on GitHub Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-input-field-name"
+50,dequeuniversity.comduplicate id active.txt,"dequeuniversity.comduplicate id active.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    IDs of active elements must be unique Rule ID: duplicate-id-active Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Accessibility testing for dev teams - No experience required  Find and fix up to 80% of accessibility issues with axe DevTools Pro. Get started with your free trial today. No credit card needed.   Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.1: MUST: ParsingWCAG Success Criteria [WCAG 2.0 (A)]4.1.1: MUST: Parsing  How to Fix the Problem Rename attributes that reuse an ID on active, focusable elements. Duplicate active IDs are common validation errors that can break the accessibility of labels for focusable elements, forms, table header cells, etc.  To fix the problem, change the duplicate ID value to ensure each ID is unique. Unique ID values differentiate each focusable element from another and prevent invalid markup and the active ID instance is acted upon by client-side scripting, or where assistive technologies typically only reference the active ID of repeated elements.  Good markup eliminates at least one possible source of accessibility problems. WCAG 1.0 used to have a provision which explicitly required the use of valid markup. That requirement has been taken out of WCAG 2.0. We mention it here because valid markup is a quick path toward ensuring accessibility. Most validation issues are usually inconsequential for accessibility (e.g., un-encoded ampersands). Other ID validation errors are very important and may cause issues relating to how assistive technology interacts with the page and renders the page to the end user.  One way to test the validity of HTML markup in order to quickly identify reused attribute ID values is to submit the code through the W3C validator at http://validator.w3.org. Why it Matters  The ID attribute uniquely identifies focusable elements on a page. It does not make sense to duplicate an active ID.  Duplicate active ID values break the accessibility of focusable elements including labels for forms, table header cells, etc., Screen readers and client-side scripts will skip any duplication other than the first instance. Validating HTML files help prevent and eliminate possible sources of accessibility problems, when not breaking accessibility.  Those experienced with client-side scripting know that when you re-use an active ID, typically the only one that gets acted upon by the scripting is the first instance of the use of that active ID. Similarly, assistive technologies may, when referencing an active ID, only reference the first one accurately. Rule Description  The value assigned to active ID attributes on focusable elements must be unique to prevent the second instance from being overlooked by assistive technology. Put another way, active ID attributes may not be used more than once on focusable elements in the same document; focusable active elements require unique IDs for assistive technology to distinguish one element from another. The Algorithm (in simple terms)  Ensures that each focusable element on the page with an active ID has a unique value.  Resources Deque University Deque University Course Pages (subscription required) Parsing and ValidityConflicts and duplicates  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. F77: Failure of Success Criterion 4.1.1 due to duplicate values of type ID Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/duplicate-id-active"
+51,search.google.comtesting tool.txt,"search.google.comtesting tool.txt.      Schema Markup Testing Tool | Google Search Central  |  Google for Developers       Google Search Central    Documentation    SEO fundamentals       Introduction             Search Essentials             Get your website on Google             How Google Search Works             SEO starter guide             Do you need an SEO?       Crawling and indexing       Sitemaps             robots.txt             Meta tags             Crawler management             Removals             Canonicalization             Redirects             JavaScript SEO       Ranking and search appearance       Visual Elements gallery             Title links             Snippets             Images             Videos             Structured data             Favicons       Site-specific guides       Ecommerce             International and multilingual sites             Education         Support    Blog    What's new          All updates             Documentation updates             Ranking updates             New YouTube videos             Recent podcast episodes         Events    Case studies        English Bahasa Indonesia Deutsch Español Español – América Latina Français Italiano Polski Português – Brasil Tiếng Việt Türkçe Русский العربيّة हिंदी ภาษาไทย 中文 – 简体 中文 – 繁體 日本語 한국어  Sign in        Google Search Central        Documentation     More     Support     Blog     What's new     More     Events     Case studies      SEO fundamentals    Introduction    Search Essentials    Get your website on Google    How Google Search Works    SEO starter guide    Do you need an SEO?    Crawling and indexing    Sitemaps    robots.txt    Meta tags    Crawler management    Removals    Canonicalization    Redirects    JavaScript SEO    Ranking and search appearance    Visual Elements gallery    Title links    Snippets    Images    Videos    Structured data    Favicons    Site-specific guides    Ecommerce    International and multilingual sites    Education     All updates    Documentation updates    Ranking updates    New YouTube videos    Recent podcast episodes          Home       Search Central       Send feedback        Stay organized with collections        Save and categorize content based on your preferences.           Test your structured data        Google recommends that you start with the Rich Results Test to see what Google rich results can be generated for your page. For generic schema validation, use the Schema Markup Validator to test all types of schema.org markup, without Google-specific validation.            Rich Results Test    The official Google tool for testing your structured data to see which Google rich results can be generated by the structured data on your page. You can also preview how rich results can look in Google Search. Go to the Rich Results Test        Schema Markup Validator    Validate all Schema.org-based structured data that's embedded in web pages, without Google feature specific warnings. Go to the Schema Markup Validator        Looking for the Structured Data Testing Tool?       We removed Google-specific validation from the Structured Data Testing Tool and migrated the tool to a new domain, Schema Markup Validator. Learn more about the change in our blog post.    Read the blog post              Podcast  Listen to our Search Off the Record podcast         Blog  Subscribe to our RSS feed         Twitter  Follow @googlesearchc on Twitter   Get support          Go to the help forum                Submit a question for office hours                           More support resources       Get updates          Blog                Twitter                           YouTube       Resources          Do you need an SEO?                SEO Starter Guide                Status of Search systems                Search Console documentation                           Case Studies       Tools          Search Console                Mobile-Friendly Test                Rich Results Test                PageSpeed Insights                           AMP Test             Android      Chrome      Firebase      Google Cloud Platform      All products       Terms      Privacy   Sign up for the Google for Developers newsletter   Subscribe    English Bahasa Indonesia Deutsch Español Español – América Latina Français Italiano Polski Português – Brasil Tiếng Việt Türkçe Русский العربيّة हिंदी ภาษาไทย 中文 – 简体 中文 – 繁體 日本語 한국어      URL of this webpage is: https://search.google.com/structured-data/testing-tool"
+52,developers.google.com.txt,"developers.google.com.txt. Loading Third-Party JavaScriptSkip to content Open menu  About Blog Learn Explore Patterns Case studies Close Thanks for tuning in to Google I/O. Watch the Chrome content on-demand.On this page What do we mean by third-party scripts?How do you identify third-party script on a page?How do I measure the impact of third-party script on my page?Lighthouse Boot-up Time AuditLighthouse Network Payloads AuditChrome DevTools Network Request BlockingChrome DevTools Performance PanelMeasuring impact of Third-Party tags with WebPageTestDetecting expensive iframes using Long TasksHow do you load third-party script efficiently?Use async or deferUse Resource Hints to reduce connection setup time""Sandbox"" scripts with an iframeSelf-host third-party scriptsA/B Test smaller samples of usersLazy load Third-Party ResourcesAnalytics can be complicatedWhat patterns should I avoid with third-party script?Avoid document.write()Use Tag Managers but use them wiselyAvoid scripts that pollute the global scopeMitigation strategiesConclusionFurther reading Loading Third-Party JavaScriptFeb 28, 2018 — Updated Feb 25, 2023 Addy Osmani TwitterGitHub Arthur Evans TwitterGitHubOn this page What do we mean by third-party scripts?How do you identify third-party script on a page?How do I measure the impact of third-party script on my page?Lighthouse Boot-up Time AuditLighthouse Network Payloads AuditChrome DevTools Network Request BlockingChrome DevTools Performance PanelMeasuring impact of Third-Party tags with WebPageTestDetecting expensive iframes using Long TasksHow do you load third-party script efficiently?Use async or deferUse Resource Hints to reduce connection setup time""Sandbox"" scripts with an iframeSelf-host third-party scriptsA/B Test smaller samples of usersLazy load Third-Party ResourcesAnalytics can be complicatedWhat patterns should I avoid with third-party script?Avoid document.write()Use Tag Managers but use them wiselyAvoid scripts that pollute the global scopeMitigation strategiesConclusionFurther readingYou've optimized all of your code, but your site still loads too slowly. Who's the culprit?Often, performance problems slowing pages down are due to third-party scripts: ads, analytics, trackers, social media buttons, and so on.Third-party scripts provide a wide range of useful functionality, making the web more dynamic, interactive, and interconnected. These scripts may be crucial to your website's functionality or revenue stream. But third-party scripts also come with many risks that should be taken into consideration to minimize their impact while still providing value.Why do you need to be careful about third-party scripts?They can be a performance concernThey can be a privacy concernThey might be a security concernThey can be unpredictable and change without you knowingThey can have unintended consequencesIdeally, you’ll want to ensure third-party script is not impacting the critical rendering path. In this guide, we’ll walk through how to find and fix issues related to loading third-party JavaScript.What do we mean by third-party scripts? #Third-party JavaScript often refers to scripts that can be embedded into any site directly from a third-party vendor. These scripts can include ads, analytics, widgets and other scripts that make the web more dynamic and interactive.Examples of third-party scripts include:Social sharing buttons (Twitter, Facebook, G+)Video player embeds (YouTube, Vimeo)Advertising iframesAnalytics & metrics scriptsA/B testing scripts for experimentsHelper libraries (such as date formatting, animation, or functional libraries)<iframe width=""560"" height=""315"" src=""https://www.youtube.com/embed/mo8thg5XGV0"" frameborder=""0"" allow=""autoplay; encrypted-media"" allowfullscreen></iframe> One example of this is the YouTube video player embed script that allows you to embed a video into your page.Unfortunately, embedding third-party scripts means we often rely on them to be fast in order to avoid slowing our pages down. Third-party scripts are a predominant cause of performance slowdowns and are often caused by resources outside of your control.These issues can include:Firing too many network requests to multiple servers. The more requests a site has to make, the longer it can take to load.Sending too much JavaScript that keeps the main thread busy. Too much JavaScript can block DOM construction, delaying how quickly pages can render. CPU-intensive script parsing and execution can delay user interaction and cause battery drain.Sending large, unoptimized image files or videos. This can consume data and cost users money.Third-party scripts loaded without care can be a single-point of failure (SPOF)Insufficient HTTP caching, forcing resources to be fetched from the network oftenLack of sufficient server compression of resourcesBlocking content display until they complete processing. This can also be true for async A/B testing scripts.Use of legacy APIs (e.g document.write()) known to be harmful to the user experienceExcessive DOM elements or expensive CSS selectors.Including multiple third-party embeds can lead to multiple frameworks and libraries being pulled in several times. This is wasteful and exacerbates the performance issues.Third-party scripts often use embed techniques that can block window.onload if their servers respond slowly, even if the embed is using async or defer.Context is important and the solution to costly third-parties can depend on your site and your ability to configure how you load third-party code. Thankfully, a number of solutions and tools exist to find and fix issues with third-party resources.How do you identify third-party script on a page? #Unless you’re aware which third-party scripts are loaded by your site and what their performance impact is, it’s impossible to know how to optimize them. Many free web speed test tools can highlight costly third-parties including Chrome DevTools, PageSpeed Insights and WebPageTest. These tools display rich diagnostic information that can tell you how many third-party scripts your site is loading, and which take the most time to execute.WebPageTest’s waterfall view can highlight the impact of heavy third-party script use. Below is an example of the requests required to load the main content for a site vs. the tracking and marketing scripts (credit: Tags Gone Wild).WebPageTest’s domain breakdown can also be useful for visualizing how much content comes from third-party origins. It breaks this down by both total bytes and the number of requests:When you see a problematic script, figure out what the script does and ask yourself whether the script is really that necessary. Do an A/B test to balance the perceived value versus its impact on key user engagement or performance metrics.How do I measure the impact of third-party script on my page? #Lighthouse Boot-up Time Audit #The Lighthouse JavaScript boot-up time audit highlights scripts that have a costly script parse, compile or evaluation time. This can be useful for discovering CPU-intensive third-party scripts.Lighthouse Network Payloads Audit #The Lighthouse Network Payloads audit identifies network requests (including those from third-parties) that may slow down page load time. Avoiding these requests or highlighting their cost to ad-networks can save users money they would have spent on cellular data.Chrome DevTools Network Request Blocking #Chrome DevTools allows you to see how your page behaves when a particular script, stylesheet or other resource isn’t available. This is done with network request blocking, a feature that can help measure the impact of blocking (dropping) specific third-party resources from your page.To enable request blocking, right click on any request in the Network panel and select ""Block Request URL"". A Request blocking tab will display in the DevTools drawer, letting you manage which requests have been blocked.Chrome DevTools Performance Panel #The Performance panel in Chrome DevTools helps identify issues with your page’s web performance. Clicking the record button and loading your page presents you with a waterfall representing where your site is spending time. At the bottom of the Performance panel, you will see a drawer starting with ""Summary"". Navigate to the “Bottom-up” tab.Here, you can use the ""Group by product"" option in the Bottom-Up tab to group third-parties by the time they spent. This helps identify which third-party products were the most costly. The Network panel also supports an option to highlight requests by product.To learn more about how to analyze page load performance with the Chrome DevTools, see Get started with analyzing runtime performance.A good workflow for measuring the impact of third-party scripts is:Measure how long it takes to load your page using the Network panel. To emulate real-world conditions, we recommend turning on network throttling and CPU throttling. On faster connections and desktop hardware, the impact of expensive scripts may not be as representative as it would on a mobile phone.Block the URLs or domains responsible for third-party scripts you believe are an issue (see Chrome DevTools Performance Panel for identifying costly scripts).Reload the page and re-measure how long the page takes without loading these blocked third-party scripts. You should hopefully see an improvement. There may be value in doing 3 or more runs of measurement and looking at the median for more stable figures. As third-party content can occasionally pull in different resources per page load, this could give you a more realistic spread. DevTools now supports multiple recordings in the performance panel, making this a little easier.Measuring impact of Third-Party tags with WebPageTest #WebPageTest supports blocking individual requests from loading (which can be useful for blocking content like ads and third-party embeds) to measure their impact.Under ""Advanced Settings"" is a Block tab. This can be used to specify a list of domains to block, simulating what it would be like if they didn't load at all.A workflow for using this feature is to:Test a page as normalRepeat the test with certain third-parties blockedCompare the two results (paying attention to the filmstrip). Results can be compared by selecting them from your Test History and clicking ‘Compare’.Below we can see the difference between filmstrips both with and without third-party resources blocked. It can be useful to try this out for individual third-party origins to determine which ones have the biggest impact on your page-load performance:The impact of blocking third-party resources on a page using WPT’s ""block requests"" feature from “Using WebPageTest To Measure The Impact Of Third-Party Tags” by Andy DaviesWebPageTest also supports two commands operating at the DNS level for blocking domains. blockDomainswhich takes a list of domains to block and blockDomainsExcepttakes a list of domains and blocks anything not on the list.WebPageTest also has a single-point of failure (SPOF) tab. This allows you to simulate a timeout or complete failure to load a resource.The difference between ""SPOF"" and ""Block"" is that SPOF slowly times out. This can make it useful for testing network resilience of third-party content to determine how well your pages hold up when services are under heavy load or temporarily unavailable.Detecting expensive iframes using Long Tasks #When scripts in third-party iframes take a long time to run, they can block the main thread delaying other tasks from running. These long tasks can cause a negative user experience leading to sluggish event handlers or dropped frames.To detect long tasks for Real User Monitoring (RUM), we can use the JavaScript PerformanceObserver API and observe longtask entries. As these entries contain an attribution property, we can track down which frame context was responsible for the task.Below is an example that will log longtask entries to the console, including one for an ""expensive"" iframe:<script> const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) {  // Attribution entry including ""containerSrc"":""https://example.com""  console.log(JSON.stringify(entry.attribution)); } }); observer.observe({entryTypes: ['longtask']});</script><!-- Imagine this is an iframe with expensive long tasks --><iframe src=""https://example.com""></iframe> To learn more about monitoring Long Tasks, read Phil Walton’s User-centric Performance Metrics.How do you load third-party script efficiently? #If a third-party script is slowing down your page load, you have several options to improve performance:Load the script using the async or defer attribute to avoid blocking document parsing.Consider self-hosting the script if the third-party server is slow.Consider removing the script if it doesn't add clear value to your site.Consider Resource Hints like &LTlink rel=preconnect> or &LTlink rel=dns-prefetch> to perform a DNS lookup for domains hosting third-party scripts.Use async or defer #JavaScript execution is parser blocking. This means when the browser encounters a script it must pause DOM construction, hand this over to the JavaScript engine and allow script execution before proceeding with DOM construction.The async and defer attributes change this behavior.With async, the browser downloads the script asynchronously while it continues to parse the HTML document. When the script finishes downloading, parsing is blocked while the script executes.With defer, the browser downloads the script asynchronously while it continues to parse the HTML document. The script doesn't run until the parsing is complete.If that's too many words, here's a pretty picture:Credit: Growing with the webIn general, you should always use async or defer for third-party scripts (unless the script does something necessary for the critical rendering path):Use async if it's important to have the script run earlier in the loading process. This might include some analytics scripts, for example.Use defer for less critical resources. A video player that's below-the-fold, for example.If performance is your primary concern, you could wait until your page has reached a key user moment (such as after the critical content has loaded) before adding async scripts. You should also take care not to async load libraries like jQuery just because they are coming from a third-party CDN.In Blink-based browsers, async and defer currently lower the priority of the network request for resources so it can cause it to load significantly later than it would as a blocking script. This is useful to know in particular for analytics scripts.Should you ever load third-party scripts without async or defer? You could make a case for this if the script is a crucial part of your site functionality. For example, if you're loading your main UI library or framework from a CDN, it will be badged as ""third-party script"" in DevTools, but should be treated as an essential part of your site, not an add-on.Note that not all scripts work if loaded asynchronously. Check the docs for any third-party scripts you're using. If you're using a script that can't be loaded asynchronously, you might want to consider an alternative, or eliminating the script if possible. Some third parties may highly recommend to load their scripts sync (to get ahead of other scripts), even if they would work fine async so do due diligence when evaluating strategies for loading third-party scripts.async is not a silver bullet. If a marketing team wants to load a large number of tracking scripts on a page, this number will still introduce bottlenecks that can impact how soon users can engage with a page on load.Use Resource Hints to reduce connection setup time #Establishing connections to third-party origins can take a significant amount of time - particularly on slow networks. Many steps can add up to delays including DNS lookups, redirects, and potentially several round trips to each third-party server to handle the request.You can use Resource Hints like to perform a DNS lookup for domains hosting third-party scripts. When the request for them is finally made, time can be saved as the DNS lookup has already been carried out.<link rel=""dns-prefetch"" href=""http://example.com"" /> If the third-party domain you are referencing uses HTTPS, you may also consider as this will both perform the DNS lookup and resolve TCP round-trips and handle TLS negotiations. These other steps can be very slow as they involve looking at SSL certificates for verification, so consider Resource Hints seriously if you find third-party setup time to be an issue.<link rel=""preconnect"" href=""https://cdn.example.com"" /> ""Sandbox"" scripts with an iframe #There are cases where third-party scripts can be loaded directly into an iframe. By restricting such scripts to iframes, they won’t block execution of the main page. This is the same approach that AMP takes to keeping JavaScript out of the critical path. Note that this approach will still block the onload event so try not to attach critical functionality to onload.Chrome also supports Permissions Policy (formerly Feature Policy) - a set of policies which allow a developer to selectively disable access to certain browser features. This can prevent third-party content introducing unwanted behaviors to a site.Self-host third-party scripts #Self-hosting third-party scripts may be an option if you would like more control over a script’s loading story. For example, if you wanted to reduce DNS or round-trip times, or improve HTTP caching headers. Self-hosting may be a viable consideration if a script is considered critical.Self-hosting can come with a number of big caveats:Scripts can go out of date. This can be a large issue as it prevents you from getting important security fixes without manually updating.Scripts that are self-hosted won’t get automatic updates due to an API change. One example: a publisher with 90% of their revenue from ads discovers that ads didn’t serve for half a day due to an API change that their self-hosted script didn’t account for, leading to loss in income.An alternative to self-hosting scripts would be using Service Workers to cache them. This can give you greater control over how often they are re-fetched from the network. This could also be used to create a loading strategy where requests for non-essential third parties are throttled until the page reaches a key user moment.A/B Test smaller samples of users #A/B testing (or split-testing) is a technique for experimenting with two versions of a page to determine which one performs best. This is done by enabling both variants (A and B) for different samples of your website traffic. The page that provides a better conversion rate wins.A/B testing is a very useful tool for analyzing user experience and behavior.However, by design, A/B testing delays rendering to figure out which experiment needs to be active. JavaScript is often used to check if any of your users belong to an A/B test experiment and then enable the correct variant. This pattern can lead to 100% of your users being sent down large, costly script even if they don’t belong to the sample receiving the experiment.A good alternative in this case is to send A/B testing scripts for only a subset of your user base (e.g 10% vs 100%), ideally attempting to decide whether they belong in a test sample on the server-side. This improves the loading experience for the majority of users while still making split-testing possible.Lazy load Third-Party Resources #Embedded third-party resources (such as ads or videos) can be a big contributor to slow page speed when constructed poorly. Lazy loading can be used to only load embedded resources when necessary. For example, serving an ad in the footer only when a user scrolls down the page. Another pattern is lazy loading content after the main page content loads but before a user might otherwise interact with the page.LazySizes is a popular JavaScript library for lazy loading images andiframes. It supports YouTube embeds andwidgets. Care does need to be taken when lazy loading any resources as this technique is often powered by JavaScript and can be subject to issues on flaky network connections.DoubleClick have guidance on how to lazy-load ads in their official documentation. If used properly, lazy loading can increase the overall viewability percentage of an ad. For example, Mediavine switched tolazy-loading ads and saw a 200% improvement in page load speed.Efficient lazy loading with Intersection Observer #Historically, solutions for detecting if an element is visible in the viewport (in order to lazy-load its content) have been error-prone, often causing the browser to become sluggish. Solutions have often listened for scroll or resize events, then used DOM APIs like getBoundingClientRect() to calculate where elements are relative to the viewport. This works, but is not efficient.IntersectionObserver is a browser API that allows us to efficiently detect when an observed element enters or exits the browser's viewport. Learn more about how to use it for lazy loading resources. LazySizes also hasoptional support for IntersectionObserver.Analytics can be complicated #Analytics scripts should never slow down your page load experience, but if you defer the load too long you can miss valuable analytics data. Fortunately, there are some well-known patterns for initializing analytics lazily while retaining early page-load data.Phil Walton's blog post, The Google Analytics Setup I Use on Every Site I Build covers one such pattern for Google Analytics.What patterns should I avoid with third-party script? #Avoid document.write() #Third-party scripts sometimes use document.write() to inject and load scripts. This is particularly true of older services that haven’t been updated in some time. Thankfully, many third-parties offer an option to asynchronously load themselves, which allows third-party scripts to load without blocking the display of the rest of the content on the page.The fix for document.write() is to simply not inject scripts using it. As of Chrome 53, Chrome DevTools will log warnings to the console for problematic use of document.write():To discover the use of document.write() at scale, you can check for HTTP headers sent to your browser when this intervention for Chrome happens. Lighthouse can also highlight any third-party scripts still using document.write() in the Lighthouse report:Use Tag Managers but use them wisely #Exercise caution when using GTM. Although it can minimize the overhead of third-party tags, it also makes it trivial for anyone with credentials to add costly tags.A ""tag"" is a snippet of code that allows digital marketing teams to collect data, set cookies or integrate third-party content like social media widgets into a site. These tags have a cost to your page's loading performance - additional network requests, heavy JavaScript dependencies, images and resources the tag itself may pull in.Managing these tags can become a real mess over time as marketing teams wish to add more ways to understand users and engineering tries to minimize the impact tags can have on user experience. To keep experiences fast, we recommend using a Tag manager. Tag managers:allow many pieces of third-party embed code to be managed from a single place (usually a user-interface)attempt to minimize how much third-party tags need to be deployed to sites.Even though individual tags can be asynchronously loaded, they still need to be read and executed individually. This could mean requesting more data while the page is still loading. Tag managers address this by reducing the number of calls a browser needs to make for them down to one.Google Tag Manager (GTM) is one such popular tag manager:""Google Tag Manager is an asynchronous tag, meaning that when it executes, it does not block other elements from rendering on the page. It also causes the other tags that are deployed via Google Tag Manager to be deployed asynchronously, meaning that a slow loading tag won’t block other tracking tags.""Tag managers may improve page load performance by reducing how many calls to external resources are needed - as long as you are not pulling in a large number of tags. They also allow tags a way to collect values in a single unique place. For GTM, this is the Data Layer. If multiple third parties wish to trigger conversion-tracking data, they can do this by pulling from the Data Layer.Risks when using Tag managersWhen using a tag manager, great care needs to be taken to avoid slowing down how quickly pages load. This is because:Anyone with credentials and access can easily add not just more tags, but any JavaScript they want. Although tag managers can load tags asynchronously, this can still lead to an excess of costly HTTP requests being made and executed. This can be minimized by only allowing one user to publish versions.Anyone can configure too many tag manager auto-event listeners. Every auto-event listener needs to be executed & the more code and network requests there are, the longer it can take for a page to fully load. With our performance guidance encouraging that you respond to events within 50ms, every tag manager event listener added eats away at that goal.Avoid scripts that pollute the global scope #Third-party scripts injected into the unknown can sometimes load a number of their own JavaScript dependencies. This can pollute the global scope and cause accidental breakage in pages.There is also no guarantee that code loaded from a third-party will remain the same as what you saw during testing. New features can be pushed out by third parties at any time, potentially breaking your page. Self-testing, sub-resource integrity and securely transmitting third-party code (to reduce the risk of in-transit modifications) can help here.Be sure to conduct careful audits of the third-party scripts you load to ensure they’re being good actors.Mitigation strategies #Adding third-party scripts to a page implies a level of trust in the origin. There are some strategies you can take to minimize their impact on performance and security:HTTPS is a must. Sites working over HTTPS shouldn’t have third-parties working over HTTP. An HTTPS page that includes content fetched using HTTP is called a mixed content page and will run into Mixed Content warnings.Consider the sandbox attribute on iframes. From a security perspective, this allows you to restrict the actions available from the iframe. Restrictions include allow-scriptscontrolling whether the context can run scripts.Consider Content Security Policy (CSP). Through a HTTP header in your server’s response, you can define behaviors that are trusted in the page. CSP can be used to detect and mitigate against the effects of certain attacks, such as Cross Site Scripting (XSS).CSP is particularly powerful as it includes directives such as script-src that specifies what are valid, allowed sources for JavaScript. Below is an example of how this can be used in practice:// Given this CSP header Content-Security-Policy: script-srchttps://example.com/ // The following third-party script will not be loaded orexecuted<script src=""https://not-example.com/js/library.js""></script> Conclusion #With sites relying on more third-party scripts than ever, it’s paramount not to ignore third-party script performance. Good things you can do:Become familiar with some of the most effective third-party script optimization methods like only loading tags that support the async loading pattern.Understand how to identify and fix issues with third-party script loading. This can help you take back control of your page load performance.Third-party script optimization should be followed by on-going real-time performance monitoring of your scripts and communication with your third-party providers. The web is evolving at a rapid pace and a script’s locally observed performance gives no guarantees that it will perform as well in the future or in the wild.Further reading #Performance and Resilience: Stress-Testing Third PartiesAdding interactivity with JavaScriptPotential dangers with Third-party ScriptsHow 3rd Party Scripts can be performant citizens on the webWhy Fast Matters - CSS WizardryThe JavaScript Supply Chain Paradox: SRI, CSP and Trust in Third Party LibrariesThird-party CSS isn't safeWith thanks to Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick and Cheney Tsai for their reviews.Last updated Feb 25, 2023 — Improve article Share We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.Contribute File a bug View source Related content developer.chrome.com Chrome updates Case studies Podcasts Shows Connect Twitter YouTube Chrome Firebase Google Cloud Platform All products Dark theme Terms & Privacy Community Guidelines Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. By Chrome DevRel URL of this webpage is: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascript/"
+53,developer.chrome.commainthread work breakdown.txt,"developer.chrome.commainthread work breakdown.txt. Minimize main thread work - Chrome DevelopersSkip to content  Home Docs Blog Articles  Home Docs Blog Articles Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsHow the Lighthouse main thread work audit failsHow to minimize main thread workScript evaluationStyle and layoutRenderingParsing HTML and CSSScript parsing and compilationGarbage collectionResourcesThanks for tuning in to Google I/O. Watch the Chrome content on-demand. Watch now. DismissDocumentation Lighthouse Performance Audits Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsHow the Lighthouse main thread work audit failsHow to minimize main thread workScript evaluationStyle and layoutRenderingParsing HTML and CSSScript parsing and compilationGarbage collectionResourcesMinimize main thread workPublished on Thursday, May 2, 2019 • Updated on Friday, October 4, 2019 Translated to: Português, PусскийTable of contents How the Lighthouse main thread work audit failsHow to minimize main thread workScript evaluationStyle and layoutRenderingParsing HTML and CSSScript parsing and compilationGarbage collectionResourcesThe browser's renderer process is what turns your code into a web page that your users can interact with. By default, the main thread of the renderer process typically handles most code: it parses the HTML and builds the DOM, parses the CSS and applies the specified styles, and parses, evaluates, and executes the JavaScript.The main thread also processes user events. So, any time the main thread is busy doing something else, your web page may not respond to user interactions, leading to a bad experience.# How the Lighthouse main thread work audit failsLighthouse flags pages that keep the main thread busy for longer than 4 seconds during load:To help you identify the sources of main thread load, Lighthouse shows a breakdown of where CPU time was spent while the browser loaded your page.See the Lighthouse performance scoring post to learn how your page's overall performance score is calculated.# How to minimize main thread workThe sections below are organized based on the categories that Lighthouse reports. See The anatomy of a frame for an overview of how Chromium renders web pages.See Do less main thread work to learn how to use Chrome DevTools to investigate exactly what your main thread is doing as the page loads.# Script evaluationOptimize third-party JavaScriptDebounce your input handlersUse web workers# Style and layoutReduce the scope and complexity of style calculationsAvoid large, complex layouts and layout thrashing# RenderingStick to compositor only properties and manage layer countSimplify paint complexity and reduce paint areas# Parsing HTML and CSSExtract critical CSSMinify CSSDefer non-critical CSS# Script parsing and compilationReduce JavaScript payloads with code splittingRemove unused code# Garbage collectionMonitor your web page's total memory usage with measureMemory()# ResourcesSource code for Minimize main thread work auditMain thread (MDN)Inside look at modern web browser (part 3)Updated on Friday, October 4, 2019 • Improve article Table of contentsHow the Lighthouse main thread work audit failsHow to minimize main thread workScript evaluationStyle and layoutRenderingParsing HTML and CSSScript parsing and compilationGarbage collectionResourcesFollow us Contribute File a bug View source Related content web.dev Case studies Podcasts Connect Twitter YouTube GitHub Chrome Firebase All products Privacy TermsContent available under the CC-BY-SA-4.0 licenseThis site uses cookies to deliver and enhance the quality of its services and to analyze traffic. If you agree, cookies are also used to serve advertising and to personalize the content and advertisements that you see. Learn more about our use of cookies. Agree No Thanks URL of this webpage is: https://developer.chrome.com/docs/lighthouse/performance/mainthread-work-breakdown"
+54,dequeuniversity.comlist.txt,"dequeuniversity.comlist.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    <ul> and <ol> must only directly contain <li>, <script> or <template> elements Rule ID: list Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Accessibility testing for dev teams - No experience required  Find and fix up to 80% of accessibility issues with axe DevTools Pro. Get started with your free trial today. No credit card needed.   Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]1.3.1: MUST: Info and RelationshipsWCAG Success Criteria [WCAG 2.0 (A)]1.3.1: MUST: Info and Relationships  How to Fix the Problem  Ensure all ordered and unordered lists (defined by ul or ol elements) contain only li content elements. Here is a list, using proper semantic markup: <p> These are a few of my favorite things</p> <ul>  <li>Raindrops on roses</li>  <li>Whiskers on kittens</li>  <li>Bright copper kettles</li>  <li>Warm woolen mittens</li>  <li>Brown paper packages tied up with strings</li>  <li>Cream colored ponies</li>  <li>Crisp apple streudels</li>  <li>Doorbells and sleigh bells</li>  <li>Schnitzel with noodles</li>  <li>Wild geese that fly with the moon on their wings</li>  <li>Girls in white dresses with blue satin sashes</li>  <li>Snowflakes that stay on my nose and eyelashes</li>  <li>Silver white winters that melt into springs</li> </ul> Why it Matters  Screen readers have a specific way of announcing lists. This feature makes lists clearer to understand, but will only work if lists are properly structured.  When content elements other than list items are contained within a set of list elements, screen readers cannot inform the listener that they are listening to items within the list.  For a list to be valid, it must have both parent elements (a set of ul elements or a set of ol elements) and child elements (declared inside of these tags using the li element), and any other content elements are invalid.  Although some non-content elements such as script, template, style, meta, link, map, area, and datalist are permitted within lists, content elements other than li are not permitted. Rule Description  Lists must be marked up correctly, meaning they must not contain content elements other than li elements. The Algorithm (in simple terms) Ensures that lists are structured correctly. Resources Deque University Deque University Course Pages (subscription required) Lists  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. H48: Using ol, ul and dl for lists or groups of links Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/list"
+55,dequeuniversity.comaria roles.txt,"dequeuniversity.comaria roles.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    ARIA roles used must conform to valid values Rule ID: aria-roles Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Need accessibility training?  Deque University offers an extensive curriculum of self-guided online courses for every skillset and experience level.  Start learning today   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, Value  How to Fix the Problem  Ensure all values assigned to role="""" correspond to valid ARIA roles. Available roles by type are: Landmark: article, banner, complementary, main, navigation,  region, search, contentinfo  Widget: alert, alertdialog, application, dialog, group,  log, marquee, menu, menubar, menuitem, menuitemcheckbox, menuitemradio,  progressbar, separator, slider, spinbutton, status, tab, tablist, tabpanel,  timer, toolbar, tooltip, tree, treegrid, treeitem  Pseudo HTML: button, button, checkbox, columnheader,  combobox, contentinfo, form, grid, gridcell, heading, img, link, listbox,  listitem, option, radio, radiogroup, row, rowgroup, rowheader, scrollbar,  textbox  Document: document (when creating a document region inside  an other type of region)  Application: application (only around a widget to enable  normal keyboard shortcuts for page content)  Presentation: presentation (to cancel the native role of  the element) Other Semantic: math, definition, note, directory Abstract: command, composite, input, landmark, range,  section, sectionhead, select, structure, widget  Why it Matters  Elements assigned invalid ARIA role values are not interpreted by assistive technology as intended by the developer.  When screen readers and other assistive technologies do not know the role of each element on the web page, they are not able to interact with it intelligently, nor are they able to communicate the role to the user. An element's features, properties, and methods of conveying information to and/or from the user can't be communicated via assistive technologies when a role value is invalid. Rule Description  Values assigned to ARIA role values must be valid. Role values must be spelled correctly, correspond to existing ARIA role values, and must not be abstract roles to correctly expose the purpose of the element. The Algorithm (in simple terms)  Checks all elements that contain the WAI-ARIA role attribute to ensure that the role value is valid  Resources Deque University Deque University Course Pages (subscription required) Landmark RolesWidget RolesPseudo HTML RolesThe Document RoleThe Application RoleThe Presentation RoleThe Math RoleThe Definition RoleThe Note RoleThe Directory RoleAbstract Roles  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. WAI-ARIA RolesAccessibility Support: HTML role attribute test suite Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-roles"
+56,web.dev.txt,"web.dev.txt. Cumulative Layout Shift (CLS)Skip to content Open menu  About Blog Learn Explore Patterns Case studies Close Thanks for tuning in to Google I/O. Watch the Chrome content on-demand.On this page What is CLS?What is a good CLS score?Layout shifts in detailLayout shift scoreImpact fractionDistance fractionExpected vs. unexpected layout shiftsHow to measure CLSField toolsLab toolsMeasure layout shifts in JavaScriptMeasure CLS in JavaScriptHow to improve CLSAdditional resourcesCHANGELOG Cumulative Layout Shift (CLS)Jun 11, 2019 — Updated Apr 12, 2023 Available in: English, Español, Português, Русский, 中文, 日本語, and 한국어 Appears in: Fast load times | Core Web Vitals | Metrics Philip Walton TwitterGitHubHomepage Milica Mihajlija TwitterGitHubHomepageOn this page What is CLS?What is a good CLS score?Layout shifts in detailLayout shift scoreImpact fractionDistance fractionExpected vs. unexpected layout shiftsHow to measure CLSField toolsLab toolsMeasure layout shifts in JavaScriptMeasure CLS in JavaScriptHow to improve CLSAdditional resourcesCHANGELOGBrowser support Chrome 77, Supported 77 Firefox, Not supported Edge 79, Supported 79 Safari, Not supported SourceKey TermCumulative Layout Shift (CLS) is a stable Core Web Vital metric. It is an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts—a low CLS helps ensure that the page is delightful.Have you ever been reading an article online when something suddenly changes on the page? Without warning, the text moves, and you've lost your place. Or even worse: you're about to tap a link or a button, but in the instant before your finger lands—BOOM—the link moves, and you end up clicking something else!Most of the time these kinds of experiences are just annoying, but in some cases, they can cause real damage. A screencast illustrating how layout instability can negatively affect users.Unexpected movement of page content usually happens because resources are loaded asynchronously or DOM elements get dynamically added to the page above existing content. The culprit might be an image or video with unknown dimensions, a font that renders larger or smaller than its fallback, or a third-party ad or widget that dynamically resizes itself.What makes this issue even more problematic is that how a site functions in development is often quite different from how users experience it. Personalized or third-party content often doesn't behave the same in development as it does in production, test images are often already in the developer's browser cache, and API calls that run locally are often so fast that the delay isn't noticeable.The Cumulative Layout Shift (CLS) metric helps you address this problem by measuring how often it's occurring for real users.What is CLS? #CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifespan of a page.A layout shift occurs any time a visible element changes its position from one rendered frame to the next. (See below for details on how individual layout shift scores are calculated.)A burst of layout shifts, known as a session window, is when one or more individual layout shifts occur in rapid succession with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.The largest burst is the session window with the maximum cumulative score of all layout shifts within that window. Example of session windows. Blue bars represent the scores of each individual layout shift.CautionPreviously CLS measured the sum total of all individual layout shift scores that occurred during the entire lifespan of the page. To see which tools still provide the ability to benchmark against the original implementation, check out Evolving Cumulative Layout Shift in web tooling.What is a good CLS score? #To provide a good user experience, sites should strive to have a CLS score of 0.1 or less. To ensure you're hitting this target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.To learn more about the research and methodology behind this recommendation, see: Defining the Core Web Vitals metrics thresholdsLayout shifts in detail #Layout shifts are defined by the Layout Instability API, which reports layout-shift entries any time an element that is visible within the viewport changes its start position (for example, its top and left position in the default writing mode) between two frames. Such elements are considered unstable elements.Note that layout shifts only occur when existing elements change their start position. If a new element is added to the DOM or an existing element changes size, it doesn't count as a layout shift—as long as the change doesn't cause other visible elements to change their start position.Layout shift score #To calculate the layout shift score, the browser looks at the viewport size and the movement of unstable elements in the viewport between two rendered frames. The layout shift score is a product of two measures of that movement: the impact fraction and the distance fraction (both defined below).layout shift score = impact fraction * distance fraction Impact fraction #The impact fraction measures how unstable elements impact the viewport area between two frames.The union of the visible areas of all unstable elements for the previous frame and the current frame—as a fraction of the total area of the viewport—is the impact fraction for the current frame.In the image above there's an element that takes up half of the viewport in one frame. Then, in the next frame, the element shifts down by 25% of the viewport height. The red, dotted rectangle indicates the union of the element's visible area in both frames, which, in this case, is 75% of the total viewport, so its impact fraction is 0.75.Distance fraction #The other part of the layout shift score equation measures the distance that unstable elements have moved, relative to the viewport. The distance fraction is the greatest distance any unstable element has moved in the frame (either horizontally or vertically) divided by the viewport's largest dimension (width or height, whichever is greater).In the example above, the largest viewport dimension is the height, and the unstable element has moved by 25% of the viewport height, which makes the distance fraction 0.25.So, in this example the impact fraction is 0.75 and the distance fraction is 0.25, so the layout shift score is 0.75 * 0.25 = 0.1875.Initially, the layout shift score was calculated based only on impact fraction. The distance fraction was introduced to avoid overly penalizing cases where large elements shift by a small amount.The next example illustrates how adding content to an existing element affects the layout shift score:The ""Click Me!"" button is appended to the bottom of the gray box with black text, which pushes the green box with white text down (and partially out of the viewport).In this example, the gray box changes size, but its start position does not change so it's not an unstable element.The ""Click Me!"" button was not previously in the DOM, so its start position doesn't change either.The start position of the green box, however, does change, but since it's been moved partially out of the viewport, the invisible area is not considered when calculating the impact fraction. The union of the visible areas for the green box in both frames (illustrated by the red, dotted rectangle) is the same as the area of the green box in the first frame—50% of the viewport. The impact fraction is 0.5.The distance fraction is illustrated with the purple arrow. The green box has moved down by about 14% of the viewport so the distance fraction is 0.14.The layout shift score is 0.5 x 0.14 = 0.07.This last example illustrates multiple unstable elements:In the first frame above there are four results of an API request for animals, sorted in alphabetical order. In the second frame, more results are added to the sorted list.The first item in the list (""Cat"") does not change its start position between frames, so it's stable. Similarly, the new items added to the list were not previously in the DOM, so their start positions don't change either. But the items labelled ""Dog"", ""Horse"", and ""Zebra"" all shift their start positions, making them unstable elements.Again, the red, dotted rectangles represent the union of these three unstable elements' before and after areas, which in this case is around 60% of the viewport's area (impact fraction of 0.60).The arrows represent the distances that unstable elements have moved from their starting positions. The ""Zebra"" element, represented by the blue arrow, has moved the most, by about 30% of the viewport height. That makes the distance fraction in this example 0.3.The layout shift score is 0.60 x 0.3 = 0.18.Expected vs. unexpected layout shifts #Not all layout shifts are bad. In fact, many dynamic web applications frequently change the start position of elements on the page.User-initiated layout shifts #A layout shift is only bad if the user isn't expecting it. On the other hand, layout shifts that occur in response to user interactions (clicking a link, pressing a button, typing in a search box and similar) are generally fine, as long as the shift occurs close enough to the interaction that the relationship is clear to the user.For example, if a user interaction triggers a network request that may take a while to complete, it's best to create some space right away and show a loading indicator to avoid an unpleasant layout shift when the request completes. If the user doesn't realize something is loading, or doesn't have a sense of when the resource will be ready, they may try to click something else while waiting—something that could move out from under them.Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations.CautionThe hadRecentInput flag will only be true for discrete input events like tap, click, or keypress. Continuous interactions such as scrolls, drags, or pinch and zoom gestures are not considered ""recent input"". See the Layout Instability Spec for more details.Animations and transitions #Animations and transitions, when done well, are a great way to update content on the page without surprising the user. Content that shifts abruptly and unexpectedly on the page almost always creates a bad user experience. But content that moves gradually and naturally from one position to the next can often help the user better understand what's going on, and guide them between state changes.Be sure to respect prefers-reduced-motion browser settings, as some site visitors can experience ill effects or attention issues from animation.CSS transform property allows you to animate elements without triggering layout shifts:Instead of changing the height and width properties, use transform: scale().To move elements around, avoid changing the top, right, bottom, or left properties and use transform: translate() instead.How to measure CLS #CLS can be measured in the lab or in the field, and it's available in the following tools:CautionLab tools typically load pages in a synthetic environment and are thus only able to measure layout shifts that occur during page load. As a result, CLS values reported by lab tools for a given page may be less than what real users experience in the field.Field tools #Chrome User Experience ReportPageSpeed InsightsSearch Console (Core Web Vitals report)web-vitals JavaScript libraryLab tools #Chrome DevToolsLighthousePageSpeed InsightsWebPageTestMeasure layout shifts in JavaScript #To measure layout shifts in JavaScript, you use the Layout Instability API.The following example shows how to create a PerformanceObserver to log layout-shift entries to the console:new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log('Layout shift:', entry); }}).observe({type: 'layout-shift', buffered: true}); Measure CLS in JavaScript #To measure CLS in JavaScript, you need to group these unexpected layout-shift entries into sessions, and calculate the maximum session value. You can refer to the web vitals JavaScript library source code which contains a reference implementation on how CLS is calculated.In most cases, the current CLS value at the time the page is being unloaded is the final CLS value for that page, but there are a few important exceptions as noted in the next section. The web vitals JavaScript library accounts for these as much as possible, within the limitations of the Web APIs.Differences between the metric and the API #If a page is loaded in the background, or if it's backgrounded prior to the browser painting any content, then it should not report any CLS value.If a page is restored from the back/forward cache, its CLS value should be reset to zero since users experience this as a distinct page visit.The API does not report layout-shift entries for shifts that occur within iframes but the metric does as they are part of the user experience of the page. This can show as a difference between CrUX and RUM. To properly measure CLS you should consider them. Sub-frames can use the API to report their layout-shift entries to the parent frame for aggregation.In addition to these exceptions, CLS has some added complexity due to the fact that it measures the entire lifespan of a page:Users might keep a tab open for a very long time—days, weeks, months. In fact, a user might never close a tab.On mobile operating systems, browsers typically do not run page unload callbacks for background tabs, making it difficult to report the ""final"" value.To handle such cases, CLS should be reported any time a page is background—in addition to any time it's unloaded (the visibilitychange event covers both of these scenarios). And analytics systems receiving this data will then need to calculate the final CLS value on the backend.Rather than memorizing and grappling with all of these cases yourself, developers can use the web-vitals JavaScript library to measure CLS, which accounts for everything mentioned above:import {onCLS} from 'web-vitals';// Measure and log CLS in all situations// where it needs to be reported.onCLS(console.log); In some cases (such as cross-origin iframes) it's not possible to measure CLS in JavaScript. See the limitations section of the web-vitals library for details.How to improve CLS #A full guide on optimizing CLS is available to guide you through the process of identifying layout shifts in the field and using lab data to drill down and optimize them.Additional resources #Google Publisher Tag's guidance on minimizing layout shiftUnderstanding Cumulative Layout Shift by Annie Sullivan and Steve Kobes at #PerfMatters (2020)CHANGELOG #Occasionally, bugs are discovered in the APIs used to measure metrics, and sometimes in the definitions of the metrics themselves. As a result, changes must sometimes be made, and these changes can show up as improvements or regressions in your internal reports and dashboards.To help you manage this, all changes to either the implementation or definition of these metrics will be surfaced in this CHANGELOG.If you have feedback for these metrics, you can provide it in the web-vitals-feedback Google group.PerformanceMetricsWeb VitalsLast updated Apr 12, 2023 — Improve article Return to all articles Share We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.Contribute File a bug View source Related content developer.chrome.com Chrome updates Case studies Podcasts Shows Connect Twitter YouTube Chrome Firebase Google Cloud Platform All products Dark theme Terms & Privacy Community Guidelines Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. By Chrome DevRel URL of this webpage is: https://web.dev/cls/"
+57,hpbn.co analyzing the resource w.txt,"hpbn.co analyzing the resource w.txt.  HTTP: Primer on Web Performance - High Performance Browser Networking (O'Reilly)       Menu High Performance Browser   Networking  |  O'Reilly    Primer on Web Performance     Table of Contents About the Author     Submit Feedback   Primer on Web Performance HTTP, Chapter 10  Introduction In any complex system, a large part of the performance optimization  process is the untangling of the interactions between the many distinct  and separate layers of the system, each with its own set of constraints  and limitations. So far, we have examined a number of individual  networking components in close detail—different physical delivery methods  and transport protocols—and now we can turn our attention to the larger,  end-to-end picture of web performance optimization:   Impact of latency and bandwidth on web performance   Transport protocol (TCP) constraints imposed on HTTP   Features and shortcomings of the HTTP protocol itself   Web application trends and performance requirements   Browser constraints and optimizations  Optimizing the interaction among all the different layers is not  unlike solving a family of equations, each dependent on the others, but  nonetheless yielding many possible solutions. There is no one fixed set  of recommendations or best practices, and the individual components  continue to evolve: browsers are getting faster, user connectivity  profiles change, and web applications continue to grow in their scope,  ambition, and complexity.  Hence, before we dive into enumerating and analyzing individual  performance best practices, it is important to step back and define what  the problem really is: what a modern web application is, what tools we  have at our disposal, how we measure web-performance, and which parts of  the system are helping and hindering our progress.  §Hypertext, Web Pages, and Web Applications The evolution of the Web over the course of the last few decades has  given us at least three different classes of experience: the hypertext  document, rich media web page, and interactive web application.  Admittedly, the line between the latter two may at times be blurry to the  user, but from a performance point of view, each requires a very  different approach to our conversation, metrics, and the definition of  performance.   Hypertext document   Hypertext documents were the genesis of the World Wide Web, the   plain text version with some basic formatting and support for   hyperlinks. This may not sound exciting by modern standards, but it   proved the premise, vision, and the great utility of the World Wide   Web.   Web page   The HTML working group and the early browser vendors extended the   definition of hypertext to support additional hypermedia resources,   such as images and audio, and added many other primitives for richer   layouts. The era of the web page has arrived, allowing us to   produce rich visual layouts with various media types: visually   beautiful but mostly non-interactive, not unlike a printed page.   Web application   Addition of JavaScript and later revolutions of Dynamic HTML   (DHTML) and AJAX shook things up once more and transformed the simple   web page into an interactive web application, which allowed   it to respond to the user directly within the browser. This paved the   way for the first full-fledged browser applications, such as Outlook   Web Access (originator of XMLHTTP support in IE5), ushering in a new   era of complex dependency graphs of scripts, stylesheets, and markup.  An HTTP 0.9 session consisted of a single document request, which was  perfectly sufficient for delivery of hypertext: single document, one TCP  connection, followed by connection close. Consequently, tuning for  performance was as simple as optimizing for a single HTTP request over a  short-lived TCP connection.  The advent of the web page changed the formula from delivery  of a single document to the document plus its dependent resources.  Consequently, HTTP/1.0 introduced the notion of HTTP metadata (headers),  and HTTP/1.1 enhanced it with a variety of performance-oriented  primitives, such as well-defined caching, keepalive, and more. Hence,  multiple TCP connections are now potentially at play, and the key  performance metric has shifted from document load time to  page load time, which is commonly abbreviated as PLT.   The simplest definition of PLT is ""the time until the loading   spinner stops spinning in the browser."" A more technical definition is   time to onload event in the browser, which is an event fired by the   browser once the document and all of its dependent resources   (JavaScript, images, etc.) have finished loading.  Finally, the web application transformed the simple web page, which  used media as an enhancement to the primary content in the markup, into a  complex dependency graph: markup defines the basic structure, stylesheets  define the layout, and scripts build up the resulting interactive  application and respond to user input, potentially modifying both styles  and markup in the process.  Consequently, page load time, which has been the de facto metric of  the web performance world, is also an increasingly insufficient  performance benchmark: we are no longer building pages, we are building  dynamic and interactive web applications. Instead of, or in addition to,  measuring the time to load each and every resource (PLT), we are now  interested in answering application-specific questions:   What are the milestones in the loading progress of the   application?   What are the times to first interaction by the user?   What are the interactions the user should engage in?   What are the engagement and conversion rates for each user?  The success of your performance and optimization strategy is directly  correlated to your ability to define and iterate on application-specific  benchmarks and criteria. Nothing beats application-specific knowledge and  measurements, especially when linked to bottom-line goals and metrics of  your business.   §DOM, CSSOM, and JavaScript What exactly do we mean by ""complex dependency graph of scripts,   stylesheets, and markup"" found in a modern web application? To answer   this question, we need to take a quick detour into browser architecture   and investigate how the parsing, layout, and scripting pipelines have   to come together to paint the pixels to the screen.    Figure 10-1. Browser processing    pipeline: HTML, CSS, and JavaScript    The parsing of the HTML document is what constructs the Document   Object Model (DOM). In parallel, there is an oft-forgotten cousin, the   CSS Object Model (CSSOM), which is constructed from the specified   stylesheet rules and resources. The two are then combined to create the   ""render tree,"" at which point the browser has enough information to   perform a layout and paint something to the screen. So far, so good.   However, this is where we must, unfortunately, introduce our   favorite friend and foe: JavaScript. Script execution can issue a   synchronous doc.write and block DOM parsing and   construction. Similarly, scripts can query for a computed style of any   object, which means that JavaScript can also block on CSS.   Consequently, the construction of DOM and CSSOM objects is frequently   intertwined: DOM construction cannot proceed until JavaScript is   executed, and JavaScript execution cannot proceed until CSSOM is   available.   The performance of your application, especially the first load and   the ""time to render"" depends directly on how this dependency graph   between markup, stylesheets, and JavaScript is resolved. Incidentally,   recall the popular ""styles at the top, scripts at the bottom"" best   practice? Now you know why! Rendering and script execution are blocked   on stylesheets; get the CSS down to the user as quickly as you can.   §Anatomy of a  Modern Web Application What does a modern web application look like after all? HTTP Archive can help us answer this  question. The project tracks how the Web is built by periodically  crawling the most popular sites (300,000+ from Alexa Top 1M) and  recording and aggregating analytics on the number of used resources,  content types, headers, and other metadata for each individual  destination.  An average web application, as of early 2013, is composed of the  following:   90 requests, fetched from 15 hosts, with 1,311 KB total transfer   size    HTML: 10 requests, 52 KB    Images: 55 requests, 812 KB    JavaScript: 15 requests, 216 KB    CSS: 5 requests, 36 KB    Other: 5 requests, 195 KB    By the time you read this, the preceding numbers have already changed  and have grown even larger (Figure 10-2); the upward climb has been a stable  and reliable trend with no signs of stopping. However, exact request and  kilobyte count aside, it is the order of magnitude of these individual  components that warrants some careful contemplation: an average web  application is now well over 1 MB in size and is composed of roughly 100  sub-resources delivered from over 15 different hosts!   Figure 10-2. Average transfer size and   number of requests (HTTP Archive)   Unlike their desktop counterparts, web applications do not require a  separate installation process: type in the URL, hit Enter, and we are up  and running! However, desktop applications pay the installation cost just  once, whereas web applications are running the ""installation process"" on  each and every visit—resource downloads, DOM and CSSOM construction, and  JavaScript execution. No wonder web performance is such a fast-growing  field and a hot topic of discussion! Hundreds of resources, megabytes of  data, dozens of different hosts, all of which must come together in  hundreds of milliseconds to facilitate the desired instant web  experience.   §Speed,   Performance, and Human Perception Speed and performance are relative terms. Each application dictates   its own set of requirements based on business criteria, context, user   expectations, and the complexity of the task that must be performed.   Having said that, if the application must react and respond to a user,   then we must plan and design for specific, user-centric perceptual   processing time constants. Despite the ever-accelerating pace of   life, or at least the feeling of it, our reaction times remain constant   (Table 10-1),   regardless of type of application (online or offline), or medium   (laptop, desktop, or mobile device).    Delay     User perception    0–100 ms     Instant     100–300 ms     Small perceptible delay     300–1000 ms     Machine is working     1,000+ ms     Likely mental context switch     10,000+ ms     Task is abandoned    Table 10-1. Time and user perception    The preceding table helps explain the unofficial rule of thumb in   the web performance community: render pages, or at the very least   provide visual feedback, in under 250 milliseconds to keep the user   engaged!   For an application to feel instant, a perceptible response to user   input must be provided within hundreds of milliseconds. After a second   or more, the user’s flow and engagement with the initiated task is   broken, and after 10 seconds have passed, unless progress feedback is   provided, the task is frequently abandoned.   Now, add up the network latency of a DNS lookup, followed by a TCP   handshake, and another few roundtrips for a typical web page request,   and much, if not all, of our 100–1,000 millisecond latency budget can   be easily spent on just the networking overhead; see Figure 8-2.   No wonder so many users, especially when on a mobile or a wireless   network, are demanding faster web browsing performance!   Jakob Nielsen’s Usability Engineering and Steven Seow’s   Designing and Engineering Time are both excellent resources   that every developer and designer should read! Time is measured   objectively but perceived subjectively, and experiences can be   engineered to improve perceived performance.   §Translating Web Performance to Dollars and Cents Speed is a feature, and it is not simply speed for speed’s sake.   Well-publicized studies from Google, Microsoft, and Amazon all show   that web performance translates directly to dollars and cents—e.g., a   2,000 ms delay on Bing search pages decreased per-user revenue by   4.3%!   Similarly, an Aberdeen study of over 160 organizations determined   that an extra one-second delay in page load times led to 7%   loss in conversions, 11% fewer page views, and a 16% decrease in   customer satisfaction!   Faster sites yield more page views, higher engagement, and higher   conversion rates. However, don’t just take our word for it, or put   your faith into well-cited industry benchmarks: measure the impact of   web performance on your own site, and against your own conversion   metrics. If you’re wondering how, then keep reading, or skip ahead to   Synthetic and   Real-User Performance Measurement.   §Analyzing the   Resource Waterfall No discussion on web performance is complete without a mention of   the resource waterfall. In fact, the resource waterfall is likely the   single most insightful network performance and diagnostics tool at our   disposal. Every browser provides some instrumentation to see the   resource waterfall, and there are great online tools, such as WebPageTest, which can render it   online for a wide variety of different browsers.   WebPageTest.org is an open-source project and a free web service   that provides a system for testing the performance of web pages from   multiple locations around the world: the browser runs within a   virtual machine and can be configured and scripted with a variety of   connection and browser-oriented settings. Following the test, the   results are then available through a web interface, which makes   WebPageTest an indispensable power tool in your web performance   toolkit.   To start, it is important to recognize that every HTTP request is   composed of a number of separate stages (Figure 10-3): DNS resolution, TCP   connection handshake, TLS negotiation (if required), dispatch of the   HTTP request, followed by content download. The visual display of these   individual stages may differ slightly within each browser, but to keep   things simple, we will use the WebPageTest version in this chapter.   Make sure to familiarize yourself with the meaning of each color in   your favorite browser.    Figure 10-3. Components of an HTTP    request (WebPageTest)    Close analysis of Figure 10-3 shows that the Yahoo!   homepage took 683 ms to download, and over 200 ms of that time was   spent waiting on the network, which amounts to 30% of total latency of   the request! However, the document request is only the beginning since,   as we know, a modern web application also needs a wide variety of   resources (Figure 10-4) to produce the final output.   To be exact, to load the Yahoo! homepage, the browser will require 52   resources, fetched from 30 different hosts, all adding up to 486 KB in   total.   The resource waterfall reveals a number of important insights about   the structure of the page and the browser processing pipeline. First   off, notice that while the content of the www.yahoo.com   document is being fetched, new HTTP requests are being dispatched: HTML   parsing is performed incrementally, allowing the browser to discover   required resources early and dispatch the necessary requests in   parallel. Hence, the scheduling of when the resource is fetched is in   large part determined by the structure of the markup. The browser may   reprioritize some requests, but the incremental discovery of each   resource in the document is what creates the distinct resource   ""waterfall effect.""   Second, notice that the ""Start Render"" (green vertical line) occurs   well before all the resources are fully loaded, allowing the user to   begin interacting with the page while the page is being built. In fact,   the ""Document Complete"" event (blue vertical line), also fires early   and well before the remaining assets are loaded. In other words, the   browser spinner has stopped spinning, the user is able to continue with   his task, but the Yahoo! homepage is progressively filling in   additional content, such as advertising and social widgets, in the   background.    Figure 10-4. Yahoo.com resource    waterfall (WebPageTest, March 2013)    The difference between the first render time, document complete, and   the time to finish fetching the last resource in the preceding example   is a great illustration of the necessary context when discussing   different web performance metrics. Which of those three metrics is the   right one to track? There is no one single answer; each application is   different! Yahoo! engineers have chosen to optimize the page to take   advantage of incremental loading to allow the user to begin consuming   the important content earlier, and in doing so they had to apply   application-specific knowledge about which content is critical and   which can be filled in later.   Different browsers implement different logic for when, and in   which order, the individual resource requests are dispatched. As a   result, the performance of the application will vary from browser to   browser.   Tip: WebPageTest allows you to select both the location and the   make and version of the browser when running the test!   The network waterfall is a power tool that can help reveal the   chosen optimizations, or lack thereof, for any page or application. The   previous process of analyzing and optimizing the resource waterfall is   often referred to as front-end performance analysis and   optimization. However, the name may be an unfortunate choice, as it   misleads many to believe that all performance bottlenecks are now on   the client. In reality, while JavaScript, CSS, and rendering pipelines   are critical and resource-intensive steps, the server response times   and network latency (""back-end performance"") are no less critical for   optimizing the resource waterfall. After all, you can’t parse or   execute a resource that is blocked on the network!   To illustrate this in action, we only have to switch from the   resource waterfall to the connection view   (Figure 10-5) provided by WebPageTest.   Unlike the resource waterfall, where each record represents an   individual HTTP request, the connection view shows the life of each TCP   connection—all 30 of them in this case—used to fetch the resources for   the Yahoo! homepage. Does anything stand out? Notice that the download   time, indicated in blue, is but a small fraction of the total latency   of each connection: there are 15 DNS lookups, 30 TCP handshakes, and a   lot of network latency (indicated in green) while waiting to receive   the first byte of each response.    Figure 10-5. Yahoo.com connection view    (WebPageTest, March 2013)    Wondering why some requests are showing the green bar (time to   first byte) only? Many responses are very small, and consequently the   download time does not register on the diagram. In fact, for many   requests, response times are often dominated by the roundtrip latency   and server processing times.   Finally, we have saved the best for last. The real surprise   to many is found at the bottom of the connection view: examine the   bandwidth utilization chart in Figure 10-5. With the exception of a   few short data bursts, the utilization of the available connection is   very low—it appears that we are not limited by bandwidth of our   connection! Is this an anomaly, or worse, a browser bug? Unfortunately,   it is neither. Turns out, bandwidth is not the limiting performance   factor for most web applications. Instead, the bottleneck is the   network roundtrip latency between the client and the server.   §Performance Pillars: Computing, Rendering, Networking The execution of a web program primarily involves three tasks:  fetching resources, page layout and rendering, and JavaScript execution.  The rendering and scripting steps follow a single-threaded, interleaved  model of execution; it is not possible to perform concurrent  modifications of the resulting Document Object Model (DOM). Hence,  optimizing how the rendering and script execution runtimes work together,  as we saw in DOM,  CSSOM, and JavaScript, is of critical importance.  However, optimizing JavaScript execution and rendering pipelines also  won’t do much good if the browser is blocked on the network, waiting for  the resources to arrive. Fast and efficient delivery of network resources  is the performance keystone of each and every application running in the  browser.  But, one might ask, Internet speeds are getting faster by the day, so  won’t this problem solve itself? Yes, our applications are growing  larger, but if the global average speed is already at 3.1 Mbps  (Bandwidth  at the Network Edge) and growing, as evidenced by ubiquitous  advertising by every ISP and mobile carrier, why bother, right?  Unfortunately, as you might intuit, and as the Yahoo! example shows, if  that were the case then you wouldn’t be reading this book. Let’s take a  closer look.   For a detailed discussion of the trends and interplay of bandwidth   and latency, refer back to the ""Primer on Latency and Bandwidth"" in   Primer on   Latency and Bandwidth.   §More Bandwidth   Doesn’t Matter (Much) Hold your horses; of course bandwidth matters! After all, every   commercial by our local ISP and mobile carrier continues to remind us   of its many benefits: faster downloads, uploads, and streaming, all at   up to speeds of [insert latest number here] Mbps!   Access to higher bandwidth data rates is always good, especially for   cases that involve bulk data transfers: video and audio streaming or   any other type of large data transfer. However, when it comes to   everyday web browsing, which requires fetching hundreds of relatively   small resources from dozens of different hosts, roundtrip latency is   the limiting factor:   Streaming an HD video from the Yahoo! homepage is bandwidth    limited.    Loading and rendering the Yahoo! homepage is latency limited.   Depending on the quality and the encoding of the video you are   trying to stream, you may need anywhere from a few hundred Kbps to   several Mbps in bandwidth capacity—e.g., 3+ Mbps for an HD 1080p video   stream. This data rate is now within reach for many users, which is   evidenced by the growing popularity of streaming video services such as   Netflix. Why, then, would downloading a much, much smaller web   application be such a challenge for a connection capable of streaming   an HD movie?   §Latency as a   Performance Bottleneck We have already covered all the necessary topics in preceding   chapters to make a good qualitative theory as to why latency may be the   limiting factor for everyday web browsing. However, a picture is worth   a thousand words, so let’s examine the results of a quantitative study   performed by Mike Belshe (Figure 10-6), one of the creators of   the SPDY protocol, on the impact of varying bandwidth vs. latency on   the page load times of some of the most popular destinations on the   Web.    Figure 10-6. Page load time vs.    bandwidth and latency    This study by Mike Belshe served as a launching point for the   development of the SPDY protocol at Google, which later became the   foundation of the HTTP/2 protocol.   In the first test, the connection latency is held fixed, and the   connection bandwidth is incrementally increased from 1 Mbps up to 10   Mbps. Notice that at first, upgrading the connection from 1 to 2 Mbps   nearly halves the page loading time—exactly the result we want to see.   However, following that, each incremental improvement in bandwidth   yields diminishing returns. By the time the available bandwidth exceeds   5 Mbps, we are looking at single-digit percent improvements, and   upgrading from 5 Mbps to 10 Mbps results in a mere 5% improvement in   page loading times!   Akamai’s broadband speed report (Bandwidth   at the Network Edge) shows that an average consumer in the United   States is already accessing the Web with 5 Mbps+ of available   bandwidth—a number that many other countries are quickly approaching or   have surpassed already. Ergo, we are led to conclude that an average   consumer in the United States would not benefit much from   upgrading the available bandwidth of her connection if she is   interested in improving her web browsing speeds. She may be able to   stream or upload larger media files more quickly, but the pages   containing those files will not load noticeably faster: bandwidth   doesn’t matter, much.   However, the latency experiment tells an entirely different story:   for every 20 millisecond improvement in latency, we have a linear   improvement in page loading times! Perhaps it is latency we should be   optimizing for when deciding on an ISP, and not just bandwidth?   To speed up the Internet at large, we should look for more ways to   bring down RTT. What if we could reduce cross-atlantic RTTs from 150   ms to 100 ms? This would have a larger effect on the speed of the   internet than increasing a user’s bandwidth from 3.9 Mbps to 10 Mbps   or even 1 Gbps.   Another approach to reducing page load times would be to reduce   the number of round trips required per page load. Today, web pages   require a certain amount of back and forth between the client and   server. The number of round trips is largely due to the handshakes to   start communicating between client and server (e.g., DNS, TCP, HTTP),   and also round trips induced by the communication protocols (e.g.,   TCP slow start). If we can improve protocols to transfer this data   with fewer round trips, we should also be able to improve page load   times. This is one of the goals of SPDY.   Mike Belshe, More Bandwidth Doesn't   Matter (Much) The previous results are a surprise to many, but they really should   not be, as they are a direct consequence of the performance   characteristics of the underlying protocols: TCP handshakes, flow and   congestion control, and head-of-line blocking due to packet loss. Most   of the HTTP data flows consist of small, bursty data transfers, whereas   TCP is optimized for long-lived connections and bulk data transfers.   Network roundtrip time is the limiting factor in TCP throughput and   performance in most cases; see Optimizing for TCP.   Consequently, latency is also the performance bottleneck for HTTP and   most web applications delivered over it.   If latency is the limiting performance factor for most wired   connections then, as you might intuit, it is an even more important   performance bottleneck for wireless clients: wireless latencies are   significantly higher, making networking optimization a critical   priority for the mobile web.    §Synthetic and Real-User Performance Measurement If we can measure it, we can improve it. The question is, are we  measuring the right criteria, and is the process sound? As we noted  earlier, measuring the performance of a modern web application is a  nontrivial challenge: there is no one single metric that holds true for  every application, which means that we must carefully define custom  metrics in each case. Then, once the criteria are established, we must  gather the performance data, which should be done through a combination  of synthetic and real-user performance measurement.  Broadly speaking, synthetic testing refers to any process with a  controlled measurement environment: a local build process running through  a performance suite, load testing against staging infrastructure, or a  set of geo-distributed monitoring servers that periodically perform a set  of scripted actions and log the outcomes. Each and every one of these  tests may test a different piece of the infrastructure (e.g., application  server throughput, database performance, DNS timing, and so on), and  serves as a stable baseline to help detect regressions or narrow in on a  specific component of the system.   When configured well, synthetic testing provides a controlled and   reproducible performance testing environment, which makes it a great   fit for identifying and fixing performance regressions before they   reach the user. Tip: identify your key performance metrics and set a   ""budget"" for each one as part of your synthetic testing. If the budget   is exceeded, raise an alarm!  However, synthetic testing is not sufficient to identify all  performance bottlenecks. Specifically, the problem is that the gathered  measurements are not representative of the wide diversity of the  real-world factors that will determine the final user experience with the  application. Some contributing factors to this gap include the following:   Scenario and page selection: replicating real user navigation   patterns is hard.   Browser cache: performance may vary widely based on the state of   the user’s cache.   Intermediaries: performance may vary based on intermediate proxies   and caches.   Diversity of hardware: wide range of CPU, GPU, and memory   performance.   Diversity of browsers: wide range of browser versions, both old   and new.   Connectivity: continuously changing bandwidth and latency of real   connections.  The combination of these and similar factors means that in addition to  synthetic testing, we must augment our performance strategy with  real-user measurement (RUM) to capture actual performance of our  application as experienced by the user. The good news is the W3C Web  Performance Working Group has made this part of our data-gathering  process a simple one by introducing the Navigation Timing API  (Figure 10-7),  which is now supported across many of the modern desktop and mobile  browsers.   Figure 10-7. User-specific performance   timers exposed by Navigation Timing   As of early 2013, Navigation Timing is supported by IE9+, Chrome 6+,   and Firefox 7+ across desktop and mobile platforms. The notable   omissions are the Safari and Opera browsers. For the latest status, see   caniuse.com/nav-timing.  The real benefit of Navigation Timing is that it exposes a lot of  previously inaccessible data, such as DNS and TCP connect times, with  high precision (microsecond timestamps), via a standardized  performance.timing object in each browser. Hence, the data  gathering process is very simple: load the page, grab the timing object  from the user’s browser, and beacon it back to your analytics servers! By  capturing this data, we can observe real-world performance of our  applications as seen by real users, on real hardware, and across a wide  variety of different networks.   §Analyzing   Real User Measurement Data When analyzing performance data, always look at the underlying   distribution of the data: throw away the averages and focus on the   histograms, medians, and quantiles. Averages lead to meaningless   metrics when analyzing skewed and multimodal distributions.   Figure 10-8 shows a   hands-on, real-world example of both types of distributions on a single   site: skewed distribution for the page load time and a multimodal   distribution for the server response time (the two modes are due to   cached vs. uncached page generation time by the application server).    Figure 10-8. Page load time (skewed) and    response time (multimodal) distributions for igvita.com    Ensure that your analytics tool can provide the right statistical   metrics for your performance data. The preceding data was taken from   Google Analytics, which provides a histogram view within the standard   Site Speed reports. Google Analytics automatically gathers Navigation   Timing data when the analytics tracker is installed. Similarly, there   are a wide variety of other analytics vendors who offer Navigation   Timing data gathering and reporting.  Finally, in addition to Navigation Timing, the W3C Performance Group  also standardized two other APIs: User Timing and Resource Timing.  Whereas Navigation Timing provides performance timers for root documents  only, Resource Timing provides similar performance data for each resource  on the page, allowing us to gather the full performance profile of the  page. Similarly, User Timing provides a simple JavaScript API to mark and  measure application-specific performance metrics with the help of the  same high-resolution timers:   function init() { performance.mark(""startTask1""); applicationCode1(); performance.mark(""endTask1""); logPerformance(); } function logPerformance() { var perfEntries = performance.getEntriesByType(""mark""); for (var i = 0; i < perfEntries.length; i++) {  console.log(""Name: "" + perfEntries[i].name +     "" Entry Type: "" + perfEntries[i].entryType +     "" Start Time: "" + perfEntries[i].startTime +     "" Duration: "" + perfEntries[i].duration + ""\n""); } console.log(performance.timing); }  Store (mark) timestamp with associated name (startTask1).    Execute application code.    Iterate and log user timing data.    Log Navigation Timing object for current page.   The combination of Navigation, Resource, and User timing APIs provides  all the necessary tools to instrument and conduct real-user performance  measurement for every web application; there is no longer any excuse not  to do it right. We optimize what we measure, and RUM and synthetic  testing are complementary approaches to help you identify regressions and  real-world bottlenecks in the performance and the user experience of your  applications.   Custom and application-specific metrics are the key to establishing   a sound performance strategy. There is no generic way to measure or   define the quality of user experience. Instead, we must define and   instrument specific milestones and events in each application, a   process that requires collaboration between all the stakeholders in the   project: business owners, designers, and developers.   §Browser Optimization We would be remiss if we didn’t mention that a modern browser is much  more than a simple network socket manager. Performance is one of the  primary competitive features for each browser vendor, and given that the  networking performance is such a critical criteria, it should not  surprise you that the browsers are getting smarter every day:  pre-resolving likely DNS lookups, pre-connecting to likely destinations,  pre-fetching and prioritizing critical resources on the page, and more.  The exact list of performed optimizations will differ by browser  vendor, but at their core the optimizations can be grouped into two broad  classes:   Document-aware optimization   The networking stack is integrated with the document, CSS, and   JavaScript parsing pipelines to help identify and prioritize critical   network assets, dispatch them early, and get the page to an   interactive state as soon as possible. This is often done via   resource priority assignments, lookahead parsing, and similar   techniques.   Speculative optimization   The browser may learn user navigation patterns over time and   perform speculative optimizations in an attempt to predict the likely   user actions by pre-resolving DNS names, pre-connecting to likely   hostnames, and so on.  The good news is all of these optimizations are done automatically on  our behalf and often lead to hundreds of milliseconds of saved network  latency. Having said that, it is important to understand how and why  these optimizations work under the hood, because we can assist  the browser and help it do an even better job at accelerating our  applications. There are four techniques employed by most browsers:   Resource pre-fetching and prioritization   Document, CSS, and JavaScript parsers may communicate extra   information to the network stack to indicate the relative priority of   each resource: blocking resources required for first rendering are   given high priority, while low-priority requests may be temporarily   held back in a queue.   DNS pre-resolve   Likely hostnames are pre-resolved ahead of time to avoid DNS   latency on a future HTTP request. A pre-resolve may be triggered   through learned navigation history, a user action such as hovering   over a link, or other signals on the page.   TCP pre-connect   Following a DNS resolution, the browser may speculatively open the   TCP connection in an anticipation of an HTTP request. If it guesses   right, it can eliminate another full roundtrip (TCP handshake) of   network latency.   Page pre-rendering   Some browsers allow you to hint the likely next destination and   can pre-render the entire page in a hidden tab, such that it can be   instantly swapped in when the user initiates the navigation.   For a deep dive into how these and other networking optimizations   are implemented in Google Chrome, see High Performance Networking in   Google Chrome.  From the outside, a modern browser network stack presents itself as  simple resource-fetching mechanism, but from the inside, it is an  elaborate and a fascinating case study for how to optimize for web  performance. So how can we assist the browser in this quest? To start,  pay close attention to the structure and the delivery of each page:   Critical resources such as CSS and JavaScript should be   discoverable as early as possible in the document.   CSS should be delivered as early as possible to unblock rendering   and JavaScript execution.   Noncritical JavaScript should be deferred to avoid blocking DOM   and CSSOM construction.   The HTML document is parsed incrementally by the parser; hence the   document should be periodically flushed for best performance.  Further, aside from optimizing the structure of the page, we can also  embed additional hints into the document itself to tip off the browser  about additional optimizations it can perform on our behalf:   <link rel=""dns-prefetch"" href=""//hostname_to_resolve.com""> <link rel=""subresource"" href=""/javascript/myapp.js""> <link rel=""prefetch""  href=""/images/big.jpeg""> <link rel=""prerender"" href=""//example.org/next_page.html"">  Pre-resolve specified hostname.    Prefetch critical resource found later on this page.    Prefetch resource for this or future navigation.    Prerender specified page in anticipation of next user    destination.   Each of these is a hint for a speculative optimization. The browser  does not guarantee that it will act on it, but it may use the hint to  optimize its loading strategy. Unfortunately, not all browsers support  all hints (Table 10-2), but if they don’t, then the  hint is treated as a no-op and is harmless; make use of each of the  techniques just shown where possible.   Browser    dns-prefetch    subresource    prefetch    prerender    Firefox    3.5+    n/a    3.5+    n/a    Chrome    1.0+    1.0+    1.0+    13+    Safari    5.01+    n/a    n/a    n/a    IE    9+ (prefetch)    n/a    10+    11+   Table 10-2. Speculative browser   optimization hints   Internet Explorer 9 supports DNS pre-fetching, but calls it   prefetch. In Internet Explorer 10+, dns-prefetch and   prefetch are equivalent, resulting in a DNS pre-fetch in both   cases.  To most users and even web developers, the DNS, TCP, and SSL delays  are entirely transparent and are negotiated at network layers to which  few of us descend. And yet each of these steps is critical to the overall  user experience, since each extra network roundtrip can add tens or  hundreds of milliseconds of network latency. By helping the browser  anticipate these roundtrips, we can remove these bottlenecks and deliver  much faster and better web applications.   §Optimizing Time to First Byte (TTFB) for Google   Search The HTML document is parsed incrementally by the browser, which   means that the server can and should flush available document markup as   frequently as possible. This enables the client to discover and begin   fetching critical resources as soon as possible.   Google Search offers one of the best examples of the benefits of   this technique: when a search request arrives, the server immediately   flushes the static header of the search page prior to even analyzing   the query. After all, why should it wait, the header is the same for   every search page! Then, while the client is parsing the header markup,   the search query is dispatched to the search index, and the remainder   of the document, which includes the search results, is delivered to the   user once the results are ready. At this point, the dynamic parts of   the header, such as the name of the logged-in user, are filled in via   JavaScript.        « Back to the Table of Contents Copyright © 2013 Ilya Grigorik. Published by O'Reilly Media, Inc. Licensed under  CC BY-NC-ND  4.0.  URL of this webpage is: https://hpbn.co/primer-on-web-performance/#analyzing-the-resource-waterfall"
+58,developer.chrome.comcsp xss.txt,"developer.chrome.comcsp xss.txt. Ensure CSP is effective against XSS attacks - Chrome DevelopersSkip to content  Home Docs Blog Articles  Home Docs Blog Articles Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsRequired practices for a non-bypassable CSPCSP targets XSSCSP uses nonces or hashes to avoid allowlist bypassesAdditional recommendations for a secure CSPConfigure CSP reportingDefine the CSP in an HTTP headerEnsure CSP is backwards compatibleHow to develop a strict CSPThanks for tuning in to Google I/O. Watch the Chrome content on-demand. Watch now. DismissDocumentation Lighthouse Best Practices Audits Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsRequired practices for a non-bypassable CSPCSP targets XSSCSP uses nonces or hashes to avoid allowlist bypassesAdditional recommendations for a secure CSPConfigure CSP reportingDefine the CSP in an HTTP headerEnsure CSP is backwards compatibleHow to develop a strict CSPEnsure CSP is effective against XSS attacksPublished on Wednesday, June 16, 2021 Table of contents Required practices for a non-bypassable CSPCSP targets XSSCSP uses nonces or hashes to avoid allowlist bypassesAdditional recommendations for a secure CSPConfigure CSP reportingDefine the CSP in an HTTP headerEnsure CSP is backwards compatibleHow to develop a strict CSPA Content Security Policy (CSP) helps to ensure any content loaded in the page is trusted by the site owner. CSPs mitigate cross-site scripting (XSS) attacks because they can block unsafe scripts injected by attackers. However, the CSP can easily be bypassed if it is not strict enough. Check out Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP) for more information. Lighthouse collects CSPs enforced on the main document, and reports issues from CSP Evaluator if they can be bypassed.Lighthouse report warning that no CSP is found in enforcement mode.# Required practices for a non-bypassable CSPImplement the following practices to ensure that your CSP can't be bypassed. If the CSP can be bypassed, Lighthouse will emit a high severity warning.# CSP targets XSSTo target XSS, a CSP should include the script-src, object-src, and base-uri directives. The CSP should also be free of syntax errors.script-src and object-src secures a page from unsafe scripts and unsafe plugins respectively. Alternatively, default-src can be used to configure a broad policy in place of many directives including script-src and object-src.base-uri prevents the injection of unauthorized <base> tags which can be used to redirect all relative URLs (like scripts) to an attacker-controlled domain.# CSP uses nonces or hashes to avoid allowlist bypassesA CSP that configures an allowlist for script-src relies on the assumption that all responses coming from a trusted domain are safe, and can be executed as scripts. However, this assumption does not hold for modern applications; some common, benign patterns such as exposing JSONP interfaces and hosting copies of the AngularJS library allow attackers to escape the confines of CSP.In practice, while it may not be obvious to application authors, the majority of script-src allowlists can be circumvented by an attacker with an XSS bug, and provide little protection against script injection. In contrast, the nonce-based and hash-based approaches do not suffer from these problems and make it easier to adopt and maintain a more secure policy.For example, this code uses a JSONP endpoint hosted on a trusted domain to inject an attacker controlled script:CSP:script-src https://trusted.example.comHTML:<script src=""https://trusted.example.com/path/jsonp?callback=alert(document.domain)//""></script>To avoid being bypassed, a CSP should allow scripts individually using nonces or hashes and use 'strict-dynamic' instead of an allowlist.# Additional recommendations for a secure CSPImplement the following practices for added security and compatibility. If the CSP does not follow one of the recommendations, Lighthouse will emit a medium severity warning.# Configure CSP reportingConfiguring a reporting destination will help monitor for any breakages. You can set the reporting destination by using the report-uri or report-to directives. report-to is not currently supported by all modern browsers so it is recommended to use both or just report-uri.If any content violates the CSP, the browser will send a report to the configured destination. Make sure you have an application configured at this destination handling these reports.# Define the CSP in an HTTP headerA CSP can be defined in a meta tag like this:<meta http-equiv=""Content-Security-Policy"" content=""script-src 'none'"">However, you should define a CSP in an HTTP response header if you can. An injection before the meta tag will bypass the CSP. Additionally, frame-ancestors, sandbox and reporting are not supported in meta tag CSPs.# Ensure CSP is backwards compatibleNot all browsers support CSP nonces/hashes, therefore adding unsafe-inline as a fallback for non-compliant browsers is recommended. If the browser does support nonces/hashes, unsafe-inline will be ignored.Similarly, strict-dynamic is not supported by all browsers. It is recommended to set an allowlist as a fallback for any non-compliant browsers. The allowlist will be ignored in browsers that support strict-dynamic.# How to develop a strict CSPBelow is an example of using a strict CSP with a nonce-based policy.CSP:script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;object-src 'none';base-uri 'none';report-uri https://reporting.example.com;HTML:<script nonce=""random123"" src=""https://trusted.example.com/trusted_script.js""></script>random123 would be any base64 string generated server-side every time the page loads. unsafe-inline and https: are ignored in modern browsers because of the nonce and strict-dynamic. For more information about adopting a strict CSP, check out the Strict CSP guide.You can check a CSP for potential bypasses using Lighthouse and CSP Evaluator. If you want to test a new CSP without the risk of breaking existing pages, define the CSP in report-only mode by using Content-Security-Policy-Report-Only as the header name. This will send CSP violations to any reporting destinations you have configured with report-to and report-uri, but it will not actually enforce the CSP.Published on Wednesday, June 16, 2021 • Improve article Table of contentsRequired practices for a non-bypassable CSPCSP targets XSSCSP uses nonces or hashes to avoid allowlist bypassesAdditional recommendations for a secure CSPConfigure CSP reportingDefine the CSP in an HTTP headerEnsure CSP is backwards compatibleHow to develop a strict CSPFollow us Contribute File a bug View source Related content web.dev Case studies Podcasts Connect Twitter YouTube GitHub Chrome Firebase All products Privacy TermsContent available under the CC-BY-SA-4.0 licenseThis site uses cookies to deliver and enhance the quality of its services and to analyze traffic. If you agree, cookies are also used to serve advertising and to personalize the content and advertisements that you see. Learn more about our use of cookies. Agree No Thanks URL of this webpage is: https://developer.chrome.com/docs/lighthouse/best-practices/csp-xss"
+59,dequeuniversity.comaria required attr.txt,"dequeuniversity.comaria required attr.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Required ARIA attributes must be provided Rule ID: aria-required-attr Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)         Learn Web Accessibility   										Subscribe to our extensive curriculum of online self-paced courses 									 Learn More about Deque University   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, Value  How to Fix the Problem Add the missing ARIA state or property to the given element. For more information about which ARIA role, state, and property attributes are allowed by role, see Accessible Rich Internet Applications (WAI-ARIA) 1.1 - Supported States and  Properties.  Whether widget roles are mapped to platform accessibility API states, for access by assistive technologies, or are meant to be accessed directly from the DOM, any property or state attributes they require must be specified so that assistive technologies can convey the purpose of the element to users.  These properties and states apply to user interface objects like alert, alertdialog, menu, progressbar, tooltip, and other widgets. Properties aria-autocomplete aria-haspopup aria-label aria-level aria-multiline aria-multiselectable aria-orientation aria-readonly aria-required aria-sort aria-valuemax aria-valuemin aria-valuenow aria-valuetext States aria-checked aria-disabled aria-expanded aria-hidden aria-invalid aria-pressed aria-selected   For more information, see W3C WAI-ARIA 1.1  Required States and Properties  in Characteristics of Roles.   Why it Matters  ARIA widget roles require additional attributes that describe the state of the widget. The state of the widget is not communicated to screen reader users if a required attribute is omitted.  Certain roles act as composite user interface widgets. As such, they typically act as containers that manage other, contained widgets. When an object inherits from multiple ancestors and one ancestor indicates support for one property while another ancestor indicates that the same property is required, the property becomes required on the inheriting object. In some cases, default values are sufficient to meet ARIA attribute requirements.  When required state and property attributes for specific roles (and subclass roles) are not present, screen readers may not be able to convey the definition of what the element's role is to the users. Rule Description  ARIA widget roles must have appropriate attributes describing the state or properties of the widget. The Algorithm (in simple terms)  Checks all elements with the role attribute to ensure required attributes are defined.  Resources Deque University Deque University Course Pages (subscription required) OverviewValue  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. WAI-ARIA States and Properties Taxonomy Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-required-attr"
+60,dequeuniversity.comlistitem.txt,"dequeuniversity.comlistitem.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    <li> elements must be contained in a <ul> or <ol> Rule ID: listitem Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Need accessibility training?  Deque University offers an extensive curriculum of self-guided online courses for every skillset and experience level.  Start learning today   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deaf Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]1.3.1: MUST: Info and RelationshipsWCAG Success Criteria [WCAG 2.0 (A)]1.3.1: MUST: Info and Relationships  How to Fix the Problem  Ensure that all list item li elements are wrapped inside of ul or ol parent elements.  List items may be contained in either unordered (bullet) lists or ordered (sequentially numbered) lists.  Screen readers notify users when they come to a list, and tell them how many items are in a list. Announcing the number of list items and the current list item helps listeners know what they are listening to, and what to expect as they listen to it. Child list item elements must be contained within the appropriate parent list elements enabling screen readers to inform the listener that they are listening to a list. Bad example <li>Coffee</li> <li>Tea</li> <li>Milk</li> Good example <ul>  <li>Coffee</li>  <li>Tea</li>  <li>Milk</li> </ul> Why it Matters  For a list to be valid, it must have both parent and child elements. Parent elements can either be a set of ul tags or a set of ol tags. Child elements must be declared inside of these tags using the li tag.  Screen readers notify users when they come to a list, and tell them how many items are in a list. Announcing the number of items in a list and the current list item helps listeners know what they are listening to, and what to expect as they listen to it.  If you don't mark up a list using proper semantic markup in a hierarchy, list items cannot inform the listener that they are listening to a list when no parent is indicating the presence of a list and the type of list. Rule Description  All list items (li) must be contained within ul or ol parent elements. The Algorithm (in simple terms) Ensures li elements are used semantically. Resources Deque University Deque University Course Pages (subscription required) Lists  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. H48: Using ol, ul and dl for lists or groups of links Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/listitem"
+61,dequeuniversity.comlabel.txt,"dequeuniversity.comlabel.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Form elements must have labels Rule ID: label Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), Section 508     Accessibility testing for dev teams - No experience required  Find and fix up to 80% of accessibility issues with axe DevTools Pro. Get started with your free trial today. No credit card needed.   Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Low Vision Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A)Section 508 WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, ValueSection 508 Guidelines1194.22: MUST: Web based intranet and Internet Information & Applications1194.22 (n): MUST: When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.  How to Fix the Problem  Programmatically associate labels with all form controls. The recommended method for most circumstances is to use the label element and an explicit association using the for and id attributes. The examples here are ordered from the most common acceptable solution to the least common acceptable solution. <label for=""firstname"">First name:</label> <input type=""text"" id=""firstname""> The label can also be implicit by wrapping the <label> element around the input: <label>First name: <input type=""text""></label> If the input is already labeled visually some other way, such as through a magnifying glass icon on a search submit button, it may be acceptable to use aria-label to create an invisible text label for screen readers to read. <input type=""text"" aria-label=""Search""> An alternative method (sometimes used when adding a <label> tag would break functionality or styles, or when multiple labels apply to the same input), is to use aria-labelledby instead: <div id=""firstname"">First name:</div> <input type=""text"" aria-labelledby=""firstname""> <!--visual labels may be elsewhere in the content, such as in table headers--> <div id=""temperature"">Temperature:</div> <div id=""high"">High:</div> <div id=""low"">Low:</div> <!-- the inputs --> <input type=""text"" aria-labelledby=""temperature low""> <input type=""text"" aria-labelledby=""temperature high""> Lastly a placeholder attribute may be used to give text inputs an accessible name. This is not a recommended solution as the visual label (the placeholder text) will be removed once the user enters text into the input, causing them to not know what the input is for. <input type=""text"" placeholder=""Search""> Also ensure that all id elements are unique on each page, and that the label text makes sense to someone listening to them with a screen reader. Form elements that should have labels  Text entry fields, e.g. <input type=""text"">,  <input type=""password""> and <textarea> Radio buttons, <input type=""radio""> Checkboxes, <input type=""checkbox""> The only exceptions for this requirement are: Buttons - buttons are self-labeling  Hidden inputs - Inputs with the type attribute value of hidden (e.g.,  type=""hidden""). These inputs are hidden and  unavailable for user input. They therefore need no label.  When adding labels, be sure to avoid the following: First name: <input type=""text"" name=""fname""> This markup renders to produce a textbox with the words ""First name:"" next to it. Sighted users have no problem associating the text with the input field. Nevertheless, this connection is not as clear for non-sighted users, especially as forms grow longer and more complex. This ambiguity can make errors more likely, especially when the information required is more complex than a first name.  For detailed instructions on how to implement these various labelling methods, see the Automated Checks that run as a part of this rule.  Finally, ensure that each input element has only one label. Note that if any of your input elements have help text, be sure this text differs from the label element text. Why it Matters  Effective form labels are required to make forms accessible. The purpose of form elements such as checkboxes, radio buttons, input fields, etcetera, is often apparent to sighted users, even if the form element is not programmatically labeled. Screen readers users require useful form labels to identify form fields. Adding a label to all form elements eliminates ambiguity and contributes to a more accessible product.  When labels for form elements are absent, screen reader users do not know the input data expectations. Screen readers cannot programmatically determine information about input objects without an established label relationship (or redundant text serving as a label).  The absence of labels prevent fields from receiving focus when read by screen readers, and users with impaired motor control do not get the benefit of a larger clickable area for the control since clicking the label activates the control. Rule Description Each form element must have a programmatically associated label element. The Algorithm (in simple terms) Ensures that every form element has a programmatically associated label. Resources Deque University Deque University Course Pages (subscription required) LabelsGroup LabelsInstructions and Other Helpful InfoDynamic Forms and Custom WidgetsName  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. Labeling ControlsF68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined nameH44: Using label elements to associate text labels with form controlsARIA16: Using aria-labelledby to provide a name for user interface controlsARIA14: Using aria-label to provide an invisible label where a visible label cannot be usedH65: Using the title attribute to identify form controls when the label element cannot be used Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/label"
+62,dequeuniversity.commeta refresh.txt,"dequeuniversity.commeta refresh.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Delayed refresh under 20 hours must not be used Rule ID: meta-refresh Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Accessibility testing for dev teams - No experience required  Find and fix up to 80% of accessibility issues with axe DevTools Pro. Get started with your free trial today. No credit card needed.   Start for free   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]2.2.1: MUST: Timing AdjustableWCAG Success Criteria [WCAG 2.0 (A)]2.2.1: MUST: Timing Adjustable  How to Fix the Problem  Either remove the http-equiv=""refresh"" attribute from each meta element in which it is present or increase the refresh time to be greater than 20 hours.  To modify this example and make it accessible, remove the http-equiv=""refresh"" attribute from the meta element. Bad Example <meta http-equiv=""refresh"" content=""10"" url=""http://www.yourdomain.com/index.html"">  If the purpose of the <meta> element is to refresh the page, this should be handled through JavaScript. Furthermore, additional scripting should be used to provide users the ability to pause the refresh, extend the time between refreshes, or to turn the refresh off entirely.  For more information, see Timed Content in the Dynamic Content section of the HTML and CSS Accessibility course. Why it Matters  Since users do not expect a page to refresh automatically, such refreshing can be disorienting. Refreshing also moves the programmatic focus back to the top of the page, away from where the user had it. Such resetting is frustrating for users.  Redirection and page refresh through the use of the <meta> element is problematic for users with disabilities in many ways. The primary reason why redirects and refreshes are problematic is that the user has no control over when the redirect or refresh occurs. If the purpose of the <meta> element is to redirect the user to a new location, server-side means should be employed instead of client-side. Content that moves or auto-updates can be a barrier to anyone who has trouble reading the stationary text as quickly as well as to anyone who has trouble tracking moving objects. It can also cause problems for screen readers. Rule Description  The document must not use <meta http-equiv=""refresh""> with a refresh time of less than 20 hours because it can prevent control over when the refresh occurs for users with disabilities. The Algorithm (in simple terms)  Checks for the presence of the http-equiv=""refresh"" attribute on the meta elements with a content value less than 20 hours.  Resources Deque University Deque University Course Pages (subscription required) Time Limits  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. H76: Using meta refresh to create an instant client-side redirectF41: Failure of Success Criterion 2.2.1, 2.2.4, and 3.2.5 due to using meta refresh to reload the page Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/meta-refresh"
+63,dequeuniversity.comaria allowed attr.txt,"dequeuniversity.comaria allowed attr.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Elements must only use allowed ARIA attributes Rule ID: aria-allowed-attr Ruleset: axe-core 4.7 User Impact: Critical Guidelines: WCAG 2.1 (A), WCAG 2.0 (A)     Need accessibility training?  Deque University offers an extensive curriculum of self-guided online courses for every skillset and experience level.  Start learning today   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Critical▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A) WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, ValueWCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, Value  How to Fix the Problem  ARIA explicitly defines which attributes are allowed for any given role and for every attribute, where that attribute may be used. The detailed information on each attribute can be found by looking at the documentation for each role and/or each attribute. Specific Reference: For more information about which ARIA attributes may or should not be used by HTML element, see ARIA in HTML - Document conformance requirements for use of ARIA attributes  in HTML  and ARIA in HTML - Requirements for use of ARIA attributes to name elements  . General Reference: For general information about what ARIA can do, refer to the following external sources of information. ARIA is primarily to be used by web developers and programmers, because implementing ARIA usually requires JavaScript skills. Learning ARIA can also take a fair amount of time because of the complexities of the programming logic and also the nuances of ensuring that ARIA role-attribute combinations are valid. WAI-ARIA Overview   WAI-ARIA 1.1   WAI-ARIA Authoring Practices   Why it Matters  Using ARIA attributes in roles where they are not allowed can interfere with the accessibility of the web page. Using an invalid role-attribute combination will, at best, result in no effect on the accessibility of the application and, at worst, may trigger behavior that disables accessibility for entire portions of an application.  When ARIA attributes are used on HTML elements that are not in accordance with WAI-ARIA 1.1, they conflict with the semantics of the elements which can cause assistive technology products report nonsensical user interface (UI) information that does not represent the actual UI of the document. Rule Description  Not all ARIA role-attribute combinations are valid. This Rule checks that each role is supplied with allowed attributes. The Algorithm (in simple terms)  Checks that each element with an ARIA role uses only ARIA attributes allowed for that role.  Resources Deque University Deque University Course Pages (subscription required) Creating Landmarks (HTML5, ARIA)Web Accessibility, Part 9: Custom JavaScript/ARIA Widgets  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. Accessible Rich Internet Applications (WAI-ARIA) 1.1 - Taxonomy of States and PropertiesAccessible Rich Internet Applications (WAI-ARIA) 1.1 - The Roles Model Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/aria-allowed-attr"
+64,developer.chrome.comnon composited animations.txt,"developer.chrome.comnon composited animations.txt. Avoid non-composited animations - Chrome DevelopersSkip to content  Home Docs Blog Articles  Home Docs Blog Articles Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsBackgroundHow Lighthouse detects non-composited animationsHow to ensure animations are compositedResourcesThanks for tuning in to Google I/O. Watch the Chrome content on-demand. Watch now. DismissDocumentation Lighthouse Performance Audits Lighthouse Overview Performance audits Accessibility audits Best Practices audits SEO audits PWA audits Table of contentsBackgroundHow Lighthouse detects non-composited animationsHow to ensure animations are compositedResourcesAvoid non-composited animationsPublished on Wednesday, August 12, 2020 Translated to: Español, Português, 한국어, 中文, Pусский, 日本語Table of contents BackgroundHow Lighthouse detects non-composited animationsHow to ensure animations are compositedResourcesNon-composited animations can appear janky (not smooth) on low-end phones or when performance-heavy tasks are running on the main thread. Janky animations can increase the Cumulative Layout Shift (CLS) of your page. Reducing CLS will improve your Lighthouse Performance score.# BackgroundThe browser's algorithms for converting HTML, CSS, and JavaScript into pixels are collectively known as the rendering pipeline.The rendering pipeline.It's OK if you don't understand what each step of the rendering pipeline means. The key thing to understand right now is that at each step of the rendering pipeline the browser uses the result of the previous operation to create new data. For example, if your code does something that triggers Layout, the Paint and Composite steps need to run again. A non-composited animation is any animation that triggers one of the earlier steps in the rendering pipeline (Style, Layout, or Paint). Non-composited animations perform worse because they force the browser to do more work.Check out the following resources to learn about the rendering pipeline in-depth:Inside look at modern web browsers (part 3)Simplify paint complexity and reduce paint areasStick to compositor-only properties and manage layer count# How Lighthouse detects non-composited animationsWhen an animation can't be composited, Chrome reports the failure reasons to the DevTools trace, which is what Lighthouse reads. Lighthouse lists DOM nodes which have animations that were not composited along with the failure reason(s) for each animation.# How to ensure animations are compositedSee Stick to compositor-only properties and manage layer count and High-performance animations.# ResourcesSource code for the Avoid non-composited animations auditStick to compositor-only properties and manage layer countHigh-performance animationsSimplify paint complexity and reduce paint areasInside look at modern web browsers (part 3)Published on Wednesday, August 12, 2020 • Improve article Table of contentsBackgroundHow Lighthouse detects non-composited animationsHow to ensure animations are compositedResourcesFollow us Contribute File a bug View source Related content web.dev Case studies Podcasts Connect Twitter YouTube GitHub Chrome Firebase All products Privacy TermsContent available under the CC-BY-SA-4.0 licenseThis site uses cookies to deliver and enhance the quality of its services and to analyze traffic. If you agree, cookies are also used to serve advertising and to personalize the content and advertisements that you see. Learn more about our use of cookies. Agree No Thanks URL of this webpage is: https://developer.chrome.com/docs/lighthouse/performance/non-composited-animations"
+65,dequeuniversity.comlink name.txt,"dequeuniversity.comlink name.txt.    Axe Rules | Deque University | Deque Systems    Skip to content  Deque University  English日本語  Set Language    Links must have discernible text Rule ID: link-name Ruleset: axe-core 4.7 User Impact: Serious Guidelines: WCAG 2.1 (A), WCAG 2.0 (A), Section 508     Need accessibility training?  Deque University offers an extensive curriculum of self-guided online courses for every skillset and experience level.  Start learning today   Sign up for the axe newsletter Stay up to date on axe features, updates, and events. Newsletter Sign-up   Compliance Data & Impact User Impact Serious▼  Minor Critical  Disabilities Affected Blind Deafblind Mobility  Standard(s) WCAG 2.1 (A)WCAG 2.0 (A)Section 508 WCAG Success Criteria [WCAG 2.1 (A)]4.1.2: MUST: Name, Role, Value2.4.4: MUST: Link Purpose (In Context)WCAG Success Criteria [WCAG 2.0 (A)]4.1.2: MUST: Name, Role, Value2.4.4: MUST: Link Purpose (In Context)Section 508 Guidelines1194.22: MUST: Web based intranet and Internet Information & Applications1194.22 (a): MUST: A text equivalent for every non-text element shall be provided (e.g., via ""alt"", ""longdesc"", or in element content)  How to Fix the Problem   Ensure that all link names are accessible. It may be possible that the  inner link text is not visible to a screen reader, that there are  duplicate link labels, or that the link is not focusable.    Ensure all links can receive programmatic focus; for example, avoid  device-specific events (for example, onmouseover).    To ensure all link text is visible to screen readers, link text cannot be  hidden (e.g. with display: none or  aria-hidden=""true"").    To ensure all links can receive programmatic focus, avoid device-specific  Javascript events such as onmouseover(),  mouseover(), hover(), onmouseout(),  mouseout(). Replace these with device-independent events such  as onfocus(), focus(), onblur(), or  blur().    Do not modify the style of the links to suppress the change in style when  a link is the object of programmatic focus. Modifying link styles removes  the capability for sighted keyboard users to know where they are on the  page. Furthermore, ensure you are creating real links using the  a element with the href attribute.   The ARIA 1.1 Wiki Using aria-label for link purpose page provides the following example to describe the purpose of a link in HTML using the aria-label element: <h4>Neighborhood News</h4> <p>Seminole tax hike: Seminole city managers are proposing a 75% increase in property taxes for the coming fiscal year. <a href=""taxhike.html"" aria-label=""Read more about Seminole tax hike"">[Read more...]</a> </p> <p>Baby Mayor: Seminole voters elect the city's youngest mayor ever by voting in 3 year old Willy ""Dusty"" Williams in yesterday's mayoral election. <a href=""babymayor.html"" aria-label=""Read more about Seminole's new baby mayor"">[Read more...]</a> </p> Why it Matters   Inaccessible link elements pose barriers to accessibility, as they are a  fundamental component of a website.    Users who rely exclusively on a keyboard (and no mouse) to navigate a  webpage can only click on links that can receive programmatic focus. A  link that cannot receive programmatic focus is inaccessible to these  users.    Like sighted users, screen reader users need to know where a link is  pointing. Inner link text provides this information, though it won't get  used if a screen reader can't access it.    Keyboard users, including visually impaired screen reader users or people  who cannot use a mouse, can activate only the links and form elements that  can receive programmatic focus. Any events activated exclusively by other  types of focus, for example onmouseover events that depend on  the mouse hover focus, are inaccessible to keyboard users. Only links and  form elements receive keyboard focus by default. Modify elements that are  not links or form components to receive focus by adding  tabindex=""0"".   Rule Description  Link text and alternate text for images, when used as links, must be discernible by a screen reader, must not have a duplicate label, and must be focusable. The Algorithm (in simple terms) Ensures that every link has an accessible name. Resources Deque University Deque University Course Pages (subscription required) Visual focus indicatorLinksLabelsLink  Deque University  Contribute to axe-core on GitHub Other Resources You may also want to check out these other resources. Using aria-label to provide labels for objectsUsing aria-label to provide an invisible labelARIA7: Using aria-labelledby for link purposeF89: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible name for an image which is the only content in a linkG91: Providing link text that describes the purpose of a linkH30: Providing link text that describes the purpose of a link for anchor elements Refer to the complete list of axe 4.7 rules. Was this information helpful?       You have already given your feedback, thank you.. Your response was as follows:  Was this information helpful? Date/Time feedback was submitted:       Edit your response Customer Feeddback Yes  No  Improvement feedback (see below)::        Contact Us Request a quote or demo Accessibility statement Site map  Main Deque Website 2121 Cooperative Way, Suite 210, Herndon, VA 20171 1-703-225-0380 © Copyright 2013 - 2023 Deque Systems. All rights reserved. See the Terms of Use.     URL of this webpage is: https://dequeuniversity.com/rules/axe/4.7/link-name"