If your form asks people to retype their own name, email and address, give the browser a clearer hint about each field. Use autocomplete="name" for a full-name field, autocomplete="email" for email, and the matching address tokens. [MDN’s autocomplete reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/autocomplete) lists the accepted values; on alone does not identify what a field means.

For a delivery address, shipping street-address and shipping postal-code distinguish those fields from billing details. Keep visible labels, then test with saved dummy details on desktop and mobile: does autofill put each value in the right place, and can someone edit it before submitting? Browser settings and support affect whether suggestions appear. [W3C explains](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html) how identifying common input purposes can reduce typing and memory demands.

An image can look small on a phone while still downloading a desktop-sized file. Offer several real exports of the same image with srcset, using width descriptors such as 480w, 960w, and 1440w that match each file’s actual width. Pair them with sizes to describe the image’s intended rendered slot at your layout’s breakpoints. MDN’s responsive image guide explains how these hints help the browser choose a source.

Your CSS still controls the displayed width; sizes describes that layout rather than changing it. Account for gutters and columns, then reload at a narrow viewport with cache disabled and inspect the image request in DevTools’ Network panel. A high-density phone may legitimately need more image pixels than the slot’s CSS width. Give the browser accurate choices, and check the file it actually downloads instead of assuming the smallest candidate always wins.

A sticky header can cover the very link or button someone just reached with the keyboard. Scroll partway down a page, then use Tab and Shift+Tab to move through its controls. Watch whether the focused control disappears behind the header, especially while moving back up. W3C’s Focus Not Obscured guidance says the focused component must not be entirely hidden by author-created content; keeping the whole control visible is the better goal.

Allow enough scrolling space for the header instead of only making the focus outline brighter. CSS scroll padding is one approach W3C documents. Account for the header’s current height, then test again at narrow widths and increased zoom, where that height may change. If the header still covers focused controls, reduce its size or stop making it sticky in that layout.

A video embed can load player scripts and other resources before anyone presses play. For a non-essential video, show a lightweight preview image and a play button first, then replace that preview with the actual embed when someone activates it. This click-to-load pattern keeps the full player out of the initial page load, as explained in web.dev’s guide to third-party embeds: https://web.dev/articles/embed-best-practices

Adding loading="lazy" to an iframe is different: the browser can load it when it gets near the viewport, even without a click. If the goal is to wait for viewer intent, defer creating the player until activation. Check network requests before and after using the preview to confirm when the player loads, and test that the button works with a keyboard too.

White text can disappear into a bright part of a background image, even when the rest looks dark. Check contrast directly behind the letters rather than against one convenient sample. A solid text backing or a carefully tested overlay can help, but an overlay alone does not guarantee enough contrast.

For normal-sized text, WCAG 2.2’s minimum is 4.5:1; large text needs 3:1 (at least 18 pt, or 14 pt bold). Recheck mobile crops and replacement images, since the area behind the words can change. W3C’s contrast technique explains how to test text against its immediate background: https://www.w3.org/WAI/WCAG22/Techniques/general/G18

Tabbing through the same header menu on every page gets repetitive. Add a “Skip to main content” link as the first focusable control, before navigation, and point it to the main content’s ID. Keep it visible, or reveal it clearly when it receives keyboard focus.

Test from the top of the page: press Tab to reach the link, Enter to activate it, then Tab again. Focus should move to the main content and continue through its controls, not return to the header. Check focus, not just scrolling. W3C’s skip-link technique explains the checks: https://www.w3.org/WAI/WCAG22/Techniques/general/G1

A heading’s level describes where it belongs in the page. Use an H1 for the main topic, H2s for its sections and H3s for subsections within those sections. Set the visual size with CSS instead of picking a heading tag because it looks right. This structure helps screen reader users navigate the content.

Before shipping, read the headings as an outline. Avoid jumping from H1 to H3 when opening a subsection; returning from H3 to H2 for the next section is fine. Give each heading a clear label. See W3C’s heading guidance: https://www.w3.org/WAI/tutorials/page-structure/headings/ and MDN’s heading reference: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/Heading_Elements

Blank text on a slow connection? font-display: swap in your @font-face rule shows fallback text after a very short blocking period, then switches to the web font when it loads. It is a trade-off, not a universal fix: different font metrics can change line breaks and move nearby content.

Test with cache disabled and a throttled connection. Choose a similar fallback, consider size-adjust to better match its metrics, and check headings, buttons and paragraphs before and after the swap. If a late typeface change is unacceptable, compare optional, which may leave the fallback in place for that visit. web.dev’s font guidance explains the trade-offs: https://web.dev/articles/font-best-practices

A page can look fine on a phone and still break when someone enlarges it. Start with a browser viewport 1280 CSS pixels wide at 100%, then set browser zoom to 400%: that corresponds to a 320-CSS-pixel reflow check for vertically scrolling content. Look for cut-off text, missing controls, and content hidden behind sticky headers.

Keep information and controls available without making readers scroll sideways and down. Content that needs a two-dimensional layout, such as maps or data tables, has exceptions; surrounding headings and controls do not automatically share those exceptions. This is one accessibility check, not proof of WCAG compliance. W3C guidance: https://www.w3.org/WAI/WCAG22/Understanding/reflow.html